A shared theme.json can turn brand decisions into visible WordPress rules. The system becomes dependable only when those rules also hold across templates, blocks and the change approval process.

A WordPress website can look consistent even when its design rules have started to drift. A new colour appears in one template, spacing changes elsewhere, and a block pattern still uses an older typography choice. Each difference seems small. Together they slow down redesigns, make editorial work less predictable and complicate quality control.

Why theme.json alone does not guarantee consistency

WordPress uses theme.json to define global settings and styles for the block editor and the website. These can include colour palettes, typography, spacing and layout rules.

The file is a shared rulebook, but it does not prove that the website follows those rules. Templates, custom blocks and other components may contain hardcoded values that bypass the central settings. The useful test is the comparison between the declared rule and the rendered result.

Which design rules to compare first

Start with the approved brand system. List the colours, type styles, spacing rules and layout limits that should be available to editors. Then compare them with the active theme.json.

Look for missing values, obsolete options and editor choices without a clear business purpose. A difference is not automatically a defect. It should, however, have a reason and an owner, and be classified as a reusable token, a documented exception or something to remove.

Where templates, blocks and the editor can bypass the rules

Review a representative set of important page types: the homepage, service pages, articles, landing pages and key conversion journeys. This reveals hardcoded colours, spacing or type values that differ from the shared settings.

Editor behaviour belongs in the review too. Too many options create accidental inconsistency. Too few force the content team to improvise. A useful system leaves enough room for real content while protecting the design decisions that need to remain stable.

How to review and release changes safely

Define who may change theme.json, who reviews the visual result and which templates must be tested before approval. Theme configuration, custom blocks and deployment belong in the same review scope. A correct rule is of little use if a component ignores it or the change is not delivered safely.

• Compare the active theme.json with the approved brand rules.
• Separate shared tokens from hardcoded values and justified exceptions.
• Test representative templates, blocks and editor options on desktop and mobile.
• Assign an owner and approval route for every material change.
• Verify the rendered result before deployment.

The management question is not whether the website has a theme.json file. It is whether approved design decisions can move through WordPress without creating hidden divergence.

Do WordPress design changes stay consistent across your website? DKSIGN reviews theme configuration, templates, blocks and deployment together, then turns the findings into a clear change process with defined ownership.

Having a backup is not proof that recovery will work. Only a controlled test shows whether the database and files match, can be found and can be restored in an isolated environment.

A notification that today's WordPress backup completed can feel reassuring. During an incident, however, it does not answer the question that matters: Can those stored data produce a working website? Several practical decisions sit between a successful backup and a successful restore. They are best made before anything fails.

What a complete backup set needs

A typical WordPress recovery needs two components: the database and the files. The database contains content, settings and much of the data used by plugins. The files include WordPress itself, themes, plugins, uploads and custom components. If one part is missing, or the two come from different points in time, the recovered site may be incomplete or inconsistent.

Choose one specific backup set for the business critical website. Record which database backup belongs with which file set, when each was created and where both are stored. Check that retention reflects the business risk and that the accountable person can actually access the backups.

A restore test makes the difference

A controlled restore provides the useful evidence. Recover the chosen set in an isolated environment without overwriting the production website. Record the start time, backups used, credentials needed, steps completed and errors encountered. This turns an assumption into an operational record that others can review.

After the restore: verify business critical journeys

Follow the technical restore with a business check. Open key pages, test login and editorial access, submit forms and confirm that expected media is present. For shops and connected systems, include orders, payment status, email and important integrations. Focus on the processes whose loss would have a real business impact.

Recovery needs clear ownership

Ownership should also be clear in advance. Who starts the restore? What recovery time is the target? When should the team try another backup set or call a specialist? How will new production data be protected during recovery? A named owner and a documented fallback save time when pressure is high.

Review it regularly, not only after an incident

A restore test cannot prevent every incident. It does show whether backups are accessible, coherent and usable in practice. Repeat it after material changes to hosting, databases, deployment or backup procedures. It should also run on a regular schedule that reflects the risk of the website.

