> This is a set of notes and remarks rather than anything comprehensive or systematic. The main point is learning from the fact that there is a development lifecycle in terms of consuming software products, and make better adoption decisions through a set of heuristics. By development, we need of course to expand this to encompass what is generally known as design, development, devops, sysops and ongoing maintenance. The key to reducing risk in WordPress development is to understand the lifecycle.
By WordPress development, we can include all of the following: - Selecting a new theme or theme framework - Making a choice between plugins - Deciding at what point custom development is needed - Themes - Plugins - Hosting decisions - Security issues - hosting and operating system configuration - security plugins - secure plugins Obviously the term development is being used in its very generic sense. Still, we can separate it from marketing and from content, which are the two other legs of the WordPress three-legged stool we use as a platform for publishing.
By lifecycle we understand that there is birth, growth, decline, and death. Development itself can be understood as the building up of something. We usually understand development as a period of time for building and a period of time for maintaining. This is obviously an architectural metaphor. However, it is really not useful or apt when looking at software development. Why is that? - Software can be refactored - Software can be loosely coupled or integrated with other software - Software versions are released over time, which tends to include more features - Software can become obsolete when it is rendered incompatible with other systems, software, or coding practices - Software can become unusable when new versions introduce new problems - Software can become a greater risk to use when it is abandoned by its original developers Finally there are financial considerations such as when free versions of critical plugins or themes are no longer available, forcing all users to pay or to spend considerable time migrating to others.
All of this comes down to the basic concept of risk management. Risk is danger to an organization, in terms of the likelihood and severity of present or future costs. While deciding which plugin to use for a contact form seems fairly innocent (and generally it is), things like multilingual, ecommerce, or elearning systems require a much greater investment in installation, configuration and maintenance, with much higher switching costs.
Lifecycle Heuristics for WordPress Development
Because a lifecycle deals with unknowns in the future, it is never perfect and there is always risk. However, there are certain heuristics -- rules of thumb -- that can be used to help mitigate and minimize risk. The following are an assortment of heuristics that, while not always accurate, do help minimize risk.
WordPress Theme and Theme Framework Heuristics
WordPress Plugin Heuristics
Plugins are a boon and a bane in WordPress. One needs many of them (some for a single tweak here or there to WordPress Core), they constantly age and require updates, are abandoned, conflict with one another and with new versions of WordPress Core. Here are a few heuristics that might help with risk management: - Older, massively popular plugins are in general a better bet (even if abandoned), because the large userbase will come up with fixes when problems arise. - There is one huge caveat to this, and that is monolithic plugins that continue to add features. This usually means ongoing problems and the introduction of new bugs. Yoast is the biggest poster child for a very popular plugin that breaks continually over the years. - Simpler plugins rather than more complex (best-of-breed vs. all-in-one) - Plugins that operate with shortcodes rather than wysiwyg drag-and-drop interfaces - Plugins whose configuration is stored properly in custom tables or extending custom posts and metadata - Examples include Redirection and ALO EasyMail Newsletter - Using custom posts, metadata and shortcodes makes the functionality more abstracted and does not require the front-end to use parameters such as ?variable=value - Plugins which, if removed, either degrade gracefully in terms of the content or data left behind, and/or are easy to work with using regex search-and-replace (e.g., unique shortcodes) - Plugins which do not have a pro (paid) version - Plugins which have a core part that is free and additional plugins that are paid are a better source of stability and risk minimization, as the core part needs to be maintained in order for the paid plugins to remain viable - Plugins with active development (even if sporadic) - That said, some of the most important plugins I rely on have not been updated for years (occasionally requiring I do a little hacking) - Plugins made by a supergenius who uses the plugin themselves (note the supergenius requirement, along with dogfooding) - Plugins around which an ecosystem has formed to extend and enhance - Plugins that use or can interact with the latest security standards and configurations - Plugins where support on WordPress.org is available (rather than requiring using an offsite system for help and support) - Ratio of 5 stars to 1 star reviews (should be around 10:1, whereas when it gets around 4:1 this signals poor quality) - Retention rate (Active installs / All time downloads) - Note that over time this ratio gets smaller naturally, so for very old plugins this doesn't work, but for 1-3 year old plugins it is a good indicator In some cases a set of plugins need to be replaced because of a need (or opportunity) for speed and/or security and/or functionality. For example, Postman SMTP allows for OAuth2, a new security standard. But this has knock on effects in that some Newsletter plugins don't support this, so it would require migrating to a new newsletter plugin. So a final heuristic is keeping up with good coding practices (without simply embracing every new (not necessarily good) idea.