DEV Community: Hamza Ahmad Aslam

How to speed up WooCommerce: a Core Web Vitals guide

Hamza Ahmad Aslam — Mon, 19 Oct 2026 14:00:31 +0000

Originally published at hamzaahmadaslam.com.

How this article was made: drafted with AI assistance from a researched brief, then checked against primary documentation before publishing.

Short answer: common causes of a slow WooCommerce store include an oversized hero image, too much JavaScript from plugins and tracking tags, pages that can't be cached, and a database bloated with old sessions, logs and autoloaded options. To speed up WooCommerce, profile the affected journey and prioritize the largest measured delay. Use field data as well as lab traces to verify the result.

Test the routes shoppers use: product pages, search, cart and checkout. The sections below cover different sources of delay. Start with the one your measurements identify.

Know the speed targets first

Google's Core Web Vitals are measured on real visitors, at the 75th percentile, on mobile and desktop separately.

Metric	What it measures	Good	Poor
LCP (Largest Contentful Paint)	When the main content is visible	≤ 2.5 s	> 4 s
INP (Interaction to Next Paint)	How quickly the page responds to taps and clicks	≤ 200 ms	> 500 ms
CLS (Cumulative Layout Shift)	How much the layout jumps around	≤ 0.1	> 0.25

Check your field data in the Core Web Vitals report in Search Console or at the top of PageSpeed Insights. Lab tools like Lighthouse are great for debugging, but the field numbers are the ones that count.

Step 1: Fix the Largest Contentful Paint

On most product and home pages, the LCP element is a big image. Make it cheap to download and ask for it early:

Serve WebP or AVIF at the size it is displayed, with proper srcset sizes.
Never lazy-load the LCP image. Lazy-load everything below the fold instead.
Give the hero image priority:

<img src="/hero-1200.webp" srcset="/hero-800.webp 800w, /hero-1200.webp 1200w"
     sizes="(min-width: 1024px) 50vw, 100vw" width="1200" height="800"
     fetchpriority="high" alt="Oak dining table in a bright kitchen">

Avoid sliders above the fold. They load several large images and a script before anything settles.
Preload only the one font file used in the first screen, and use font-display: swap.

Step 2: Put JavaScript on a diet (this is where INP lives)

A busy browser main thread can delay interactions even when the server responds quickly. Open Chrome DevTools, go to the Performance panel, record a tap on "Add to cart" and look for long tasks.

Common culprits and fixes:

Plugins that load everywhere. A form, slider or review plugin often enqueues its scripts on every page. Unload them on pages that don't use them, with your theme's functions.php or an asset manager.
Cart fragments. Recent WooCommerce versions only load the wc-cart-fragments script where a mini-cart needs it. If your theme or a plugin still loads it everywhere, it can send an uncached ?wc-ajax=get_refreshed_fragments POST that skips the page cache on the first page view in a tab session, when the stored cart hash no longer matches the cart cookie after a cart change, and when stored fragments expire after 24 hours. Other page views reuse fragments saved in sessionStorage.
Tag managers. Every marketing pixel adds work. Remove tags nobody reads, load the rest after the page is interactive, and consider server-side tagging for the heaviest ones.
Chat widgets and heatmaps. Load them on interaction (for example, when the visitor clicks "Chat") instead of on page load.

Here is a small, safe example that stops a plugin's script loading outside the pages that need it:

add_action( 'wp_enqueue_scripts', function () {
    if ( ! is_page( 'contact' ) ) {
        wp_dequeue_script( 'example-form-plugin' );
        wp_dequeue_style( 'example-form-plugin' );
    }
}, 100 );

Use your plugin's real script handles, which you can find in the page source or with the Query Monitor plugin.

If cart fragments are part of that JavaScript work, check which pages load wc-cart-fragments and whether they need it to keep a cart widget up to date.

Step 3: Cache what can be cached (and nothing else)

Full-page caching is the biggest win for anonymous visitors, but a store has pages that must never be cached:

Cart, checkout and my-account pages
Any request carrying WooCommerce's session cookies, such as woocommerce_items_in_cart and wp_woocommerce_session_*

Most good hosts and caching plugins know these rules. Check them anyway, because a cached checkout is a serious bug. On top of page caching, add a persistent object cache (Redis or Memcached) so logged-in shoppers and admin pages stop hammering the database.

Step 4: Clean the database

WooCommerce stores collect clutter quietly. Look at these three places:

Autoloaded options. On WordPress 6.6 and later, autoload can use yes, on, auto-on and auto for values WordPress loads by default, while WP-CLI's --autoload=on filter only counts on and yes. Use the full autoloaded-options measurement method to measure the full set and find the largest entries before changing anything.
Scheduled actions. WooCommerce's Action Scheduler keeps a log of completed jobs. Review failed actions before removing their history, agree a retention policy for completed actions, and make sure WP-Cron runs (a system cron is more reliable than visitor-triggered cron).
Orders storage. Check whether the store would benefit from High-Performance Order Storage (HPOS), which moves orders out of the generic posts tables into dedicated ones. It's the default for new stores. Older stores can switch from WooCommerce → Settings → Advanced → Features. First check plugin compatibility and enable compatibility mode (order sync). Let the sync finish, then switch, and keep compatibility mode on for a while so you can revert if something breaks.

For order storage, see migrating to WooCommerce High-Performance Order Storage. For background-job buildup, see how to clear a WooCommerce Action Scheduler backlog.

Step 5: Server basics that still matter

A PHP version that WordPress and WooCommerce recommend (8.3 or newer), with OPcache enabled. Confirm that your plugins and theme support the target PHP branch on staging before you upgrade.
HTTP/2 or HTTP/3 and Brotli or gzip compression
A CDN for images, CSS and JS
A server close to your customers, or edge caching if they're spread out

Measure, change one thing, measure again

Performance work goes wrong when ten changes land at once. Keep a simple log: what you changed, the Lighthouse or WebPageTest result before and after, and the field data 28 days later. If a change doesn't help, roll it back.

During my time as website developer at Half Price Packaging, the site achieved a 10x boost in performance and a 5x increase in traffic. The work there included WordPress admin and theme changes, performance improvements and security cleanup. Those numbers describe that site; another store needs its own baseline.

Want a performance review of your store? Explore my WooCommerce Speed Optimization service or request a store audit.

Fix INP in WordPress by finding the slow interaction

Hamza Ahmad Aslam — Sat, 17 Oct 2026 14:00:31 +0000

Originally published at hamzaahmadaslam.com.

How this article was made: drafted with AI assistance from a researched brief, then checked against primary documentation before publishing.

To fix INP in WordPress, start by reproducing the exact tap or key interaction that feels slow, then record it in Chrome DevTools and split its delay into input, processing, and presentation. Trace the slowest phase to the main-thread task that overlaps it, make one controlled change, and repeat the same mobile interaction before looking for confirmation in field data.

Fix INP in WordPress by tracing one interaction

INP measures the latency of clicks, taps, and keyboard interactions across a page visit. For most visits, the slowest interaction becomes the page's INP candidate, with outlier handling for pages that have many interactions. Google evaluates the field result at the 75th percentile of page loads, split between mobile and desktop, with 200 ms or less classed as good and more than 500 ms as poor. The official INP reference explains the calculation and thresholds.

That definition points to the first diagnostic rule: do not optimize a generic "speed score." Find the interaction.

Choose interactions that represent what visitors do

Start with controls that can change the page after it has loaded. On a typical WordPress site, useful candidates include:

Open and close the mobile menu.
Type into the first meaningful form field.
Open a search, filter, accordion, modal, or account control.
Accept or reject a consent choice if that action starts other scripts.
Submit a form or advance to its next step.

If field data or your own monitoring identifies a page or interaction target, start there. If it does not, choose the busiest page templates and the interactions a visitor is most likely to use.

A fast loading page can still feel laggy. Loading and responsiveness measure different work. A page can finish its initial render, then run expensive JavaScript or rendering work when a visitor taps a menu or presses a key.

Freeze the mobile setup before you compare traces

Use the same physical phone for the baseline and the retest. Record the setup before you touch code.

Mobile interaction setup
Device model: [record]
OS version: [record]
Chrome version: [record]
Network: [record]
Page URL or template: [record]
Logged-in state: [record]
Consent state: [record]
Form or cart state: [record]

Keep those conditions the same for the before and after trace. The goal is repeatability, not a synthetic score that happens to be green.

Record a repeatable menu and form test

Run one interaction per Performance recording. Open the page in the same state, start a recording, perform the gesture, wait for the visual response, then stop. Repeat the same action after your controlled change.

The table below is an illustrative worksheet. Replace every bracketed field with your own trace data.

Scenario	Exact gesture	Before trace	Dominant phase	Overlapping task or render work	One controlled change	Expected after change	Function check
Illustrative: mobile menu	Tap menu button once	[record]	[input / processing / presentation]	[script, function, layout or paint]	[change one cause]	Same menu behavior with less delay in the targeted phase	Open, close, focus, Escape or keyboard control
Illustrative: form typing	Focus first field and type the same text	[record]	[record]	[record]	[change one cause]	Typing stays responsive and validation still runs	Keyboard typing, Tab order, validation
Illustrative: consent action	Tap the same consent choice	[record]	[record]	[record]	[change one cause]	Choice still applies and any permitted scripts start as designed	Consent state and dependent scripts
Illustrative: analytics-sensitive action	Repeat the menu or form action that emits analytics	[record]	[record]	[record]	[change one cause]	Interaction improves without dropping or duplicating the intended event	Analytics event count and payload shape