The better management question is not: Do we have backups? It is: Can we return this WordPress website to a verified state from a known backup set within an acceptable time? A documented answer turns recoverability into a sound operational decision.

Checklist

• Identify a matching backup set containing the database and files.
• Verify creation time, retention, storage location and access.
• Complete a restore in an isolated environment.
• Test business critical pages, functions and integrations.
• Document the recovery owner, target time, escalation and fallback decision.

Do you know whether your business critical WordPress website can really be recovered? DKSIGN can assess the backup set, hosting, database and files, then support a controlled restore with clear evidence.

A new feature is needed, so another plugin is added. A form, an integration, an analytics tool. Each decision may be reasonable. Years later, the site is harder to change and nobody is quite sure which extension is still needed for what.

The problem is rarely a particular number. A site with 35 well-managed plugins can still be more reliable than one with twelve whose roles nobody can explain. Complexity does not come from the plugin count. It comes from unmanaged dependencies.

Every plugin is a decision with an ongoing cost

A plugin brings its own code, updates and often connections to other systems. It may be the right solution. Someone still needs to judge whether it fits and works safely with the rest of the site.

Without an owner, outdated integrations, duplicated features and conflicting settings accumulate. The consequences appear when a campaign goes live, an update fails or a small request affects unrelated parts of the site.

Fewer is not automatically better

Removing plugins indiscriminately is no more of a strategy than continually adding them. A custom-built feature can create more work than an established plugin. An extension kept active out of habit may, however, add risk without providing enough value.

The better question is not, “How many plugins are we allowed to have?” It is, “What business purpose does this extension serve today?” Then ask: Who owns it, and how will it be maintained or replaced?

Ownership makes complexity manageable

Each extension needs a clear purpose and owner. It also needs a maintenance plan covering controlled updates, checks of critical forms and workflows, clear documentation, and a backup and recovery plan.

The management decision that matters

A business-critical site does not need the lowest possible plugin count. It needs decisions that can be explained. That allows the site to develop without turning every change into a risk.

If nobody can confidently explain the current setup, an inventory is a sensible place to begin. In a DKSIGN Check, I clarify which extensions still serve the business, where critical dependencies exist, and how ownership and maintenance should be assigned.

Review your WordPress setup with a DKSIGN Check

A decision model for marketing and technical teams

Most companies treat production access as a permissions question. Who has an Editor account? Who has Administrator access? Who knows the hosting login?

Those details matter, but they come too late in the conversation.

The business question is simpler: who is allowed to release a particular change, and who owns the outcome if that change affects more than expected?

The same Publish or Update button can send a corrected sentence live, change a form used by every campaign, load a new tracking script, or alter a global template. WordPress makes these actions look similar. Operationally, they are not.

That distinction matters most in established businesses. Marketing cannot wait for a developer to approve every headline. Technical owners cannot reasonably accept unreviewed changes to integrations, consent logic, or shared components. Both teams need room to do their jobs.

The answer is not to pick one team and lock out the other. It is to separate publishing access from release authority.

Capability is not authority

A WordPress role defines what a user can do inside the software. It does not decide what that person should release in a given business context.

An experienced marketing manager may be the right owner for a campaign page built with approved components. The same person may be the wrong owner for installing a plugin that changes how the page sends data to the CRM.

An agency developer may understand the code but not know that a change is scheduled during the company’s largest campaign of the quarter.

Release authority has to follow the change, not the job title.

Two questions are enough to classify most changes:

First axis: consequence

The visible size of a change is a poor guide to its operational impact.

A short script pasted into a settings field can affect consent, analytics, page speed, or every visitor on the site. A long rewrite of an isolated article may affect only that article.

Useful consequence questions include:

This is not about imagining every possible disaster. It is about knowing whether the effect is local or systemic.

Second axis: reversibility

Teams often describe a change as reversible because a backup exists. That is only part of the answer.

Reliable reversal means the previous state is known, someone can restore it within a useful time, and doing so will not erase orders, enquiries, form entries, or edits created in the meantime.

