In October 1972 the new Bay Area Rapid Transit (BART) system experienced what could have been a disastrous failure. An automated sensor that detected the train approaching the terminus station was supposed to slow the train down in preparation for the stop, however it reversed and sped up the train to 70MPH. The operator couldn’t prevent the train from running out of elevated track, resulting in the train falling onto the street below. Good thing this accident was part of a series of test runs with only a few individuals involved. Engineers fixed this and other problems in what was then a futuristic designed automated system that has since served the public well for nearly 40 years.
Not everything is built to last. Often times quality gives way to budget shortfalls or pressures to produce rapidly. Lackluster quality can in the worst case scenario lead to accidents and even death. Accidents cannot always be avoided, but they can often be prevented by planning well, providing detailed product specifications, building carefully, testing rigorously, and maintaining vigorously. With respect to websites, the areas one generally needs to protect are: image, operations, and valuable customer data. It makes sense to take as many measures as possible to prevent one’s Internet operations from ever becoming a train wreck!
We recently discussed the topics of WordPress security and performance as they relate to Plugins. These topics aren’t necessarily the driving force behind custom plugin development, but they most certainly should be major considerations throughout the product lifecycle as internal and external forces develop. Changes that occur over time include server software developments, web browser developments, database buildup, WordPress core developments, theme and plugin developments, and JavaScript library developments.
Today’s plugin quality topic is interoperability—how well various Plugins work together via the core framework of WordPress over time. Software in general becomes outdated rather quickly. More so with open-source community powered software. Depending on the scope of a project, the intended product lifecycle is usually no more than around 5 years. The higher quality the application, the better chance it will have of satisfying expectations and the longer it will last.
In terms of out of the box WordPress Plugins, in particular free and unsupported products, we see all sorts of bugs, performance, security and interoperability issues. A recent statistic was released noting that half of the Plugins in the WordPress repository aren’t compatible with WordPress 3.0 or above, and that 85% of the Plugins were throwing various PHP notices or warnings. To combat these community plugin quality issues, per a recent policy announcement from WordPress maintainers, Plugins will automatically expire once their last updated date reaches 2 years old.
Most Plugins simply aren’t built to last more than a year or two. Those short term products do serve a purpose—providing useful functionality at a nominal cost to solve an immediate need, often without much planning, specifications, building, and testing. While the benefits of free apps like WordPress Plugins are clear, it is also clear that free and cheap comes with a bigger price—especially when evaluated from the perspective of time.
So here’s how one builds WordPress Plugins to last, despite an ever evolving core:
- Plan well: The more you consider upfront, the more you will be prepared for near future business changes. Custom software should not just fill a current niche but also handle growth throughout the near future as well.
- Design well: Most training can be avoided simply by having a sensible and intuitive interface catered to the individual stakeholders. Since the framework is WordPress, make the UI follow common WordPress routines.
- Take security seriously: Security holes can lead to intrusions that result in the stealing or corruption of your valuable data.
- Take performance seriously: Fast performing applications result in happier staff, happier customers, and of course improved efficiency to make management happier as well.
- Take interoperability seriously: Plugins must work with the latest version of WordPress core and must not break current versions of other Plugins. If there are problems, find a better plugin, or if the functionality is essential and nothing appropriate exists then have one custom built.
- Prepare for disasters: Maintain readily available backups. Ensure your hosting provider has appropriate measures in place and can get you back online in the event of major faults.
- Build to the core: Rely on the documented and supported core API. That is designed to have legacy support for a reasonable period of time, and developments upstream can easily be traced.
- No hacking: Never rely on combining Plugins together for a single purpose. Never alter existing Plugins because that will break future community contributions and security fixes to that plugin. If there is an existing plugin that meets your needs and doesn’t intertwine with functionality you are having built, it’s okay to keep the pre-built plugin running separately.
- Keep it in the family: Be very careful piecing together outside resources or third party code. Vendors can point fingers at one another, fail to deliver as expected, and cause communication and scheduling difficulties. It’s best to have a single provider be responsible for a standalone product such as a complete WordPress plugin or theme.
Thank you for taking the time to read this post. Note that we really appreciate feedback about what we’ve written as well as what topics you’d like us to discuss in future posts so please do let us know.
beAutomated 