Updated 20-Sep-2023
> 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.
WordPress Development
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.
Development Lifecycle
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.
Risk Management
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
Most themes are not maintained for long. The average half-life of a theme (the amount of time by which the probability of it being abandoned is 50%) is most likely immediately after the first version is released. Many try to minimize this risk by paying for a theme, but the same is true of paid themes. Theme frameworks have a much longer lifecycle, as they are made for designers and developers who will pay maintenance fees in order to get some stability and continuity. Regular subscription fees are a motivator for theme frameworks to incrementally improve and maintain compatibility with the every changing panoply of plugins as well as WordPress core (which has major releases three times per year). However, yearly maintenance fees do not remove all risk, and the lack of yearly maintenance fees are not a sign of impending abandonment. Ultimately, one should consider any theme framework from the perspective of the following question: > If this framework is abandoned tomorrow, will it meet my needs and is it worth whatever maintenance I need to do myself, for the next two years or more? Since a framework will eventually be replaced (i.e., it has a lifespan, and is not immortal), risk management consists of a clear-eyed assessment of the functionality vs. maintenance costs (in time and money) as well as opportunity cost for going with a different system. Ultimately, one should build one's own theme and child themes. The risk of course is building something that does not meet present or future needs, and/or is too time-consuming to maintain. Several years working with other themes and theme frameworks for a given website or set of websites are the ideal approach to understanding the design space. Indeed, working with an incomplete or aging theme framework can be extremely informative in terms of producing a set of requirements for a theme and child themes that will provide excellent value for years to come. Some of the following may help flesh out the requirements from a functionality perspective: - No javascript or gracefully degrades without javascript - Support for screen reader CSS - Responsive design with target viewport dimensions - Plays nicely with all current plugins, especially those with important functionality, e.g., - WooCommerce - ALO EasyMail Newsletter - Can potentially replace one or more plugins where that makes the most sense, e.g., - Custom search and 404 pages - Remove author pages - Custom templates that display lists of all posts organized by category - Single CSS file
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.