Restoring an earlier page revision is usually straightforward. Rolling back a database after customers have placed orders is a different decision entirely.

Reversibility also depends on ownership. If nobody knows who can perform the restore, a theoretically recoverable change is not operationally reversible.

Four release classes

Combining consequence and reversibility gives teams four practical release classes. These classes sit above WordPress permissions. They explain when those permissions may be used.

Routine publishing

The impact is local and the previous state is easy to restore.

Examples include copy corrections, replacing an image within an approved layout, or updating a date on a single content page.

Marketing and editorial teams should normally publish these changes themselves. Requiring technical approval would add delay without adding meaningful control.

Routine does not mean careless. The publisher still checks the preview, links, and the live result. The important point is that the boundary has already been agreed, so a small content change remains a small operational event.

Controlled publishing

The change is led by marketing but has a wider footprint. It is still reasonably reversible, although an error could affect several pages, campaigns, or measurement points.

Examples include launching a landing page from approved components, editing reusable content, adding redirects, or changing an existing lead form.

These changes benefit from a defined second review. Marketing can own the release, while another person checks the elements that carry wider consequences.

The reviewer does not always need to be technical. A campaign owner may be the right person to verify an offer or audience. Technical review becomes necessary when the change touches data flow, consent, scripts, global components, or an external integration.

Technical release

The change modifies the system or cannot be safely reversed through the editor.

Plugin and theme updates, code deployments, template changes, caching rules, DNS changes, hosting work, and new integrations belong here.

Administrator access does not make these suitable for direct changes on the live site. A technical release needs a known starting point, an appropriate test route, a credible rollback, and someone who can judge interactions across the system.

Marketing may still need to confirm the customer-facing result. Technical release authority, however, belongs with the person who understands the dependencies and owns recovery if the release fails.

Joint release decision

Some changes carry both substantial business consequence and difficult recovery.

A checkout change, a new form integration, a consent platform migration, or a major release immediately before a high-value campaign can fall into this class.

Neither marketing nor the technical owner has enough context to decide alone.

Marketing understands timing, offer logic, campaign dependencies, and expected user behaviour. The technical owner understands system dependencies, failure modes, and recovery time. The release decision needs both perspectives.

Senior leadership does not need to approve every deployment. It does need to name the person who decides when a commercial deadline conflicts with operational risk.

So who gets to publish?

The practical answer is to give enough people access to keep the business moving, then place clear boundaries around the kinds of change each person may release.

Marketing should be able to publish content that has no material technical dependency. That autonomy is part of a healthy operating model.

System changes should be released or supervised by the person who can assess their effects and take responsibility for recovery. An Administrator badge is not evidence of either ability.

Changes with broad commercial and technical consequences need a named joint decision. This does not require a committee. It often requires a short conversation between two people who know they are accountable.

What uncertainty tells you

If a proposed change cannot be classified, the problem is rarely a missing WordPress role. More often, the company lacks a reliable picture of how the site works.

If nobody knows where form submissions go, nobody can confidently approve a form change. If a shared component has no known list of uses, its consequence is unclear. If recovery belongs to "the agency" but no individual owns it, reversibility is an assumption.

The model exposes those gaps before a live release does.

Good governance protects speed

Release governance can sound like another layer of process. Done well, it has the opposite effect.

Marketing moves faster on routine work because the boundary is already clear. Technical attention is reserved for changes that can actually affect the system. Joint decisions happen only where commercial timing and technical consequence genuinely meet.

The Publish button then becomes what it should be: the final action in a decision that already has an owner.

Checklist for the next live release

• Classify each change by consequence and reversibility.
• Distinguish routine publishing, controlled publishing, technical releases, and joint decisions.
• Name an accountable owner for technical and joint releases.
• Check the preview, rollback path, and business outcome before release.

Next step

If production access has grown over time but release responsibility is still vague, I can help you define a workable model. We can separate the changes your team should publish independently from those that need controlled review or technical ownership.

After a plugin, theme or configuration change, a dependable before-and-after comparison brings clarity quickly. A concise change record shows what changed and when, which important journeys still work and which recovery route has actually been tested.