Do not combine several changes before the retest. If you remove a listener, delay a script, alter a DOM update, and change CSS at once, the faster trace will not tell you which change mattered.

Split the delay into input, processing, and presentation

Every measured interaction has three parts. The web.dev INP optimization guide defines them as input delay before callbacks start, processing duration while callbacks run, and presentation delay until the browser presents the next frame.

Use the largest phase to decide where to inspect next.

Phase that dominates	What it means	Where to look
Input delay	The main thread was busy before your handler could start	Tasks immediately before the interaction, script evaluation, timers, other callbacks
Processing duration	The event callbacks themselves took too long	Click, pointer, key, input, or change handlers and the functions they call
Presentation delay	The browser spent too long getting the next frame ready	Style recalculation, layout, paint, large DOM updates, rendering work

Chrome's Performance panel exposes this split in the Interactions track. The Performance panel reference shows the input and presentation whiskers and the phase timings in the interaction tooltip. Chrome 132 added phase timings to live interaction metrics, so screenshots from older Chrome versions can look different; see the Chrome 132 DevTools notes.

A quick PerformanceObserver can help when you want event timings in the Console while reproducing a control. Treat this as a diagnostic view, not as your field INP implementation.

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.log({
      event: entry.name,
      total: entry.duration,
      input: entry.processingStart - entry.startTime,
      processing: entry.processingEnd - entry.processingStart,
      presentationApprox: Math.max(
        0,
        entry.startTime + entry.duration - entry.processingEnd
      ),
    });
  }
});

observer.observe({
  type: "event",
  buffered: true,
  durationThreshold: 16,
});

The Event Timing API allows durationThreshold for event entries, with 16 ms as the lowest value. Event durations are rounded, so the presentation value above is approximate. Raw event timing also has measurement limits, so do not turn this snippet into your own INP calculator.

Isolate the long task that overlaps the interaction

Once you know the slow phase, stay on the same trace. A long task is main-thread work lasting at least 50 ms. Current DevTools marks long tasks in the Main track with a red triangle and shades the portion beyond 50 ms.

Use this sequence:

Select the slow interaction in the Interactions track.
Align its timing with the Main track.
If input delay is high, inspect the task running before the event callback starts.
If processing is high, expand the event task and follow its call tree.
If presentation is high, inspect style, layout, and paint work after the callback.
Record the narrowest useful owner: script URL, function, plugin asset, theme asset, or browser rendering work.

A script filename can suggest ownership, but it does not prove that a whole plugin is the problem. The useful finding is narrower: this interaction waited on this task, or this handler caused this rendering work.

Third-party JavaScript can compete for main-thread time too. At this stage, record which external task overlaps the interaction. Leave the wider business decision about removing or replacing that script for a separate audit.

Use field attribution when the slow interaction will not reproduce

A lab trace is controlled. Field INP comes from visitor sessions with their own devices, network conditions, page states, and behavior. The web.dev guide to lab and field differences notes that CrUX field reports use a 28-day distribution, while a lab run uses one controlled setup.

CrUX can tell you that a page or origin has an INP problem, but it cannot identify the exact cause. If you collect your own real-user monitoring, the web-vitals attribution build can add the interaction target, interaction type, and the three phase durations. The current API is documented in the official GoogleChrome web-vitals repository.

import { onINP } from "web-vitals/attribution";

onINP(({ value, attribution }) => {
  console.log({
    inp: value,
    target: attribution.interactionTarget,
    type: attribution.interactionType,
    input: attribution.inputDelay,
    processing: attribution.processingDuration,
    presentation: attribution.presentationDelay,
  });
});

Use that data to group slow sessions by page and interaction target, then reproduce the same control in DevTools. Do not send form values or other user-entered content as diagnostic labels. Keep your existing consent and analytics rules intact when you add performance telemetry.

A Lighthouse run or a single DevTools trace is lab evidence. Do not describe its score as an INP field measurement. Field and lab data answer different parts of the diagnosis.

Can content-visibility improve INP in WordPress?

It can help when presentation delay is the problem. content-visibility: auto lets the browser skip rendering work for offscreen content until that content is needed. web.dev lists it as a way to reduce rendering work that can affect INP.

Use it as a controlled test on long pages with expensive offscreen sections. If presentation delay falls while input and processing stay similar, the trace supports that direction. If a JavaScript handler dominates, content-visibility is aimed at the wrong phase.

Retest keyboard access, focus behavior, dynamic sections, and the same menu or form path after the CSS change. A rendering optimization is only useful if the interaction still works.

Retest the function before you trust the faster trace

After one controlled change, run the exact same mobile sequence and fill the "Expected after change" column. The expected result is lower time in the phase you targeted, with the feature still behaving the same way.

Check the paths that often break when interaction code changes:

Open and close the menu with touch and keyboard controls.
Type, delete, Tab, and submit in the form.
Repeat the consent choice from the same starting state.
Confirm the intended analytics event still fires once, with the expected shape.
Repeat any interaction that was delayed until first input.

Then compare field context. CrUX will not change immediately because it summarizes a rolling 28-day field distribution. Your own RUM can provide more direct interaction attribution if you already collect it.

This also explains why INP can get worse while page-load metrics barely move. A new key handler, menu callback, tag, or DOM update can add work only when the visitor interacts. The initial loading path may remain almost unchanged.

Decide what to fix next

If the trace points back to loading the main visual content rather than click or typing responsiveness, use the WordPress LCP image optimization guide for that separate problem. To set phase targets before another pass, the Core Web Vitals budget calculator splits INP into input, processing, and presentation budgets.

If the slow path crosses theme code, plugin JavaScript, and browser rendering work, WordPress performance optimization can use the same trace to scope the fix without changing unrelated parts of the site.

Headless WordPress with Next.js: when it fits

Hamza Ahmad Aslam — Fri, 16 Oct 2026 14:00:53 +0000

Originally published at hamzaahmadaslam.com.

How this article was made: drafted with AI assistance from a researched brief, then checked against primary documentation before publishing.

Short answer: headless WordPress with Next.js is worth it when you need a very fast, highly custom front end, several channels fed from one CMS, or a team that already works in React. It isn't worth it for a brochure site or a store that leans on page builders and plugins that expect to render the front end. Decide based on content workflow and plugin dependencies, not on hype.

"Headless" means WordPress keeps doing what editors love (writing, media, users, revisions) while a separate application (here, Next.js) renders the pages visitors see. The two talk over an API. It's a powerful setup, but it moves a lot of work from WordPress onto you.

What changes when WordPress goes headless

Area	Traditional WordPress	Headless WordPress with Next.js
Rendering	PHP theme renders every page	Next.js renders pages, usually statically with revalidation
Plugins	Anything that outputs HTML just works	Only data survives; the front end has to be rebuilt
Previews	Built in	Needs a preview route and draft mode
SEO tags	Output by your SEO plugin	Fetched from the API and mapped to Next.js metadata
Hosting	One server	Two systems: WordPress and the front end
Security surface	Public WordPress site	WordPress can be locked away; the public site is mostly static

The last row is an underrated benefit. When visitors only ever reach the Next.js front end, the WordPress admin can sit behind an allowlist, a VPN or a separate subdomain, which can reduce direct exposure when access restrictions are enforced. A separate hostname alone is not an access control.

When headless WordPress with Next.js is the right call

Performance is a product requirement. Statically generated pages served from a CDN are hard to beat on Core Web Vitals, and you control every byte of JavaScript.
The design is highly interactive. Complex filters, dashboards, animation or 3D are easier in React than in a PHP theme.
One CMS feeds several channels. A website, an app and a kiosk can all read the same content.
Your team already ships React. You get type safety, component libraries and modern tooling.

When it's the wrong call

The site depends on page builders. Elementor, Divi and similar builders store layouts that only their own PHP can render. Going headless means rebuilding every layout by hand.
Plugins render part of the front end. Forms, bookings, memberships and many WooCommerce extensions output their own HTML and scripts. Each one needs an API-based replacement.
Editors need true WYSIWYG. Block content can be rendered in Next.js, but matching every core and third-party block takes real effort.
The budget is tight. Two systems cost more to build, host and maintain than one well-tuned theme.

If most of these apply, a fast classic theme is usually the better investment.

REST API or WPGraphQL?

WordPress ships with the REST API out of the box. The popular WPGraphQL plugin adds a GraphQL endpoint.

REST API: no extra plugin, simple to cache, and many plugins already register their own routes. You may need several requests per page.
WPGraphQL: fetch exactly the fields a page needs in one request, with a strongly typed schema. It adds a plugin to keep updated, and some plugins need extensions to expose their data.

For a blog-style site the REST API is often enough. For content models with many relationships, GraphQL usually leads to cleaner front-end code.

A caching strategy that keeps content fresh

