In this piece
The three layers you are updating
Core is WordPress itself, the software that runs everything else. Themes control how the site looks. Plugins add functions core does not have. All three ship updates on their own schedules, and none of them wait for the other two.
WordPress itself. Scheduled major releases, minor releases as needed.
Controls how the site looks. Ships on the theme author’s own schedule.
Adds functions core does not have. Ships on each plugin author’s own schedule.
A mechanism diagram, not a risk score. Testing and rollback on the plugin and theme layer are offered by several providers.
Core minor releases are near-automatic and safe, because WordPress core maintains strict backward compatibility across minor versions. That is the whole reason they can run unattended. Plugin and theme updates are a different animal. Each one is written independently, by a different developer, with no obligation to stay compatible with any other plugin, theme or PHP version on your site. WordPress has no way to test that combination in advance, which is exactly why the project leaves plugin and theme auto-update off by default. You have to turn it on per item, or in bulk, since WordPress 5.5.
That default is worth sitting with. The people who built the update system decided the compatibility risk on this layer was high enough that it should not happen without someone choosing it. “Turn on auto-update for everything” is advice that skips the one step, testing, that actually prevents breakage. It is not wrong that updates should happen. It is wrong about which layer is safe to leave unattended.
This is the gap a maintenance retainer that separates the safe updates from the risky ones is built to close.
Check what you have now
Before changing anything, confirm what is actually running. In wp-admin, the Dashboard > Updates screen shows the current core version and lists any plugin or theme with an update pending. The Plugins screen shows every active plugin and its version number. Appearance > Themes shows the active theme and any child theme in use.
Write the list down, or export it, before you touch a single update. You cannot tell whether an update changed something if you did not know the state it changed from.
Confirm the list matches what is actually active in wp-admin, not what you remember installing. Plugins get deactivated and reactivated, themes get swapped, and a list based on memory is often out of date.
How to handle core updates
Core minor releases (as-needed maintenance and security fixes, no new features) are safe to leave on auto-update. WordPress ships three major releases a year, roughly four months apart, and on installs running WordPress 5.6 or later, both minor and major releases auto-apply by default. Major releases change more surface area than minor ones, so they carry more risk even though the default treats them the same as minor releases on newer installs. For more detail, see how often WordPress actually ships updates.
Via plugin
An update-management plugin can group and schedule core updates, giving you a single place to see what applied and when, rather than checking the Updates screen manually.
Via server
WP-CLI or a hosting panel’s built-in update trigger can apply core updates from the command line or a dashboard, which is the more common route on managed hosting.
How to handle plugin and theme updates
WordPress does not auto-update plugins and themes by default, and that default is the clearest signal available that this layer needs more than a toggle. The general mechanism for testing an update before it reaches visitors works the same way regardless of who runs it: pull the update into an environment that mirrors the live site, same PHP version, same active plugin and theme stack, same content, apply it there first, and confirm the site still renders and functions before applying it live. Take a backup immediately before the live update goes out, so the change is reversible if something surfaces after it ships.
-
01Update pulled into a staging environment mirroring liveSame PHP version, plugin and theme stack, and content.
-
02Applied in staging
-
03Checked for rendering and function
-
04Applied live, with a backup taken immediately before
What NoDrama’s own care plans confirm on this layer, and no more: plugin and theme updates run with key pages photographed before and after, and are put back if something breaks, on all three plans. This is not unique to NoDrama. ManageWP, WP Umbrella and WP Remote all offer comparable tested-update mechanisms.
This is where how NoDrama checks updates matters, because building a test step yourself means standing up and maintaining a second environment.
Via plugin
A staging or cloning plugin is the DIY route: it clones the live site into a separate environment where updates can be applied and checked before going live.
Via server
Some hosts include a staging environment as part of the hosting plan, which removes the need for a separate plugin.
Via code
A developer-run site can manage this with a manual git and WP-CLI workflow, pulling updates into a version-controlled staging branch before deploying to production.
Via host or CDN
Some managed hosts and CDN providers offer their own staging or rollback tooling as part of the platform, where it is included.
Apply the change
As general good practice, not a documented NoDrama process: apply core minor updates first, since they carry the least risk. Then work through plugin and theme updates via the tested path above, one at a time or in a controlled batch, never all of them at once with no backup in place. No internal NoDrama documentation confirms this specific sequencing. It is standard practice, presented here as such.
A full pre-update checklist covers the steps in more detail if you are building this process yourself.
Verify safely
Load the updated site logged out, in a private or incognito window, not just in wp-admin. Check the pages that matter most: the homepage, any checkout or lead form, and any page that uses the functionality the updated plugin touches. Confirm the backup taken before the update is still current and restorable, not just that it exists.
Confirm the site functions for a logged-out visitor. A page that loads fine for a logged-in admin can still be broken for everyone else, since caching, session state and admin-only scripts can mask a problem that a normal visitor would hit immediately.
See how updates are checked and put back.
NoDrama’s WordPress maintenance service photographs your key pages before and after every plugin and theme update, and puts back anything that breaks.
Troubleshoot
“The update broke the layout”
This is usually a theme or plugin CSS or JavaScript conflict introduced by the new version. Roll back to the pre-update backup, then test the update again in staging before reapplying it live.
“A plugin update will not apply, or the site white-screens”
This is usually a PHP version mismatch. Check the plugin’s stated minimum PHP version against the version your host actually runs, since an update can require a newer PHP version than the site is on.
What this does not solve
A tested-update process catches problems before they reach visitors. It does not make every plugin update backward compatible by itself, and it does not eliminate the underlying risk that plugin code can change without warning. Testing reduces the cost of that risk. It does not remove the risk itself.
Conclusion
The practical version of this is simple to state, even if it takes some process to run. Core minor releases can be left on autopilot, because WordPress guarantees their backward compatibility. Plugin and theme updates cannot, because WordPress itself treats them as opt-in, and they need to be tested before they go live rather than applied and hoped for. A maintenance retainer that separates the safe updates from the risky ones is the practical way to get updates checked without building a staging process yourself.