A form stops working, a page becomes slower or an editorial workflow suddenly behaves differently. With a recorded starting point, the cause can be narrowed down more deliberately. Without one, diagnosis begins with guesses: was it the update, a configuration, an external service or a problem that was already there?

Useful change evidence does not have to start as a comprehensive monitoring project. For many business-critical sites, a small repeatable baseline is enough: relevant WordPress, plugin and theme versions; one to three critical business journeys; selected error and performance signals; and the last known working state.

Before the change, record what was checked and the expected result. Afterwards, run the same real journey again, such as an enquiry, registration or editorial process. Keep the change, timestamp, owner and observed difference in the same record. That creates a clear comparison instead of a collection of disconnected screenshots and log lines.

WordPress provides useful technical reference points. The Site Health screen surfaces information about site configuration and operation. The official debugging documentation describes tools for investigating issues in controlled environments. These signals complement a test of a real business journey; they do not replace it. Someone still needs to decide which difference matters operationally.

A clear recovery route belongs in the evidence too. Having a backup does not by itself show that a change can be reversed reliably. Decide in advance which state will be restored, who makes the call and how the critical journey will be checked afterwards.

Keep the record purpose-bound. Capture only the technical information needed for comparison and diagnosis, and avoid unnecessary personal content. Access, retention and ownership should reflect the importance of the site.

The result is not a guarantee that every change will be trouble-free. It is a stronger basis for decisions: see what changed sooner, narrow the cause more deliberately and use a tested recovery route when needed. That keeps a technical difference manageable and makes the next decision easier to explain.

Checklist

• Record relevant versions and the last working state before the next change.
• Define one to three business-critical journeys and their expected results.
• Keep the change, timestamp, owner and technical signals in one record.
• Retest the same real journey after the change and capture differences.
• Test the recovery route, decision owner and post-restoration check in advance.

Want clearer evidence around changes to your business-critical WordPress site? DKSIGN can review the baseline, critical journeys and recovery route with you, then guide the next change in a controlled way.

A success message in the browser does not prove that an enquiry reached the intended mailbox or CRM. A business-critical form needs a verifiable path from submission to destination, plus a clear owner when the evidence is missing.

The contact form says the message was sent successfully. Yet the enquiry never appears in the sales mailbox or CRM. This kind of failure can go unnoticed because the visible confirmation covers only part of the delivery path.

WordPress documents this boundary clearly: a successful return from wp_mail() means that the message was accepted for processing. It does not prove that the message was delivered. A green confirmation on the form therefore says nothing about the final handoff to the intended recipient.

For the site owner, the key question is not which plugin to install next. It is: what evidence shows that a business-critical enquiry reached its destination, and who acts when that evidence is missing?

Begin by mapping the real path: from the form in the browser, through WordPress processing and the email, SMTP or webhook transport, to the mailbox, CRM or other receiving system. For every handoff, record the expected identifier, the evidence that can be checked and the person responsible.

Next, send a controlled test enquiry with a recognisable reference. Verify both the response shown to the user and the receipt in the destination system. A timestamp, a non-sensitive reference and the result will often provide enough evidence to trace the chain. Personal content should not be logged or retained unnecessarily.

A one-off test becomes dependable only when it can be repeated. Depending on the importance of the form, that may mean a scheduled test, tightly bounded monitoring or an alert when handoff evidence is missing. Escalation and fallback matter too: who investigates, which alternative channel can accept enquiries and when should the technical team intervene?

The aim is not a blanket guarantee for every email. It is a verifiable evidence chain for the forms on which sales, support or operations depend. That turns a simple success message into a process whose operation and ownership can genuinely be demonstrated.

Checklist

• Choose one business-critical form and its exact destination system.
• Document the path from browser response through WordPress and transport to the recipient.
• Send a recognisable test enquiry and verify receipt in the destination system.
• Define non-sensitive evidence, ownership and a repeatable test.
• Set an escalation route and an alternative intake channel for failed handoffs.