The classic mistake is fetching WordPress on every request, which makes the front end as slow as the back end. Instead, render statically and refresh on change:

Fetch content at build time or on first request, and cache it with a tag such as posts.
In WordPress, send a webhook when a post is saved or deleted.
In Next.js, a small route handler verifies a shared secret and calls revalidateTag("posts", "max").

// app/api/revalidate/route.ts
import { revalidateTag } from "next/cache";

export async function POST(request: Request) {
  const secret = process.env.REVALIDATE_SECRET;
  if (!secret || request.headers.get("authorization") !== `Bearer ${secret}`) {
    return new Response("Unauthorized", { status: 401 });
  }
  revalidateTag("posts", "max"); // mark stale; a subsequent request can trigger background refresh
  return Response.json({ revalidated: true });
}

Cached pages remain available while revalidation happens. With the "max" profile, a visitor may receive stale content while a background refresh runs. Keep a time-based revalidation as a safety net in case a webhook is missed.

Previews, SEO and the details people forget

Previews

Editors expect a "Preview" button that works. In Next.js, use Draft Mode on a preview route that checks a secret, then fetch the latest revision with authentication. WordPress Application Passwords are a simple way to authenticate server-to-server requests.

SEO

Your SEO plugin still does the thinking; you just render its output. Yoast SEO, for example, adds a yoast_head_json field to REST responses with the title, description, canonical URL and Open Graph data. Map those fields to Next.js metadata, and generate the sitemap and robots rules in Next.js so they list front-end URLs, not WordPress ones.

Images and links

Rewrite image URLs to go through Next.js image optimisation, or serve them from a CDN.
Turn internal links inside post content into front-end paths so visitors never land on the WordPress domain.
Redirect the old WordPress URLs if the structure changes, to keep existing rankings.

Security checklist for a headless setup

Put the WordPress admin on its own subdomain and restrict it (IP allowlist, VPN or an access proxy).
Disable what the front end doesn't use: XML-RPC, unused REST routes and user enumeration.
Keep secrets (API tokens, revalidation keys) on the server side only.
Keep WordPress and plugins updated. Going headless does not remove that need. My WordPress security hardening checklist still applies in full.

How to decide in one afternoon

List every plugin and mark whether it outputs front-end HTML.
List every page template and how it's built (blocks, builder or custom fields).
Estimate the rebuild cost for each front-end feature.
Compare that with what you'd gain in speed, flexibility and security.

If the rebuild list is short and the gains are clear, go headless. If not, invest in the classic stack and revisit later.

For concrete implementations, see headless WordPress examples and their architectures. If you are still deciding, use the free headless WordPress decision aid to weigh the same questions.

Planning a custom WordPress or headless build? Learn about my Custom WordPress Development service or let's talk it through.

Run a WordPress backup restore test and prove recovery works

Hamza Ahmad Aslam — Thu, 15 Oct 2026 14:00:31 +0000

Originally published at hamzaahmadaslam.com.

How this article was made: drafted with AI assistance from a researched brief, then checked against primary documentation before publishing.

A WordPress backup restore test should end with a working isolated copy, a timed recovery log, and a pass/fail record for the business tasks that matter. Restore a representative backup away from production, verify the files and database together, run defined checks, and record anything missing or unavailable.

What a WordPress backup restore test must prove

For a typical WordPress site, recovery needs both the database and the site files. The WordPress backup guidance says you need both to fully restore a typical site and recommends treating them as one backup set created around the same time so they stay consistent. The database and files hold different parts of the site.

Do not assume payment or mail credentials sit outside that backup. WooCommerce gateways built on WC_Settings_API store their settings in WordPress options, so a database restore can bring live gateway keys into the isolated copy. WooCommerce Stripe, for example, uses the woocommerce_stripe_settings option.

Mail plugins can behave the same way. WP Mail SMTP stores plugin options in wp_options and can also read credentials from wp-config.php constants. A full files-and-database restore can therefore carry live mail settings too.

Reserve "outside dependency" for access that the backup does not contain. Examples include DNS or registrar access, a hosting account, object-storage credentials held outside WordPress, or keys available only through server environment variables.

Define recoverable assets

Write the acceptance target before you touch a backup. This stops a successful homepage load from becoming a false pass.

Recovery item	What you expect to recover	Evidence to collect
Database	Posts, pages, users, settings and plugin-created tables that existed at the backup point	Open known records and complete one safe write
Site files	Themes, plugins, uploads, custom code and other required files	Load media, theme output and custom functionality
Configuration	The configuration needed for the isolated target to connect and boot	Confirm the restored copy uses only test resources
Restored secrets	Payment or mail credentials that may arrive in the database or files	Confirm live credentials are removed or replaced before testing
External dependencies	Host, DNS, object-storage or environment-level access required for recovery but absent from the backup	Mark each one available or unavailable

The WordPress file backup guidance explains that files and the database are separate. It also calls out wp-content and wp-config.php as important parts of a file backup. Your recovery plan may rebuild WordPress core from a clean distribution instead of storing it, but that choice needs to be written down.

After creating your first backup, run one restore drill before you depend on it. Repeat the drill when the backup tool, host, restore method or site architecture changes. Set the ongoing schedule from how much change you can afford to lose and how quickly the site must return.

Restore in isolation, not over production

A restore test needs a target that cannot overwrite the live site. A local installation, private development site or separate staging environment can work. WordPress documents development copies as a way to work without interrupting the live installation.

Give the restore target its own database credentials and its own file path. Do not allow normal browser traffic to reach a restored WooCommerce copy until you have made it safe.

Before the first page load, give the copy a URL different from production, disable WP-Cron, disable Action Scheduler's default queue runner, and block outgoing mail. WordPress checks for due WP-Cron tasks on page loads, so place this in the restored wp-config.php before browsing the copy:

define( 'DISABLE_WP_CRON', true );

WooCommerce Subscriptions has another safeguard, but do not depend on it alone. Its staging-site handling switches to staging mode when the current site URL differs from the stored live URL. If the URL stays the same, Subscriptions can remain in live mode. Its staging mode also continues to trigger scheduled renewal and expiration events by default, although automatic subscription payments and subscription-related emails are suppressed.

After the database import, but still before the first browser request, clear or replace production gateway keys and switch each gateway you intend to exercise to its test or sandbox mode. Keep outbound mail blocked because WordPress, WooCommerce or another plugin may still send mail even when Subscriptions itself is in staging mode.

If the site uses WooCommerce Subscriptions, confirm the staging-mode notice or status appears when you first open the safe copy. Never run a restored WooCommerce copy under the production URL with live gateway keys in place.

Start the recovery timer before you retrieve the backup and credentials. That captures the access steps that would also exist during an incident.

Restore the same backup set you intend to trust

Use the restore path that matches the artifact you have. For a host snapshot or backup plugin package, use that product's documented restore flow on the isolated target. For separate file and database backups, WordPress documents the typical restore order as files first, then the database.

For a raw SQL dump, use a new empty database when possible. After restoring the files, replace the database constants in the restored wp-config.php with the isolated target's own credentials before running any reset or import command. Then confirm which database WP-CLI will use:

wp config get DB_NAME
wp config get DB_HOST

Both values must point to the isolated test database. Do not run wp db reset or wp db import while that wp-config.php still points at production.

If you need to empty a reused isolated database and its database user can drop and create that database, run the reset without --yes so you see the confirmation before it proceeds:

wp db reset
wp db import backup.sql

wp db reset runs DROP DATABASE and CREATE DATABASE statements using the database credentials loaded from wp-config.php. The database user therefore needs permission to drop and create that database. If your host does not give that user permission to create databases, recreate the empty test database through the host's database panel instead.

The wp db import reference says the import uses database credentials from wp-config.php, does not create the database, and only performs the tasks defined in the SQL.

That last point matters during a restore drill. Importing a dump over an old staging database can leave a table that the dump never contained. A later check could mistake that leftover table for recovered data. Starting with an empty database makes everything present after the import attributable to the backup.

After the import, sanitize the restored payment and mail configuration before allowing a browser request. Make sure the restored URL differs from production, live gateway keys are cleared or replaced, outbound mail is blocked, WP-Cron remains disabled, and any required Action Scheduler runner protection is in place.

You do not need FileZilla. WordPress lists host backup software, FTP clients and shell access as ways to move site files. Use the method that fits your backup format and access level.

A staging URL must differ from production if you rely on WooCommerce Subscriptions to detect the clone as staging. If your restore tool does not handle stored URLs, use a method that understands serialized WordPress data. WP-CLI's wp search-replace command handles serialized data, and its --dry-run flag reports changes without saving them.

Verify content and business tasks against the backup point

Check the restored site against what existed when the backup was created, not against production now. Content created after the backup point is outside that recovery point. Content that should have existed at the backup point but is missing is a recovery gap.

Use checks that prove both read and write behavior:

Log in to WordPress admin with an authorized test account after the safety controls are in place.
Open a known page or post that existed before the backup point.
Load representative images and downloadable files.
Save a disposable draft, refresh the page and confirm the change persists.
Open functionality provided by custom code or a business-critical plugin.
For a WooCommerce demo, open a product, add it to the cart and reach checkout with live payment credentials already removed or replaced.
Record any task you cannot run because a required outside service is unavailable.

