I’ve been a long-time developer of WordPress and Drupal. WordPress since version 2.6 and Drupal since version 6. Both platforms have their pros and cons; both platforms have their place in the CMS world. While I typically use WordPress for small to medium size websites that rely on limited, registered user interactions, I use Drupal for large websites, and systems that are not only CMS related.
Having used these systems for so many years, I wanted to contribute some of the code back to the communities. This past January, I decided to contribute a WordPress plugin to wordpress.org and an old Drupal module I created to drupal.org. I recently wrote about each of them.
What follows is a comparison of the two experiences and some observations about the processes.
WordPress Plugin
My plugin includes a widget and an API to find similar content. It is very similar to other plugins out there, but WordPress doesn’t care, as this gives users the ability to choose exactly what plugin is right for them.
Coding Standards
WordPress coding standards are a little more modern than Drupal’s. They’re also a little more relaxed on certain things. For example, comments are encouraged but the exact spacing, grammar, and distance from the code are not in consideration.
While there may be some automated tools to help with WordPress code standard checking, I didn’t use one and didn’t need to as it turns out. My plugin was approved with nothing coming back. With the exception of the README format, I wasn’t directed towards any by the community.
The Submittal Setup Process
Every plugin has to go through a review process. This means no new plugins get into the WordPress repository without being reviewed by WordPress reviewers. However any subsequent updates, such as version 1 to version 1.1 or 2.0, will not go through the review process.
After writing your plugin, you’ll need to create an SVN repo for your code. This is unfortunate as most of the web has standardized on git. You don’t actually put code on WordPress.org using SVN though—more on this later—when you log into WordPress, you can upload a zip file of your repo for review. Your WordPress plugin page will be available by direct link, but not visible to searches. This is good if you don’t want your plugin “approved” but still hosted on WordPress.
Submitting the Plugin
When you’re ready, you can submit your plugin for approval at https://wordpress.org/plugins/add/. When I submitted mine, I expected it to take a while as there were 36 plugins pending review.
WordPress is big on documentation, so there was a lot of checking to ensure the plugin page was well written and the README file was appropriately formatted. This is because a lot of the wordpress.org API and even the WordPress plugin page of your website has integration points that use this data.
Somewhat confusingly, the wordpress.org code will look in your README for a location to the most recent stable version, which can be a tag. Your tag must have a copy of this README but the version listed there will not be used in that regards. You also have to remember to update your {plugin-name}/{plugin-name}.php file’s version number each time you do an update. That’s potentially three places you have to keep track of each new version, and it’s a bit clumsy.
Putting the code onto WordPress is a matter of uploading a zip file as mentioned before. I fully expected something to come back and for it to take a while, but 1 1/2 days later I received a notification that my plugin was approved. At this point I was given an SVN repo on wordpress.org and am allowed to commit code there. The stable version is provided in my README, so everything works once I publish my plugin.
Drupal Module
My module came from an old Drupal 6 module I created back in 2012. I updated it and sent it to the Drupal.org community for approval. It is a module to allow callable keys from your theme for random bits of content not associated with any specific node.
Coding Standards
Drupal coding standards are about as strict as you can get. They offer numerous tools to review your coding, and if one space is missed, one line break is wrong, even if your comments are too far apart or missing a period or capital letter, they will come up in the review process and get dinged.
Unfortunately, many of Drupal’s coding standards are leftovers from the legacy days of green text on black monitors. You are restricted to 80 characters per line, you use spaces instead of tabs—and two spaces at that—and don’t get me started on the if/else line breaks. The positive is that you are left with very consistent code that, when completed properly, will be indistinguishable from any other developer’s code. It will be as if a machine generated it.
The Submittal Setup Process
Submitting a Drupal Module is different than WordPress in that once your module is approved, all future updates to that module do not go through the review process, and assuming your module is large enough (120 lines of code at the time of this post), your account is approved to submit any other modules without going through a review process. This may sound more relaxed than WordPress’s submittal process, but there’s a lot more to the process than WordPress… a lot more.
Drupal has very high standards—perhaps too high—for what gets submitted into drupal.org. Unlike WordPress, Drupal does not allow modules with duplicate functionality. They encourage you to collaborate with the creators of the modules that have similar functionality. While I believe encouraging collaboration is a good thing, it also limits the options that users have when looking for functionality.
Drupal’s submittal process is a bit more intuitive than WordPress. First, you create your own git repo on drupal.org, and you can submit any code you want and have as many modules (called projects) as you want. They are all listed as sandbox projects and come with warnings while not being available to download via drush or come up in searches.
With each “project” on drupal.org you get an issues queue, bug queue, and project page. You can use this as a place to host indefinitely, but it comes with warnings that this is sandbox/untested code. You’re unlikely to get many people using sandbox code on production sites so it’s to everyone’s benefit that you submit it for approval.
When/if you want your sandbox code to be submitted for approval, you open a ticket under the “Drupal.org Project applications” project queue.
Submitting the Plugin
Submitting the project is as simple as opening a ticket in the “Drupal.org Project applications” queue with a description, link to your project page, and a git pull request.
Unlike WordPress where the code goes directly to a WordPress admin for review, the Drupal project is reviewed by the community before being reviewed by a “git administrator” (someone who has the authority to approve your project and give you approval process for future modules). When I first saw the issues queue I was a little bit concerned. There were modules that had been in queue without updates for 6 months. There were about 100 in queue.
What I discovered was that the community was more than willing to be helpful, but also that the standards are much higher for Drupal. Immediately I received great feedback on how to build out my module in a more “Drupal” way. I learned about many APIs I never knew about and it only increased my Drupal knowledge. Everything was cordial and professional. For reference, here’s a link to the entire feedback ticket from beginning to end.
The difficult part was that this was all subjective. For example, one reviewer suggested I use a theming system rather than embed HTML in the module. This was good advice, until a more experienced drupalist came along and said this was overkill and recommended a few functions that took care of this for me. This meant that a fair amount of work I did to make my module better was removed and never used. Similarly, there were conflicting suggestions on how to best use the database API and even some bug reports that were more feature requests than actual issues.
Because there is a large backlog of issues, weeks were going by and only a few updates were coming through. That’s when I decided to use the PAReview Bonus. This is allows you to get on the “short list” for reviews and speed up the process. To receive this you must perform your own three reviews on other modules. This is time consuming but also helps others as well as grow your own Drupal expertise. The catch is that once you are reviewed, if it comes back with more issues you lose your review bonus and you can only do the PAReview process one more time.
The biggest hurdle I faced was explaining why my module should be approved when it had some similarities to other modules. I faced this with many reviewers and feared for a while that it wasn’t going to get approved.
After 34 days, two PARreview bonuses, performing six reviews, numerous rewrites including 29 git commits, and spending an estimated 5x as much time rewriting my module as initially writing it, my module was approved and my account updated to allow creation of full projects.
Comparing the two processes
WordPress requires you to go through the approval process every time you create a plugin, however the quick review process is fairly painless. Knowing that every module is reviewed gives me confidence that no sneaky code is submitted to wordpress.org, where as Drupal only reviews the first one. Confidence isn’t 100% however due to the fact that you can add any code you want after it’s been approved.
Although Drupal allows any new modules to be submitted as full projects after your initial module, you have such an arduous process to go through I wonder if anyone would bother going through that for the opportunity to do something nefarious.
Duplication isn’t a bad thing, and I think this is where WordPress shines. Users have many options and developers can “compete”.
The Drupal process is grueling, it’s obvious that Drupal is more fitted for enterprises than is WordPress. The code quality on Drupal is in a different league than WordPress. The downside is that the community is so far behind in queues, I wonder if this is actually the achilles heal of Drupal. As it is, Drupal 8 has been in development for years and is not yet released. In reality it should have been production ready years ago.
WordPress is clearly a large niche and thriving. Besides moving to git and making the plugin repo available from the start, there aren’t many recommendations to improve the process.
Drupal is enterprise ready, but the slowness of development may lead to it’s eventual obsolescence. That is more hyperbole than a prediction, but it is concerning. Add that to the ancient coding standards, prohibition of competing modules, and difficult-to-understand documentation on the process itself (something I didn’t even touch on) and Drupal has some issues to work out.
Where WordPress has a thriving ecosystem and simplified process to its benefit, Drupal has a great community of high-quality developers to contrast its painful process.
Anyone wishing to get more deeply involved in either of these platforms should consider contributing back. It made me a better developer in both platforms.