Updates: WordPress Maintenance – Part 4

Caution: Pressing the Update Button is not a Panacea

Timely, researched updates ensure website features, functionality, and security continuity. However, updates performed without due diligence can potentially lead to compatibility issues, bugs, or broken functionality.

By default, the WordPress CMS regularly scans for available updates to WordPress core and installed themes and plugins — whether active or inactive. When an authorized user logs into the WordPress dashboard, if there are updates, the number will display prominently as on the screen below:

Clicking on the Updates menu item and viewing the list of available updates is simple. Even with a massive list of available updates, users can be lulled into a false sense of security by selecting and clicking to update all. But what if something goes wrong?

The Process is Important

Updates are a rip-and-replace process. Again, it is critical to have backups in place in the event of a need to revert to an earlier version, also called a “rollback.”

Even as a very experienced professional who develops and cares for websites daily, this writer sometimes encounters a “fatal error” or critical performance issues despite observing best practices with an update process. It rarely happens. For Sullivan Solutions, the update process, as only part of maintenance care, involves researching item stability. We stay abreast of the latest developer buzz in various technical forums to be forewarned of potential problems. We often defer updates for a day or two, except when we know there is a security patch involved until we have monitored feedback from support forums—especially when dealing with free plugins that too often are not well-supported.

When we encounter such a problem, we also have disciplined processes to revert and quickly eliminate the problem without considerable front-end website issues or downtime.  This is one practical example of the importance of backups (see Part 2 in this series). Finally,  we submit that most website owners do not have the technical experience to manage this type of incident.  Further, even with a maintenance care plan subscription, if said plan is one where updates are managed among numerous websites from an external tool that bulk updates remotely, the probability of this type of problem increases.  How responsive is the service going to be should this type of update process result in taking a website down?  Will that service provider even realize the problem exists?  We submit that the old-fashioned, hands-on process is a far better approach to minimize risk.

Let’s Step Back to Learn More About WordPress Construction.

First, WordPress must be installed on a server configured correctly and with sufficient resources for its size, complexity, and anticipated traffic activity (space, memory, CPU, Inodes, PHP version and configuration, etc.). In Part 5 of this series, we discuss Performance Optimization, which includes the WordPress website environment and how the hosting environment contributes to the equation.

WordPress websites include the following key software components: WordPress core, Themes, and Plugins.

The following WordPress components change over time (or should), and just like the software on your laptop or mobile device, these complex software programs must be monitored and updated to ensure ongoing access to features and functionality and prevent potential security risks.

1. WordPress Core – This is the actual CMS application that includes a set of files that would be the same on all WordPress installations before any customizations, including a connection to a separate MySQL database in a configuration file.  See more below about WordPress core.
2. Themes are the files that control the site’s front-end layout and visual display. WordPress comes with a set of default themes. Still, hundreds of other free themes are available in the WordPress theme repository, and many premium themes are available for purchase. Premium themes such as Divi (our first choice for the sites we build) and Avada include a built-in page builder system, while other themes might require an external plugin to provide options beyond the default WordPress editor.  See more below about Themes.
3. Plugins are separate software programs installed to provide extended features or functionality. There is an immense set of options, so see more details below. Numerous plugins are installed and active on each WordPress site as needed to achieve all required functionality.  See more below about Plugins.

About WordPress Core

WordPress has a formal Development RoadMap that we monitor for the release calendar and do our best to plan our availability around that date. The next major release is due in November 2024. The WordPress Development team loves Jazz, and all major releases are named after a prominent Jazz Musician. The latest release is version 6.6, Tommy Dorsey—view WordPress History.

It’s also possible to obtain pre-release copies of the upcoming major releases to test— also known as the “Release Candidate.” WordPress calls very early testing versions “Beta” even before any potential Release Candidate.  WordPress locks any new features thirty days before the scheduled release and uses that last period to polish and perfect.  We would never install a “Release Candidate” or “Beta” version on a live or “production” website. However, our Developer uses a testing or staging server to become familiar with the new version and tests it for compatibility with the themes and plugins typically installed on our client websites.

Even after the major versions are released, bugs are identified and fixed, and any security issues are exposed and patched.  There’s an extensive feedback process for reporting problems to the WordPress Development Team. Once there is an issues list, monitoring the planned release of new “subversions” that include these bug fixes and security patches is possible. In the previous major release, 6.5, called Regina (Carter – Jazz Violinist), after the initial launch, there were five subversions: 6.5.1, 6.5.2, 6.5.3, 6.5,4, and 6.5.5. Typically, we see subversions categorized as:

1. Security & Maintenance Release
2. Maintenance Release

There may be rare scenarios when we wait to update a website to a major new WordPress version and selectively opt to keep the older subversion installed for a while.

Themes Provide the Visual Design and Layout Templates

Only one theme is “active” on a website, and any deviation is a custom feature that is not typically recommended.

