Audit My Site Get Started

Tag: Operating

  • WordPress Update Management: Core, Theme and Plugin Updates Done Safely

    WordPress Update Management: Core, Theme and Plugin Updates Done Safely

    In this piece

    1. 01Work out what you are actually running
    2. 02Apply updates the safe way
    3. 03Confirm it held

    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.

    Three layers, two kinds of updateCore can run on autopilot. Theme and plugin updates need a test step first.
    Core

    WordPress itself. Scheduled major releases, minor releases as needed.

    CompatibilityStrict backward compatibility across minor versions
    Auto-update defaultOn, for minor and major releases on WordPress 5.6 or later
    Safe to automate

    Theme

    Controls how the site looks. Ships on the theme author’s own schedule.

    Plugin

    Adds functions core does not have. Ships on each plugin author’s own schedule.

    CompatibilityIndependently coded, no compatibility guarantee with your other plugins, theme or PHP version
    Auto-update defaultOff. Opt-in per item or in bulk since WordPress 5.5
    Test before it goes live

    A mechanism diagram, not a risk score. Testing and rollback on the plugin and theme layer are offered by several providers.

    Diagram comparing WordPress core, theme and plugin update risk.

    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.

    Verification step

    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.

    Tested-update workflowThe path an update takes before it reaches the live site
    1. 01
      Update pulled into a staging environment mirroring liveSame PHP version, plugin and theme stack, and content.
    2. 02
      Applied in staging
    3. 03
      Checked for rendering and function
    4. 04
      Applied live, with a backup taken immediately before
    Flow diagram showing a WordPress update tested in staging before going live.

    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.

    Verification step

    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.

    See Maintenance Work

    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.

  • WordPress Security Hardening: What It Is and What It Actually Covers

    WordPress Security Hardening: What It Is and What It Actually Covers

    What this guide covers

    1. 01Understand what hardening is made of
    2. 02Sort the current advice from the stale advice
    3. 03Decide what you will run

    The short answer, and where hardening lives

    Hardening is configuration, not detection. A firewall and a malware scanner watch for something happening. Hardening removes the path it would happen down in the first place.

    Six categories make up the stack: patching, file and database permissions, administrative surface, response headers, obscurity measures, and the operational layer that keeps the rest true after a release goes out. Patching lives at the plugin, theme and core level. Permissions live on the server and in the database. The file editor and two-factor authentication live on the admin screens, and response headers get sent by the server or a proxy. A plugin cannot set a file permission or send a header the way a server configuration can.

    Six layers, three places they live
    A plugin reaches only the WordPress band

    Server

    • File and directory permissions
    • Response headers
    • wp-config.php protection

    Database

    • Reduced database privileges
    • Authentication keys and salts

    WordPress

    • File editor disabled
    • Two-factor authentication
    Update cadence spans all three bands: it is what keeps the rest of this true after a release goes out.

    No figures needed here. This is a grouping of measures by where each is configured, not a severity ranking.

    Diagram showing WordPress hardening measures grouped by where each one is configured.

    Read what ongoing WordPress security work covers once you know which of the six you actually own.

    Verification step

    List which of the six categories you can currently point at a real setting for, not a plugin dashboard toggle. The ones you cannot name are the gap this piece is about.

    How the layers actually work

    Three controls, in the order this section covers them

    File permissions
    Directories 755/750, files 644/640, wp-config.php 440/400 on suexec

    File editor disabled
    One line in wp-config.php closes the in-browser edit path

    Database and keys
    Reduced privileges, rotatable authentication keys and salts
    Diagram summarising the three controls covered in this section: file permissions, the file editor, and database privileges and keys.

    File and directory permissions

    WordPress core, wp-admin and wp-includes should be writable only by your user account. wp-content is the exception, since plugins, themes, uploads and cache write there. The handbook gives permissions as ranges, not one number: directories at 755 or 750, files at 644 or 640, and wp-config.php at 440 or 400 on a suexec setup.

    Which number is correct depends on your host. On suexec or PHP-FPM, the PHP process runs as the file owner and can use the tighter number; on a shared mod_php setup, the web server’s own user needs write access, so the same tight number breaks the site. wp-config.php gets the strictest rule, holding the database credentials and the four secret authentication keys, and the handbook calls a default 644 permission on it a hazard.

    The file editor, and why it goes first

    Setting DISALLOW_FILE_EDIT to true in wp-config.php removes the plugin and theme editor from wp-admin, equivalent to removing the edit_themes, edit_plugins and edit_files capabilities from every user. Without it, an attacker holding an admin session can paste a PHP web shell straight into a theme file through the browser, no upload needed. Removing the editor closes that path.

    Database privileges and authentication keys

    Day to day, WordPress needs only SELECT, INSERT, UPDATE and DELETE from its database user. DROP, ALTER and GRANT can be revoked without breaking anything WordPress normally does, so an injection flaw in an unpatched plugin cannot drop a table or create a privileged user, even if it succeeds.

    The keys and salts sign your authentication cookies. If they are weak, default or leaked, someone holding them can forge a valid login cookie without your password, and rotating them ends every logged in session at once, the fastest way to remove a session you do not control.

    Read the three plans and what each covers if you’d rather have someone else run this. See the three plans.

    Verification step

    After each change, load the site, log in, upload a media file and save a post. Those four actions confirm permissions, sessions and write access at once, so you know within a minute whether the tighter setting broke something.

    Security headers, including the one to stop maintaining

    The headers worth setting

    • Content-Security-Policy tells the browser which sources may load or execute. A policy that disallows unsafe-inline means an injected script tag does not run.
    • X-Frame-Options stops the page loading inside a frame on another domain, the mechanism behind clickjacking.
    • X-Content-Type-Options: nosniff stops the browser guessing a file’s type instead of trusting the declared type.
    • Strict-Transport-Security tells the browser to only connect over HTTPS for the stated period.
    • Referrer-Policy and Permissions-Policy limit what leaks to other origins and which browser features a page may use.

    X-XSS-Protection, and why guides still list it

    MDN, the reference most browser vendors defer to, marks this header both deprecated and non-standard. It “was a feature of Internet Explorer, Chrome and Safari that stopped pages from loading when they detected reflected cross-site scripting (XSS) attacks.” Chrome and Edge have since removed the XSS auditor the header controlled, so setting it today changes nothing.

    MDN’s own guidance is direct: “it is recommended that you use Content-Security-Policy instead of XSS filtering.” It warns that in some cases the header “can create XSS vulnerabilities in otherwise safe websites,” which makes it a header that can work against you.

    The honest answer to what people are searching for is this. Do not tune this header. Retire it, and put the effort into Content-Security-Policy, which is harder to get right and is the one doing the actual work.

    Header What it does Status
    Content-Security-Policy Tells the browser which sources may load or execute Set it, does the actual work
    X-Frame-Options Stops the page loading inside a frame on another domain Set it, stops clickjacking
    X-Content-Type-Options Stops the browser guessing a file’s type instead of trusting the declared type Set it, stops MIME sniffing
    Strict-Transport-Security Tells the browser to only connect over HTTPS for a stated period Set it, forces HTTPS
    Referrer-Policy Limits what leaks to other origins on navigation Set it, limits leakage
    Permissions-Policy Limits which browser features a page may use Set it, limits feature access
    X-XSS-Protection Once stopped some browsers loading pages with detected reflected XSS Deprecated per MDN, retire it

    Status described in words, not header syntax to copy. No HSTS max-age value shown, since that number is sourced only to a secondary vendor article.

    Chart of WordPress security response headers with the deprecated X-XSS-Protection marked.

    Read about how response headers and caching are handled for performance if headers are new territory for you.

    Verification step

    Request your own home page and read the response headers back. Then check a page that loads a third party script or embed, since a policy that passes cleanly on the home page often blocks something the moment an embed is involved.

    What good looks like

    The configuration is set, and somebody can say when each item was last checked. Updates are applied on a schedule, tested before going live, and reversible if one breaks something. That is ordinary practice offered by several providers, not something unique to any one of them. The plugin inventory is short, and every item on it is still maintained upstream.

    Patchstack, a vendor that sells a vulnerability monitoring product, published figures worth reading with that in mind:

    Layer Share of 2025 disclosures
    Plugins Roughly 91 percent
    Themes Roughly 9 percent
    Core 6 vulnerabilities, out of 11,334 total
    Table showing that most WordPress vulnerabilities disclosed in 2025 were in plugins. 11,334 total disclosures, a 42 percent increase on 2024. Shares are rounded. All figures from Patchstack, a vendor with a commercial interest in this figure, not an independent survey.

    Read how updates get tested before they go live once you know the plugin layer is where the exposure actually sits.

    Verification step

    Pick the three most recently updated plugins on your site and find out who applied each update and whether anything was checked afterward. If you cannot answer either question, that is the gap.

    What to do about it

    In order of what returns most for the effort:

    01

    Audit your plugins and themes and remove what is not used.

    02

    Disable the file editor, one line in wp-config.php.

    03

    Tighten wp-config.php permissions, then the directories, testing after each.

    04

    Set the current header set, and remove X-XSS-Protection if it is there.

    05

    Reduce the database user’s privileges and rotate the keys.

    06

    Decide who applies and tests updates, and on what cadence.

    Verification step

    After each change above, run the same four checks from the permissions section again: load the site, log in, upload a media file, save a post. A hardening change you cannot confirm is a change you are trusting rather than one you have made.

    Would rather not run this list yourself?

    See what hardening is included in NoDrama’s WordPress security retainer.

    See Security Work

    Common misconceptions

    “A security plugin is hardening.”

    It firewalls, scans and limits login attempts: detection, not configuration.

    “Changing the table prefix and admin username secures the site.”

    The handbook frames this as obscurity, stopping scripted attacks rather than a targeted one. Cheap and worth doing, not a defense on its own.

    “Core updates are the priority.”

    6 of the 11,334 vulnerabilities disclosed in 2025 were in core, and core auto-updates already cover most of that.

    “My host handles security.”

    Hosting-level protection is a different layer from the application-level configuration described here.

    What this does not cover

    The exact permission numbers for your host, which depend on how it runs PHP. Writing a Content-Security-Policy for your specific third party scripts. Incident response and cleanup after a compromise. And no formal certification: hardening supports compliance work, not a compliant status.

    Where this leaves your site

    Hardening is a stack of configuration changes, most of it living outside WordPress itself: the server, the database, the response headers. It holds only as long as somebody keeps patching the layer where the vulnerabilities actually are, plugins rather than core.

  • The WordPress Maintenance Checklist

    The WordPress Maintenance Checklist

    Get the checklist

    Copy this into a doc, a spreadsheet or a project board. It is ordered by cadence, not by importance, because a task that runs continuously and a task that runs monthly are both required, just not on the same day.

    WordPress maintenance checklist

    • Uptime monitoringContinuous
    • BackupsDaily to weekly, scaled to activity
    • Update review, core, plugins and themesWeekly
    • Security scanning and hardeningOngoing
    • Performance checkMonthly
    • Database and log cleanupMonthly

    Each line names the task and the cadence only. The next section covers what “correctly” means for each one, because a task run on schedule but run wrong is not much better than a task skipped.

    If the list above is more than you want to track by hand, see which parts of it NoDrama’s plans cover.

    Run each task correctly

    Updates, staged and tested

    A WordPress core update is not a single event on a single day. WordPress’s 2026 release schedule runs three major releases roughly four months apart, and plugins and themes ship on their own separate schedules on top of that. WordPress’s built-in auto-update system, introduced in WordPress 5.5, checks for available plugin and theme updates twice a day by default.

    That default check is not the same as a safe default rollout. WordPress’s own documentation on plugin and theme auto-updates says plainly that you may want to make sure you can roll back to a previous version before enabling them. The correct sequence is staging first, live push second, rollback held ready as the fallback if the live push still breaks something the staging test missed.

    The update pipeline

    Staging test
    The update installs on a clone first. Key pages and forms checked there.

    →

    Live push
    Passed on staging. The same update goes to production.

    →

    Rollback if needed
    The fallback path when the live push breaks something staging missed.

    Rollback is a fallback path that depends on a recent backup existing, not an automatic or instant recovery.

    Flow diagram of a WordPress update tested on staging before it goes live, with rollback as the fallback.
    Verify it

    After any update goes live, confirm the site’s key pages and forms still load and submit correctly. A staging test that passed is not the same evidence as a live push that held.

    Backups, matched to how often the site changes

    WordPress.org’s own backup guidance sets the cadence by activity rather than by a flat weekly rule for every site: once a week for smaller sites with fewer posts, daily for high-activity sites with a lot of posts.

    A backup has to cover both halves of the site to be useful. WordPress.org is direct about this: you need both the database and the files to fully restore a typical WordPress site, not one or the other. Keep 3 to 5 recent backups stored across at least two locations, so a single storage failure does not take out the only copy.

    Verify it

    Actually restore from a backup at least once, on a staging copy, rather than trusting that the backup file exists. A backup nobody has restored is a backup nobody has tested.

    Security scanning and hardening

    A security scan checks the site’s installed core, plugins and themes against databases of known, disclosed vulnerabilities. That is useful and it is also limited: a scan catches what has already been found and published. It does not catch a zero-day, a misconfigured server, or a weak password, because none of those show up in a vulnerability database.

    Hardening is a separate layer that sits alongside scanning rather than replacing it: correct file permissions, disabling the in-dashboard file editor, and protecting wp-config.php from being read directly.

    Verify it

    Confirm the scan actually ran and produced a dated result, and confirm hardening settings held after the last update. Some updates reset file permissions or reactivate a setting the update assumed was default.

    Uptime monitoring

    Uptime monitoring answers one question continuously: is the site responding right now. It does not answer why the site is down, and it does not catch a site that returns a page but is broken in a way that does not trip a downtime alert, a checkout that loads but will not process a card, for instance.

    Verify it

    Confirm the monitoring alert path itself still works by triggering a test alert periodically, so the first real outage is not also the first time anyone finds out the alert never fires.

    Performance and database cleanup

    A monthly performance check catches drift before it becomes a pattern: the same page that loaded fine last month, loading slower this month because of an accumulation of plugins, images or database bloat. It’s the comparison against last month’s result, not a single reading, that reveals the drift.

    Database cleanup removes what accumulates in the background and nobody deletes on purpose: old post revisions, expired transients, spam comments and orphaned metadata left behind by deactivated plugins. Left alone, these slow database queries and inflate the size of every backup that follows. Take a fresh backup before running any cleanup, since a cleanup tool that deletes the wrong table row is not something you want to discover without a way back.

    Verify it

    Confirm the site still loads and functions correctly after cleanup, the same way you would after an update.

    What reviewers and auditors actually check

    Anyone reviewing whether this routine actually ran, an auditor, an insurer, a new hire taking over the site, checks for evidence rather than intent. That means:

    • What updated, and when, with a dated log rather than a memory of “we keep it current”.
    • Whether the last backup completed and whether it has ever been restored, not just whether a backup file exists.
    • What the last security scan found, and whether anything flagged was addressed.
    • Uptime over the review period, as a record rather than an impression.

    A routine that ran but left no trace is indistinguishable, to a reviewer, from a routine that never ran.

    What this checklist does not cover

    This checklist covers the recurring maintenance work. It is not a security incident response plan for something that has already gone wrong, it is not a compliance program for a specific regulatory standard, and it is not a full site rebuild. Those sit on the other side of a boundary this checklist does not try to cover.

    Where teams get this wrong

    The same three mistakes show up across sites of every size.

    A security plugin gets installed once and never checked again.

    Installing a scanner is a decision made on one day. Reading its findings is a habit, and the habit is the part that lapses.

    Auto-updates get switched on with no backup and no rollback path behind them.

    The update mechanism runs on schedule either way. Whether a bad update costs an afternoon or costs nothing depends entirely on whether a rollback exists to fall back on.

    A one-off backup gets mistaken for a routine.

    Someone took a backup before a big change six months ago, and the site has changed a dozen times since then without another one.

    NoDrama’s plans cover the core of this list on every tier: updates kept current, off-site backups daily or more often, malware scans every 12 hours, uptime checked every minute, and real visitor speed data each month. Database cleanup is not part of the plans. See what every plan includes.

    Conclusion

    A WordPress maintenance routine is six jobs on six different clocks: updates tested before they go live, backups matched to how often the site changes, security scanning paired with hardening, continuous uptime monitoring, a monthly performance check, and regular database cleanup. Running any one of them on the wrong cadence, or running them without a way to verify they held, is how a routine task turns into a surprise.