Want to know whether WordPress enquiries reliably reach your mailbox or CRM? DKSIGN can map the delivery path, test each handoff and establish a bounded evidence and escalation process.

WooCommerce 11.0 reserves stock in an unfinished checkout for 60 minutes by default. Whether that setting is right depends on the products, payment methods and actual buying behaviour in your store.

A customer starts checkout but does not complete the order. The stock remains temporarily reserved. When availability is limited, that raises a practical question: how long should another ready-to-buy customer wait before the item returns to sale?

If the window is too long, products may appear unavailable when they do not need to be. If it is too short, a reservation may be released while the customer is still completing payment. This matters especially for limited products, drops, promotional stock, bundles and payment methods with extra steps.

WooCommerce 11.0 sets the default reservation period for unfinished checkouts to 60 minutes and notes that stores can configure the value to suit their needs. That number is a starting point, not a universal recommendation for every business.

A sound decision starts with evidence from the store itself. How many checkouts remain unfinished? Which products run out of stock? How long do successful payments actually take? Does support hear about disappearing baskets or unavailable products? Dispatch cycles, replenishment patterns and connected systems also shape the answer.

The team can then test one adjusted window in a production-like staging environment. The test should cover checkout, stock release, order status, emails, reporting and any connected inventory or fulfilment systems. Acceptance criteria agreed in advance show whether the change improves availability without creating new friction elsewhere.

WooCommerce 11.0 also includes a database update. A version change should therefore be handled separately from an uncontrolled configuration change on the live store. A current backup, a clear rollback route and a named owner belong in the plan.

The aim is not to find a supposedly perfect number of minutes. It is to choose a reservation period that reflects the store's real payment times and stock conditions, then verify it with the store's own data.

Checklist

• Record the current reservation period and the operational reason behind it.
• Review unfinished checkouts, stock-outs, successful payment times and support questions together.
• Assess scarce products, drops, bundles and slower payment routes separately.
• Test one adjusted window on staging, including connected systems.
• Define acceptance criteria, an owner, a backup and a rollback route before production change.

Want to check whether the reservation period fits your WooCommerce store? DKSIGN can review the order and stock flow, test one bounded change on staging and document a safe route into operation.

The arrival of WordPress 7.1 RC1 creates an option to evaluate the next version. It does not create a reason to update a live business website.

In its official notice of 5 August 2026, WordPress says RC1 remains under development. It also says not to install, run or test the release on production or mission-critical websites, and directs testing to a test server and site.

For an owner or operational lead, that guidance resolves the immediate decision. Keep RC1 away from the live service. Any evaluation should be separately authorised, isolated and tied to a useful question about the site.

Availability is not approval

Release candidates are made available so that the next version can be examined before its stable release. That purpose can easily be misunderstood inside a business. Someone sees a new version, assumes it is almost finished and treats it as the next routine update.

The important distinction is not how close the version may appear to release. It is whether the version has a place in the environment under consideration. RC1 can have a legitimate place in a controlled test environment. It has no place on the production website that receives enquiries, supports bookings, provides customer access or underpins a daily workflow.

This gives decision-makers two separate approval questions:

• Is there a good reason to evaluate RC1 on an isolated copy?
• At some later point, is a stable release ready for this specific live site?

Answering yes to the first question says nothing about the second.

Testing is optional, even when staging exists

Having a staging site does not mean every preview release needs to be installed on it. Early testing takes time, creates results that need interpretation and may require the environment to be refreshed afterwards.

A business may have a sound reason to test when its website contains bespoke functionality or operational dependencies that deserve advance attention. Custom blocks, unusual publishing workflows, important forms and connections to external systems are examples. The purpose might be to identify areas that will need another look when the stable version becomes available.

A straightforward company site may gain little from that exercise. Waiting is a valid operational choice. The official notice makes testing possible in the right place; it does not make testing compulsory.

Isolation means protecting real operations

A useful test environment needs more than a different URL. It must prevent the test from reaching customers or changing live business data.

