Over the past 48 hours I spent time between numerous meetings writing another WordPress Plugin, a WooCommerce Report Modifier that we need for our Store Locator Plus store.   I’ve not written a “new from scratch” plugin that was not related to the Store Locator Plus system for quite some time.    It gave me a new perspective on the entire WordPress plugin coding adventure.

Open Source Is Great

One of the biggest things I re-affirmed about coding plugins for WordPress is that I LOVE open source.   As a developer this love for open source has NOTHING to do with price.    I don’t love it because the prices of open source are often lower than “regular” software; in face I think that is on of the biggest problems with open source is the stigma … or general idea that users THINK… the products should be free or darn-near it.    What I love is that I can both FIX things and SEE HOW THEY WORK.     The fixing and the seeing were both key elements in being able to create a plugin that did what I needed in just over a day versus weeks or months waiting for the people at WooCommerce to do something for me.

Starting A  Plugin Is Easy

I also realized that despite my difficulties in writing my first plugin years ago, the entire process is actually fairly easy and does not to be as complicated as many people make it out to be – even when using well defined classes in place of procedural code (please, please , please do NOT write your plugins using “inline” or procedural code).   For a private plugin you don’t even need to create a readme.txt file.   Create a directory in the plugins folder of WordPress, name a file the same thing as the directory with a .php extension and add a few lines of code.

Since I could read the original source of WooCommerce I knew exactly which hook I needed to invoke and whipped up the first function in a few minutes.

Hooks and Filters Are Paramount

Speaking of hooks, learn about them and USE THEM.   Implementing WordPress hooks and filters is critical to properly augmenting anything in WordPress.   Since most well-crafted plugins, including my Store Locator Plus base plugin and add on packs,  and themes also sprinkle hooks liberally throughout their code.    In my case I could find a WooCommerce hook that allowed me to modify the product report without messing with the original code from WooCommerce.      Since  WooCommerce was open source I could read the report-generating code and find the exact hook I needed within minutes.   Very nice.

Plugins and Plugin Components Are Not Created Equal

In the bad category, I was reminded almost immediately that not all plugins or plugin modules are created equal.  WooCommerce is a beast that has lots of code with lots of modules written by different authors and includes obsolete elements and dead-ends; much like Store Locator Plus.   This means that outdated practices are built into the code as are some algorithms that were created during the “hey, I’m learning WordPress coding” phase of plugin development.   Typically that means little-or-no ability to modify that piece of code and change how it works because there are NO hooks or filters to tap into.   Boo!

Inconsistent Plugin Architecture = More Plugins

The lack of hooks and filters is true with MANY of the WooCommerce native elements like the Customer List report or Orders search interface.     That meant recreating an exact copy the Customer List I wanted to modify and adding in hooks, filters, and feature to my “Extended Customer List” report.   That means I have a plugin that shares 70% of the Customer List coding from the WooCommerce product which in turn means my live site now has over 100 lines of code installed that should never have been necessary.    Multiply that by the 48 plugins I need to run my site properly.

More plugins = more bloat = more maintenance and security issues.

The lack of a true coding standard for plugin developers , or maybe it is a training issue, causes a LOT of repeat work in the WordPress plugin ecosystem.

Documentation Is Inconsistent

As you delve deeper into the WordPress plugin coding world you soon realize not all documentation is created equal.   Some WordPress functions are well documented internally and externally with full phpDoc comments a presence on the “old and outdated” Codex and on the “new and improved” WordPress Code Reference.  Many functions, however are incomplete at best with no examples and little-or-no community knowledge on the WordPress Code Reference site.   Often you end up jumping back to the older Codex site.    In some cases, rather infrequently with WordPress Core, you find functions or classes that are not even listed or documented on EITHER site or if they do appear through the coding “fu” on the WCR they have zero useful information thanks to the lack of proper phpDocs.    In the end you read code and trace execution (thank you again Open Source).

Plugins are exactly like that but worse.  Many, including the super-popular WooCommerce plugin, have sparse-if-any online documentation on CODING for the product.   Almost NONE have any easy way to ferret out those hooks and filters.  You always end up spending time tracing code execution to find those “nuggets of knowledge”.

Contributing Code Is Futile

Well, mostly futile.    If you code plugins or themes for long enough you will find a bug in SOMEONE ELSE’S CODE.    Most organizations have a way to report the bug and contribute your patches to fix the bug back to them so they can improve their products.   Most organizations take their sweet time getting around to it.  Often your patches never get put in place.

My personal experiences: Store Locator Plus was born from over 100 patches to a plugin that were submitted to the author but never integrated despite a few-dozen emails to the author.  In fact the response was “I’m on haitus”.  For over a YEAR.      My original fixes to dbDelta, admittedly a critical component of WordPress that warrants extra care-and-attention, took OVER TWO YEARS to finally make it into core.   Patches to bbPress and over a dozen other lesser-known plugins were never even looked at.   WooCommerce?  We’ll wait and see.

It would sure be nice if plugins, especially those hosted on the WordPress Plugin Directory, had a formal and consistent patch submission system.   Even better, a community “vote” to allow a “master of all plugins” to accept the patches on behalf of a MIA plugin author.   I’d check off the “allow WordPress Plugin Team to integrate patches” on my repo.

Internal Use Only Components Are Bad

WP_List_Table.    It has been clearly marked as “for internal use only”.    Yet nearly any significant plugin out there is running a class that extends it.     Which is fine except you are NOT SUPPOSED TO DO THAT according to WordPress.  You are supposed to clone the entire class (more duplicate code – see above) and build off of that.

Yes, I get why that is, but that kills one of the key concepts that makes WordPress great – the ability to extend and augment with hooks and filters not copies-and-hacks.

PHP Versions Are  A Pain

The WordPress Plugin Team announced, just yesterday, that you should run PHP 7 lint against your code.  VVV runs PHP 5.5.  WordPress itself says PHP 5.2 is fine.   Most hosting companies are running PHP 5.5 or lower.

When you code using a version of PHP newer than 5.2, as I do on my VVV box, you have a high risk of creating a plugin that passes all testing but as soon as someone runs it on PHP 5.4 it crashes.  Hard.

<!– start sidebar –>
WordPress must set a baseline standard for PHP.  If it is 5.2 that’s fine.   You cannot have your plugin team recommending PHP7, your core team recommending a development environment that defaults to 5.5, and  tell hosting companies PHP 5.2/3/4 are fine.
    
IMO WordPress needs to set the standard to PHP5.6 which they ‘recommend’ but do not require.   When 28% of the Internet is using your technology you can dictate what version of PHP is running nearly everywhere.
<!– end sidebar–>

Overall It Is A Good System

In general the system WordPress has  in place for plugin development is pretty darn good.  I think it is one of the biggest reasons WordPress has gained market share and has so many plugins available.     The system needs work.  The code needs work.    But in reality, what big world-changing products don’t need to evolve on a continual basis.

At the end of the day I could get what I wanted to accomplish done in just over a day.    I have my new report of customers that I can export to a CSV file, sort, hide columns and do all of the things I needed to get a project done.  (BTW, I’ve posted my WooCommerce Report Modifier on my store in case anyone else wants to check it out.)

Open source made that possible.  At the end of the day that is the BEST argument for why I think Open Source is the best option for releasing software.   Now if we can just convince the consumers that it is worth MORE TO THEM than closed-source system.   Open Source software should be priced HIGHER than other solutions not “Nearly Free”.