A pass means the expected item is present and the defined task works on the restored copy. A failure means something that should have been recoverable is missing or broken. Unavailable means the restore reached an outside dependency that you intentionally did not provide to the test environment.

Use this restore log and acceptance checklist

Copy this log for each drill. Fill it with the backup identifier and the exact target you used.

Restore log field	Value to record
Backup identifier
Backup creation time
Backup storage location
Isolated restore target
Database target
Recovery started at
Files restored at
Database restored at
Acceptance checks finished at
Elapsed recovery time	Acceptance checks finished at minus recovery started at
Overall result	Pass, failed, or incomplete
Recovery gaps
Unavailable dependencies
Manual steps to add to the runbook

The next table is an illustrative demo scenario. Every row, item name, path, status and result below is illustrative, and every result is an expected result rather than an observed outcome.

Illustrative row	Illustrative demo item	Illustrative backup scope	Expected classification	Expected acceptance evidence
Illustrative A1	Illustrative page named `Restore marker`	Included in illustrative database backup	Expected survived	The illustrative page opens with content from before the illustrative backup point
Illustrative A2	Illustrative file `illustrative-product-photo.jpg`	Included in illustrative uploads backup	Expected survived	The illustrative image loads from the restored media path
Illustrative A3	Illustrative WooCommerce product and cart data	Included in illustrative database and plugin files	Expected survived	The illustrative product opens and can be added to the cart without a live payment
Illustrative A4	Illustrative path `wp-content/uploads/private-reports/illustrative-report.csv`	Excluded by the illustrative backup policy	Expected failed, lost	The illustrative required file is absent, so the backup policy needs correction
Illustrative A5	Illustrative object-storage key held only in a server environment variable	Excluded from the illustrative WordPress backup	Expected unavailable dependency	The illustrative outside credential is unavailable and is recorded separately
Illustrative A6	Illustrative production payment gateway credential	Included in the illustrative database backup, then cleared or replaced before browser access	Expected restored and neutralized	The illustrative live credential does not remain active on the restored copy
Illustrative A7	Illustrative administrator login and draft save	Included in illustrative database and files	Expected survived	The illustrative user can log in and save a disposable draft

Replace the illustrative rows with your own acceptance criteria before the test. If a required item is marked lost, the drill has found a backup gap. If a dependency is unavailable by design, decide before an incident whether that blocks recovery or has a separate recovery procedure.

Record recovery gaps and elapsed time

Use one timing rule on every drill: start when the responder begins retrieving the backup or access needed for recovery, and stop when the required acceptance checks finish. Record the file restore, database restore and acceptance milestones separately so the slow step is visible.

Treat the measured elapsed time as evidence for that tested backup, target and procedure only. A local restore time is not a promise for a different host, database size or recovery path. Treat the exercise as a small WordPress disaster recovery test with the same timer and acceptance rules each time.

Classify each gap so the next action is clear:

Fix a backup gap when a required file, table or record from the backup point is missing.
Fix a procedure gap when recovery depends on a manual step that was not documented.
Fix an access gap when the person running the drill cannot reach a backup, credential or account they need.
Record an unavailable dependency when the test intentionally excludes an outside service or account that is not contained in the backup.

Keep the failed acceptance row with the restore log after you fix it. On the next drill, that row becomes a regression check.

If the restore or move fails, reset the isolated target and try again

An isolated target is disposable. If a move or restore attempt fails, reset or recreate that target, correct the procedure, and restore the same backup again. Do not turn production into the retry target.

Whether the staging database is restored depends on the backup and restore scope. For an SQL dump, wp db import only performs the tasks defined in that SQL. It does not prove that unrelated tables already present in the target came from the backup.

For a valid drill, import into a new empty database or empty the isolated target first. Before using wp db reset, replace any restored production database credentials in wp-config.php with the isolated database credentials and confirm DB_NAME and DB_HOST with wp config get. The reset command drops and recreates the database named by that configuration, so it must never run against a wp-config.php that points at production.

If the test database user lacks permission to create the database, recreate the empty database through the host's database controls instead of using wp db reset. Then import the backup into that empty target.

If the package is files-only, the database is not restored. Check the package contents and the target database credentials before every retry.

Put the verified restore path into normal maintenance

Once recovery is repeatable, keep it as the fallback behind testing WordPress plugin updates before they reach production so update work starts with a known recovery path. If you want backup ownership, restore drills and recovery documentation handled as ongoing operations, the WordPress maintenance service covers that work.

Custom WordPress plugin cost: what to include in the brief

Hamza Ahmad Aslam — Tue, 13 Oct 2026 14:00:31 +0000

Originally published at hamzaahmadaslam.com.

How this article was made: drafted with AI assistance from a researched brief, then checked against primary documentation before publishing.

A useful custom WordPress plugin cost estimate starts with a brief that turns workflows, users, integrations, failure paths, acceptance checks, and ownership into scope. Give a developer that scope before asking for a fixed price, then price the work from estimated effort using the supplier's agreed rate instead of a generic market band.

What drives custom WordPress plugin cost before a quote

Broad labels such as "simple plugin" or "complex WooCommerce plugin" are weak estimating inputs. A quote becomes more defensible when the developer can identify the actions to build, the paths to test, and the support obligations that remain after launch.

A useful cost breakdown starts with these scope areas:

Scope area	What to put in the brief	Why it changes the estimate
Workflow	Trigger, steps, decisions, successful outcome	More branches mean more behavior to build and test
Users	Who can view, create, edit, approve, retry, export, or configure	Different permissions create separate application states
Data	Inputs, outputs, validation rules, retention, migration needs	More data rules create more development and test cases
Integrations	External system, trigger, fields, authentication owner, failure behavior	An external dependency adds states outside WordPress
Acceptance	A repeatable action and its expected result	Clear checks define what "done" means
Support	Update checks, incident response, small changes, documentation	Ongoing obligations affect the total budget
Ownership	Source access, handover, third-party components, maintenance responsibility	The buyer needs to know what remains available after delivery

If environment compatibility is part of the deliverable, put the supported WordPress and PHP baseline in the brief. WordPress provides Requires at least and Requires PHP fields in its plugin header requirements, so compatibility should be an explicit project decision rather than an unstated assumption.

This is also where custom plugin pricing separates from a generic feature list. A request such as "add an approval screen" says little about who can approve, what happens after rejection, what gets recorded, or how the buyer proves the workflow works.

Describe the workflow and users before listing features

Start each workflow with an event, an actor, and an expected outcome.

A useful pattern is:

When [event happens], [user or system] does [action], subject to [rules], and the expected result is [observable outcome].

That format exposes hidden decisions. A request to "let staff approve submissions" still needs answers about who counts as staff, whether approval can be reversed, what happens to rejected records, and who receives a notification.

For each user type, state what that person may:

view;
create or submit;
edit;
approve or reject;
retry;
export;
delete;
configure.

WordPress separates roles from capabilities. Its roles and capabilities documentation describes roles as sets of capabilities, and custom capabilities can be used for custom admin or front-end areas.

That distinction belongs in WordPress plugin requirements. "Administrators only" may be enough for a tiny internal tool, but a business workflow often needs permissions based on actions rather than role names.

The current_user_can() reference confirms that the function checks whether the current user has a specified capability. It also discourages checking particular role names directly because that can produce unreliable results.

In my current agency role I build custom ACF-powered plugins for client WordPress sites. The useful part of the brief is the point where business language becomes behavior that both sides can test.

Define integrations and failure paths without designing the implementation

An integration requirement needs more than the other system's name.

For each external system, write down:

what starts the exchange;
which records and fields move;
which system owns each value;
who supplies credentials and test access;
what the user should see while the other service is unavailable;
what should happen after authentication fails;
how a failed operation becomes visible to support staff;
whether an authorized user needs a manual retry;
what should happen if the same event arrives again.

Keep this at requirements level. Retry algorithms, queue design, caching, and request scheduling belong in technical design after the behavior has been agreed.

WordPress provides an HTTP API for communication with external APIs. The wp_remote_request() reference shows that the function returns the result of WP_Http::request().

The WP_Http::request() reference shows two different failure cases that a plugin must distinguish. A request-level failure, such as a transport exception, returns WP_Error. If the remote server sends an HTTP response, including an error status such as 401 or 500, WordPress returns a response array whose response.code value contains the HTTP status code.

The brief should therefore define behavior for both transport failures and error responses from the other service. Authentication rejection, invalid data, and a server error need their own expected behavior even though WordPress received an HTTP response.

A sentence such as "sync orders to the fulfillment system" leaves those states open. A scoped version says what triggers the sync, what information is sent, what the expected successful state looks like, and what staff can do when delivery fails.

Agree acceptance checks before agreeing the fixed scope

Acceptance checks let the buyer and developer test the same definition of completion. They should describe an action, setup conditions, and an expected result.

All rows below are illustrative.