Forms and email delivery need to be contained. Connections to a live CRM, booking platform or other external service need suitable test settings or controls. Scheduled tasks should not trigger production actions. Search engines should not be offered a public duplicate of the website.

The test environment also needs enough fidelity to answer the intended question. The relevant theme, plugins, PHP version, configuration and integrations should reflect the live setup. Otherwise, a successful test may prove only that RC1 runs on a generic WordPress installation, not that the organisation’s own operating paths behave as expected.

Isolation and realism pull in different directions, so both need deliberate ownership. The environment should resemble production where that improves the test, while remaining unable to affect production.

Test the path, not just the page

Before RC1 is installed, write down the small number of outcomes that matter. For a service business, these might include receiving a complete enquiry, confirming an appointment, signing into a protected area or publishing an urgent content change.

Then run each path from beginning to end. Submitting a form is not enough if nobody checks whether the message arrives. Opening the editor is not enough if the normal review and publishing steps are omitted. A connected system has not been tested merely because the page containing its form still loads.

Record what was done and what was observed. A useful note identifies the function, the action, the expected result and any difference seen during the check. There is no need to turn an optional evaluation into an exhaustive audit of every page.

The result is advance information, not production clearance. It may identify something to revisit, or it may show no relevant difference within the chosen scope. Neither outcome establishes how a later stable release will behave on the final production configuration.

Give the live decision its own gate

Production approval belongs to a later process. It starts only once a stable version exists, and it depends on checks against the website the business actually operates.

That gate should have a named owner. The person carrying out the technical work can report what was tested, but someone with responsibility for the website’s business role must be able to see the boundary: preview evaluation was authorised; live deployment was not.

A concise release policy helps make that visible:

• Development builds, betas and release candidates stay off production.
• Preview testing requires a defined reason for the particular website.
• The test environment must be isolated from real customers, data and workflows.
• A stable release receives a fresh, site-specific production decision.

For WordPress 7.1 RC1, there is no need to speculate about defects, performance or a future release date. The official environment restriction is enough. Evaluate it only where testing belongs, and reserve production approval for a stable release and the real website that will depend on it.

A major release is not an automatic update signal. For operators of business-critical shops, it starts a specific approval decision: what matters to this shop, what has been validated under control, and who authorises production deployment?

Available does not mean approved

WooCommerce 11.0.0 is available. Before updating production sites, the official release note directs operators to review the highlights, update guide, and full changelog.

That is a sensible starting point. The real decision remains specific to each shop: does the release fit the theme, extensions, payment methods, shipping rules, and internal workflows in use? In DKSIGN’s view, a major release should not move automatically into production simply because it is available.

Which changes matter to the approval decision

For version 11.0, WooCommerce highlights areas including guest checkout, performance and backlog improvements, and analytics accuracy and resilience. The release note also identifies experimental developer features.

These points do not predict that your shop will have problems. They indicate where operators should look more closely when those areas matter to their commercial or technical setup. Experimental developer features belong in a separate assessment and should not be treated as ordinary production-ready highlights.

Four areas to validate before approval

The following structure is DKSIGN guidance. It is not a checklist quoted verbatim from WooCommerce.

1. 1. Interpret the official guidance
   Read the release highlights, update guide, and changelog. Mark only the changes that actually touch your theme, extensions, or operating workflows.
2. 2. Validate revenue-critical journeys
   Test the purchasing paths relevant to your shop in a controlled environment. These may include guest checkout, sign-in, basket, coupons, payment, shipping, order confirmation, and downstream integrations.
3. 3. Observe data and operations
   Where the business depends on them, review analytics output, background processing, and perceived performance. Compare the results with a known baseline.
4. 4. Record approval and recovery decisions
   Document the result, owner, update window, and the decision to take if validation fails. This is a DKSIGN operating recommendation, not a formal WooCommerce requirement.

Why the distinction matters commercially

A shop can be technically updated while still leaving operational questions unanswered. Without controlled validation, it remains unclear whether checkout, reporting, performance, and extensions work together as expected in the specific setup.

