Blog of Raivo Laanemets

Stories about web development, freelancing and personal computers.

WordPress issues


I do custom application development with JavaScript and/or Prolog. I have 14 years of experience in developing custom solutions. I have an efficient workflow (covers issue tracking, code versioning, testing and deployment) for dealing with custom applications and I enjoy it.

However, I occasionally get requests to do WordPress projects. I have done simpler sites with it but I feel that I lack specialization and experience to provide more complex sites. At some level of complexity the WordPress itself starts to feel inadequate.

No blogs

I have had only a single WordPress project that could be classified as a blog. It was a part of much larger project. I had to create a custom theme from scratch. It was straightforward and thus my initial impressions about WordPress were good.

However, it did not take long before we had a conflict between the caching plugin and a "display random X" plugin. The caching plugin was just saving the first output of the "display random X" and kept displaying it without any randomness.

Since then my WordPress projects have gone gradually more complex and I have faced more and more issues with them. Most of them are due to plugin-based development workflow (although it is probably the reason why WordPress is so popular).

Plugins/theme compatibility

The WordPress plugin directory only includes compatibility data on plugin versions vs WordPress versions. There is no data on plugin-theme compatibility and plugin-plugin compatibility. It is unlikely that such data is ever provided for all themes and plugins because of the enormous amount of combinations between them. Hosted WordPress at wordpress.com does not even allow plugins while the Enterprise version only allows a limited set.

In the worst case, the amount of work to find a working set of plugins grows exponentially with the number of plugins you have already found. If you already have n plugins but you need a plugin X which provides some awesome feature that client needs/wants and it's not compatible with none of previously found plugins, then all your previous work spent on those n plugins is wasted. If those plugins were non-free then money spent on them is also wasted.

Unless you already know the suitable set of plugins it's quite risky to provide useful estimations for a WordPress-based project under these conditions. This requires experienced developer who has done a number of projects and has learned the internals of many plugins.

Based on my experience, the riskiest plugins are:

  • Multilanguage plugins
  • Caching plugins (for site performance)
  • E-commerce plugins (these have massive amounts of code)

These have caused most incompatibilities for my projects so far. Both multilanguage plugins and caching plugins potentially affect every other installed plugin.

Security issues

Not all plugin developers are professional programmers. There are no formal checks or code reviews before a plugin or a theme gets accepted into the plugin or theme registry.

Plugins by inexperienced developers have led to high number of security issues. Detecting security issues requires complex monitoring infrastructure which is not provided by most hosting providers. At the same time there are automatic bots scanning WordPress sites for vulnerabilities and automatically exploiting them. Hacked sites are usually used for sending spam mails and embedding links.

Vulnerabilities in plugin code can only be detected (before they reach into a vulnerability registry such as CVE) by manual inspection of the code. This requires extensive knowledge of writing secure PHP code.

PHP also allows to execute any PHP file that can be accessed by an URL. This means that all security checks built into the main index.php file can be trivially bypassed.

Manual development workflow

Under a workflow I mean the process that allows to apply modifications, test them out, record them and reapply on the production system. There are 3 different types of modifications in a plugin-based development:

  1. Installing plugins and themes;
  2. Updating plugin/theme options;
  3. Modifying the code of existing plugins and themes.

Code versioning tools like Git can easily only handle the 3rd type of modifications. 1st and 2nd type of modifications must be documented in depth and later applied manually which can be incredibly dull and time consuming.

I have seen people doing development directly on the live site. For personal blogs it might be fine. But on a e-commerce site it can cause arbitrary errors in transaction processing: missing orders, missing payments, system not getting payment notifications, etc. In the worst case it makes the whole system unusable if errors are introduced in the code or files get accidentally deleted. This also makes it harder to upgrade plugins/theme or the WordPress core as any upgrades can cause new incompatibilities.

My custom projects usually lack modifications of the 1st and 2nd type. This enables a lean workflow where I can move changes from development to test and production with a single command, without any manual work. All changes are recorded in a Git repository. The database changes are explicit and reversible. This eliminates human errors from deployment and when things go wrong, old version of the application/site can be easily brough back. Individual changes that caused the error can be isolated, quickly debugged and fixed.

Development environment

For a PHP development system on your computer you are likely going to need:

  • Web server (NGinx or Apache),
  • PHP setup (PHP5-FPM, mod_php), PHP plugins like GD
  • Mail server

On top of this you need a MySQL database for WordPress. All of this has to be correctly configured as well. This is solvable and is only a minor inconvenience compared to issues above.

Some time ago I even created a VirtualBox machine to encapsulate the environment. This way I was able to start the environment only for the time when I was developing the PHP code and not have it use computer resources all the time.

The complexity of this environment is beyond that of a purely frontend project (needs only a static file serving) or a NodeJS/Swi-Prolog project where the project environment consists of a single process started with a single command.

Conclusions

  • WordPress development requires lots of experience with existing plugins.
  • Time estimates are hard to provide for complex applications.
  • Securing WordPress sites takes extra work.
  • Developing on your own computer is inconvenient.
  • Deployment requires tedious manual work.
  • WordPress projects should be blogs or simple websites.

Comments

No comments have been added so far.

Email is not displayed anywhere.
URLs (max 3) starting with http:// or https:// can be used. Use @Name to mention someone.