Illustrative check	Procedure	Expected result
Illustrative permission check	Sign in as a user who lacks the approval capability and open the approval action	Expected: the user cannot perform the approval
Illustrative successful workflow	Submit an eligible record and complete the defined approval steps	Expected: the record reaches the agreed final state
Illustrative integration failure	Make the configured external service unavailable in a test environment, then trigger the integration	Expected: the failure becomes visible through the agreed support path
Illustrative retry check	Retry an illustrative failed operation through the agreed admin action	Expected: the operation is attempted again without creating an unintended duplicate
Illustrative exclusion check	Attempt an explicitly excluded workflow	Expected: the plugin does not provide that behavior

Acceptance checks should cover the paths that change the quote. Permissions, failures, reversal rules, WooCommerce state changes, and external systems usually deserve their own checks when they are in scope.

Do not write "works correctly with WooCommerce" as an acceptance condition. Name the store action, setup, and expected state that the buyer will test.

Compare three illustrative plugin briefs

The following samples contain no market prices. Their purpose is to show how added requirements create more work and future support responsibility.

Illustrative sample A: an internal admin utility

Illustrative workflow: An authorized content team member selects an existing WordPress record, applies an internal status, and sees that status in the agreed admin view.

Illustrative users: Only users with the agreed capability can change the status. Other users may see it only if the brief explicitly permits that.

Illustrative integrations: None.

Illustrative acceptance: An authorized user can set and change the status. An unauthorized user cannot perform the change. The selected status remains attached to the intended record.

Illustrative assumptions: The existing site and record type remain in place. The buyer supplies staging access and confirms the required capability mapping.

Illustrative exclusions: No public-facing interface, external API, data import, reporting dashboard, or automated notification.

The estimate stays narrow because the brief has one workflow, a limited permission model, and no external dependency.

Illustrative sample B: a WooCommerce review workflow

Illustrative workflow: A store team member identifies an order that meets agreed conditions, records a review decision, and exposes the resulting status to the agreed staff users.

Illustrative users: Store staff can review. A separate authorized user can change plugin configuration.

Illustrative integrations: WooCommerce is part of the site context, but there is no external system in this sample.

Illustrative acceptance: Eligible and ineligible orders follow their defined paths. Users without the required capability cannot change the review state. Reversing a decision follows the rule stated in the brief.

Illustrative assumptions: The buyer supplies a staging copy with the WooCommerce extensions that must be supported and identifies the order states used by the business.

Illustrative exclusions: No payment gateway changes, fulfillment API, accounting sync, historical data migration, or new customer dashboard.

This sample creates more estimating work because order state, permissions, reversal behavior, site compatibility, and regression checks all need definition.

Illustrative sample C: a WooCommerce fulfillment integration

Illustrative workflow: An eligible WooCommerce order triggers an outbound fulfillment request. Staff can see whether the operation is pending, successful, or failed according to the states agreed in the brief.

Illustrative users: Store staff can inspect status and perform any approved recovery action. Configuration access is restricted to the agreed capability.

Illustrative integration: An external fulfillment API receives the agreed order fields.

Illustrative failure paths: The brief defines expected behavior for unavailable service, rejected credentials, rejected data, duplicate events, and failed retries. It also states what information staff can see.

Illustrative acceptance: An eligible order produces the expected outbound request. Failed communication follows the agreed support path. An approved retry does not create an unintended duplicate fulfillment request.

Illustrative assumptions: The buyer supplies current API documentation, test credentials, representative test data, and a contact who can answer questions about the external service.

Illustrative exclusions: No redesign of the fulfillment platform, no undocumented third-party behavior, no historical migration unless separately scoped, and no new features outside the stated order workflow.

The larger estimate comes from the extra states and responsibilities. The developer must scope WordPress behavior, WooCommerce behavior, external-system behavior, recovery paths, and support visibility.

Build the estimate from work packages and known rates

A wordpress plugin development cost estimate should map each part of the brief to work that can be estimated and reviewed.

Use owner-authorized or supplier-confirmed rates. Do not fill missing rates with an online average.

A worksheet can look like this:

Discovery cost
= estimated discovery days × agreed day rate

Specified work package cost
= estimated work package days × agreed day rate

Build estimate
= sum of all approved work package costs

Third-party cost
= provider charges confirmed by the owner

Reserved maintenance capacity
= agreed support days per month × agreed support day rate

Approved out-of-scope work
= separately quoted fixed scope
  OR
  actual approved time × agreed hourly/day rate

The estimate should also identify unknowns that block a fixed quote. Common examples are missing API documentation, unavailable credentials, an inherited plugin that has not been reviewed, unclear data migration, unknown extension compatibility, or business rules that different stakeholders describe differently.

Do not hide those unknowns inside a fixed number. Mark each one as an assumption, exclusion, or discovery task.

A fixed price is then a commercial wrapper around a defined scope. The developer can price the accepted work packages and state how changes will be handled.

Choose a pricing model after the unknowns are visible

The right commercial structure depends on how much can be specified before development begins.

Pricing model	Fits when	Put in writing
Fixed project price	Workflow, assumptions, exclusions, and acceptance checks are stable	Deliverables, acceptance, change process, payment points, launch scope
Hourly or day rate	Discovery is still needed or inherited code and integrations contain material unknowns	Rate, approval process, reporting, spend controls
Fixed build plus recurring support	Build scope is stable but the buyer wants ongoing capacity after launch	What the build includes, what maintenance includes, response expectations, change work
Fixed build plus a license arrangement	The commercial model includes separately defined rights, updates, hosted services, or reusable supplier-owned components	Exactly what the recurring fee provides

For a custom WooCommerce or WordPress plugin built for one client, separate the build from deployment, documentation, training, and ongoing support even if the final quote groups some of them together. That makes later changes easier to classify.

Do not call an ongoing service a license fee unless the agreement defines what is being licensed. Ownership, copyright, licensing, and contract language should be reviewed by a qualified legal professional where they matter to the deal.

Budget maintenance by obligation, not by a percentage

Custom plugin maintenance cost should come from the work the buyer expects after launch.

Separate at least three categories:

Defect handling covers behavior that does not meet the accepted specification, subject to the agreed post-launch terms.
Maintenance keeps the agreed plugin working with the supported environment and dependencies.
Enhancements change or extend the accepted specification.

For the question "How many days per month in support over the next year?", do not choose a default from a pricing article. Estimate the recurring workload.

Use this worksheet:

Expected monthly support capacity
= expected compatibility and release-review work
+ expected incident-response capacity
+ approved minor-change capacity

If neither party can identify enough recurring work to reserve support days, time-based support may be clearer. If the plugin affects a business process that needs predictable response capacity, reserve capacity and state exactly what it covers.

The brief should also say who keeps the source repository, who receives technical documentation, who controls external service credentials, who approves releases, and what happens when the maintenance agreement ends.

Copy this WordPress plugin project brief

Complete every section you can before requesting a quote. Mark anything you cannot answer as an assumption or discovery question instead of guessing. Leave the agreed rate, discovery estimate, work package estimates, fixed-price scope, and pre-existing supplier components for the developer to complete with the quote.

PROJECT
Project name:
Business owner:
Technical contact:
Site/staging contact:

PROBLEM
Current workflow:
Problem being removed:
Expected business outcome:

USERS AND PERMISSIONS
User type:
Actions they may perform:
Actions they must not perform:
WordPress capability requirements:

WORKFLOW
Trigger:
Steps:
Decision rules:
Successful outcome:
Reversal/cancellation rules:

DATA
Inputs:
Outputs:
Required fields:
Validation rules:
Existing data involved:
Migration required:
Retention/deletion requirements:

INTEGRATIONS
External system:
Trigger:
Fields sent:
Fields received:
Credential owner:
Test environment available:
Expected success behavior:
Expected unavailable-service behavior:
Expected authentication-failure behavior:
Expected invalid-data behavior:
Expected duplicate-event behavior:
Support visibility:
Manual recovery required:

COMPATIBILITY
Supported WordPress baseline:
Supported PHP baseline:
WooCommerce required:
Required plugins/extensions:
Theme dependencies:
Multisite required:

ACCEPTANCE CHECKS
Check:
Setup:
Action:
Expected result:

Check:
Setup:
Action:
Expected result:

ASSUMPTIONS
-
-
-

EXCLUSIONS
-
-
-

DELIVERY
Source repository handover:
Deployment included:
Documentation included:
Training included:
Post-launch defect terms:
Release approver:

MAINTENANCE
Compatibility review responsibility:
Incident support:
Reserved support capacity:
Minor changes included:
Enhancements billed separately:
Response expectations:
Maintenance end/handover process:

COMMERCIAL INPUTS
Agreed hourly or day rate:
Discovery estimate:
Work package estimates:
Third-party charges:
Fixed-price scope, if applicable:
Change-request method:

OWNERSHIP
Custom code ownership terms:
Pre-existing supplier components:
Third-party licensed components:
Update rights:
Repository access after handover:

Turn the brief into a quote request

First settle the procurement decision. If WordPress may be the wrong place for the business logic, compare a custom WordPress plugin with a SaaS integration before asking developers to estimate the build.

Once the plugin path is settled, send the completed brief when requesting custom WordPress plugin development with a scoped quote. Keep the brief as the source for acceptance, assumptions, exclusions, and change requests rather than replacing it with implementation notes.

