Sometimes you may wish to run Artisan commands from your admin dashboard /application, without using the command line. Perhaps you don’t have access to the command line (in which case perhaps it’s time to switch hosting!), or more likely perhaps you want to manually run tasks right from your application. Here’s a quick guide to how you might set that up.
Running a command
To run a command programmatically, you simply do this:
The first argument is the name of the command, the second your options, which I’m going to ignore for brevity.
It’s probably more useful if you can get a hold of the command’s output; you can do this by passing a third argument, which should be a class that implements Symfony\Component\Console\Output\OutputInterface. Perhaps the most useful of these classes is StreamOutput. So, for example, you can write the output to a file:
I needed the means to add a quote to a website I was working on — a simple task, which could be acheieved by simply adding a text or HTML block. However this can be taken a step further by implementing a simple block type specifically for quotes, with the markup generated for you.
To mark up a quote semantically, we’ll want a blockquote for the content and a cite for the source (or author), so the HTML needs to look something like this:
<p>It is the mark of an educated mind to be able to entertain a thought without accepting it.</p>
…which will give us something a little like this:
In this simple tutorial, I’m going to show how Concrete5 can be extended to integrate a third-party JQuery plugin to enhance an existing module, and then how this can be encapsulated in a package. I’m going to allow the slideshow module to display images using the clean & lightweight Craftyslide plugin, pictured below.
Concrete5 comes shipped with simple slideshow functionality in the form of a block called, imaginatively enough, slideshow. As this is part of the core you can find it in /concrete/blocks/slideshow. It’s in the concrete directory to keep it separate from custom code. And some custom code is what we’re going to produce — to override the output of that block, and then to encapsulate this into a package.
In the first part, I looked at creating the database schema for a simple Drupal module designed to allow you to associate colours with taxonomy terms. In this second part, I’ll look at the administration aspects of the module. In essence, what we need to do is as follows:
Since colour-coding may only be appropriate to certain vocabularies (e.g. categories) and not others (tags, perhaps). We need to provide the user with the option to specify which vocabularies are applicable.
The user needs to be able to specify a colour when adding or editing a term, where appropriate.
We need to provide a mechanism which allows the colour associated with a term to be stored, retrieved, and to be displayed.