This does not mean WooCommerce 11.0 is unsafe or will damage a particular shop. It means a major version deserves a deliberate production approval. The process difference is modest, but it matters for accountability and operating continuity.

The practical approval question

Before updating, do not ask only whether WooCommerce 11.0 is available. Ask whether you understand the changes relevant to your shop, have validated its critical journeys, and have a documented production approval.

Prepare your WooCommerce update under control

If your shop needs a clear update assessment and production-approval process, DKSIGN can support interpretation, controlled validation, and technical implementation.

Source: WooCommerce Developer Blog, ‘WooCommerce 11.0 Release Notes’, 4 August 2026. The validation steps and risk interpretation are DKSIGN guidance, not requirements quoted verbatim from WooCommerce.

WordPress 7.0.2 is a security release published on July 17, 2026. For site owners, the relevant question is not simply whether an update was initiated. You need to know which corrected version is actually installed and whether the website’s business-critical functions still work as expected.

Which WordPress versions are affected?

The required version depends on the release branch the site was running:

• WordPress versions before 6.8 are not affected.
• WordPress 6.8 is affected only by the first of the two corrected issues. WordPress 6.8.6 contains the fix.
• WordPress 6.9 requires version 6.9.5, which corrects both issues.
• WordPress 7.0.x requires version 7.0.2, which also corrects both issues.

Forced automatic updates were enabled for affected versions. This shortened the time to installation, but it does not replace verification that the appropriate corrected version reached the specific site.

The official WordPress 7.0.2 release announcement lists the corrected release branches. On July 21, 2026, CISA also added the relevant vulnerabilities to its Known Exploited Vulnerabilities Catalog, as documented in its official alert.

How to prove which version is installed

Check the version number inside WordPress and, where possible, confirm it through the hosting or site-management platform as well. A useful record should identify the site, the time of the check and the version found.

• A site on the WordPress 6.8 branch must be running at least version 6.8.6.
• A site on the WordPress 6.9 branch must be running at least version 6.9.5.
• A site on the WordPress 7.0 branch must be running at least version 7.0.2.
• An update request or automatic-update email does not, by itself, prove the result.

Check that the update completed cleanly. A site left in maintenance mode, a pending database update or errors in the administration area all warrant closer inspection.

Which site functions should be tested after the update?

A correct version number does not show whether forms, logins and connected workflows still operate properly. Test the paths that generate enquiries, bookings or revenue.

• Submit every important contact, enquiry and application form using realistic test data. Confirm the on-screen response, message delivery and stored entry.
• Test login, password reset and the user roles that matter. A successful administrator login is not enough.
• For online stores, complete a test purchase through to the order confirmation. For booking systems, verify selection, availability, confirmation and notifications.
• Check handoffs to the CRM, helpdesk, newsletter platform or other connected services. Compare the transmitted fields and confirm that the record reached its destination.

Record when each test was performed and what happened. If a problem appears later, this helps establish whether it existed immediately after the update or arose afterwards.

How to assess possible signs of compromise

The update closes the known vulnerabilities in the relevant release branch. It does not establish whether someone accessed or changed the site before the update was installed.

Unknown administrator accounts, unexplained changes to content or settings, newly appearing extensions, unusual redirects, and suspicious login or server-log activity justify technical review. The same applies if forms suddenly send to different recipients or integrations transmit unexpected data without a planned change.

These observations are triage indicators, not forensic proof. They may have harmless explanations, while an uneventful spot check cannot conclusively rule out earlier access. Document and contain suspicious changes before cleaning up files, logs or accounts that may be relevant to a deeper investigation.

What evidence should you have at the end?

• The installed, corrected WordPress version for the site’s release branch
• A documented successful test of the site’s business-critical functions
• A confirmed test of data handoffs to connected systems
• An assessed list of unexplained changes or anomalies

This does not prove that the site was never affected. It does provide a clear basis for the next decision and shows where deeper investigation may be required.

Missing any of this evidence? With the DKSIGN WordPress Security Check, we verify the installed version, critical website functions and unusual changes, then provide a prioritised list of next steps.