After the behavior is stable enough to build, turn suitable acceptance rules into automated checks. The guide to WordPress plugin unit testing with wp-env and PHPUnit covers that implementation step without changing what belongs in the buyer's brief.

WordPress security hardening: a practical checklist for 2026

Hamza Ahmad Aslam — Fri, 02 Oct 2026 14:00:30 +0000

Originally published at hamzaahmadaslam.com.

How this article was made: drafted with AI assistance from a researched brief, then checked against primary documentation before publishing.

Short answer: outdated plugins, reused passwords and forgotten admin accounts are all risks to review. Good WordPress security hardening comes down to a few habits: keep everything updated, remove what you don't use, lock down logins and file editing, stop PHP from running in the uploads folder, and keep off-site backups you have restored. Use this checklist to review the installation and plan the changes it needs.

Cleaning up infected WordPress sites is part of my work. Start with an inventory of installed code and account access, then record how you will detect a problem and recover from it.

Start with a read-only review

Before changing anything, find out where you stand. If you have WP-CLI on the server, these read-only commands tell you a lot:

# Are core files exactly what WordPress.org shipped?
wp core verify-checksums

# Same check for plugins from the WordPress.org directory
wp plugin verify-checksums --all

# Who can change everything?
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

# What is out of date?
wp plugin list --update=available
wp theme list --update=available

Any checksum mismatch, admin you don't recognise or plugin that is years behind goes straight to the top of your to-do list.

The WordPress hardening checklist

