During a ‘workation’ (vacation while working) with my family in Colombia in late December 2016, I was brainstorming on how best to use all the knowledge acquired while developing the Drupal Console . Drupal Console is a CLI tool that can be used to generate boilerplate code, interact with, and debug Drupal. Drupal Console was inspired by the Symfony Console’s use of code generation to streamline best practices in symfony development.
After some research, I decided to narrow down on platforms with a vast user base like WordPress and Laravel initially, then target other platforms later.
My Journey into WordPress
While the easier target would have been to start with Laravel, because the framework uses Symfony components as the foundation, it was a much more interesting challenge to test if it would be possible to integrate Symfony components into a non-Symfony platform. So, I spent a couple of weeks trying to develop proof of concept and …voilà! Project wp-console was born!
Why not just use wp-cli?
That question brings back memories of the same scenario in the Drupal community: “Why Drupal Console? We already have Drush?”
The answer is not quite simple, so let me elaborate.
When I started playing around with the idea of the WordPress console, wp-cli was not the official WordPress CLI. In fact, the maintainer wrote several blog posts trying to find a viable solution for the project’s maintenance (like this one ). My understanding is that it became the official CLI in mid-January 2017, and officially implemented sometime in March 2017.
So, did I try the wp-cli? The simple answer is yes, but the truth is I did much more than try. I must admit that it works well, different approach but works like a charm. The problem I came across was with integration, for the long-term feasibility of the project and to speed up development, I needed to reuse as much code and logic that was already implemented in the Drupal Console and Symfony Console.
I even tried using pipelines to concatenate commands like you do in Unix, but quickly discovered that what I really needed was a deeper integration. We connected with the wp-cli maintainer on the issue but he seemed more concerned that the project may have been duplicating efforts, rather than see that this was a value add for any member in the community with an interest in Symfony Components. You can find that discussion here .
Back To The Project
After exhaustive tests I decided to continue with the wp-console project, reusing and maximizing on code and the extensive knowledgebase acquired while developing the Drupal Console. After all, the main point was to transfer the wealth of knowledge acquired on another open source platform and make it available to a new community. That’s the spirit of the broader open source tech community, sharing and applying knowledge to help users universally.
We want to make it clear, that the point of the wp-console is not to replace the wp-cli, but rather share the knowledge and benefits we have picked up solving similar problems on other platforms. We have proof that developers improve their skills and code becomes cleaner and standardized from this approach.
That’s why I love Open Source, there is no room for dictatorial solutions and anyone can have a different approach to solving the same problem. Challenging the status quo is the mantra, and without that, we lose innovation and by extension the core of Open Source community.
So what does wp-console do that wp-cli doesn’t?
Like I mentioned before, my intention is not to replace wp-cli nor is it about advancing features that the wp-cli doesn’t have. The goal, as a PHP/Symfony/Drupal developer, is to learn how to be a WordPress user and coder. The best contribution I can make to the community is to learn from the inside out, and along the way contribute in the form of new commands and features in the wp-console.
Here’s a link to the latest WordPress Console release from a few days ago
We divided the commands into three distinct groups; Debugging, Administrative and Generators.
Debug commands
The debug commands provide insights on the processes running in an installation. By observing the processes, you develop much needed clarity on how the entire engine runs. With time, these commands help you master the inner workings of WordPress.
Here’s the current list of debug commands:
| debug:chain (dc) *** | List available chain files |
| debug:container (dco) | Displays current services for an application |
| debug:multisite (dm) | List all sites in network available to a specific user |
| debug:plugin (dp) | Display current plugins available for application |
| debug:roles (dusr) | Displays current roles for the application |
| debug:shortcode (ds) | Displays current shortcodes in your WordPress application |
| debug:theme (dt) | Display current themes available for application |
*** Chain is concept brought from the Drupal Console, is a command that helps you concatenate commands creating a chain reaction.
Administrative commands
As developers, we get caught in the habit of creating shortcuts. Whether you don’t like using the mouse/trackpad, or it’s just cooler to use keyboard shortcuts, the admin commands make quick work of routine tasks. As part of the automation, we included some commands that let you install WordPress (single or multi-site), enable plugins, and or basically interact with core for routine tasks without using the admin interface.
The admin commands originated from a need to test the code created from the generators using the wp-console. They helped us resolve conflicts, and basically isolate code from the generators so we could identify the source of any failures.
Current list of Administrative commands:
| multisite:install (mi) | Install a WordPress multisite network |
| plugin:activate (pa) | Activate plugins or plugin in the application |
| plugin:deactivate (pld,pd) | Deactivate plugins or plugin in the application |
| role:delete (rd) | Delete roles for the application |
| role:new (rn) | Create roles for the application |
| theme:activate (ta) | Activate theme in the application |
| cache:flush (cf) | Flush the WordPress object cache |
| create:roles (crr) | Create dummy roles for your WordPress application |
| create:users (cru) | Create dummy users for your WordPress application |
Generator commands
Finally, the generators, the root and source of inspiration to create the wp-console.
The mainstream opposition on the WordPress platform is that it’s not OOP. So we decided to go as OOP as possible, and we didn’t have to invent anything, there were plenty of examples to work from. We believe that the generator commands will make a lot of people very happy.
Current list of generators commands:
| generate:command (gc) | Generate commands for the console |
| generate:cron:job:event (gcje) | Generate a schedule cron job event |
| generate:menu (gm) | Generate a menu |
| generate:metabox (gmb,gm) | Generate a metabox |
| generate:plugin (gpl,gp) | Generate a plugin |
| generate:post:type (gpt) | Generate a custom post type |
| generate:quicktag (gqt) | Generate a quicktag |
| generate:register:script (grsp) | Generate a register script on your theme or plugin |
| generate:register:style (grst) | Generate a register style on your theme or plugin |
| generate:shortcode (gs) | Generate a shortcode |
| generate:sidebar (gsb) | Generate a sidebar |
| generate:taxonomy (gta) | Generate a custom taxonomy |
| generate:theme (gth) | Generate a theme |
| generate:toolbar (gtb) | Generate a toolbar |
| generate:user:contact:methods (gucm) | Generate a User contact methods |
| generate:widget (gwd) | Generate a widget |
What’s next?
As you can probably make out from the stats, so far we have more commands than we do downloads. But that’s not the priority right now, the current maintainers also happen to be the main users of the tool. It’s making quick work of our learning processes, not to mention the time savings from current commands.
It’s certainly surprising that people have already been trying it out, especially considering that this is the first time we’re promoting the wp-console. We’re hoping that soon, more people will discover wp-console as a complementary tool to optimize their journey into WordPress.
Another adventure in the works…?
A few months ago, while on another ‘workation’ in South America (Chile, Argentina, Colombia) another idea came to me. I’d like to learn NodeJS and React, and with all this knowledge from Symfony + Drupal + WordPress … the idea finally came. Create an Online Generation platform to allow people to generate code for Drupal, WordPress and so on. I love the command line, but I must recognize that is not for everyone and it’s hard to beat a visual online solution.
With this new platform, Freelancers and Agencies could jump one platform to another to create medium and intermediate level code to use in a routine tasks and projects, without the need of be a senior developer, so you can be an expert in your niche platform but can dip your feet a little bit in other platform avoiding all the challenges that come with that.
That is how MagicGen were born, the platform is functional and we plan to launch at early January 2018, check back for more information about MagicGen.