All recent websites we have built have been constructed with the “Divi” theme from Elegant Themes — an excellent and tremendously well-supported tool for contemporary websites.  In almost all cases, we install a “Child Divi Theme” that enables the ability to customize beyond the regular capabilities, but for the Child to work, the “Parent” Divi theme.  Why?  Divi saves all theme options in the database, such as Custom CSS or Google code snippets.  However, sometimes, we need to add custom code to a critical theme file called “functions.php,” which requires a bit of custom code.

The Use Case:

Hypothetically, a client website requires a “custom post type” with a unique layout. We need to add custom code to that functions.php file for the new post type to display in the WordPress dashboard.  If we added this code to the original Divi parent functions.php file, when the theme updates, it would eradicate that custom code and overwrite it with the version included with the original theme.  However, if we use the Child theme and put our customizations in that functions.php folder, the custom code remains, and all the new updates are available.

On the sites Sullivan Solutions builds, we keep one “default” WordPress theme (e.g., “Twenty Twenty Four” as included free with core) to provide a technical backup should we ever encounter problems.  This is a WordPress best practice.  We also can temporarily activate the default theme to narrow down a conflict scenario with a plugin.  Does the problem, whatever it may be, disappear if we change from our ordinarily active theme to the default?  If the issue resolves quickly, we have a first step in identifying the nature of the problem.  We usually delete older default themes as they are not needed and can become a magnet for bots seeking out old scripts that are not updated.  See Part 3 of this series on Security.

WordPress comes with numerous default themes installed with core:

• Twenty Twenty-One – delete this one
• Twenty Twenty-Two- delete this one
• Twenty Twenty-Three- delete this one
• Twenty Twenty-Four – keep this one

Sometimes, we inherit a website to maintain where other themes may still be installed in addition to the above.  These may have been used in prior website versions but are no longer needed.  It would be due diligence to archive (gzip copy) and remove it from the theme list.  Why? Especially if customized by name — and the original theme source is not apparent, it may no longer be possible to update the theme for compatibility with existing site configuration and security; we cannot define it or ensure that the old customized theme does not present a security risk.  It is common for some developers to remove references to a base theme altogether and rename the theme to the business name.  Why? If someone examines the website source code, it won’t be easy to identify the true source and replicate it on another website.  Another scenario might present that the developer wishes to remain secretive and ensure they become indispensable to keep the theme updated for compatibility with future WordPress and PHP versioning.

The Nitty Gritty About Plugins

What are plugins?

Plugins customize the features of the website and might include some of the following classifications:

• Page Builders (e.g., Elementor, Divi Page Builder within the Divi theme, but also available as a standalone plugin for use with any theme, Fusion Builder (Avada theme’s required builder is also available for standalone use)
• Backup Utilities (e.g., Solid WP aka BackupBuddy, Updraft Plus)
• Security (e.g., WordFence, Securi, Defender)
• Forms (e.g., Gravity Forms, Contact Form 7, WP Forms)
• SMTP (e.g., Post SMTP or WP Mail SMTP that enable sending outbound mail from the website to ensure deliverability)
• Event Calendars (e.g., The Events Calendar, Modern Events Calendar, WP Events Manager)
• eCommerce Store (e.g., WooCommerce, Ecwid, Shopify)
• Page Builder-Specific Extensions (e.g., Divi Plus is a set of premium modules for the Divi Page Builder adding more front-end layouts; Elementor Pro provides added design capabilities to the free Elementor builder).
• Builder-agnostic Design Tools (e.g., ASWM Teams for team profiles, wpDataTables, where the plugin enables customized tables and charts, but the content and design are set up outside the builder from an option in the admin dashboard and can be embedded with a “shortcode” regardless of the builder used)
• Image Optimization (compress and resize large images and even PDF documents to download more quickly on the front end, e.g., Imagify, EWWW, Hummingbird, Shortpixel)
• Performance Optimization (speed up the site by leveraging the environment, compressing files, caching, lazy-load images, etc., for improved user experience and SEO, e.g., WP Rocket, SG Optimizer (SiteGround specific), W3 Total Cache, Asset Cleanup, Perfmatters)

The Plugin Repository: Free WordPress Plugins

WordPress.org includes an enormous repository of free plugins.  We can search for plugins to install on sites by name, author, or keywords (such as one of the classifications above).  When a developer creates a new plugin, there is a submission and review process to get it added to the WordPress plugin repository.  A WordPress.org technical review team examines the plugin and, once approved, adds it to the repository.  At that point, it is up to the developer to monitor support requests and work within agreed rules.  Developers agree to an ongoing process to update their plugins to work in the latest WordPress and PHP versions and respond to support requests.

Sometimes, plugins launch with very attentive developers who invest their time in providing support and updates.  But this is often the make-or-break point for many.  This is often why we discriminate in our initial evaluation of a free plugin and are critical about the risk versus reward of installation.  We tend to look for plugins with an available premium version (listed and linked to from the repository version), even if we only want the free version.  Having a commercial version often indicates that with the premium support and updates demanded by paying customers, the development team will also keep their free version current.  Some developers require that the free version be installed with the paid version as an add-on, and this is generally an exemplary scenario in our evaluation when comparing the plugins we’ll use.

For illustration purposes, let’s take the very popular “The Events Calendar” plugin, which has a free version available in the repository and a premium version with added tools available for purchase.

When making initial selections about which plugins to install to achieve specific functionality, we look at the Last Updated date, the number of active installations, and the WordPress version (6.6 is the latest) to which the developer has tested the plugin for compatibility.  There is also a star rating (1 to 5) along with corresponding Reviews tabs to see what other users who have installed the plugin have to say.

The Support screen yields considerable information communicated from the developers and any specific issues that users have reported and require support. We evaluate how many issues are closed (usually meaning a fix is in place) versus open tickets.

It is also important to note that in the case of plugins that offer both a free a premium version, support for the paid version is not offered in the free version support area

For example, The Events Calendar provides support for their free version only via the plugin repository.   The Events Calendar Pro requires an active license-holder account to secure support for the premium version.

Finally, we take a look at the plugin’s Changelog.  This is merely a list of features or functions that changed in each version by its number of date of release. Refer to the example to the right for The Events Calendar.

The above process is used for the initial selection of plugins and our ongoing update research and support needs.

Premium Plugins: Paid Plugins

As described above, often the “free” plugins we decide to use also have a premium version available. We believe that the availability of a premium version adds some insurance to the probability of ongoing updates and support for both free and premium.  Premium versions sometimes require that the base free version also be installed, while in some cases, the premium version will not work with the free version installed.  There is no standard and it’s up to the developers how they construct their software.

Premium plugins can also be found on numerous third-party sites to include the following in part:

• Code Canyon (part of the Envato empire) is a significant source of premium plugins. Licenses are generally limited to one website for installation, and at purchase, the license includes six months of developer support with options to add paid support extensions. However, when installed with the license key or API, the plugin itself will generally update in perpetuity.
• Divi Marketplace via Elegant Themes—Sullivan Solutions generally uses the Divi theme for all new sites we build. We source many Divi plugins through the Marketplace, and after purchase, these utilize the connected Divi license. Most of these plugins have a one-year subscription.
• WooCommerce.com is our primary source for extensions to the WooCommerce e-commerce plugin.  These plugins are often more expensive but have a tremendous ROI for their functionality (ranging from $50 to $300 per one-year subscription license on one website installation).  Other third-party developers also provide very specialized and customizable features for online stores.

The next step is to verify that we have the patched version installed on all impacted websites. In the rare instances where a plugin is not patched, we do more research to include support forums and the risk associated with leaving the offending plugin in place.  Or is it so dangerous that we must temporarily or permanently replace the plugin with another that provides the necessary site functionality?  This type of activity can be tedious and time-consuming, and there is no one-size-fits-all as it is a very custom activity from one site to another. Rarely are our client sites “cookie-cutter;” most have some custom features.

Sometimes, a plugin may become abandoned in the accessible WordPress plugin repository.  This is often the case with a great new plugin published by a skilled developer who doesn’t realize how much effort is required to provide “support” and address any user issues about their plugin’s compatibility with other plugins or themes.  It is not uncommon for a well-meaning developer to just call it quits and stop working on the plugin so that it remains compatible with the latest releases of WordPress core and PHP versions (coding changes).  WordPress.org may consider the plugin abandoned and that it is too dangerous to allow access for download.  Another developer or group frequently takes on the future management of an abandoned plugin — sometimes renaming it or “forking it” with other improvements while building upon the initial foundation.  » See Security: WordPress Maintenance Series – Part 3

We use a combination of free and premium plugins on our client websites.  When choosing between several free plugins offering the same functionality, we evaluate ratings, how long the plugin has been published, frequency of support ticket resolutions, and updates.  However, another factor to be considered is whether there is a premium upgrade available that provides more functionality and support.  When a plugin development team has a premium version for sale, the odds are that the base plugin will be upgraded and supported with more frequency — including security patches and bug fixes.

How many plugins are too many for installation?

Plugins are necessary for every WordPress site, but too many can impact website performance if Performance Optimizations are not included. It is not the number of plugins that may cause issues; instead, it is their quality.  Sullivan Solutions often combines the use of numerous high-quality plugins on the websites we develop. Determining exactly how many WordPress plugins to install requires experience and the ability to make assessments.  As we create sites, we use staging environments that give us a good indication of plugin compatibility and if there would be possible conflicts.  We make our decisions based on the needed functionality, the hosting environment, and the end performance required to ensure excellent organic SEO.

The WordPress Maintenance Series:

Part 1 – It’s Not Optional

Part 2 – Backups

Part 3 – Security

Part 4 – Updates

Part 5 – Performance Optimization

Sullivan Solutions’ developer Deb Clark has over 31 years of website development experience and 17 years specific to advanced WordPress.  She has maintained all Sullivan Solutions’ client websites with active maintenance plans for over ten years.  In this time, no Sullivan Solutions client site has been hacked.  She has been sought after to successfully clean up major hacks in the past by businesses who were not clients before the hack including a major university research facility.