Area	What to do	Why it matters
Updates	Turn on automatic minor core updates and plugin auto-updates for well-maintained plugins	Reduces exposure to known, patched vulnerabilities
Plugins	Delete (don't just deactivate) anything unused; replace plugins abandoned for over a year	Inactive code can still be reached
Accounts	One admin per real person, strong unique passwords, two-factor authentication	Stolen passwords are the cheapest way in
Logins	Rate-limit `wp-login.php` and XML-RPC	Stops credential stuffing
File editing	Disable the built-in theme and plugin editor	Removes the dashboard editor as one route to changing code
Uploads	Block PHP execution inside `wp-content/uploads`	Uploaded web shells can't run
Secrets	Unique salts in `wp-config.php`, rotated after any incident	Invalidates stolen sessions
Backups	Automatic, off-site, versioned, and tested by restoring one	A backup you've never restored is a guess
Monitoring	Watch uptime, vulnerabilities and file changes	You fix what you see

1. Put `wp-config.php` to work

These constants restrict selected dashboard actions and connection behavior:

// Nobody edits PHP from the dashboard. Deploy changes instead.
define( 'DISALLOW_FILE_EDIT', true );

// Always use HTTPS for the admin area.
define( 'FORCE_SSL_ADMIN', true );

// Allow automatic minor core updates (security releases).
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

If you also deploy plugins through Git or a pipeline, DISALLOW_FILE_MODS blocks installing and updating from the dashboard too. Only enable it if something else keeps your plugins updated.

Rotate your salts whenever you suspect a leak. This signs everyone out:

wp config shuffle-salts

2. Stop PHP from running in uploads

The uploads folder should only ever contain media. On Apache, add an .htaccess file inside wp-content/uploads:

<FilesMatch "\.(?:php[0-9]?|phtml|phar)$">
    Require all denied
</FilesMatch>

On Nginx, add this to the server block:

location ~* /wp-content/uploads/.*\.(?:php[0-9]?|phtml|phar)$ {
    deny all;
}

3. Tighten logins

Turn on two-factor authentication for every account that can publish or manage plugins.
Give people the lowest role that works. Editors rarely need to be administrators.
Limit login attempts at the web application firewall or with a well-maintained plugin.
If nothing uses XML-RPC (Jetpack and some older integrations still do), block xmlrpc.php at the server.

4. Set sane file permissions

A common baseline is 755 for folders and 644 for files, with wp-config.php readable only by the account PHP runs as (640 or 600, depending on your host). Never use 777.

5. Add security headers

Headers cost nothing and block common browser-side attacks. Start with X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, a frame-ancestors rule (or X-Frame-Options) and HSTS once the site is fully on HTTPS. A Content Security Policy is the strongest of all, but test it carefully, because page builders often rely on inline scripts.

For the details, see which WordPress security headers to set and how to test them safely.

If a site is already infected

Take a full copy first (files and database). You'll want it for investigation.
Put up a maintenance page or block traffic while you work.
Reinstall core and every plugin and theme from clean sources. Don't try to "fix" infected copies.
Search for PHP files that shouldn't exist, especially in uploads, and check mu-plugins and .htaccess.
Review scheduled tasks with wp cron event list. Malware likes to schedule its own return.
Remove unknown admin users, then reset every password and shuffle the salts.
Update everything, then find the entry point. If the entry point remains open, the site can be compromised again.
Request a review in Google Search Console if the site was flagged.

If the site is already compromised, follow the step-by-step guide to cleaning a hacked WordPress site.

Keep it that way

Hardening needs review as plugins, accounts and hosting change. Subscribe to a vulnerability feed such as Wordfence Intelligence, WPScan or Patchstack, and check it against the plugins you run. Once you look after more than a handful of sites, automate that check. That is exactly why I built Fleet Sentinel.

Need a hand hardening or cleaning a site? Check my maintenance & security service or get in touch directly. Hardening and malware cleanup are a regular part of my work.

WooCommerce checkout slow: diagnose the request that blocks payment

Hamza Ahmad Aslam — Tue, 29 Sep 2026 14:00:35 +0000

Originally published at hamzaahmadaslam.com.

How this article was made: drafted with AI assistance from a researched brief, then checked against primary documentation before publishing.

When your WooCommerce checkout is slow, start with the single browser request that begins when the delay begins. Record that request's timing, then match it to a server trace so you can separate browser delay from WooCommerce, shipping, tax, gateway, database, or server work. Change one dependency on staging, repeat the same checkout, and verify the expected totals, payment state, and errors before accepting a fix.

WooCommerce checkout slow: find the request that owns the wait

Do not start by disabling random plugins. First reproduce one specific interaction: loading checkout, changing an address, choosing shipping, or pressing Place order. Open the browser Network panel, preserve the log, perform only that interaction, and note the request that spans the visible delay.

The request depends on the checkout type. WooCommerce says stores started after version 8.3, released in November 2023, use the Cart and Checkout blocks by default. Established stores may still use the classic shortcode checkout. You can confirm the page setup with WooCommerce's Cart and Checkout customization documentation.

On classic checkout, look for requests such as ?wc-ajax=update_order_review while address or shipping data changes. WooCommerce core calculates shipping before totals during that update. When Place order is submitted, the classic ?wc-ajax=checkout handler passes the request into checkout processing.

On block checkout, filter Network requests for wc/store. The current Store API exposes POST /wc/store/v1/checkout, which accepts the final customer addresses and payment method, attempts payment, and returns the result. The Checkout API reference documents that endpoint.

The important point is the boundary. If the customer clicks Place order and no WooCommerce request starts for a while, the wait is happening before WordPress receives the checkout request. If the request starts promptly and then waits, trace the server side of that request.

Separate browser delay from server delay

Chrome DevTools shows request phases in the Network panel. Its Network timing reference defines Waiting (TTFB) as one network round trip plus the time the server takes to prepare the first byte. TTFB is therefore useful, but it is not a pure PHP measurement.

Use three observations:

If there is a gap between the checkout action and the WooCommerce request starting, inspect browser JavaScript, validation, and any gateway-side browser call that runs first.
If the WooCommerce request starts quickly and most of its time is Waiting (TTFB), match it to a server trace. The delay can sit in PHP, database work, a queue for server capacity, or a blocking outbound request.
If the first byte arrives quickly but the customer still waits, inspect response download, redirects, browser JavaScript, and the next request in the chain.

A server trace is simply a timeline for the same server request. It should show PHP work, database calls, and outbound HTTP calls if your tracing tool records them. Match browser and server records by timestamp, HTTP method, route, and approximate request duration. Redact customer data, payment data, tokens, cookies, and authorization headers before sharing a trace.

Identify shipping, tax, and gateway calls inside the request

A browser waterfall cannot show every dependency. A payment, tax, or carrier request made by PHP happens inside the WooCommerce request from the browser's point of view.

For classic checkout, update_order_review is a useful boundary because current WooCommerce core calculates shipping and then totals before returning refreshed checkout fragments. A slow request here can therefore include shipping calculation, tax calculation, extension callbacks, database work, and outbound calls made during those steps.

Place order is a different boundary. A gateway may run browser-side work before the WooCommerce request starts, server-side work while the request is open, or both. Do not label the gateway as slow from the browser request alone. Find the matching outbound span in the server trace, or the browser-side provider request that precedes checkout.

Use this decision table to choose the next test:

Signal	What it tells you	Next controlled test
WooCommerce request starts late after the user action	The delay begins in the browser or a browser-side provider step	Record a browser performance trace and isolate the script or provider request that runs first
`update_order_review` waits while a carrier or tax HTTP span is open	That dependency is on the server-side recalculation path	On staging, replace only that remote dependency with a local test equivalent and repeat
Place order waits while a gateway HTTP span is open	The gateway call is part of the server-side wait	Repeat with the gateway in sandbox mode, then compare with an offline test method as a diagnostic control
WooCommerce request waits with no long outbound span	The wait is elsewhere in WordPress, PHP, the database, or server capacity	Profile the matching server transaction instead of changing payment settings
Browser provider call finishes slowly before WooCommerce starts	The delay is outside the server request	Inspect that provider call and the JavaScript that waits for it

Tax and shipping behavior differs by store. Some stores calculate locally, while others use extensions that call remote services. Trace the store you have rather than assuming an external API exists.

Copy this redacted checkout trace worksheet

The artifact below is a fictional, redacted demo specification. Every sample name, scenario, and number is marked illustrative, and every result is an expected example rather than an observed result. Use sandbox or test payments only.

First record the environment. WooCommerce's System Status report shows current version numbers for active plugins, which makes the test reproducible.

Checkout trace record

Test environment: <staging URL or environment name>
WooCommerce version: <record from WooCommerce > Status>
Checkout type: <classic | block>
Theme and version: <record>
Payment extension and version: <record>
Shipping extension and version: <record>
Tax extension and version: <record>
Payment mode: sandbox/test only
Cart contents: <fixed test cart>
Shipping address: <redacted test address>
Expected subtotal: <record>
Expected shipping total: <record>
Expected tax total: <record>
Expected order total: <record>
Expected payment state: <record for this gateway flow>
Expected validation error: <record one safe failure case>

Then capture several repeats of the same interaction before changing anything. Keep the cart, address, account state, shipping choice, and payment method fixed.

Scenario	Run	Browser request	Total time	Waiting (TTFB)	Matching server span	Expected reading
Baseline sandbox Place order, illustrative	Run A, illustrative	`POST /?wc-ajax=checkout`, illustrative route	2.40 s, illustrative	2.18 s, illustrative	`POST gateway.example`, redacted and illustrative, 1.46 s illustrative	Gateway span occupies much of the server wait, illustrative expected reading
Baseline sandbox Place order, illustrative	Run B, illustrative	`POST /?wc-ajax=checkout`, illustrative route	2.55 s, illustrative	2.31 s, illustrative	`POST gateway.example`, redacted and illustrative, 1.52 s illustrative	Same dependency remains visible, illustrative expected reading
Baseline sandbox Place order, illustrative	Run C, illustrative	`POST /?wc-ajax=checkout`, illustrative route	2.44 s, illustrative	2.20 s, illustrative	`POST gateway.example`, redacted and illustrative, 1.49 s illustrative	Same dependency remains visible, illustrative expected reading
Offline payment control, illustrative	Run A, illustrative	`POST /?wc-ajax=checkout`, illustrative route	0.91 s, illustrative	0.73 s, illustrative	No gateway HTTP span, illustrative	Removing only the remote payment step reduces expected request time, illustrative
Offline payment control, illustrative	Run B, illustrative	`POST /?wc-ajax=checkout`, illustrative route	0.88 s, illustrative	0.71 s, illustrative	No gateway HTTP span, illustrative	Expected result remains consistent, illustrative
Offline payment control, illustrative	Run C, illustrative	`POST /?wc-ajax=checkout`, illustrative route	0.94 s, illustrative	0.75 s, illustrative	No gateway HTTP span, illustrative	Expected result remains consistent, illustrative

For the illustrative set below, use the middle value after sorting the repeated timings:

Baseline median = middle(Baseline run A, Baseline run B, Baseline run C)
Variant median = middle(Variant run A, Variant run B, Variant run C)
Timing delta = Variant median - Baseline median
Dependency share = matching dependency span / total server-request duration, expressed as a percentage

The offline payment row is a diagnostic control, not a production fix. It changes checkout behavior on purpose. Return to the sandbox gateway before testing the final code or configuration change.

Do the same isolation for shipping or tax only when your trace points there. Change one thing, repeat the same procedure, and keep a note of what changed. Do not compare runs that use different carts, addresses, shipping methods, or account states unless that difference is the variable you are testing.

Do not generalize the expected pattern in this illustrative demo to another store. Use the dependency spans and repeated timings from that store's own request path.

Check errors while the same request is running

A timeout can hide a PHP error or extension failure. On staging, use the logging configuration in the WordPress debugging documentation: enable WP_DEBUG and WP_DEBUG_LOG, disable WP_DEBUG_DISPLAY, and turn off PHP error display so debug messages are not printed into checkout responses.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

With WP_DEBUG_LOG set to true, WordPress writes the log to the content directory, usually wp-content/debug.log. You can instead set WP_DEBUG_LOG to a valid custom file path, such as a log file outside the public web root.

This matters during checkout testing because WP_DEBUG_DISPLAY defaults to true when debugging is enabled. Leaving display enabled can put PHP errors or warnings into a response and change the request you are trying to measure.

Match the log timestamp to the browser request and server trace. A clean browser response does not tell you whether a warning or recoverable error happened during the request. A failed browser response also does not identify which dependency failed without server evidence.

If checkout stays slow after disabling ordinary plugins, keep tracing. WooCommerce core, the theme, custom code, PHP, the database, server capacity, DNS, network latency, and remote services can still sit on the request path. Plugin isolation answers one question; it does not prove the remaining stack is fast.

Treat a 504 after Place order as an unfinished request path

An HTTP 504 means a gateway or proxy did not receive a response from its upstream server in time. That is the definition in MDN's 504 reference. The status code does not identify whether PHP, the database, server capacity, or a server-side remote call caused the upstream delay.

When a WooCommerce checkout timeout appears after Place order, correlate the 504 with the origin trace and logs. Look for the last span that started but did not finish before the proxy gave up.

Do not assume the payment failed just because the browser received a 504. Check the WooCommerce order and the sandbox gateway state before repeating the payment attempt. Your correctness test should define the expected order and payment state for both success and failure paths.

Verify the faster request still produces the right checkout

A timing improvement is useful only if the same scenario still behaves as expected. Run the original checkout path again with the intended fix in place, not the temporary isolation control.

Check all of these against values recorded before the change:

Confirm the expected subtotal, discount, shipping, tax, and final total.
Confirm the expected shipping method remains available for the test address.
Confirm the sandbox gateway reaches the expected payment and order state.
Run one safe failure case and confirm the expected customer-facing error appears.
Check that a retry follows the expected order and payment behavior for that gateway.
Repeat the timing runs with the same cart, address, account state, shipping method, and payment method.
Record the extension versions with the final trace so another developer can reproduce the setup.

A fast request with a missing tax, skipped shipping rate, wrong payment state, or swallowed error is a failed change.

Choose the next step from what the trace shows

If the trace points beyond checkout to broader origin performance, use the WooCommerce Core Web Vitals speed guide for the store-wide work instead of repeating it here. If you need request-level implementation help after isolating the slow dependency, the WooCommerce speed optimization service covers that work.

If the investigation shows that your classic checkout and extension set are the problem you plan to replace, follow the WooCommerce cart and checkout blocks migration plan so compatibility testing and rollback stay separate from this timing diagnosis.

AI vs rule based automation: when a small business needs AI

Hamza Ahmad Aslam — Mon, 28 Sep 2026 14:00:31 +0000

Originally published at hamzaahmadaslam.com.

How this article was made: drafted with AI assistance from a researched brief, then checked against primary documentation before publishing.

For AI vs rule based automation, use rules when the correct action follows fixed inputs, use AI when the task depends on meaning in messy text, and keep a person involved when a wrong action is costly or hard to reverse. Do not decide from a product label. Run both approaches on the same labeled cases, compare where they disagree, and choose the smallest system that handles the task safely.

AI vs rule based automation starts with the input

Start with one business decision, such as routing a website inquiry to sales, support or billing. Do not judge an entire department as an “AI task.”

Fixed fields favor rules. A country code, product ID, account status, checkbox or selected service can map to a known action. If the business can write the correct mapping before the automation runs, a rule gives you a clear baseline.

Free text changes the problem. “I was charged twice” is easy to classify. “Can you fix the checkout issue and quote a rebuild?” contains two intents. A keyword rule can see “fix” while a person may treat the request as a sales inquiry.

If you are still deciding which business process is a useful automation candidate, start with the broader small-business AI automation decision. This page assumes you already have one task and need to choose its handling method.

The rules based automation vs AI choice gets clearer when you separate three questions:

Task property	Rule-based start	AI candidate	Manual or review start
Input	Fixed fields or stable codes	Free text with varied wording	Missing context or conflicting facts
Correct answer	Can be written as a stable mapping	Requires interpretation	People cannot label it consistently yet
Wrong-action cost	Low and reversible	Low or reviewable	High, external or hard to undo
Testing	Expected result is exact	Compare against labeled examples	Record why a person had to decide

Use a deterministic baseline before testing AI

Deterministic means the same input and the same rule version produce the same result. That gives you something concrete to compare with an AI classifier.

For one inquiry-routing task, write the smallest rule set that a developer could implement without a model. The following rule names, keywords, order and routes are illustrative.

Illustrative rule 1: if the message contains refund, charged or invoice, route to billing.
Illustrative rule 2: otherwise, if it contains error, broken, login or log in, route to support.
Illustrative rule 3: otherwise, if it contains quote, pricing or proposal, route to sales.
Illustrative rule 4: otherwise, route to manual_review.

The order matters. An illustrative message containing both “broken” and “quote” reaches the support rule first. Keep that behavior fixed while you test, or you will be comparing a moving baseline with a moving model.

A deterministic vs AI automation test is useful only when both methods receive the same cases and are judged against the same labels.

Test the same labeled inquiries both ways

Create labels before you look at either system’s answer. The label is the route a person says is correct under your written business policy.

The illustrative sample below is deliberately small and deliberately includes ambiguous wording. It is a test design, not a benchmark. Every row, message, route and expected result is illustrative.

Illustrative row	Illustrative message	Human label, illustrative	Rule result, expected	AI result, expected if it follows main intent
Illustrative row 1	“Please send a quote for a WordPress site.”	`sales`	`sales`	`sales`
Illustrative row 2	“I was charged twice for an invoice. Please help.”	`billing`	`billing`	`billing`
Illustrative row 3	“I cannot log in after resetting my password.”	`support`	`support`	`support`
Illustrative row 4	“Your checkout is broken and I need a quote to fix it.”	`sales`	`support`	`sales`
Illustrative row 5	“I need pricing, but first can you fix the error on my current site?”	`support`	`support`	`support`
Illustrative row 6	“Please do not refund anything. I only need a copy of the invoice.”	`billing`	`billing`	`billing`
Illustrative row 7	“Can you help with the thing we discussed yesterday?”	`manual_review`	`manual_review`	`manual_review`
Illustrative row 8	“Our proposal form shows an error after submit. Can you rebuild it?”	`sales`	`support`	`sales`

Illustrative rows 4 and 8 are expected disagreements. They expose one known weakness in the illustrative rule order: support keywords appear inside a sales request. They do not prove that an AI classifier will get those rows right.

Give the classifier a closed output shape

Ask the classifier for a route, a short reason and a review flag. Do not let it invent new route names.

The following illustrative schema uses JSON Schema Draft 2020-12. The JSON Schema object reference documents properties, required and additionalProperties, while the enum reference defines a fixed set of allowed values.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "properties": {
    "route": {
      "type": "string",
      "enum": ["sales", "support", "billing", "manual_review"]
    },
    "reason": {
      "type": "string"
    },
    "needs_review": {
      "type": "boolean"
    }
  },
  "required": ["route", "reason", "needs_review"],
  "additionalProperties": false
}

Keep the prompt fixed for the whole test. Tell the model what each route means. Tell it to choose manual_review when the message lacks enough information. Save the model name and prompt with the results so a later rerun is comparable.

Record disagreements instead of arguing from examples

Copy this worksheet and fill it with your own labeled inquiries. Do not replace a representative set with hand-picked easy cases.

Measure	Formula	What it tells you
Rule accuracy	`rule-correct rows / total labeled rows`	How far fixed logic gets on its own
AI accuracy	`AI-correct rows / total labeled rows`	Whether text interpretation adds useful signal
Disagreement rate	`rows where rule route != AI route / total labeled rows`	How often the choice of method changes the route
High-cost wrong decisions	`count(wrong rows where error cost = high)`	Which errors need a stop or person
Review rate	`reviewed rows / total labeled rows`	How much work still reaches a person

For the illustrative eight-row sample, the illustrative expected rule disagreement count with the human labels is 2 / 8. Do not use that sample number as a target. Your own labeled set is what matters.

Let error cost decide where a person stays involved

Accuracy alone can hide the error that matters most. Sending a low-value inquiry to the wrong internal queue is different from sending money, deleting data or making a customer commitment.

Write the consequence beside each label before you automate the action. Use plain categories such as low, medium and high. Define them for your business.

The NIST AI Risk Management Framework is voluntary and is intended to bring trustworthiness into the design, use and evaluation of AI systems. For this small task, the useful habit is simple: judge the model by the harm of its errors, not only by its average score.

If an AI step can trigger an external or hard-to-reverse action, put approval between classification and execution. n8n documents human review for AI Agent tools, including approval before sending communications, modifying records, deleting data or making purchases.

That pattern also answers when to use AI automation for uncertain text: let AI interpret, let rules enforce fixed constraints, and let a person decide where the consequence is too high.

I built Sense Check as an example of that split, where fixed rules settle what is certain, an AI model judges the rest, and anything the model is unsure about goes to a person.

Choose manual, rules, AI or a hybrid from the evidence

Do not turn “does this task need AI” into a yes-or-no debate. Use the test results to pick the smallest method that meets the business need.

Evidence from your test	Starting choice
Fixed fields determine the right route and exceptions are rare	Rule-based automation
Free text changes the correct route, and the classifier improves those cases without unacceptable errors	AI classification inside a fixed workflow
Rules handle clear cases, while text interpretation helps only on ambiguous cases	Hybrid: rules first, AI second
The team cannot agree on labels, or wrong actions have high consequences	Manual handling until the policy or review path is clear
AI and rules disagree often, but neither matches human labels reliably	Keep the task manual and improve the labels, inputs or policy

This is also the useful way to frame AI or traditional automation. You are choosing where interpretation belongs, not buying a technology category for the whole workflow.

Know what this sample cannot prove

The illustrative sample is too small to support a performance claim. It is also constructed around three illustrative route types and a manual fallback. Your inquiry mix may be different.

A useful test set should include ordinary cases, rare wording, incomplete messages and the mistakes that would cost you most. Keep the human label separate from the rule and model outputs.

Do not infer production quality from one prompt run. Model behavior can change when you change the prompt, model, context or surrounding workflow. Rerun the same labeled set after any material change.

The sample also tests classification only. It does not test reply writing, lead scoring, outbound messaging, data retention or an agent that chooses many tools.

Build the smallest next step on WordPress

Start by exporting a set of past form messages that you are allowed to use, remove data you do not need, and label each message under one written routing policy. Run the deterministic baseline and classifier against the same rows, then review every disagreement and every high-cost error.

If the result belongs in a WordPress form, plugin or internal admin workflow, custom WordPress development can keep the fixed rules, AI call and review queue as separate parts. That separation makes each decision easier to test and change.

DEV Community: Hamza Ahmad Aslam

How to speed up WooCommerce: a Core Web Vitals guide

Know the speed targets first

Step 1: Fix the Largest Contentful Paint

Step 2: Put JavaScript on a diet (this is where INP lives)

Step 3: Cache what can be cached (and nothing else)

Step 4: Clean the database

Step 5: Server basics that still matter

Measure, change one thing, measure again

Fix INP in WordPress by finding the slow interaction

Fix INP in WordPress by tracing one interaction

Choose interactions that represent what visitors do

Freeze the mobile setup before you compare traces

Record a repeatable menu and form test

Split the delay into input, processing, and presentation

Isolate the long task that overlaps the interaction

Use field attribution when the slow interaction will not reproduce

Can content-visibility improve INP in WordPress?

Retest the function before you trust the faster trace

Decide what to fix next

Headless WordPress with Next.js: when it fits

What changes when WordPress goes headless

When headless WordPress with Next.js is the right call

When it's the wrong call

REST API or WPGraphQL?

A caching strategy that keeps content fresh

Previews, SEO and the details people forget

Previews

SEO

Images and links

Security checklist for a headless setup

How to decide in one afternoon

Run a WordPress backup restore test and prove recovery works

What a WordPress backup restore test must prove

Define recoverable assets

Restore in isolation, not over production

Restore the same backup set you intend to trust

Verify content and business tasks against the backup point

Use this restore log and acceptance checklist

Record recovery gaps and elapsed time

If the restore or move fails, reset the isolated target and try again

Put the verified restore path into normal maintenance

Custom WordPress plugin cost: what to include in the brief

What drives custom WordPress plugin cost before a quote

Describe the workflow and users before listing features

Define integrations and failure paths without designing the implementation

Agree acceptance checks before agreeing the fixed scope

Compare three illustrative plugin briefs

Illustrative sample A: an internal admin utility

Illustrative sample B: a WooCommerce review workflow

Illustrative sample C: a WooCommerce fulfillment integration

Build the estimate from work packages and known rates

Choose a pricing model after the unknowns are visible

Budget maintenance by obligation, not by a percentage

Copy this WordPress plugin project brief

Turn the brief into a quote request

WordPress security hardening: a practical checklist for 2026

Start with a read-only review

The WordPress hardening checklist

1. Put wp-config.php to work

2. Stop PHP from running in uploads

3. Tighten logins

4. Set sane file permissions

5. Add security headers

If a site is already infected

Keep it that way

WooCommerce checkout slow: diagnose the request that blocks payment

WooCommerce checkout slow: find the request that owns the wait

Separate browser delay from server delay

Identify shipping, tax, and gateway calls inside the request

Copy this redacted checkout trace worksheet

Check errors while the same request is running

Treat a 504 after Place order as an unfinished request path

Verify the faster request still produces the right checkout

Choose the next step from what the trace shows

AI vs rule based automation: when a small business needs AI

AI vs rule based automation starts with the input

Use a deterministic baseline before testing AI

Test the same labeled inquiries both ways

Give the classifier a closed output shape

1. Put `wp-config.php` to work