Coder Legion - Recent posts tagged wordpress

What Is a Good Conversion Rate? (And Why the Average Can Fool You)

Sat, 31 Oct 2026 13:43:31 +0000

We build Opti-Behavior, the WordPress plugin mentioned in this guide.

Imagine Nadia. She sells online yoga classes. Last month, 3,000 people visited her sales page and 45 bought a class. She typed "what is a good conversion rate" into Google and found an article that said "the average is 2.35%". Hers was 1.5%. She felt terrible.

Nadia is an example: her site and figures are made up to show the method step by step.

Then she found another article that said "a good conversion rate is 10%". Now she felt even worse.

Here is the truth: both articles were talking about other people’s websites. A good conversion rate depends on what you sell, who visits, and what you count as a conversion. In this guide we will work out a good rate for Nadia’s site, step by step, and then find ways to raise it.

Short answer: A good conversion rate is one that is better than your own rate last month, measured the same way. Industry averages are rough hints, not goals. Measure one clear action, per visitor, for each type of page, and improve the weakest step first.

What is a conversion, exactly?

A conversion is when a visitor does the thing you want. It can be big or small:

Type	Examples
Big (macro) conversion	A purchase, a paid sign-up, a booked call, a quote request
Small (micro) conversion	Adding to cart, starting a form, signing up to a newsletter, watching a demo

Small conversions matter because they lead to big ones. If nobody adds to cart, nobody buys.

How to calculate your conversion rate

The formula is simple:

Conversion rate = conversions ÷ visitors × 100

Nadia: 45 purchases ÷ 3,000 visitors × 100 = 1.5%.

But watch out. Tools do not all divide by the same thing:

Per visitor: 45 buyers out of 3,000 people. This is the honest one for sales.
Per session: 45 buyers out of 4,200 visits. The rate looks lower, because many people visit twice before buying.
Per page: conversions on one page divided by that page’s visitors. Best for comparing pages.

When you compare numbers, always use the same method. Many "benchmark" articles do not say which one they used.

So what is a good conversion rate?

Here are ranges you often see quoted in marketing reports. They come from different studies and change every year, so treat them as rough hints:

Type of page or site	Often quoted range
Online shop (all visitors)	1% to 3%
Shop, visitors who add to cart	30% to 60% reach checkout
Lead form on a service site	2% to 5%
Dedicated landing page from an ad	5% to 15%
Newsletter sign-up box on a blog	1% to 3%
Free trial sign-up (software)	3% to 10%

Why are the ranges so wide? Because a "good" rate depends on:

Price. A $5 ebook converts more than a $900 course.
Traffic source. Visitors from your newsletter already trust you. Visitors from a cold ad do not.
Device. Mobile visitors often browse and buy later on a computer.
Intent. Someone searching "buy yoga class online" is ready. Someone searching "is yoga good for back pain" is learning.

So Nadia’s 1.5% was not bad for a paid course with mostly cold traffic. The real question was: which part of her journey was weak?

Split the rate into steps

One big conversion rate hides where the problem is. Split the path into steps. This is called a funnel.

Nadia’s path was: Sales page, Pricing, Checkout, Thank-you page. In Opti-Behavior, you can create this funnel in a minute: go to Opti-Behavior > Funnels, click Build New Funnel, and add each step with a URL rule, like "URL Contains /pricing/". Opti-Behavior also suggests funnels built from the pages of your site.

Each step shows how many visitors continue and how many leave.

Here is what Nadia’s funnel showed:

Step	Visitors	Continue to next step
Sales page	3,000	28%
Pricing	840	22%
Checkout	185	24%
Thank-you	45

The big leak was at checkout: 185 people started to pay, only 45 finished. That is 76% lost at the very last step. Her sales page was fine. Her checkout was not.

With Pro, each funnel step links to the recordings of the people who left right there. Nadia watched eight of them. On phones, her checkout asked people to create an account with a password before paying. Most gave up at the password field.

In Pro, each step links to the recordings of the visitors who dropped there.

Measure what counts as a win

When you change something, you want to know if it worked. That is what A/B tests are for: half your visitors see the old version, half see the new one, at the same time.

In Opti-Behavior, a test has goals. The first goal is the one that picks the winner.

Goal	Counts a conversion when	Plan
Page visit	The visitor reaches a page, like a thank-you page	Free
Click	The visitor clicks an element you pick on the page	Free
Form submit	A form on the page is sent	Free
Scroll depth	The visitor scrolls to a depth you set	Pro
Time on page	The visit lasts longer than a threshold	Pro
Revenue	WooCommerce orders from the test	Pro

Pick the action that counts as a conversion. The first goal decides the winner.

The free version runs up to 3 tests at the same time, with up to 3 versions each.

Careful: a higher conversion rate is not always better

This surprises a lot of people. Look at this real-style example from our A/B testing docs:

Version	Visitors	Orders	Conversion rate	Average order	Revenue per visitor
A (current)	1,000	30	3.0%	60 €	1.80 €
B (free shipping over 50 €)	1,000	27	2.7%	78 €	2.11 €

Version B has a lower conversion rate, but people spend more, so it earns 17% more per visitor. If you only looked at the conversion rate, you would pick the wrong version. For shops, watch revenue per visitor too. Pro can measure it with a Revenue goal.

Know what one conversion is worth

Once you know the value of one conversion, every leak has a price. In Smart Insights settings, you can type the value of one conversion (Free and Pro). Smart Insights then estimates what a problem costs you. With Pro, WooCommerce orders set that value for you.

Type the value of one conversion, or, with Pro, let WooCommerce orders price the losses.

For Nadia, one class was worth 60 €. Losing 140 people at checkout every month was not "a bad conversion rate". It was up to 8,400 € a month walking away. That made the fix very easy to prioritize.

8 ways to raise your conversion rate

Fix the weakest step first. A 10% gain on your worst step beats a 10% gain on your best one.
Remove forced account creation. Let people buy as guests. Offer an account after payment.
Show the price and what is included early. Surprises at checkout kill sales.
Make the main button obvious. One clear action per page, visible without scrolling on mobile.
Answer doubts next to the button. Refunds, delivery time, support. One line each.
Speed up mobile. A slow checkout on a phone loses people fast.
Check for broken things. Rage clicks and JavaScript errors on a checkout page are pure lost money. Read our guide on rage clicks.
Test, do not guess. Run an A/B test on one change at a time. Our WordPress A/B testing guide shows how.

Nadia’s new conversion rate

Nadia allowed guest checkout and moved the account creation to the thank-you page. Six weeks later, 44% of people who reached checkout finished paying, instead of 24%. Her overall conversion rate went from 1.5% to 2.7%, with the same traffic.

She still does not know if 2.7% is "good" for the whole yoga industry. She does not care anymore. It is better than last month, and she knows exactly which step to work on next.

Find your weakest conversion step

Opti-Behavior is free: funnels, click heatmaps and A/B tests on WordPress. Pro adds drop-off recordings and revenue goals, with a 6-month free trial.

Good conversion rate FAQ

What is a good conversion rate?

It depends on your site, price and traffic. Rough ranges often quoted are 1% to 3% for online shops, 2% to 5% for lead forms and 5% to 15% for focused landing pages. The best benchmark is your own rate last month, measured the same way.

How do I calculate my conversion rate?

Divide the number of conversions by the number of visitors and multiply by 100. For example, 45 sales from 3,000 visitors is a 1.5% conversion rate.

Is a 2% conversion rate good?

For an online shop with mixed traffic, 2% is often considered solid. For a landing page that only receives ad visitors, it may be low.

Why is my conversion rate low?

Usually one step loses most people: an unclear offer, a hidden button, a surprise cost, a long form or a broken checkout. A funnel shows which step, and recordings show why.

Should I trust average conversion rate benchmarks?

Only as a rough hint. Studies measure different sites in different ways. Track your own rate per page and per step, and try to beat it.

The Opti-Behavior Team

Full guide: https://optiuser.com/go/coderlegion-conversion-rate

Drafted with AI assistance, reviewed by the Opti-Behavior Team.

How to Find Keywords Your Website Is Almost Ranking For

Fri, 30 Oct 2026 15:41:31 +0000

You don't always need to publish new content to improve your website's SEO. Sometimes, your best opportunities are already hiding in Google Search Console.

These are search queries for which your existing pages receive impressions but haven't reached the rankings or traffic you want.

Finding and improving these queries can help you get more value from content you've already published.

Start With Google Search Console****

Open Google Search Console and navigate to Performance → Search results.

Enable all four metrics:

Total clicks
Total impressions
Average CTR
Average position

Choose a date range that provides enough data. If your website receives limited traffic, use a longer period rather than judging performance from a few days.

Find Queries for an Existing Page****

Open the Pages tab and select an article you want to improve.

Next, click the Queries tab.

You'll see the search terms associated with that particular page. Look for relevant queries with impressions but limited clicks.

For example, an article about WordPress speed might appear for searches such as:

How to improve WordPress website speed
Reduce WordPress loading time
Why is my WordPress website slow?

These queries can reveal what Google already considers relevant to your content.

3. Focus on Positions 8–30

As a practical starting point, examine queries with average positions between 8 and 30.

Prioritize queries that have:

Relevant search intent
Meaningful impressions
Room for ranking improvement
A clear connection to your existing article

Don't target every query automatically. An unrelated keyword may indicate a different topic that deserves its own article.

Also remember that average position is an aggregate metric, not your exact live ranking.
**

Improve Content Naturally**

Once you identify a promising query, review your article.

Ask yourself:

Does the content answer the searcher's question?
Is an important explanation missing?
Would a useful example improve the article?
Are the headings clear?
Can relevant internal links help readers explore the topic?

Make focused improvements instead of repeating keywords throughout the content.

If a query represents a completely different search intent, consider creating a separate article.

5. Monitor Your Results

After updating the page, record the changes and date.

Allow Google time to recrawl the content. Then compare clicks, impressions, CTR, and average position using suitable date ranges.

Avoid making additional changes every few days. Give the updated page enough time to collect meaningful performance data.

Final Thoughts

Your existing content may have more ranking potential than you realize.

Use Google Search Console to discover relevant queries, identify content gaps, and improve pages that already receive search visibility.

Instead of publishing more articles just for the sake of publishing, start by improving the opportunities you already have.

Read the complete guide: https://seovixo.com/find-queries-page-almost-ranking-for/

More practical SEO guides and free tools: https://seovixo.com/

WordPress Crash Recovery & Plugin Conflict Resolution

Fri, 30 Oct 2026 14:36:25 +0000

When a WordPress site crashes immediately after an update, the immediate business impact is lost revenue, disrupted customer workflows, and compromised search standing. In production environments, standard advice like "restore a backup from yesterday" can cause critical data loss: orders placed between the backup and the crash, customer registrations, and recent transactions vanish.

A disciplined engineering approach treats a crashed WordPress site as a contained system failure: isolate the execution failure, restore availability, fix the root cause, and verify data integrity before returning traffic to normal operations.

Common Crash Failure Modes After Updates

WordPress crashes after updates typically stem from four discrete architectural failure modes:

PHP Fatal Errors (Type Errors & Deprecations): A plugin update requires PHP 8.1+ syntax or library extensions that conflict with the server runtime or an older theme calling deprecated functions.
Hook and Filter Signature Conflicts: Two active plugins hook into the same action (e.g., woocommerce_checkout_order_processed or template_redirect) expecting incompatible argument types or returning invalid objects.
Database Schema Migrations & Locked Tables: Complex plugins (WooCommerce, membership tools, custom post-type managers) execute DDL migrations upon activation. If a migration times out or hits MySQL lock contention, queries fail across the application.
Autoloaded Options & Memory Exhaustion: Plugins accumulating transient data in wp_options with autoload = 'yes' spike PHP memory usage beyond memory_limit, triggering fatal out-of-memory crashes on high-concurrency requests.

Systematic Diagnostic Protocol

When diagnosing a crashed WordPress production instance, follow this 5-step engineering triage:

Step 1: Capture Raw Error Logs Without Exposing Stack Traces

Do not enable WP_DEBUG_DISPLAY on a live production URL. Instead, enable debug logging to a private log destination:

// In wp-config.php (before /* That's all, stop editing! */)
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', '/var/log/wordpress/debug.log'); // Secure path outside public web root
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', '0');

Inspect debug.log or the web server error log (NGINX/Apache/FPM error log) to identify the exact file, line number, and exception stack trace.

Step 2: Safe Plugin Isolation via WP-CLI

Avoid renaming the entire wp-content/plugins folder if possible, as this deactivates all plugins and breaks widget and database mappings upon reactivation. Use WP-CLI to isolate the culprit:

# Check status of installed plugins
wp plugin list --status=active

# Deactivate the suspect plugin identified in the error stack trace
wp plugin deactivate offending-plugin-slug --skip-plugins --skip-themes

# Verify frontend HTTP response code
curl -I https://example.com

Step 3: Check MySQL Database Integrity and Migration Locks

If the error indicates missing tables or broken queries, verify table health:

# Check and repair WordPress core and plugin tables
wp db check
wp db repair

# Identify oversized autoloaded options causing memory exhaustion
wp db query "SELECT option_name, LENGTH(option_value) AS size FROM wp_options WHERE autoload='yes' ORDER BY size DESC LIMIT 10;"

Step 4: Patch Compatibility or Pin Version

If the site requires the updated plugin for business operations, evaluate whether a targeted patch (e.g., handling a null object check in a template hook) or a clean version downgrade via WP-CLI is appropriate:

# Safely roll back to previous known-stable version
wp plugin install offending-plugin-slug --version=2.4.1 --force

Step 5: Verification and Regression Testing

Verify that critical customer journeys work end-to-end:

Homepage, archive, and single post rendering
User authentication and session persistence
E-commerce cart, checkout, and webhook callbacks
Scheduled cron tasks (wp cron event list)

When to Seek Engineering Assistance

If a WordPress crash involves corrupted database transactions, custom plugin architecture conflicts, security compromises, or legacy codebase friction, contained engineering intervention restores stability safely.

For rapid assistance with an active failure or production regression, see WordPress & website bug fixing or queue an urgent bug fix. To prevent update regressions entirely with weekly staging tests and daily backups, explore the WordPress Care Plan. If your platform requires broader architecture stabilization, review SazM's Diagnostic Audits or start a direct technical inquiry at the contact page.

Originally published with full diagnostic protocols at SazM: WordPress Crash Recovery & Plugin Conflict Resolution.

What Is a Good Bounce Rate? Ranges by Page Type and When to Worry

Tue, 27 Oct 2026 13:38:17 +0000

We build Opti-Behavior, the WordPress plugin mentioned in this guide.

You open your analytics. Bounce rate: 68%. Is that a good bounce rate, and how do you reduce bounce rate when it is not?

The honest answer: it depends on the page. A blog post and a checkout page have very different jobs. A bounce rate that is great for one is terrible for the other.

This guide explains what a good bounce rate is for each kind of page, why a high number is sometimes fine, and how to find the real reason people leave.

What is a bounce, exactly?

In simple words, a bounce is a visit where the person arrives and leaves without doing much.

But "without doing much" means different things in different tools:

Old Google Analytics (Universal Analytics): a bounce was a visit with only one page view. Someone who read your article for 10 minutes and left still counted as a bounce.
GA4: a bounce is a visit that is not engaged. A visit counts as engaged if it lasts more than 10 seconds, or has two or more page views, or includes a conversion. So GA4 bounce rate is simply 100% minus the engagement rate.

That is why your bounce rate probably dropped when you moved to GA4. The visitors did not change. The definition did.

Tip: When you compare your bounce rate with any "average", first check which definition it uses.

Good bounce rate ranges by page type

These are broad ranges often seen across websites, using the "one page, short visit" idea. Treat them as a starting point, not a rule.

Page type	Typical range	Why
Blog post or article	65% to 90%	People read one article and leave. That is normal.
Landing page (one offer)	60% to 90%	One page, one action. No reason to click deeper.
Home page	40% to 60%	It should send people to other pages.
Product page (e-commerce)	30% to 55%	People compare, add to cart, look at other products.
Service or lead-gen page	35% to 60%	Visitors check prices, reviews, contact.
Checkout or cart	Under 30%	Leaving here usually means a problem.

When a high bounce rate is fine

The page answered the question. Someone searched "store opening hours", found them, left happy.
It is a single-page site or landing page. There is nowhere else to go.
The goal is off-site. A click to call, to an app store, or to a partner.
Long reads. In old-style analytics, a 10-minute reader who leaves is still a bounce.

When a high bounce rate is a problem

Visitors leave fast (under 10 seconds). They did not find what they expected.
Paid traffic bounces. You pay for each visit, so every quick exit costs money.
Pages that should lead somewhere (home, category, pricing) have a very high rate.
Mobile is much worse than desktop. Something is broken or slow on phones.

How to find out why people bounce

The bounce rate tells you that people leave. It never tells you why. For that you need to look at behavior.

Scroll heatmap. Do people even reach your main content? If 70% stop at the hero, the top of the page is the problem. (Pro in Opti-Behavior)
Click heatmap. Are people clicking on something that is not a link, then giving up?
Session recordings. Watch 5 to 10 visits that ended quickly. You will often spot the reason in minutes. (Pro in Opti-Behavior)
Speed on real visitors. A slow page on mobile is one of the most common causes of quick exits.

In Opti-Behavior, the Traffic dashboard shows your bounce rate and average scroll depth. Click heatmaps are free; scroll heatmaps and session recordings are in Pro. Smart Insights (Free) then turns your traffic, click and funnel data into one card per problem (Pro adds signals from recordings, scroll heatmaps, errors and forms): what is wrong, where it happens, the evidence behind it and what to check next.

7 ways to lower a bad bounce rate

Match the promise. The page must deliver what the ad or search result said.
Say what you offer in the first screen. One clear headline, one sentence, one button.
Speed up mobile. Compress the hero image, remove heavy widgets.
Remove pop-ups that fire right away. Let people read first.
Add clear next steps. Related articles, "see pricing", a visible button.
Make text easy to scan. Short paragraphs, headings, bullet lists.
Test your changes. An A/B test tells you if the new version really keeps people longer.

A good bounce rate: the bottom line

A good bounce rate is the one that fits the page’s job. Compare each page with itself over time, not with a random average. When a page that should lead somewhere starts to bounce more, look at its heatmap and a few recordings before you change anything. Our guides on adding a heatmap to WordPress and form abandonment show the next steps.

Good bounce rate FAQ

What is a good bounce rate?

It depends on the page. Very roughly, 30% to 55% is common for product pages, 40% to 60% for home pages, and 65% to 90% is normal for blog posts and landing pages.

Is a 70% bounce rate bad?

Not for a blog post or a landing page. It can be a warning sign for a home page, a product page or a checkout.

Why did my bounce rate drop in GA4?

GA4 counts a visit as a bounce only if it is not engaged (under 10 seconds, one page, no conversion). Universal Analytics counted every one-page visit, so GA4 numbers are usually lower.

How do I lower my bounce rate?

Find out why people leave with click heatmaps (free), scroll heatmaps and recordings (Pro), then fix the first screen, the speed on mobile and the next step you offer. Test the change with an A/B test.

The Opti-Behavior Team

Full guide: https://optiuser.com/blog/what-is-a-good-bounce-rate/?utm_source=coderlegion&utm_medium=referral&utm_campaign=oct26-problem-keyword&utm_content=good-bounce-rate

Drafted with AI assistance, reviewed by the Opti-Behavior Team.

Scoping a pest control website: the questions I ask before quoting

Mon, 26 Oct 2026 12:19:17 +0000

A pest control site is not priced like a brochure. When a company asks me for a quote, I skip the page count and ask these first:

Which pests do you treat? Each one should get its own page. A visitor with carpenter ants wants a page about carpenter ants, not a bullet in a list of twelve services.
How do recurring plans work today? Quarterly or monthly service is often steady income. The site can explain the plans, hand requests to your scheduling software, or take full online sign-up and billing. Each step up adds build and testing time.
What does your quote form need? Pest, property type, ZIP, contact method, optional photo. Anything beyond that costs leads.
How many service areas? I start with the three to six that bring the most work and write each one properly instead of cloning city pages.
What is already in use? Field-service or scheduling software decides how much integration work there is.
Who reviews the safety and licensing wording? That content should come from the licensed people on your team, not from me.

Typical freelancer builds land around $2,500 to $10,000 depending on how far down this list the project goes, with $50 to $300 a month in running costs. Agencies commonly charge 1.5 to 2.5 times more for the same scope.

I wrote the full breakdown, with three sample budgets and seven questions to ask any developer before signing:
https://amanurrahman.com/blog-post/pest-control-website-cost

Scoping a quote-form project for a moving company: what I look at first

Mon, 26 Oct 2026 08:39:23 +0000

When a moving company asks for a website, I skip the page list and start with one question: what happens after someone presses Submit?

That answer sets most of the cost.

Here is the checklist I run through before estimating:

Form depth. A short contact form, a multi-step quote form, or a calculator. These are three different builds, not three sizes of the same one.
Routing. Who is notified, how fast, and through what channel. An instant email or text to the estimator beats a shared inbox checked twice a day.
Auto-reply. A confirmation that states when someone will call reduces duplicate submissions.
Data handoff. If the company already uses a moving CRM, the form should feed it. That adds integration time.
Location pages. I ask how many areas they actually serve and what they can say about each one. Thin, copy-pasted city pages are not worth the build time.
Mobile behavior. The call button must be reachable without scrolling and the form must fit a phone screen.

On pricing, I see freelancer builds land around $2,500 to $10,000 depending on how far down this list the project goes. Agencies commonly charge 1.5 to 2.5 times that for the same scope.

For most local movers I recommend the multi-step form over a calculator. It collects what the estimator needs and costs far less to build and maintain.

I wrote up the full cost breakdown with three sample budgets and seven questions to ask any developer before signing:
https://amanurrahman.com/blog-post/moving-company-website-cost

Headless Vue + WordPress Boilerplate v2.0.0

Mon, 26 Oct 2026 01:04:13 +0000

Headless Vue + WordPress Boilerplate v2.0.0

Yes, Version 2.0.0 is here!!!

This boilerplate allows you to use Vue as the front-end for your WordPress theme in a headless architecture. WordPress handles the backend and REST API, while Vue powers the user interface using modern frontend tooling like Vite.

Key Features

Use Vue 3 with Vite for a fast and modern development experience
⚡ Hot Module Replacement inside WordPress: save a .vue file and see it instantly, no rebuild
One-line REST API routes in PHP and one-line calls in Vue (useApi, useWp)
WordPress pages, posts and menus work out of the box with Vue Router
Modular folder structure for components, pages, APIs, and stores
⚙️ Supports Vue Router and Pinia (Vue Store)
Style with Tailwind CSS, standard CSS or your preferred CSS preprocessor

Requirements

WordPress 6.7+ and PHP 8.1+
Node.js 20+
Pretty permalinks (Settings > Permalinks, anything except "Plain")

Folder Structure

themes/
└── vue-boilerplate/
    ├── functions/               # WordPress PHP functions
    │   ├── api.php              # Your REST API routes
    │   ├── api-helpers.php      # vue_theme_api_get(), vue_theme_api_post(), ...
    │   ├── vite.php             # Loads the Vue app (dev server or build)
    │   └── theme-settings.php   # Theme supports and menu locations
    ├── src/                     # Vue application root
    │   ├── api/                 # API client (index.js) and JS modules for API calls
    │   │   └── wp/
    │   ├── assets/              # Static assets like images and SVGs
    │   ├── components/          # Vue components (e.g., layout)
    │   ├── composables/         # useApi and useWp
    │   ├── page/                # Vue page views
    │   ├── router/              # Vue Router setup
    │   ├── stores/              # Pinia stores
    │   │   └── wp/
    │   ├── utils/               # HTML sanitizer and link helpers
    │   ├── App.vue              # Root Vue component
    │   ├── main.js              # Vue app entry point
    │   ├── settings.js          # Values passed from WordPress
    │   └── style.css            # Global styles
    ├── dist/                    # Production build (created by npm run build)
    ├── *.php                    # WordPress theme files (header.php, footer.php, etc.)
    ├── style.css                # Theme metadata
    └── vite.config.js           # Configuration file for Vite, a fast frontend build tool.

Getting Started

Download and put the files inside your themes folder, then activate the theme.
Download Latest Release
Install Dependencies
```
npm install
```
Run the Development Server
```
npm run dev
```
Open your WordPress site URL (e.g. http://mysite.local), not the Vite URL.

While npm run dev is running, WordPress loads the app from the Vite dev server. Vue and CSS changes show up instantly, and PHP changes reload the page. Stop the dev server and WordPress goes back to the production build.

Make sure WordPress is running locally (e.g., with LocalWP or Laragon) and that the theme is activated.

Build for Production

npm run build

This will compile and optimize your Vue app into dist/. Upload the theme with the dist folder, you don't need node_modules or src on the server.

Working with the API

Add a route (PHP)

Add it at the bottom of functions/api.php. Routes live under /wp-json/vue-theme/v1/.

vue_theme_api_get('/books', function () {
    return get_posts(['post_type' => 'book']);
});

// URL parameter
vue_theme_api_get('/books/{id}', function ($request) {
    $book = get_post((int) $request['id']);

    if (!$book) {
        return new WP_Error('not_found', 'Book not found.', ['status' => 404]);
    }

    return $book;
});

// JSON body
vue_theme_api_post('/contact', function ($request) {
    $email = sanitize_email($request['email']);

    return ['sent' => true];
});

// Logged in users only, or users with a capability
vue_theme_api_post('/notes', 'my_callback', ['permission' => true]);
vue_theme_api_delete('/notes/{id}', 'my_callback', ['permission' => 'edit_posts']);

Use it (Vue)

In a component, useApi and useWp are auto-imported and give you reactive state:

<script setup>
const { data: books, loading, error } = useApi('books')

// WordPress core API: posts, pages, categories, media, your custom post types...
const page = ref(1)
const { data: posts, totalPages } = useWp('posts', () => ({ per_page: 6, page: page.value }))
</script>

<template>
    <p v-if="loading">Loading...</p>
    <p v-else-if="error">{{ error }}</p>
    <ul v-else>
        <li v-for="book in books" :key="book.ID">{{ book.post_title }}</li>
    </ul>
</template>

Anywhere else (stores, event handlers), use the clients:

import { api, wp } from '@/api' // or a relative path like '../api'

const books = await api.get('books')
const result = await api.post('contact', { email, message })
const posts = await wp.get('posts', { per_page: 5, search: 'vue' })
const { data, total, totalPages } = await wp.paginate('posts', { page: 2 })

Failed requests throw an ApiError with message, status and code. The nonce for logged in users is sent automatically.

Routing

Add your own routes in src/router/index.js.
Any other URL is looked up in WordPress: src/page/Content.vue shows the page or post with that slug, or a "Page not found" message.
Menus assigned to Primary Menu and Footer Menu (Appearance > Menus) are rendered by Header.vue and Footer.vue.

Integration Tips

Site title, logo and menus are available without a request: useSiteStore()
Pass your own PHP data to Vue with the vue_theme_app_config filter, then read it from window.wpVueTheme
Always use sanitizeHtml() from src/utils/html.js before rendering WordPress content with v-html
Import images from src/assets so they get the right URL after the build
Set show_in_rest to true on your custom post types to load them with useWp('your-post-type')

❓ Troubleshooting

"The Vue app is not built yet": run npm install and npm run build, or start npm run dev.
Changes don't show up: check that npm run dev is still running and that you opened the WordPress URL.
Port 5173 is already in use: create .env.local with VITE_DEV_PORT=5174.
*Local domain is not localhost, `.local, .loc or .test**: add VITE_WP_ORIGIN=http://your-domain` to .env.local.
WordPress runs in Docker: PHP can't see the dev server on your machine, so add add_filter('vue_theme_check_dev_server', '__return_false'); to functions.php while developing.
Vue routes return a server 404: enable pretty permalinks in Settings > Permalinks.

⬆️ Upgrading from 1.x

See CHANGELOG.md for the breaking changes.

Github Repo

See Headless Vue + WordPress Boilerplate v2.0.0

License

See MIT License

Prepared by: Christopher Robin Chase

Finding the slow part of a WooCommerce page with Query Monitor

Sat, 24 Oct 2026 22:32:40 +0000

Query Monitor is a free WordPress plugin by John Blackbourn. It adds a panel to the admin toolbar that shows what one page load did: database queries, hooks, HTTP calls, PHP errors and the template that rendered the page. On a WooCommerce store it answers the usual question, "which plugin makes the product page slow", with numbers instead of guesses.

Install it on staging first

Query Monitor shows its panel to administrators only, so customers on a live store never see it. It still does its work on every request you make while logged in, which is why staging is the better home for it. Install it from the plugin directory and activate it. The toolbar then shows four figures for the current page: generation time, peak memory, database query time and the number of queries.

Read the queries by component

Open the panel and go to Queries by Component. Every query is attributed to the plugin, theme or core file that made it, with a count and a total time. Sorting by time usually points at one or two plugins.

Duplicate Queries is the next view to open. The same query repeated dozens of times in one request often comes from a loop that reads product meta one product at a time.

Slow Queries lists every query that took longer than 0.05 seconds. That threshold is the QM_DB_EXPENSIVE constant, and you can lower it in wp-config.php when the whole page is slow but no single query stands out.

Check outgoing HTTP calls

The HTTP API Calls panel lists the requests a page sent to other servers while it was being built. Licence checks, currency rates and shipping quotes are the usual suspects. A plugin that calls an external API on every product page adds that server's response time to yours. For each call the panel shows the URL, the response code and how long it took.

Time your own code

Query Monitor also has a small profiling API. Wrap a block of code in two actions and it shows up in the Timings panel:

do_action( 'qm/start', 'shipping_estimates' );
// the code you want to measure
do_action( 'qm/stop', 'shipping_estimates' );

For a value you want to inspect, do_action( 'qm/debug', $variable ); sends it to the Logs panel instead of the page output.

Look at a page as a guest

Some slowness only appears for logged-out visitors, for example when a cache plugin treats them differently. The Query Monitor settings can set an authentication cookie, and with it the panel keeps working in the same browser after you log out.

When you are done

Deactivate the plugin once the slow part is found. It is light, but there is no reason to keep it running on a store that nobody is debugging.

Logging WooCommerce shipping rates to find where they disappear

Sat, 24 Oct 2026 17:37:33 +0000

When a store reports "No shipping options were found," the first useful question is where in the pipeline the rates vanish. Zones and methods are only one possibility. A plugin can filter them out, or the rates can exist and fail to display.

WooCommerce passes the final list of rates through the woocommerce_package_rates filter. A small logger there tells you immediately which side of the problem you are on. Run it on staging with WP_DEBUG_LOG enabled:

add_filter( 'woocommerce_package_rates', function ( $rates, $package ) {
    error_log( 'Shipping rates found: ' . count( $rates ) . ' for ' . $package['destination']['country'] . ' ' . $package['destination']['postcode'] );
    return $rates;
}, 999, 2 );

How to read the result:

Zero rates: the problem is upstream. Check zones, enabled methods, postcode rules, free shipping conditions, product weight for carrier plugins, and the carrier plugin's own log.
One or more rates, but the customer sees nothing: the problem is display. Suspect page caching on cart or checkout, a theme override, or a plugin that does not support the checkout type (shortcode or block).

Two tips that save time:

Turn on the shipping debug mode in WooCommerce settings. It bypasses cached rates and shows which zone matched.
Change one thing at a time and clear the WooCommerce transients between tests, otherwise a stale result can make a real fix look like it did nothing.

Remove the logger when you finish. If you want the full non-developer checklist, with a symptom and fix table, I put it here: https://amanurrahman.com/blog-post/woocommerce-no-shipping-options-available-fix

WooCommerce checkouts started but not paid: a 15-minute diagnosis

Sat, 24 Oct 2026 13:42:12 +0000

We build Opti-Behavior, the WordPress plugin mentioned at the end.

Carts get filled. The checkout page gets visits. Few orders arrive. Before you change the design, find out where the money stops.

Count two pages over the same days: visits to the checkout page and visits to the order received page. The gap is your checkout leak.
Open WooCommerce > Orders and filter on Pending payment and Failed. Many Failed orders point to a payment problem, not to buyers changing their mind.
Look at the dates. A sudden drop right after a plugin or theme update points to a broken checkout. Place a test order on a phone and on a computer.
Read the payment gateway logs in WooCommerce > Status > Logs for the days of the drop.
Split by device. A checkout that works on desktop can fail on phones.

To keep an eye on it without reading logs every day, track five steps: product page, add to cart, cart, checkout, order received. For the last one, match "URL contains order-received", because the real address holds the order number.

In Opti-Behavior's free plugin, a purchase funnel is suggested on WooCommerce sites, and Smart Insights writes a card that names the step where visitors leave, ranked by visitors lost. Opti-Behavior Pro adds payment errors grouped by error type and payment method.

Smart Insights (Free) flags the funnel step where visitors drop off and says what to open next.

The full guide (set-up with GA4 or inside WordPress, the four usual leaks, Free vs Pro): https://optiuser.com/blog/woocommerce-conversion-tracking/?utm_source=coderlegion&utm_medium=referral&utm_campaign=oct26-problem-keyword&utm_content=woocommerce-conversion-tracking

Drafted with AI assistance, reviewed by the Opti-Behavior Team.

Designing the estimate form for a painting contractor site

Sat, 24 Oct 2026 13:42:02 +0000

Most local-service sites treat the contact form as an afterthought. For a painting contractor it is the main conversion point, so it deserves the same care as the design.

Why painters are different from emergency trades: nobody calls a painter at midnight. They collect a few names, describe the job and wait for a reply. The form has to make describing the job quick, and it has to give the contractor enough detail to answer well.

Fields that earn their place:

Name, phone, email, and a preferred contact method
Interior, exterior, or both
Rough number of rooms, or approximate exterior size
A photo upload (the biggest quality boost, because the painter can give a better first answer)
Timing: this month, next season, flexible
One free-text box for the unusual stuff (high ceilings, wallpaper, repairs)

Things I check before calling it done:

The form works on a phone with one thumb
The notification reaches a real inbox, not spam
Spam protection does not block real customers
The visitor sees a confirmation and gets an automatic email
Uploaded photos are size-limited so the host does not choke

The same logic applies to the rest of the site: put the effort into the gallery, one page per job type and the form, and skip the animation and the dozens of thin town pages.

If you want the full cost breakdown with budget ranges and three sample budgets, I put it together here: https://amanurrahman.com/blog-post/painting-contractor-website-cost

What I put in an electrician website before I quote it

Fri, 23 Oct 2026 04:48:40 +0000

Electricians look like an easy client: a few pages, a phone number, done. In practice the site is a trust check. Customers cannot judge wiring, so they judge the website before they call. That changes how I scope the work.

First, proof. I plan a block showing the license number, insurance and real photos of the van, the team and finished work, such as a tidy panel upgrade. Stock photos of smiling models do the opposite of what the client wants.

Second, one page per job type. Nobody searches "all electrical work." They search for panel upgrades, EV charger installation, generator hookups or rewiring. A page for each can rank for that exact search and gives the client something specific to link from ads or a Google Business Profile.

Third, the enquiry form. A plain contact form produces "need an electrician" and nothing else. I build a quote form that asks for job type, property age, town, urgency and a photo of the area. The electrician gets one email with enough detail to price the job, and out-of-area jobs are filtered before anyone phones back.

Fourth, ongoing costs. I put hosting, maintenance and any call tracking or scheduling software in the proposal from day one, so the client is not surprised later.

Fifth, ownership. I tell the client up front that the domain and files are theirs. A subscription site that disappears when payments stop is rent, not a website.

For a solo or small-shop electrician who wants a custom site with job pages and a quote form, I usually quote between $2,800 and $5,500. The full breakdown, with feature costs, running costs and sample budgets, is here: https://amanurrahman.com/blog-post/electrician-website-cost

Keeping a Website Healthy: What Maintenance Covers, Who Should Do It

Fri, 23 Oct 2026 00:32:27 +0000

A website isn't finished the day it launches. The software underneath keeps changing, certificates and domains expire on a schedule, hosting occasionally fails and forms break quietly when something upstream changes. This guide covers what maintenance actually includes, what skipping it costs, a schedule you can keep yourself and how to judge a plan if you'd rather hand it off.

I define maintenance as everything that keeps an existing site safe, working and fast, as distinct from redesigns and from hosting. Almost every plan or sensible routine comes down to six jobs: backups (stored off-site and actually test-restored), updates, security, monitoring, renewals and fixes. How much a site needs depends mostly on how many moving parts it has.

The costs of skipping it are ordinary rather than dramatic: a known vulnerability gets exploited, a contact form stops delivering and nobody notices, a certificate or domain lapses, speed slowly decays, a forced PHP upgrade lands all at once, or there's no clean backup when you need one. The schedule covers continuous, monthly, quarterly and yearly tasks.

I list the signs it's time to hand maintenance off and eight questions to ask before signing up for any plan, including whether you keep your logins and backups if you cancel. There's a disclosed look at BugShield's WordPress plans as a content partner, and a note on why custom-coded sites with no plugin stack need less upkeep.

Key takeaways

Maintenance is six jobs: backups, updates, security, monitoring, renewals and fixes
A backup you've never restored isn't a plan
Test every form monthly by submitting it
Track domain and certificate renewals and the card behind them
Before signing a plan, confirm you keep your logins and backups

Related on BuiltToWinWeb: BuiltToWinWeb's services

Read the full guide on BuiltToWinWeb: The complete website maintenance guide

A summary by Jacob Campbell of an article first published on built2winweb.com on October 8, 2026.

How I scope an HVAC contractor website before quoting it

Thu, 22 Oct 2026 11:26:06 +0000

HVAC contractors look like an easy client. Five pages, a phone number, done. I have learned to scope them more carefully, because the real work hides in a few places.

First, I split visitors into two groups: someone with a dead furnace tonight, and someone planning a replacement. The first needs a big click-to-call button and visible hours. The second needs proof and financing. If the homepage does not serve both within a few seconds, the design is wrong, whatever it looks like.

Second, I ask what software they run. Many contractors use dispatch or scheduling tools, and connecting the website to them is a separate piece of work. I quote it on its own line, because some tools have clean connections and some do not.

Third, I ask whether they sell maintenance plans. If they do, I scope a membership or recurring-payment setup: plan tiers, renewals, receipts and a small account page. It is the feature that makes the project pay for itself, and it behaves like a small store, so I treat it like one.

Fourth, I limit city pages. Clients often ask for thirty. I start with the three to six towns that produce most of their calls and write each with real local detail. Thin pages cost money and rarely rank.

Last, I quote ongoing maintenance on day one, and I ask who owns the domain and the site files. A subscription site that disappears when the client stops paying is rent, not a website.

For a single-location company that wants a site that books jobs, I usually land between $3,000 and $7,000. The full breakdown, with feature costs, running costs and three sample budgets, is here: https://amanurrahman.com/blog-post/hvac-website-cost

What I check first when a WordPress site throws a memory exhausted error

Wed, 21 Oct 2026 05:20:32 +0000

A client message I see often: "the site went white after I installed a plugin," and the log shows an allowed memory size error. Here is the order I work in, because the usual advice skips a step.

First, I do not touch any file. I read the error. The number is in bytes, so 134217728 means the site was capped at 128 MB. The file path at the end tells me which plugin or theme was running when memory ran out.

Second, I check what limit PHP really has. In wp-admin, Tools then Site Health then Info then Server shows it. If it says 128M, adding a 256M line to wp-config.php will not help, because the host's ceiling wins. That is the number one reason the popular fix fails.

Third, I raise the limit at the layer that owns it: the hosting panel's PHP settings, a php.ini or .user.ini line, and only then wp-config.php. I avoid the .htaccess php_value method unless I know the server uses mod_php, since on PHP-FPM it turns one error into a 500.

Fourth, and this is the step people skip, I find out why memory ran out. I turn on WP_DEBUG_LOG with display off, repeat the action that fails, and read the newest lines in debug.log. If one plugin keeps appearing, I deactivate it by renaming its folder and retest. Usually the culprit is a backup plugin, a big import, an unresized image upload, or a page builder page with too many widgets.

If a site needs 512M to load a basic page, a bigger limit is a bandage. I would rather fix the source.

Full guide with the bytes table and a symptom-to-cause chart: https://amanurrahman.com/blog-post/wordpress-allowed-memory-size-exhausted-fix

SendFleet now has a WordPress plugin

Tue, 20 Oct 2026 18:00:37 +0000

SendFleet is now in the WordPress.org plugin directory.

How it works: install the plugin, paste your API key, and your WordPress site sends its emails through SendFleet instead of the server’s default mail. It works with WooCommerce and contact form plugins.

You can send through your own AWS SES account, so the sending reputation stays yours, or through SendFleet’s.

Plugin page: https://wordpress.org/plugins/sendfleet

This is the first version. If you run a WordPress site, I want to know what is missing or confusing. I will answer every reply.

How many characters your language gets in a WordPress URL

Mon, 19 Oct 2026 08:06:20 +0000

When The 200-byte trap went up, a reader on CoderLegion asked the question I should have answered in the article itself: is this only an Arabic problem?

It isn't. But "it isn't" is not much of an answer, and the one I gave in the comments was arithmetic, not measurement. So I put a typical news headline in fifteen languages through a fresh WordPress 7.1.3 site and looked at what came out the other end. Then I opened the resulting URLs the ways readers actually open them: whole, cut short, and after the slug had changed.

The short answer: English gets 200 characters. Arabic, Hebrew, Greek and Russian get about 33. Hindi, Thai, Chinese and Japanese get 22. The longer answer has a few surprises in it, and one setting that makes most of it stop mattering.

The rule: 200 characters, counted after encoding

WordPress builds a slug from the title in sanitize_title_with_dashes(). Anything outside plain ASCII is stored percent-encoded, the same %XX form it travels in, and the cut is applied to that encoded form, in one line of current core:

$title = utf8_uri_encode( $title, 200 );

Every UTF-8 byte becomes a three-character %XX token, so what a letter costs depends only on how many bytes its script needs:

a Latin letter, a digit or a hyphen: 1 byte, costs 1
Arabic, Persian, Urdu, Hebrew, Greek, Cyrillic: 2 bytes, cost 6
Hindi, Thai, Chinese, Japanese, Korean: 3 bytes, cost 9
an emoji: usually 4 bytes, costing 12, and some cost far more

Divide 200 by the cost and you have the ceiling. The cut never splits a character in half, because utf8_uri_encode() stops before one that would not fit. It does split words: nothing in it knows where a word ends. Category and tag slugs go through the same function, with the same 200.

The emoji line hides two surprises. ❤️ is two code points at 9 each, and the second is an invisible one that stays in the URL. A family emoji is three people held together by invisible joiners, and WordPress counts the joiners, then strips them, so the URL ends up with three separate people.

Every slug gets the same 200 characters. A Latin letter spends one of them, an Arabic, Hebrew, Greek or Russian letter six, a Hindi, Thai, Chinese, Japanese or Korean character nine, and an emoji twelve. What is left over is too small for one more.

The numbers, measured

Here is what WordPress 7.1.3 kept of a news headline in each language. "Cost per letter" is counted after accents are removed, so é costs what e does. "Characters kept" includes the hyphens that replaced the spaces, and the last word counted is usually a fragment.

Language	Cost per letter	Characters kept	Of which letters	Words
English	1	199	170	30
French	1	190	161	30
German	1	198	174	25
Vietnamese	1	157, the whole headline	123	35
Arabic	6	38	32	7
Persian	6	36	30	7
Urdu	6	40	32	9
Hebrew	6	38	32	7
Greek	6	37	32	6
Russian	6	36	32	5
Hindi	9	26	21	6
Korean	9	27	21	7
Thai	9	22	22	1, no spaces
Chinese	9	22	22	1, no spaces
Japanese	9	22	22	1, no spaces

Three things in that table are worth a second look.

The two-byte scripts stopped at 32 letters, not 33, and Persian at 30. Hyphens come out of the same 200, so a headline with six spaces keeps 32 letters and six hyphens, and Persian's missing two are explained further down. In practice that is five to nine words, depending on how long the words are, and the last is usually cut: the Arabic slug ends in «ال», the definite article of a word that did not fit.

Twenty-two characters is fewer letters than it sounds in Hindi and Thai. The count is of code points, and their vowel signs and tone marks are code points of their own. The Thai slug ends in «ใหม», which is «ใหม่» without its tone mark.

Thai, Chinese and Japanese get no hyphens at all. They don't put spaces between words, so the whole slug is a single run of 22 characters.

One more cost doesn't show in the table. When a slug is already taken, WordPress cuts it again to fit a suffix, so a second and a third post with the same Urdu headline each lost a letter to make room for -2 and -3. And with only five to nine words to tell headlines apart, non-Latin slugs are likelier to collide in the first place, for the same reason cut-off links go astray below.

Accented Latin gets the full 200, and the site language decides how

French, German and Vietnamese kept as much as English because their accents never reach the encoder. When a slug is saved, sanitize_title() runs remove_accents() first: é becomes e, and the whole Vietnamese headline came through as plain ASCII.

How a letter is transliterated depends on the site language. On a site set to English, «Maßnahmen» became masnahmen, and «Größe» would become grose, which is a different word. With the site set to German, the same function produces massnahmen and groesse. Danish (soester, paa), Catalan (collegi) and Serbian (djordje) get the same care from their own locales. Slugs are generated when a post is saved, so set the site language before the archive grows, not after.

What spends the budget without showing up

The cut happens before WordPress tidies the slug, so some characters are counted first and only then removed or replaced. Arabic and Persian headlines are full of them, and English ones are not free of them either.

Angle quotes. «» cost 6 each and are stripped once counted. A headline that opened with «عاجل» and quoted one more word kept one letter of «الشركات», where the same headline without the quotes kept five, «الشرك».
Invisible marks. A right-to-left mark costs 9, and so does the Persian zero-width non-joiner. Both are stripped. The Persian headline shows a second cost too: «کسبوکار» came out as «کسبوکا», glued together and then cut.
Curly punctuation, in any language. A curly apostrophe, as in what’s, costs 9 and is stripped, and so are curly quotes and the ellipsis. En and em dashes cost 9 and become hyphens. Headlines pasted from a word processor tend to be full of them: a long English headline with four apostrophes, a pair of curly quotes and a dash lost 62 characters of its slug to them, and stopped at 133.

What spends the budget and stays in the URL

Worse are the characters that are counted and then kept. WordPress's list of characters to strip was written for Latin text, so marks from other scripts reach the URL at full price.

Arabic-Indic digits. ٥٠٠٠ costs 24 where 5000 costs 4, and the cut can fall inside a number. A headline about a 5,000-dinar grant came out ending in «بقيمة-٥٠٠», worth 500: a figure that looks right and isn't. Typed with Western digits, the same headline kept the whole number.
Diacritics. Each tashkeel mark costs 6. A fully vocalised headline fitted three and a half words, «الحُكُومَةُ-تُعْلِنُ-خُطَّةً-جَدِيد».

Punctuation from other scripts is kept too, at 6 or 9 a mark. This is core's own output:

Arabic comma and question mark
عاجل،-الحكومة-تعلن-خطة؟-جديدة

Arabic semicolon
أولاً؛-ثانياً

Urdu full stop
حکومت-کا-اعلان۔-نیا-منصوبہ

Japanese punctuation
「速報」政府が新計画を発表！

Chinese punctuation
政府宣布，新计划。

The worst are invisible. WordPress strips the old bidirectional embedding marks once it has counted them, but it keeps the newer isolates, U+2066 to U+2069, and the Arabic letter mark. The isolates cost 9 each and the mark 6, and they stay in the URL without ever showing in the headline.

What happens when someone opens a cut-off link

Most sites use slug-only permalinks, /%postname%/. I opened the Arabic test post four ways:

Request	Result
the stored slug	200, the article
cut after four words, an opening two headlines share	301 to one of the two, picked by the database
cut where only one headline matches	301 to the right article
longer than the stored slug	404

The middle rows come from redirect_guess_404_permalink(). When a slug isn't found, WordPress looks for one that starts with what was requested, post_name LIKE 'cut%', and redirects to the first match. The query has no ORDER BY, so when two headlines share their opening words, which one the reader gets is up to the database. On my test site the older article won, but don't count on it: another database, or the same one reading through a different index, can return the other. News headlines share openings all the time («القبض على المتهمين في» …), and the redirect is a 301, which tells browsers and search engines the move is permanent.

If you would rather WordPress matched exactly than guessed, there is a filter for that:

add_filter( 'strict_redirect_guess_404_permalink', '__return_true' );

With it, a cut-off link gets a 404 even when the guess would have been right. Exact matches are still redirected, and that matters further down: after a switch to ID-anchored permalinks, old slug-only links are found by this same guess, and strict matching keeps them working. The filter that turns guessing off altogether, do_redirect_guess_404_permalink, would send every one of them to a 404.

The last row is the 200-byte trap in miniature. A link longer than the stored slug never matches, because the stored slug doesn't start with it. That is what readers meet when a core update shrinks a widened column under links that are already out in the world.

Put the ID in the URL

The setting that makes most of this stop mattering is under Settings → Permalinks: a custom structure of /%post_id%/%postname%/. The words stay in the URL for readers, and the number decides which article it is. The same requests, plus a few harsher ones:

Request	Result
the ID and the stored slug	200
the ID and a longer slug	301 to the article
the ID and the shared four-word cut	301 to the right article
the ID and unrelated words	301 to the article
the ID alone	200, with a canonical tag naming the full URL
an old slug-only link, after switching	301 to the article
the right slug with another post's ID	301 to that other post

The reason is a few lines in redirect_canonical(). When the slug doesn't match, the request is a 404 for a moment, but the post ID is still in it, and WordPress sends the reader to that post's real permalink:

if ( is_404() ) {
// Redirect ?page_id, ?p=, ?attachment_id= to their respective URLs.
$post_id = max( get_query_var( 'p' ), get_query_var( 'page_id' ), get_query_var( 'attachment_id' ) );

$redirect_post = $post_id ? get_post( $post_id ) : false;
// … and for a public post: $redirect_url = get_permalink( $redirect_post );

The last row in the table is the price: the number outranks the words, so a mistyped ID lands on a different article. Links are copied far more often than they are typed, and for a large archive that is a trade I would take.

Switching an existing site went smoothly in the test: old slug-only links were redirected to their articles by the same guess as above, with or without strict matching. So after switching, leave guessing on, and watch the 404 log for a while.

Give the slug its budget back

A small must-use plugin recovers the space those characters waste, and keeps Arabic-script punctuation out of the URL. It runs before WordPress counts, and only when a slug is being saved, so existing URLs keep matching exactly as before:

<?php
/**
 * Give slugs their budget back: drop or replace characters that cost slug
 * space, before WordPress counts them. Mostly Arabic, Persian and Urdu ones,
 * plus the curly quotes, dashes and ellipses that English headlines pick up.
 */
add_filter( 'sanitize_title', function ( $title, $raw_title = '', $context = 'display' ) {
if ( 'save' !== $context ) {
return $title; // Leave lookups alone, so existing URLs keep matching.
}
// Arabic diacritics, superscript alef and tatweel: 6 each, and they clutter the URL.
$title = preg_replace( '/[\x{064B}-\x{065F}\x{0670}\x{0640}]/u', '', $title );
// Quotes, the ellipsis and invisible marks, which WordPress strips anyway,
// but only after counting them.
$title = preg_replace( '/[\x{00AB}\x{00BB}\x{2039}\x{203A}\x{2018}-\x{201F}\x{2026}\x{200B}-\x{200F}\x{FEFF}]/u', '', $title );
// Direction controls: WordPress strips the embeddings only after counting
// them, and keeps the isolates and the Arabic letter mark in the URL.
$title = preg_replace( '/[\x{061C}\x{202A}-\x{202E}\x{2066}-\x{2069}]/u', '', $title );
// Punctuation that WordPress keeps in the URL (Arabic comma, semicolon and
// question mark, Urdu full stop) or turns into a hyphen only after counting
// it (no-break space, en and em dash): make it a space, which costs 1.
$title = preg_replace( '/[\x{060C}\x{061B}\x{061F}\x{06D4}\x{00A0}\x{2013}\x{2014}]/u', ' ', $title );
// Arabic-Indic and Persian digits cost 6 each; 0 to 9 cost 1.
$title = strtr( $title, array_combine(
preg_split( '//u', '٠١٢٣٤٥٦٧٨٩۰۱۲۳۴۵۶۷۸۹', -1, PREG_SPLIT_NO_EMPTY ),
str_split( '01234567890123456789' )
) );
return $title;
}, 9, 3 );

On the test site, the quoted headline's slug came out identical to the unquoted one. A long headline with an Arabic comma and question mark got plain hyphens in their place, and kept two more letters. A headline carrying invisible isolates lost them and kept three more letters, and the Arabic letter marks were dropped too. The grant headline came out with its whole number, 5000, and the vocalised headline went from three and a half words to six, with no diacritics in the URL. English titles come out as core makes them, only no longer cut short: the long English headline went from 133 characters to 195. The plugin leaves Chinese and Japanese punctuation alone, so there it still costs 9 and stays in the URL.

So, is it only Arabic?

No. Every language outside the Latin alphabet pays for the same 200 characters at a higher price: six per letter for the two-byte scripts, nine for the three-byte ones. English pays too, every time a curly apostrophe or a dash is pasted in. Arabic newsrooms are where I met it first, because that is mainly where I work, not because the rule treats Arabic differently.

What to do about it, roughly in order of effort:

If your language uses accented Latin, set the site language before you publish.
Edit long slugs by hand. Five to seven words is plenty.
On a Russian or other Cyrillic site, consider a transliteration plugin such as Cyr-To-Lat, which writes slugs in Latin letters, so they cost what English costs. Arabic rarely goes that way, because Arabic written in Latin letters is hard to read back.
On an Arabic, Persian or Urdu site, or any site whose headlines arrive with curly quotes and dashes, add the plugin above.
On a large archive, anchor permalinks on the post ID.
If you need longer slugs than any of this allows, widen the column, raise the budget, and stop core updates from shrinking it back. That is what wp-arabic-slug-schema-guard does.

Every number here was measured on a stock WordPress 7.1.3 site in WordPress Playground, which runs on SQLite. The slug lengths are worked out in PHP and will be the same on MySQL. Which article a shared opening lands on may not be, which is rather the point.

MelaCMS: the CMS for the agentic era

Sun, 18 Oct 2026 09:48:57 +0000

WordPress won the last era

For twenty years WordPress was the fastest way to put a small or medium website in a client's hands. You picked a theme, added a few plugins, uploaded it all to a cheap shared host and handed over a login. The client wrote their own pages from then on. Nobody needed a server team, and one developer could deliver a site in days.

That was a good deal. It is why so much of the web runs on WordPress, and it should be respected.

The era changed

Today the developer does not type most of the code. A coding agent does: it reads the project, makes the change, runs the tests and hands back a diff to review.

So speed no longer comes from how much you can click together in an admin screen. It comes from how much of the site an agent can read, change and prove.

By that measure WordPress is slow.

Why WordPress stops an agent

The site lives in the database. Menus, widgets, page builder layouts, plugin options and custom fields are rows in wp_options and wp_postmeta, often as serialized PHP. An agent cannot read them in a diff. Nobody can review a change to them, and a commit cannot carry them from a local copy to production.

The code belongs to someone else. Much of what a WordPress site does sits in third-party plugins. An agent cannot fix a plugin, only work around it, and the next plugin update can undo the work.

Nothing proves the site works. A WordPress site comes without a test suite. An agent that cannot run tests can only guess, and you are left to check its guesses by clicking around.

Every site is different. Each one has its own mix of plugins, versions and page builder. What the agent learned on one site does not hold on the next.

The basics cost extra. Translated content, custom fields and serious SEO are usually plugins, often paid ones, each with its own data model to learn.

A language decision is forever. With a multilingual plugin such as WPML, each translation is a separate post, linked to an original in the default language. The licence is the small cost. The big one comes when the client decides, a year later, that the site should open in English instead of Italian, or when a junior developer set the wrong default language on day one. Every post, page, menu, slug and string was built around that choice, and changing it turns into a migration project.

Shipping is manual. Files go up over FTP, databases are copied between environments, and updates are clicked in production.

None of this mattered when a human did the clicking. It is the bottleneck now.

And WordPress pays for its flexibility at runtime

WordPress is flexible because it stores almost everything in the same few tables. Every post, page, product and menu item is a row in wp_posts. Every custom field of every one of them is a separate key/value row in wp_postmeta, with the value in a text column that has no index.

That one design fits any content type. It also means:

a record with twenty fields is twenty-one rows,
filtering or sorting by a field is a join on that text column, done once per field,
wp_postmeta grows faster than any other table and slows down every query that touches it,
every active plugin loads on every request, whether the page needs it or not.

The usual fix is more caching, a bigger server or a managed host, which is the opposite of the cheap shared hosting that made WordPress popular.

Flexible and fast

MelaCMS keeps the flexibility and drops the cost:

Each kind of content has its own table, with real columns of the right type that you can index. A record is one row. Filtering a list of services by date is a plain indexed query, not a join through a meta table.
Translations live in the same row, in JSON columns. Adding a language adds no rows and no joins.
The default language is a setting, not a foundation. An admin picks another default language on the Languages page and saves. No data moves, however much content is already translated. The new default goes to the root of the site, the old one moves under its prefix, and every page keeps an address.
Flexibility where it belongs. A field that only one page template needs goes into a single JSON column on the page, with no migration. Content that grows or gets queried gets its own table, which an agent writes in a minute.
Nothing runs that the site did not ask for. There are no plugin hooks loading on every request. The site's settings are read with one query per request, and the deploy caches the config, routes, views and events.
Images are ready before the visitor arrives. WebP sizes are made once at upload, not resized on the fly.

The result is a site that stays fast on the cheap host as its content grows. This is not a separate feature: it follows from the site being code.

What MelaCMS keeps

WordPress was right about what matters to clients and to small studios. MelaCMS keeps all of it:

An admin panel the client understands. They log in and write pages, upload images, translate content and change the site's details, without calling you.
Cheap hosting. A shared host with PHP and SSH is enough. No containers, no Node server, no queue worker, no managed platform to pay for.
What every site needs, out of the box. Pages, a media library, languages, SEO, a sitemap, users and roles.
One person can deliver a site.

What MelaCMS changes

Everything else becomes code.

The site is a Laravel repository. Models, migrations, admin screens, views and routes are files that an agent reads, changes and tests.
The core is a dependency. It arrives through Composer, is never edited, and is updated with one command. Every site runs a known version.
The agent gets instructions. The installer writes a MelaCMS section into the site's AGENTS.md and CLAUDE.md. A guide shipped with the core takes the agent from the migration to the test of a new kind of content, and the core's own test suite runs that guide's code, so it cannot go stale.
Shipping is set up from the first commit. CI, conventional commits, versions, changelog and a deploy over SSH on every release.
Content and structure are kept apart. Editors own the pages and the media, in the database. Developers own how the site works, in git.

What MelaCMS refuses

No plugin marketplace. A feature the site needs is code in the site: written with the agent, tested, and owned.
No page builder. Templates are Blade views. Editors choose a template and fill in its fields.
No structure in the database. Anything that changes how the site works lives in git.
No update button on the server. An update happens on a developer's machine, passes CI and ships as a release.

Who it is for

MelaCMS is for freelancers and small studios who build client websites with a coding agent, who work with Laravel or want to, and who want to hand over a site that:

the client can edit,
the next developer, or the next agent, can understand,
runs on the hosting the client already pays for.

It is not for building a site without code, for a client who expects to install plugins themselves, or for a host with FTP and no SSH.

The bet

Building a website keeps getting cheaper. What stays expensive is a website nobody can safely change.

MelaCMS bets that the CMS of this era is the one an agent can read from end to end, change with confidence and prove with tests, while the client still logs in to an admin panel on a cheap shared host, as they always have.

That is the WordPress deal, rebuilt for the agentic era.

Six Steps to Make a WordPress Site Readable by AI Assistants

Fri, 16 Oct 2026 16:18:32 +0000

Most WordPress installs were configured with Google in mind rather than AI assistants. Fortunately WordPress already provides most of what's needed: structured content in a database, a REST API, permalinks and a big plugin ecosystem. Making it readable by AI is mostly about not blocking the right bots, exposing content in cleaner forms and telling agents where to look. This guide goes step by step, with plugin and manual options.

Step one is checking you aren't blocking AI search and user-triggered bots, not only in robots.txt but in security plugins and CDN toggles too. Step two is being indexed in Google and Bing, with sitemaps submitted and IndexNow on. Step three is checking your schema: organisation details filled in, a LocalBusiness subtype for local firms and no self-serving review markup expecting stars.

Step four is adding llms.txt, and actually reading what a plugin generates, because automatic files often list every post and say nothing about the business. Step five, the one most WordPress sites skip, is serving Markdown versions of posts with the right headers. Step six is an MCP server built on the REST API or WooCommerce, with read-only public tools.

I mention the one-plugin route through the AI Indexing Pack's WordPress edition, and end with two checks: a WebAgentScan score before and after, and asking a browsing assistant to read your llms.txt and describe your business.

Key takeaways

Check security plugins and CDNs as well as robots.txt
Be indexed in both Google and Bing, with IndexNow on
Review any auto-generated llms.txt by hand
Markdown versions of posts are the most-skipped step
Test by asking an assistant to describe your business from llms.txt

Related on BuiltToWinWeb: robots.txt rules for AI crawlers

Read the full guide on BuiltToWinWeb: How to make WordPress readable by AI

A summary by Jacob Campbell of an article first published on built2winweb.com on October 5, 2026.

The Questions I Ask a Landscaper Before Quoting a Website

Fri, 16 Oct 2026 13:45:02 +0000

A landscaping owner once told me, "I just need a simple site." Ten minutes later we had listed a gallery, five services, four towns, a quote form with photo upload, and weekly mowing sign-ups. Here are the questions that turned a vague request into a priced scope.

How many finished projects can you show right now?
The gallery is the heart of a landscaping site. If the photos are not ready, that is the first cost, because strong photos matter more than any feature. I ask for the last 10 to 15 jobs, ideally before-and-after pairs.
Which services do you actually want calls for?
Each one gets its own page with real text. I ask owners to rank services by profit, not just by popularity, and launch with the top few.
Which towns do you really serve?
Service area pages help only when each has something specific to say. Copy-and-paste pages for ten towns add cost and little value, so I cap the first version.
What should the quote form collect?
A basic contact form means follow-up calls to learn the job. A structured form saves those calls. A form with photo upload saves site visits, but it needs secure file handling, size limits, and spam protection, so it is priced separately.
Do customers pick maintenance plans themselves?
Lawn size and access vary, so most owners prefer quote-first, then enrollment. Full online sign-up means subscriptions, billing, and cancellation rules. I only build that when plans are truly standard.
When do you want to launch?
Enquiries rise toward the growing season. If the site is live before then, there is time for testing and for search engines to find the pages. A rushed mid-season launch usually means thin content and untested forms.

My rough bands, for reference: a small crew information site around $1,500 to $3,500, an established residential company around $3,000 to $6,500, and design-build with online plans around $6,500 to $12,000. These are general ranges, not quotes.

The most common overspend I see is building full online enrollment and a dozen area pages before the gallery and quote form are strong.

Full cost breakdown, ongoing fees, and three example budgets: https://amanurrahman.com/blog-post/landscaping-website-cost

What I Ask a Repair Shop Owner Before Quoting a Website

Fri, 16 Oct 2026 08:29:05 +0000

A repair shop owner asked me for a "basic website" last month. After ten minutes of questions it became three different projects with three different prices. These are the questions I now ask before I quote anything.

How do customers contact you today?
If 90% still call, the priority is a tappable phone number, hours, and a map on every page. That is a small build. If the front desk is buried in calls, we talk about appointment requests.
Do you want appointment requests or live scheduling?
A request form lets the customer suggest a time while the shop confirms it. Live scheduling shows real open slots and has to know how many bays and technicians exist, how long jobs take, and what happens when one runs over. The first is quick to build. The second is a real feature.
What shop software do you use?
Many shop management systems already offer appointment or estimate widgets. If one exists, embedding it is far cheaper than a custom integration. I always ask the vendor before writing a line of code.
Do you want online estimates?
A request form that captures year, make, model, and the problem is easy. A price calculator is not. And any number shown online should be labeled a rough range, because a form cannot diagnose a car.
How many locations?
Every location needs its own page, address, hours, map, and reviews. The structure matters, because locations should support each other in search, not compete.
Who updates the site later?
If the front desk will manage specials and hours, the admin experience matters. I budget for a short training session and a maintenance plan, since a form that silently stops working costs real jobs.

My rough bands, as a reference: one-bay information site around $1,500 to $3,500, independent shop with appointment and estimate forms around $3,000 to $6,500, and multi-location or software-connected sites from $6,500 up. These are general ranges, not quotes.

The most common overspend I see is buying live scheduling and custom integrations for a shop that mostly needs a fast site, honest photos, and a clear phone number.

Full cost breakdown, ongoing fees, and three example budgets: https://amanurrahman.com/blog-post/auto-repair-shop-website-cost

Scoping a Tutoring Website: The Questions I Ask Before Quoting

Thu, 15 Oct 2026 16:26:31 +0000

When a tutor or learning center asks for a website quote, I do not start with design. I start with five scoping questions, because the answers decide whether the project is a $2,000 build or a $10,000 one.

Who needs to book, and with whom?
A solo tutor needs one calendar. A center needs per-tutor availability, double-booking prevention, and subject matching. This one answer changes the architecture more than anything else.
What happens when a student cancels or reschedules?
Cancellation rules sound like business policy, but they become logic: refund windows, credit carry-over, reminders. Clients rarely mention this until it is built, so I ask early.
How does money move?
Card payment at booking, prepaid packages, and monthly plans each need different handling. Packages need credits that get used up and can expire. Monthly plans need renewal and failed-payment handling. I price these separately from the booking calendar.
Do parents need to log in?
Accounts mean passwords, email flows, permissions, and ongoing support. If a client has fewer than a few dozen families, I usually suggest receipts by email instead, and revisit accounts later.
Who will run the site after launch?
If front-desk staff will manage bookings, the admin experience matters as much as the public pages. I budget for a short training session and for plan-level maintenance, since a broken booking form in exam season costs the client real students.

A note on children's data: if students are minors, keep forms minimal, write plain-language consent text, and have the client confirm local privacy requirements with a qualified professional.

My rough bands, for reference: a solo inquiry-only site sits around $1,500 to $3,000, solo with booking and payment around $2,500 to $5,000, and a small center around $5,000 to $12,000. These are general ranges, not quotes.

The pattern I see most: clients overspend by building features for the business they hope to have in two years. Launch lean, watch what families actually ask for, and add from there.

I put the full cost breakdown, including ongoing fees and three example budgets, on my blog: https://amanurrahman.com/blog-post/tutoring-business-website-cost

AmazingPlugins

Wed, 14 Oct 2026 10:51:32 +0000

Every WooCommerce store owner knows the feeling. An order gets stuck in processing, a customer emails to say the checkout button does nothing with a screen reader, or a price change across two hundred products eats a whole afternoon. These are not exotic problems. They are the everyday friction of running a real shop, and they quietly cost sales.

The usual answer is a heavy premium plugin, a monthly subscription, or a script that sits on top of your theme and pretends to fix things. There is a better way: small, focused, free tools that solve one problem properly.

Accessibility is a good example. Many "accessibility" products add an overlay widget that changes how the page looks without touching the underlying code. Assistive technology still meets the same broken markup. A real fix means correcting the HTML itself: proper labels on form fields, meaningful button names, sensible heading order, and focus that lands where a keyboard user expects. Accessibility Fixer from AmazingPlugins does exactly that inside WooCommerce, so the improvement is in the page, not painted over it.

Order problems deserve the same treatment. Orders that never leave pending, statuses that drift out of sync with payments, and stock that does not match reality all create support tickets. Order Fixer looks for these common breakages and helps you put them right without exporting spreadsheets or editing the database by hand.

Bulk editing is next. Smart Bulk Editor, coming soon, is built to let you change prices, stock and attributes across many products quickly and safely.

The idea behind all of this is simple. A store owner should be able to install a free tool, see the problem fixed, and move on with the day. No bait and switch, no surprise paywall halfway through a task. If your WooCommerce shop has any of these headaches, take a look at the free plugins at https://amazingplugins.com and pick the one that matches your problem.

Heatmap Empty After Installing a Cache Plugin? 3 Checks in 60 Seconds

Tue, 13 Oct 2026 22:27:08 +0000

Your heatmap is empty, the session counter says zero, and nothing errors. On WordPress, the usual cause is not the analytics tool. It is the cache or performance plugin: it merges, defers or delays JavaScript, and the tracker stops running without a single warning. This applies to every tool in the category (Hotjar, Microsoft Clarity, Matomo, Opti-Behavior or your own beacon).

Open your site in a private window, logged out, and run these three checks in order.

1. Is the script in the HTML?
View source (Ctrl+U, not the Elements tab) and search for your tracker's file name.

Not there: the script was never added. Check the plugin is active and that you are not excluded as a logged-in admin.
src points to something like /wp-content/cache/min/...: the tracker was merged into a bundle.
type is not text/javascript (for example rocketlazyloadscript): the script is delayed until the first interaction.

2. Does the request leave the browser?
DevTools > Network > Fetch/XHR, then click and scroll for ten seconds.

No request: the tracker never started.
4xx: often an expired nonce on a page served from cache for too long.
200: tracking works; look at filters or admin exclusion instead.

3. Is the config object defined?
In the console, type your tracker's global config name. undefined while the file is present means the small inline config block was optimised away. Excluding the file is only half the job: the inline block needs its own exclusion rule.

The full guide has the exclusion code for WP Rocket, LiteSpeed Cache, SiteGround Optimizer, Autoptimize, Perfmatters, WP-Optimize, W3 Total Cache, Breeze and Jetpack Boost, plus a clean way to verify the fix:
https://optiuser.com/blog/heatmap-not-working-cache-plugin/?utm_source=coderlegion&utm_campaign=traffic-oct26

Disclosure: written by The Opti-Behavior Team, the publisher of the Opti-Behavior plugin, with the help of AI tools, and reviewed by the team.

What Are Rage Clicks and Dead Clicks? 7 Causes and How to Fix Them

Tue, 13 Oct 2026 15:05:42 +0000

A rage click is when a visitor clicks the same spot several times in a very short time, usually 3 or more clicks within about one second. Rage clicking almost always means the visitor expected something to happen, and it did not. Think of an elevator button you press again and again: that is exactly what rage clicks are, but on a website.

A dead click is the quiet version: a single click on something that looks clickable and does nothing.

Rage clicks are one of the clearest signs of a frustrated visitor. And frustrated visitors do not buy, sign up or come back. The good news: rage clicks are easy to find and often easy to fix.

Simple definition: A rage click is 3 or more quick clicks on the same small area, usually within about one second. A dead click is a single click that does nothing at all. In Opti-Behavior, rage, dead and error click detection is a Pro feature; the free plugin gives you click heatmaps, where dead clicks show up as hot spots on things that are not links.

Rage clicks vs dead clicks vs error clicks

These three often come together. Here is the difference.

Type	What happens	What the visitor feels
Rage click	Many fast clicks on the same spot	"Why is this not working?!"
Dead click	One click, nothing changes on the page	"Hmm, I thought that was a button."
Error click	A click that triggers a JavaScript error	Often nothing visible, the feature is broken

A dead click can turn into a rage click. The visitor clicks once, nothing happens, so they click again, harder.

What causes rage clicks?

Here are the most common causes we see on WordPress sites.

Things that look clickable but are not. A product image, an icon, bold blue text, a card. People expect a link.
Slow buttons. The button works, but it takes two seconds to react. The visitor clicks again because they think it failed.
Broken JavaScript. A plugin conflict or an error stops a menu, a slider or an "Add to cart" button from working.
Tiny tap targets on mobile. The link is too small, so the finger misses it again and again.
Form buttons that do not give feedback. The visitor presses "Send", nothing shows, so they press again.
Pop-ups that will not close. The close button is too small or covered.
Disabled buttons with no explanation. The button is grey because a field is missing, but nothing tells the visitor.

How to find rage clicks on your WordPress site

Option 1: Watch recordings (slow)

You can open session recordings one by one and look for fast clicks. It works, but it takes hours on a busy site.

Option 2: Let a tool flag them (fast)

Opti-Behavior Pro detects friction events on its own. It flags rage clicks, dead clicks and error clicks, groups them by page and element, and links each one to the recording where it happened.

Each line is one element where visitors got stuck, with the number of events.

Open an event to see the page, the element and the recording.

This turns hours of watching into a short to-do list, for example: "The ‘Size guide’ link on product pages gets the most rage clicks." Now you know exactly what to fix. See friction events in the docs.

Option 3: Check your click heatmap

A click heatmap shows hot spots on things that are not links. That is where dead clicks live. It is included in the free version of Opti-Behavior. Our guide on how to add a heatmap to WordPress shows the setup.

Hot spots on images or plain text often mean dead clicks.

Dead clicks: the quiet cousin of rage clicks

A rage click is loud. Someone hits the same spot five times in a second. A dead click is quiet. Someone clicks once on something that looks clickable, nothing happens, and they just leave. No drama, no noise. That is why dead clicks are easy to miss, and why they often cost more.

Here is a typical example. Imagine a shop with a "Size guide" line under the price, in blue and underlined. It looks exactly like a link, but it is plain text. Visitors click it and nothing opens. Some of them never add to cart, because they are not sure which size to pick.

The three kinds of friction clicks

Type	What happened
Rage click	Several fast clicks on the same spot
Dead click	A click on something that looks clickable and does nothing
Error click	A click followed by a JavaScript error

Why a click can be "dead"

When Opti-Behavior Pro records a dead click, it also saves the details: the element that was clicked, whether it was really interactive, whether something was covering it, what happened after the click, and the screen size, browser and device. The button View element on page highlights the element on your live page, so you see exactly what visitors saw.

Most dead clicks come from one of these three causes:

Covered by an overlay. A pop-up, a cookie banner or a sticky bar sits on top of the button. The visitor sees the button but clicks the invisible layer above it. This is very common on mobile.
Not interactive. The element looks like a link or a button (blue, underlined, an arrow, a card with a shadow) but it is just text or an image.
A script problem. The button should work, but its JavaScript failed to load or crashed.

The verdict tells you who should fix it

In Opti-Behavior Pro, each group of friction events gets a verdict, so you know if it is a design job or a developer job:

Verdict	What it means	Who fixes it
Probable code bug	Clicks on this element triggered a captured error	Developer
Needs review	Could be a bug or the network (ad blockers, offline)	Check a few recordings first
Visitor behavior	Normal behavior, like impatient clicking	Usually nobody, or a small design tweak

With Pro, Smart Insights measures rage clicks per 100 visits, so a busy page does not flood you with cards. You see the elements that frustrate a real share of visitors, not every single double-click.

How to fix dead clicks

Covered by overlay: move or shrink the pop-up, cookie banner or sticky bar, or delay it until the visitor scrolls.
Not interactive: make it a real link, or change its look so it does not pretend to be one. No blue underline on plain text.
Probable code bug: open the linked JavaScript error and fix or replace the script that breaks.

After the fix, check the same element two weeks later. Dead clicks on it should drop close to zero.

How to fix rage clicks

Fix the cause, not the symptom. Here is a simple guide.

Cause	Fix
Image or icon looks clickable	Make it a link, or change the style so it does not look clickable
Button is slow	Show a loading state right away ("Adding…") so people know it worked
JavaScript error	Check the error log, update or replace the plugin that breaks
Tiny mobile link	Make tap targets at least 44 by 44 pixels
Form button gives no feedback	Show a message or spinner right after the click
Pop-up close button hard to hit	Make it bigger and let people close it by tapping outside
Disabled button	Tell people what is missing, next to the button

Measure before and after

Before you fix anything, look at the verdict. Opti-Behavior Pro tells you if the clicks look like a design problem (people click something that is not a button) or a code bug (the clicks trigger an error).

Here the clicks triggered a captured JavaScript error, so the verdict is "probable code bug".

After a fix, compare the number of rage clicks on that element for the next two weeks. If it drops, you fixed it. If you want to be sure the change also helped sales or sign-ups, run an A/B test. Opti-Behavior’s A/B testing is free.

Are rage clicks always bad?

Almost always, but not every time. Some people double-click out of habit. A game or a quiz may need fast clicks. That is why good tools look for a pattern: many visitors, same element, again and again. One person with a fast finger is not a problem. Fifty people on the same button is.

Slow buttons and rage clicks often go together. If your page reacts slowly to taps, read our guide to Core Web Vitals on WordPress, especially the part about INP.

Find the rage clicks on your site

Start free with click heatmaps and funnels. Rage click and dead click detection with recordings is in Pro: see the pricing page for the free trial and plans.

Download free on WordPress.org Open the live demo

Rage clicks FAQ

What are rage clicks?

Rage clicks are several fast clicks on the same spot, usually within about one second. They show that a visitor expected something to happen and it did not.

What is the difference between rage clicks and dead clicks?

A dead click is one click that does nothing. A rage click is many fast clicks in the same place. A dead click often becomes a rage click when the visitor tries again.

How do I track rage clicks in WordPress?

Use a behavior analytics plugin that detects friction events. Opti-Behavior Pro flags rage clicks, dead clicks and error clicks and links each one to a session recording. Cloud tools such as Microsoft Clarity also flag rage clicks; see our Microsoft Clarity alternatives guide for the differences.

Do rage clicks hurt conversions?

They can. A rage click means a visitor tried to do something and could not, so it often marks a step where people give up. Fix the elements with the most rage clicks first, then check the effect with an A/B test.

This article was drafted with the help of AI tools and reviewed by The Opti-Behavior Team.

Why I Debug WooCommerce Variations in a Fixed Order

Mon, 12 Oct 2026 14:56:49 +0000

When a store owner messages me "my product options disappeared," the first thing I do is resist the urge to start changing things. Missing variation dropdowns look dramatic, but the cause is usually small. What matters is the order you check in, because each step either fixes the problem or removes a whole category of causes.

I think about it in three layers.

Layer one is data. Is the product actually a variable product? Are the attributes marked for variations and saved? Does every variation have a price, an enabled checkbox and a sensible stock status? WooCommerce quietly hides a variation that has no price, which catches people more than anything else. This layer takes five minutes and solves a surprising share of cases.

Layer two is the environment around the product. Does the theme override the add-to-cart template, and is that override out of date? Did a plugin or a page builder template change what prints on the product page? A custom single-product template without the Add to Cart element will show a product with no options at all. I test with a default theme on staging to see which side the problem lives on.

Layer three is delivery. The dropdowns are JavaScript, so anything that delays, combines or caches scripts can break them. I check the browser console first, then purge every cache, then pause optimization settings. If that fixes it, I turn optimization back on with exclusions instead of leaving it off.

Two smaller things are worth knowing. Products with more than 30 variations are handled differently by default, and a filter lets you raise that limit when you really need to. And if nothing makes sense, turning on debug logging to a file often points straight at the cause.

I try not to touch live data before taking a backup, and I try to change one thing at a time. When a store is losing sales, it is tempting to try five things at once, but then you never learn which one worked.

I put the full checklist, with exact settings and snippets, here: https://amanurrahman.com/blog-post/woocommerce-variable-products-not-showing-fix

Do you have a fixed order you follow when you debug a store problem?

Scoping a Website for a Cleaning Business: What I Ask Before I Quote

Mon, 12 Oct 2026 07:18:42 +0000

I build WordPress sites for local service businesses, and cleaning companies are one of the most common requests. They also tend to ask for a price before they know what they need. Over time I have settled on a handful of questions that turn a vague request into a clear scope. If you freelance, you can reuse them. If you run a cleaning company, they show what a good developer should ask you.

Who are the customers?

Residential and commercial buyers behave differently. A homeowner searches on a phone and decides in minutes, so the site needs a fast quote form and a call button. A facilities manager compares several firms and wants proof: the kinds of buildings you clean, your process, references. If the business serves both, I plan separate entry points from the home page so each group sees language that fits.

How do they want to get quotes?

There are three levels. A request-a-quote form is the cheapest and works for most. An instant calculator needs a pricing formula the owner trusts. Full online booking with payment is the most work because it connects to scheduling and payment tools. I usually suggest starting with the form and adding the rest once the business has data on what customers actually ask for.

Where do they work?

This decides how many service-area pages to plan. I would rather build five strong area pages with real neighborhood details than twenty copies of one page with the city name swapped. Thin duplicate pages do not help local search.

What content and photos exist?

Real before-and-after photos beat stock images, and clients often underestimate how long it takes to gather them. If the owner cannot supply copy, writing becomes part of the budget.

What happens after launch?

I always ask who handles hosting, updates and backups. A site that nobody maintains slows down and becomes easier to break. This also matters when comparing quotes, because a cheap build price can hide ongoing costs.

With those answers, the quote usually lands in one of three ranges: a basic build for a solo operator, a mid-size build with service-area pages and booking for a growing residential company, or a more content-heavy build for commercial and janitorial firms. I wrote the full cost breakdown, sample budgets and a hiring checklist here: https://amanurrahman.com/blog-post/cleaning-company-website-cost

If you scope sites for local trades, what is the first question you ask a new client?

Scoping a daycare website as a developer: what to pin down before you quote

Sat, 10 Oct 2026 07:15:31 +0000

Daycare and preschool inquiries look uniform and aren't. "We need a website for our center" can mean a five-page brochure or an admissions funnel with tour booking, a waitlist and secure forms. Here are the questions I settle before I price anything.

Where does the child data go?

Contact details from a parent are one thing. A form that asks about a child's age, health notes or pickup arrangements is another. I avoid generic contact form plugins that email submissions in plain text for anything beyond the first inquiry. Keep the website form short, and send detailed enrollment into a system built to store it. Ask the client what they already use for enrollment and billing before you design a custom flow.

What is the booking model?

Tour booking is usually the most valuable feature. The decision is between a hosted scheduler (monthly fee, quick) and a booking build inside WordPress (more setup, tighter control). Scope notification emails, time zones, rescheduling and what happens when a slot is full as separate items. Clients tend to assume it is one checkbox.

Is there already a parent app?

Most centers have one for attendance and daily updates. Link to it. Building a custom parent portal for a single location rarely pays off and can double the project.

Photos and permissions

Ask for the center's photo policy before anyone schedules photography. Many centers avoid identifiable faces and show rooms, materials and activities. It also keeps your content plan simpler.

Who owns care after launch?

Write down who handles updates, backups and edits. Tuition and enrollment dates change often, so a site with no maintenance owner goes stale quickly.

How I structure the quote

Build (theme, pages, mobile checks, speed)
Booking and forms, itemized
Copy and photos, supplied or priced separately
Search basics (titles, descriptions, headings)
Ongoing care, optional but clearly priced

For planning, I see roughly a few hundred dollars for DIY builder sites up to around $5,000 to $6,000 for a custom single-center WordPress site, with multi-location groups higher. These are general ranges and scope moves them more than anything else.

I wrote the non-developer version, with budgets by center size and a quote checklist, here: https://amanurrahman.com/blog-post/daycare-website-cost

Which part of a childcare site do you find clients underestimate most?

Scoping a therapist's website as a developer: the three decisions that set the budget

Fri, 09 Oct 2026 16:42:58 +0000

When a therapist or counselor asks for a website quote, the visible work (a clean theme, five to eight pages) is the easy part. Three decisions underneath decide whether the project stays on budget.

What happens to the form data?

A contact form that only collects a name and email is low risk. A form that asks what someone is struggling with is a different animal. Before choosing a plugin, ask where submissions are stored, who can read them, and whether they travel by plain email. For anything sensitive, I prefer a purpose-built intake or practice management form on a plan that offers a business associate agreement, rather than a generic form plugin mailing details to an inbox. It adds setup cost, and it is much cheaper than rebuilding later.

Which booking tool, and what does it connect to?

Every scheduling or telehealth link is another vendor in the privacy chain. Clarify with the client which tool they already use, whether their plan covers what they need, and how the booking widget will look on mobile. If you build booking inside WordPress, scope the licensing, email notifications and calendar sync as separate line items. Clients often assume it is one checkbox.

Who owns hosting, updates and backups after launch?

This is where small projects quietly go wrong. Decide in writing whether you manage updates and backups, whether the client does, or whether a maintenance plan covers it. A practice site that stops getting updates is exactly the kind of thing that ends in an awkward email at 7 a.m.

How I structure the quote

Build (theme, pages, mobile checks)
Forms and booking setup, itemized
Copy and photos, either supplied by the client or priced separately
Search basics (titles, descriptions, headings, speed)
Ongoing care, optional but clearly priced

A note on wording: I avoid promising "compliance" in proposals. I describe what I build and which vendors handle which data, and I tell clients to confirm requirements with their board or an adviser. I am a developer, not their lawyer.

Typical ranges I see for planning: a few hundred dollars for DIY builder sites up to roughly $5,000 for a custom solo-practice site, with group practices and clinics going higher. These are general figures, not a price list, and scope moves them more than anything else.

I put the non-technical version, with the full budget table and a quote checklist for clinicians, in a guide here: https://amanurrahman.com/blog-post/therapist-website-cost

If you scope sites for health practitioners, what is the one line item clients most often forget?

WordPress Speculation and Prerender Plugins vs Core Web Vitals

Fri, 09 Oct 2026 06:56:48 +0000

WordPress speculative loading started as a Performance Team feature plugin and landed in WordPress 6.8 as Core behaviour for most public front ends. The browser still does the work through the Speculation Rules API: JSON rules tell Chromium-class browsers which URLs to prefetch or prerender before the click finishes. Agencies then face a practical choice. Keep Core’s conservative prefetch, install (or leave) the Speculative Loading plugin with stronger prerender defaults, or layer a third-party wordpress prefetch / prerender plugin on top of both.

That choice is not “faster equals always better.” Speculative loading can make the next navigation feel instant and can improve Interaction to Next Paint (INP) on the path the user actually takes. It can also pull HTML, scripts, and third-party tags for pages nobody visits, inflate bandwidth on mobile, and confuse first-visit Largest Contentful Paint (LCP) or Cumulative Layout Shift (CLS) when teams measure the wrong navigation. What follows is a WordPress-centric how-to for retainers: when speculation rules help Core Web Vitals, when a wordpress prerender plugin hurts, and how to verify with lab schedules instead of a single homepage paste.

For broader WordPress monitoring context, see WordPress Performance Monitoring: A Complete Guide. When the site is still slow after delivery tweaks, keep Why Your WordPress Site Is Slow (It Is Not Always Hosting) in the runbook: speculation will not fix plugin asset storms on the current URL.

What WordPress speculative loading is (prefetch vs prerender)

Speculation rules are progressive enhancement. Unsupported browsers ignore the script. Supported Chromium browsers (Chrome, Edge, Opera at current versions) may act on the rules subject to memory, Data Saver, and other heuristics. Treat every rule as a hint, not a preload contract.

Two modes matter on WordPress sites:

Mode	What the browser roughly does	Typical CWV upside	Main risk
Prefetch	Fetches the document (and often related resources) early	Shorter wait before paint on the next navigation	Extra bytes if the user never clicks
Prerender	Loads the page in a hidden background state, ready to activate	Near-instant next navigation; load CLS can finish before activation; INP can look better because work finished early	Runs client JS earlier; analytics and personalisation bugs; higher CPU/memory; more wasted work on wrong guesses

Chrome’s documentation is explicit: prerender can drive near-zero LCP and reduce CLS for the activated view when load shifts happen before the user sees the page, and it can improve INP because interaction lands on a warmer page. The same docs warn against over-prerendering because of memory and network cost. WordPress Core and the Speculative Loading plugin are different opinions about how aggressive that trade-off should be by default.

Older wordpress prefetch plugins (Flying Pages-style link hover prefetch, theme “instant page” scripts, some cache-plugin toggles) sit adjacent to this story. Some now emit Speculation Rules; others still use older link-rel or mouseover fetch patterns. For agency audits, treat “prefetch on hover” and “Speculation Rules prerender” as different levers with different failure modes.

Core 6.8 defaults vs the Speculative Loading plugin

WordPress 6.8 enables speculative loading on the front end by default when the visitor is logged out and the site uses pretty permalinks. The effective Core starting point is prefetch with conservative eagerness: speculation starts around the beginning of a click. That is intentionally close to configurations large CDNs have used at scale. It buys a short head start with a low rate of unused fetches.

Core disables the feature for logged-in users and when pretty permalinks are off, because query-string “action URLs” (cart adds, favourites, state changes via GET) are common in the plugin ecosystem and must not be guessed into. URLs with query parameters are excluded by default. Filters such as wp_speculation_rules_configuration and wp_speculation_rules_href_exclude_paths let engineers raise eagerness, switch to prerender, or exclude path patterns such as /cart/*.

The Speculative Loading plugin remains useful after the Core merge. Its defaults are more aggressive: prerender with moderate eagerness (typically on link interaction), plus a Settings → Reading UI for mode and eagerness. The plugin also documents opt-ins for authenticated front-end users when the host can absorb the load (object cache strongly recommended). On WordPress 6.8+, the plugin builds on Core’s API rather than replacing the whole idea; agencies should know which layer owns the live configuration before they “install one more speed plugin.”

HTTP Archive and CrUX analysis cited in the Core note reported roughly a 1.9% median lift in LCP passing rate for sites that enabled speculative loading via the feature plugin over the study window. That is a population signal, not a promise that every client homepage will drop 200 ms in lab LCP after you flip prerender to moderate.

Speculation pays off when users move through predictable internal links: article → related post, category → product, docs hub → guide. The win shows up on the destination navigation, not on the cold first entry from search or ads. Agencies selling “instant site” from a single PageSpeed Insights homepage score are measuring the wrong clock.

Helpful patterns we see in practice:

Core prefetch / conservative on content sites with clean pretty permalinks and few GET action URLs.
Plugin or filter prerender / moderate on a small set of high-confidence destinations (primary nav, top product cards) after cart and account paths are excluded.
Chromium-heavy audiences (many B2B and ecommerce dashboards) where progressive enhancement still covers Safari/Firefox users without harm.

INP can improve on the activated page because main-thread work and hydration had a head start. Next-page LCP can look excellent when the LCP image and text were already in the prerender. Neither outcome excuses a heavy first HTML response or third-party tags on the URL the user opened first. Speculation multiplies whatever that destination loads; it does not delete unused JavaScript.

When a WordPress prerender plugin hurts first-visit LCP, CLS, or bandwidth

Problems show up when teams install a wordpress prerender plugin (or raise Core to prerender/eager) and then judge success only from a warmed multi-page lab session, or when unused prerenders compete with the current page for CPU and network on mid-range mobiles.

Common failure modes:

First visit from search or paid landings stays untouched. Speculation does not prerender the entry URL from Google. If mobile LCP is poor on that landing template, fix the LCP resource and server path first.
Eager or broad prerender on mega-menus. Hovering a header with forty links can queue many documents. Bandwidth and main-thread cost rise; field INP on the current page can worsen while “next page” demos look great in the office.
Cart, checkout, account, and nonce URLs. Prefetching a GET add-to-cart or wishlist URL can change state without a full navigation. Core excludes many query-string URLs; custom rewrite “action URLs” still need wp_speculation_rules_href_exclude_paths (or the plugin’s plsr_speculation_rules_href_exclude_paths) and no-prefetch / no-prerender classes on blocks.
Analytics and personalisation. Prerender runs page JS early. Providers that do not wait for activation can double-count or set cookies too soon. Chrome documents delaying analytics until activation; many major tags already do this, but custom theme JS often does not.
CLS “improvements” that hide layout debt. Load CLS that finishes during prerender may not appear at activation, which is good for users and scores, but it can mask unreserved embeds that still break when prerender is cancelled or unsupported. Keep fixing reserved space.
Stacked plugins. Core + Speculative Loading + Flying Pages + a cache plugin’s “preload links” toggle can emit overlapping hints. Pick one speculation owner per site.

If lab LCP on the entry URL got worse after enabling prerender, check whether the test device is fighting background prerenders while measuring the current document. If field LCP improved only on internal navigations, say so in the client report; do not imply organic landing LCP moved the same way. Separating those clocks is what keeps the retainer honest when a plugin changelog promises “instant LCP.”

Safe settings for agency WordPress retainers

Use a staged default rather than a global “enable prerender” checkbox on every brochure site.

Site type	Starting point	Escalate only when
Marketing / blog, pretty permalinks	Core prefetch / conservative (6.8 default)	Internal nav is the KPI and Chromium share is high
WooCommerce / membership	Core default + exclude `/cart/*`, checkout, account, wishlist paths	Host capacity proven; action URLs audited
High-traffic content with clear next clicks	Speculative Loading plugin or Core filter to prerender / moderate on selected patterns	Analytics and tag managers verified under prerender
Logged-in app-like front end	Leave disabled until object cache and exclusions exist	Product owners accept extra authenticated load

Agency checklist before go-live:

Confirm WordPress version and whether Core already injects speculation rules (View Source for a speculationrules script type).
Inventory other prefetch/prerender plugins and cache-plugin toggles so one owner remains.
Exclude cart, checkout, logout, nonce, and any GET action paths.
Decide logged-in behaviour explicitly (usually off).
Document mode and eagerness in the retainer runbook so the next plugin cleanup does not reset them.

Theme and page-builder “instant load” marketing copy is not a configuration record. Write the actual mode (prefetch vs prerender) and eagerness (conservative / moderate / eager) into the handoff. The next engineer should not have to reverse-engineer View Source to learn what you enabled.

How to verify with lab schedules and field data

Measure two journeys separately.

Entry URL (first visit): PageSpeed Insights or scheduled Lighthouse on the money landing template with a cold load. Speculation should not be the primary fix here. Watch LCP resource, TTFB, and third-party blocking.

Internal navigation: From a listing or article, follow a primary link in Chrome with Speculation Rules debugging enabled (Chrome documents debugging flows for prerender). Compare activation feel and performance panel timings with rules on versus off. For portfolio retainers, keep scheduled lab history on both the entry URL and one representative destination URL so a plugin change cannot hide behind a single score.

Field data (CrUX via PageSpeed Insights or Search Console) mixes navigations. A rise in origin LCP after enabling prerender may reflect faster subsequent views, a changing Chrome population, or unrelated template work. Annotate the speculation change in your monitoring notes the same week you ship it. WordPress Performance Monitoring: A Complete Guide covers ongoing schedules; use those schedules so “we turned on prerender” is a dated event next to the charts.

Apogee Watcher fits the verification loop for agencies: multi-site lab schedules on entry and destination URLs, budgets when LCP regresses after a plugin change, and history account managers can open without re-running a laptop test. Speculation remains a WordPress and browser feature; monitoring tells you whether the retainer got faster for the journeys you sell. Without that history, every prerender debate restarts from a single screenshot.

FAQ

What are WordPress speculation rules?

They are Speculation Rules API instructions WordPress prints so compatible browsers can prefetch or prerender likely next URLs. WordPress 6.8 includes a conservative prefetch default for logged-out users on pretty-permalink sites.

Is the Speculative Loading plugin still needed on WordPress 6.8?

Often yes if you want prerender, moderate eagerness, or a wp-admin UI. Core’s default is safer and milder. The plugin (or Core filters) is the escalation path, not a required install on every site.

Will a wordpress prerender plugin fix homepage LCP from Google?

Usually not by itself. Speculation targets subsequent navigations. Fix the landing template’s LCP resource, CSS, and server response for entry traffic first.

Can speculative loading break WooCommerce?

It can if add-to-cart or other GET action URLs are guessed. Cart, checkout, and account paths belong on the exclude list, and Core’s conservative defaults are the safer starting point until those exclusions are proven. POST-based cart flows remain the healthier pattern regardless of speculation.

Does wordpress prefetch help Safari and Firefox?

Those browsers ignore Speculation Rules today. Users still get a normal navigation; they simply miss the head start. Do not promise cross-browser instant navigation.

How do we know it helped Core Web Vitals?

Compare scheduled lab tests on entry versus destination URLs before and after the change, and annotate field dashboards with the ship date. Destination LCP or INP gains matter only when entry-URL scores and bandwidth stay within the budgets you already sold.

If a client’s WordPress stack already ships Core 6.8, start by documenting the live speculation configuration before installing another prerender plugin. Keep lab schedules on the URLs you sell in the retainer, and treat speculation as a navigation optimisation with explicit exclusions. Start a free Apogee Watcher trial when you want those WordPress URLs monitored across clients without pasting PageSpeed Insights by hand after every plugin toggle.

References

Speculative Loading in 6.8 (Make WordPress Core)
Speculative Loading (WordPress plugin) (WordPress Performance Team)
Prerender pages in Chrome for instant page navigations (Chrome for Developers)
Implementing speculation rules (Chrome for Developers)
Speculation Rules API (MDN)
WordPress Performance Monitoring: A Complete Guide
Why Your WordPress Site Is Slow (It Is Not Always Hosting)

Originally published on Apogee Watcher.

How to Migrate WordPress to a Static Site Builder (Step-by-Step)

Thu, 08 Oct 2026 23:46:07 +0000

Moving a WordPress website to a static site builder can reduce dependence on traditional WordPress hosting, plugins, themes, and server-side maintenance. It can also provide a simpler visual workflow for building and maintaining pages.

But migrating a WordPress website is not the same as copying files from one server to another. WordPress stores content in a database and relies on themes, plugins, media files, and other components to produce the finished website. A visual site builder uses a different content and design system, so a successful migration requires planning, content export, rebuilding, testing, and careful handling of URLs.

Platforms such as Webflow and Framer provide current migration workflows for WordPress sites. Webflow's official documentation describes the process as a rebuild rather than an automated transfer, while Framer provides a dedicated WordPress migration guide covering content, media, plugins, SEO, and CMS collections.

Here is a practical step-by-step process for moving a WordPress website to a static-oriented site builder.

Audit the Existing WordPress Website
Do not start rebuilding the website immediately.

First, create an inventory of what currently exists.

Review your WordPress pages, posts, categories, tags, custom post types, media files, forms, integrations, plugins, and important URLs. The purpose is to determine what actually needs to move and what can be removed.

WordPress's export system can include posts, pages, custom post types, comments, custom fields, categories, tags, custom taxonomies, and users in its XML export.

Your audit should answer several basic questions:

Which pages are essential?
Which blog posts need to be migrated?
Which URLs receive significant traffic?
Which images and downloadable files are still required?
Which WordPress plugins provide functions that must be replaced?
Which content belongs in a CMS collection?
Which pages can become ordinary static pages?
Are there outdated posts or pages that should be removed instead of migrated?
Does the existing site use custom post types?
Are there forms, newsletters, search functions, memberships, or ecommerce features that require replacement?
Framer's current WordPress migration documentation similarly recommends cataloging pages, posts, custom post types, media, and plugins before migration.

This audit prevents a common migration mistake: rebuilding every part of an old website without questioning whether those parts are still necessary.

Choose the Destination Builder
The next decision is where the rebuilt website will live.

Webflow and Framer are two examples of visual platforms with current WordPress migration documentation.

Webflow provides a CMS that uses Collections to manage structured dynamic content. It supports CSV import for CMS Collection items, which makes structured content migration possible after converting WordPress's XML export into a compatible CSV file.

Framer also provides a CMS and documents several approaches for moving WordPress content, including CSV-based migration for larger amounts of structured content. Its documentation specifically describes mapping WordPress custom post types and ACF-managed content to CMS collections.

The correct platform depends on the website rather than the migration tool alone.

A simple marketing website with a few pages may require very little CMS structure. A publication with hundreds or thousands of articles requires a more deliberate content architecture.

Before committing to the destination, check its current CMS limits, import capabilities, hosting requirements, forms, integrations, SEO controls, and domain configuration.

Back Up the WordPress Website
Create a complete backup before making major migration changes.

WordPress recommends maintaining backups of both the database and the site's files. The database contains content such as posts, comments, and links, while the site's files contain WordPress core files, plugins, themes, images, and other website assets.

Do not treat the WordPress XML export as a complete website backup.

The WordPress export file is useful for moving content, but the official WP-CLI documentation notes that WXR exports do not include site configuration or the attachment files themselves.

A proper backup gives you a recovery point if something goes wrong during the migration.

Keep the original WordPress website available until the new website has been completely tested and launched.

Export Your WordPress Content
WordPress provides a built-in export function under the administration area.

Go to:

WordPress Dashboard → Tools → Export

From there, select the content you want to export and download the generated XML file.

WordPress calls this format WordPress eXtended RSS, or WXR. The export can contain posts, pages, custom post types, comments, custom fields, categories, tags, custom taxonomies, and users, depending on the selected content.

For a migration, you may need separate exports or additional processing depending on the content structure and destination platform.

Do not assume that exporting XML automatically creates a finished version of your new website. The XML is a content source. The destination builder still needs to receive that content in a structure it can understand.

Webflow's current WordPress migration documentation specifically states that WordPress content is exported as XML and that the XML can be converted to CSV before importing it into Webflow.

Convert and Clean the Content
This is one of the most important stages of the migration.

A WordPress site may contain content that depends on WordPress-specific formatting, shortcodes, plugins, custom fields, or theme functionality.

Do not simply move the text and assume the formatting will remain identical.

Review the exported content for:

Shortcodes
Broken HTML
Unnecessary formatting
Old internal links
Missing images
Unused metadata
Outdated categories
Duplicate content
Plugin-specific elements
Embedded content that depends on WordPress
Custom fields that need new CMS fields
If you are migrating to Webflow, its current documentation recommends converting the WordPress XML export into CSV before importing the content into a CMS Collection. Webflow's CMS importer then allows fields from the CSV to be mapped to existing or newly created Collection fields.

Framer's migration documentation also identifies CSV import as a common approach for bulk WordPress content and recommends cleaning WordPress-specific formatting during the conversion process.

This stage is an opportunity to improve the content database rather than reproduce unnecessary legacy structures.

Rebuild the Content Structure
Once the content is clean, determine how it should be organized in the new platform.

A WordPress blog might have posts, authors, categories, tags, featured images, excerpts, and custom fields. Your new builder may organize these differently.

For example, a blog could use a CMS collection containing fields such as:

Title
Slug
Author
Publication date
Featured image
Excerpt
Main content
Category
Tags
SEO title
Meta description
The exact fields should match the requirements of the website.

Webflow describes a CMS Collection as a structured database for a particular type of content. Its CMS allows dynamic content to be managed from a shared structure rather than manually maintaining repeated information across pages.

This distinction matters because not every WordPress page should become a CMS item.

A homepage, contact page, about page, and pricing page may be better treated as individual static pages. Blog posts, case studies, team members, products, or testimonials may be better managed through collections.

Import the Content
After creating the destination CMS structure, import the prepared content.

In Webflow, the current workflow is to create a Collection, open its import function, upload the CSV, confirm the header row, map the columns to Collection fields, review the imported items, and complete the import. Webflow also provides error reporting when imported records fail.

Large migrations should be handled in controlled batches rather than treated as one giant operation.

Import a manageable group first.

Then check:

Titles
Slugs
Text formatting
Images
Categories
Dates
Author information
Internal links
Custom fields
If the first batch works correctly, continue with the remaining content.

This approach makes it easier to identify structural problems before they affect the entire migration.

Rebuild the Website Design
Content migration does not automatically reproduce the old WordPress theme.

The new website needs to be rebuilt using the destination platform's design system.

Start with the site's core structure:

Header
Navigation
Homepage
Main content templates
Blog or article template
Footer
Contact page
Other important landing pages
Then reproduce the visual elements that are actually required.

This is another reason to audit the WordPress website before beginning. A migration is a good time to remove obsolete design components instead of rebuilding them simply because they existed in the old theme.

Webflow explicitly describes WordPress migration as a rebuild in which page layouts, styles, CMS structures, and interactions are recreated in Webflow.

Framer's migration documentation similarly separates content migration from the work of rebuilding the site's design and functionality.

Replace WordPress Plugin Functionality
Plugins require special attention.

A WordPress plugin may provide forms, SEO functions, analytics integration, caching, redirects, ecommerce capabilities, social integrations, or other features.

Those functions do not automatically transfer to the new platform.

Create a plugin inventory and classify every plugin into one of three categories:

Replace: The function is still required but must be implemented through another service or native feature.

Rebuild: The function is important and must be recreated within the new platform.

Remove: The function is no longer necessary.

This prevents a common migration problem where the new website looks correct but loses important functionality.

For example, if a WordPress contact form was responsible for receiving customer inquiries, the new website must have another verified method for receiving those submissions before the old website is retired.

Preserve Your URL Structure
URL management is one of the most important parts of a migration.

WordPress describes permalinks as the permanent URLs used for posts, pages, categories, tags, and other archive pages.

Whenever practical, preserve existing URLs.

If a URL must change, create a permanent redirect from the old address to the correct new address.

For example:

Old URL:
example.com/blog/website-speed-guide/

New URL:
example.com/website-speed-guide/

The old URL should redirect to the new URL rather than simply returning an error.

Webflow's migration documentation specifically includes 301 redirects and SEO considerations as part of its WordPress migration process.

Framer's WordPress migration guidance also identifies URL mapping and permanent redirects as important parts of an SEO migration.

Create a spreadsheet containing the old URL, new URL, and redirect destination before launch. This gives you a clear record of every URL change.

Recreate SEO Metadata
Moving the visible content is not enough.

Review the SEO information associated with important pages and posts.

Check:

Page titles
Meta descriptions
Slugs
Heading structure
Canonical settings where applicable
Image alt text
Internal links
XML sitemap
Robots directives
Redirects
Do not automatically assume that the new platform will reproduce your WordPress SEO configuration.

Some SEO settings may have been controlled by a WordPress plugin rather than WordPress itself. Those settings must be recreated using the capabilities of the destination platform.

The goal is to make the new website understandable to both visitors and search engines while preserving important existing URLs.

Test the New Website Before Launch
Never switch the domain immediately after finishing the build.

Test the new site first.

Open important pages manually and inspect them on desktop and mobile devices.

Test:

Navigation
Buttons
Forms
Images
Videos
Internal links
External links
Search functionality
CMS templates
Contact processes
Redirects
Page titles
Meta descriptions
404 behavior
Downloadable files
Pay particular attention to migrated articles.

Open old high-value URLs and confirm that they either remain available at the same address or redirect correctly to the new location.

Also test pages that were imported in bulk. A migration can succeed technically while individual records still contain missing images, broken formatting, or incorrect links.

Webflow's current migration checklist recommends importing CMS content, designing pages and templates, and carrying out the migration in stages rather than treating content transfer as the entire process.

Connect the Domain and Launch
Once testing is complete, configure the new platform for the production domain.

The exact domain process varies between site builders, so follow the current documentation for the platform you selected.

Do not shut down the WordPress site before confirming that the new website is working on the production domain.

Once the new site is live, test the most important URLs again.

Check the homepage, major landing pages, high-traffic articles, contact forms, redirects, and other business-critical functions.

Keep the WordPress backup even after launch.

Monitor the Website After Migration
The migration is not finished simply because the new site is live.

Monitor the website after launch for broken links, missing pages, redirect problems, indexing issues, form failures, and missing assets.

Compare the new website against your original migration inventory.

If a page or feature was supposed to be transferred but cannot be found, investigate it immediately.

It is also useful to keep the old URL-to-new URL mapping available after launch. If visitors or search engines encounter an old URL, the mapping tells you where that URL should lead.

Common WordPress Migration Mistakes to Avoid
Several mistakes repeatedly create unnecessary problems during website migrations.

Migrating without a backup
A WordPress XML export is not a complete backup of the entire site. Keep a separate backup of the database and files.

Assuming the migration is automatic
Webflow explicitly states that moving a WordPress site to Webflow requires rebuilding the site.

Moving content without cleaning it
Shortcodes, obsolete formatting, broken links, and plugin-dependent elements can survive the export process and cause problems in the new system.

Ignoring URLs
Changing URLs without implementing appropriate redirects can create broken links and unnecessary SEO problems.

Forgetting plugin functionality
A WordPress plugin may perform a critical task that is not visible on the front end. Inventory your plugins before migration.

Launching without testing
A website that looks correct on the homepage can still contain broken forms, missing images, incorrect links, or failed redirects elsewhere.

Migrating WordPress to a static-oriented site builder is best treated as a website reconstruction project, not a simple file transfer.

The safest process is straightforward: audit the existing website, back up the WordPress installation, export the content, clean and restructure the data, import it into the new CMS, rebuild the design, replace essential plugin functionality, preserve URLs, configure redirects, reproduce important SEO information, test everything, and only then launch.

Webflow and Framer both provide current documentation specifically addressing WordPress migrations, but their workflows demonstrate an important point: the destination platform needs to be planned around the site's actual content and functionality.

A smaller WordPress site may require only a modest amount of rebuilding. A large content-driven website can require substantial preparation because every page, CMS record, image, URL, plugin function, and integration needs to be accounted for.

The objective should not be to reproduce every technical detail of the old WordPress installation. The objective is to preserve the content and functionality that matter, establish an appropriate structure in the new platform, protect existing URLs where possible, and launch a website that can be maintained without carrying unnecessary WordPress complexity into the new system.

Quovex Blocks: A Post Grid, Featured Posts and Announcement Bar Built on the Interactivity API

Thu, 08 Oct 2026 10:37:36 +0000

Most WordPress sites end up needing the same few things: a grid of recent posts, a featured section on the homepage, and a banner for announcements. The usual answer is a page builder or a stack of separate plugins, each bringing its own UI and its own frontend scripts.

Quovex Blocks is a free WordPress plugin that does all three as native Gutenberg blocks, with the frontend interactivity running on the WordPress Interactivity API instead of jQuery.

▶️ Watch the 2-minute demo: https://youtu.be/ADyo0WuhiR0

The three blocks

Query Grid

A filterable, paginated grid that works with any public post type: Posts, Pages, WooCommerce products or your own custom post types.

Grid, List, Masonry and Carousel layouts
Search bar and taxonomy filter pills (multi-select within a taxonomy), optionally in a left or right sidebar
Numbered pagination or a "Load more" button, plus a "Show all posts" toggle
Responsive column counts, plus color and typography controls that use your theme's fonts

Content Showcase

A magazine-style section for up to three posts.

Magazine, Split, Overlay and Two-Thirds/One-Third layouts
Automatic mode (latest posts, optionally filtered by taxonomy) or manual mode (hand-pick a post for each slot)
Image hotspots: pins you place on a post's image, each opening a popover with its own title, text and link

A dismissible announcement bar or inline alert.

Announcement, Info, Success and Warning presets, with five style variations
Emoji, dashicon or SVG icon picker, and an optional call-to-action button
Dismissal is remembered in the visitor's browser, so a closed banner stays hidden on their next visit

How it's built

Dynamic blocks + the Interactivity API

Query Grid and Content Showcase are dynamic blocks rendered in PHP through render.php, so the first paint is plain server-rendered HTML. Frontend behavior (search, filters, pagination, the carousel and hotspots) is attached with the Interactivity API through a viewScriptModule, so it ships as a script module and no jQuery or other framework is loaded.

Here's the relevant part of Query Grid's block.json:

{
  "apiVersion": 3,
  "name": "quovex-blocks/query-grid",
  "render": "file:./render.php",
  "viewScriptModule": "file:./view.js",
  "supports": {
    "interactivity": true
  }
}

Pagination that search engines can follow

Clicking a page number swaps in the new results without a full page reload, but the address bar updates to a real URL, and opening that URL directly server-renders the correct page. So visitors get instant navigation, and crawlers still get normal, followable links. The pagination URL segment is configurable (for example /your-site/quovex-page/2/) as a site-wide setting.

Layouts as style variations

Every layout is a native block style variation. Switching from Grid to Masonry, or from Magazine to Overlay, is one click in the editor's Styles panel, with no custom layout picker to learn.

A cache that invalidates itself

Query results are cached and cleared automatically the moment a post, category or tag changes, so repeat visits stay fast without serving stale content. Nothing is loaded on pages that don't use the blocks.

Clean uninstall

Deactivating leaves everything in place in case you come back. Deleting the plugin runs uninstall.php, which removes every option and cached value the plugin created.

Tooling

Built with @wordpress/scripts using --experimental-modules and --blocks-manifest
PHP classes autoloaded via PSR-4, with a built-in fallback loader so the shipped plugin needs no vendor/ folder
PHPUnit tests, PHPCS and ESLint, with Husky pre-commit hooks
GitHub Actions for CI, and a workflow that deploys new tags to WordPress.org

Try it

The plugin is free on WordPress.org. In your dashboard, go to Plugins → Add New and search for "Quovex Blocks".

Plugin: https://wordpress.org/plugins/quovex-blocks/
Source: https://github.com/akshat009/quovex-blocks

Feedback and issues are welcome on GitHub, and a review on WordPress.org helps other people find it.

I'm Akshat Saxena, a Senior WordPress Developer with 8+ years in WordPress, working across WooCommerce, Gutenberg/FSE and custom plugins. If you're looking for someone to build or extend a WordPress product, feel free to reach out on LinkedIn.

WordPress Login Loop After an SSL Change: How I Triage It

Mon, 05 Oct 2026 06:01:17 +0000

"I can type my password but WordPress just sends me back to the login page." I get this one a lot, and it nearly always shows up right after an SSL install, a www change, or a host move. Here is how I triage it.

Step 0: Backup. Most fixes touch wp-config.php, .htaccess, or the database.

Step 1: Rule out the browser.
Clear cookies for the site, try a private window, try another browser. The login is really about a cookie, so a bad cookie is a cheap first suspect.

Step 2: Compare siteurl and home.
If http vs https or www vs non-www differs between them, the cookie can fail. If I can't reach Settings, I force both with WP_HOME and WP_SITEURL in wp-config.php, then fix the real values and remove the override.

Step 3: Look at who is forcing HTTPS.
Host toggle, SSL plugin, .htaccess rule, Cloudflare. Two at once is a classic loop. Cloudflare Flexible SSL plus an origin redirect is the one I see most.

Step 4: Rename .htaccess.
If login works without it, I regenerate it from Permalinks and add custom rules back one by one.

Step 5: Rename the plugins folder.
No dashboard needed. If that fixes it, I bring plugins back one at a time.

Step 6: Cache and security.
wp-login.php and wp-admin should never be cached. I also check whether a 2FA or firewall plugin blocked my own IP.

Step 7: Make sure it's really a loop.
If the redirect goes to another website, or there are unknown admin users, it's a security incident, not a settings problem.

Full version with the exact snippets and a decision table for "fix it myself or call someone": https://amanurrahman.com/blog-post/wordpress-login-redirect-loop-fix

What's your usual first move when a client says they're locked out?

Why Your WooCommerce Coupon Fails: A Support-Ticket Triage Guide

Mon, 05 Oct 2026 05:35:49 +0000

Over the years, coupon complaints have been one of the most common WooCommerce support requests I handle. The surprise is how rarely it is a code bug. Here is how I triage one.

Step 1: Get the exact error text.
Ask the customer for a screenshot, or reproduce it yourself. "Coupon does not exist", "usage limit reached", and "not valid for sale items" are three different problems with three different fixes.

Step 2: Reproduce it as a guest.
Admin accounts can hide problems. Open a private window, add the same products, apply the code. If it works for you but not the customer, I look at allowed emails, per-user limits, and caching.

Step 3: Inspect the coupon.
Published? Expiry date still in the future? Usage count versus limit? One thing people miss is that stale pending orders can hold usage on a coupon with a low limit, so a code can seem to run out early.

Step 4: Check restrictions one by one.
Minimum and maximum spend, individual use only, excluded sale items, product and category lists, and allowed emails. Most "mystery" failures end here.

Step 5: Free shipping coupons get their own check.
The coupon needs "Allow free shipping" ticked, and the shipping zone needs a free shipping method that accepts a coupon. Missing either one leaves the coupon with nothing to do.

Step 6: Rule out the environment.
Is cart and checkout excluded from cache? Any red errors in the browser console when the code is applied? Are JS optimization settings delaying cart scripts?

Step 7: Conflict test on staging.
Default theme, WooCommerce only, then re-enable plugins one at a time. Discount and pricing plugins are the usual offenders.

A preventive habit that saves a lot of tickets: test every campaign coupon as a guest, with the exact products and cart total the campaign will drive, before the email goes out.

The full guide, with the error-message table and a 10-step checklist, is here: https://amanurrahman.com/blog-post/woocommerce-coupon-not-working-fix

How do you handle coupon support requests? Any gotchas I missed?

Pricing a Portfolio Site for an Interior Designer: A Freelancer's Checklist

Sun, 04 Oct 2026 17:23:55 +0000

When an interior designer asks for a website quote, the number depends on a handful of decisions that are easy to overlook in the first call. This is the checklist I run through before pricing one.

1) What does the site need to do?
Credibility only, lead generation, or selling design packages? A pure portfolio is the cheapest. Adding a store, deposits, or paid consultations changes the scope.

2) How many projects, and how deep?
Six strong projects with a short story each is a very different job from thirty projects with full case studies. Ask for the real number early.

3) Template or custom?
A refined template with the client's colors, fonts, and logo is the biggest cost saver. Custom layouts make sense when the brand itself is the selling point.

4) How will images be handled?
This is the line most clients do not think about. Photo-heavy sites need resizing, compression, and lazy loading, or they feel slow on phones. I count this as a real line item, not an afterthought.

5) Who writes the copy?
If the client writes it, the build is cheaper but the timeline stretches. If I coordinate it, it becomes its own line.

6) What happens after launch?
Hosting, backups, updates, and who owns the domain. I always put the domain and hosting in the client's name.

Rough ranges I use as a starting point:

DIY builder: $200–$700 a year
Template-based WordPress: $1,200–$3,000
Custom portfolio: $3,000–$7,000
Studio-level build: $8,000+

These are only starting points, not quotes. Page count and features move them up or down.

I wrote this up in full, including a line-item cost table, a builder-vs-WordPress comparison, and three sample budgets: https://amanurrahman.com/blog-post/interior-designer-website-cost

Curious how others here handle image performance in quotes. Do you price it separately or fold it into the build?

Building Delivery Rules Into a WooCommerce Flower Shop: What Drives the Cost

Wed, 30 Sep 2026 08:36:03 +0000

Flower shops look like an easy WooCommerce project until you list the rules. Most online stores sell items that ship in a few days. A florist sells a perishable product that has to arrive on a chosen date, so nearly every order carries conditions.

Here are the pieces that turn "a shop with a cart" into a real build, and roughly what each adds.

Delivery date and time slots
The customer must choose a day, and the shop must be able to block days it cannot serve and cap how many deliveries it takes per day. Without a cap, a busy date means orders the team cannot fulfil. Typical cost: $200 to $600.
Delivery zones and fees
Price and availability change by postcode or ZIP code. Checking coverage early in the flow stops customers from falling for an arrangement the shop cannot deliver. Typical cost: $250 to $700.
Same-day cut-off logic
"Order within two hours for same-day delivery" has to be enforced by the store, not just written on the page. Typical cost: $150 to $400.
Gift messages and recipient data
Card notes, recipient phone numbers, and delivery instructions need clean fields that carry through to emails and order screens. Typical cost: $100 to $300.
Subscriptions
Weekly or monthly flowers add recurring billing, skip and pause controls, and scheduling against delivery capacity. This is the most complex item, usually $800 to $2,500.

The part that gets underestimated: peak dates
A handful of dates bring a large share of a florist's year in a short window. A store that copes on a normal Tuesday can slow down or fail when orders arrive in bursts. What I recommend before those dates: run a full test order, check hosting capacity, set daily limits, and freeze plugin updates.

Rough totals I see for clients in the US, UK, and Canada: $2,000 to $6,000 for a WooCommerce florist build, against $100 to $500 per month for florist-specific platforms, some of which also take a share of each order.

If you are scoping a flower shop for a client, or budgeting for your own, I wrote a longer breakdown with a feature-by-feature price list and a checklist to use before asking for quotes:
https://amanurrahman.com/blog-post/florist-website-cost

For those who have built delivery scheduling in WooCommerce: do you use a plugin for date and zone rules, or custom code?

Why Image-Heavy Sites Cost More to Build: Lessons From Photography Portfolios

Wed, 30 Sep 2026 08:17:30 +0000

When a photographer asks for a quote, the first surprise is usually the price gap between quotes. The second is that most of the difference comes from work nobody sees: how the site handles images.

I build WordPress and WooCommerce sites for a living, and photography portfolios are one of the clearest examples of how "just a gallery" turns into real engineering.

Where the hours actually go

Image pipeline. A single gallery can hold hundreds of full-size files. Someone has to decide sizes, compression, modern formats, and lazy loading. Skip this and a homepage can pass 20 MB, which loses mobile visitors before the first photo shows.
Layout that survives real content. Grids and sliders look fine with demo images. Portrait, landscape, and panoramic shots in the same gallery break lazy layouts fast, so the CSS needs care.
Delivery and protection. Watermarking, disabling easy downloads, and private client galleries either add development time or a monthly service fee.
Transactions. The moment a photographer wants deposits, session booking, or a print store, it stops being a brochure and becomes an e-commerce project with payments, tax, and delivery rules.

What I tell clients about budgets

A builder is often cheaper for three years if the site is only a portfolio and an inquiry form.
WordPress makes sense when they want to own the site, sell prints or downloads, or build custom booking.
Rent client proofing from a dedicated service. Rebuilding it is rarely worth the cost.
Speed work on image-heavy sites is usually the highest-return line item.

Rough numbers I see for US, UK, and Canadian clients: builder at about $16 to $60 per month, WordPress with a template and a freelancer at $800 to $2,500, custom WordPress at $2,500 to $6,000, and agency builds from $6,000 up.

If you are scoping a photography site for a client, or budgeting for your own, I wrote a longer breakdown with a feature-by-feature price list and a checklist to send before asking for quotes:
https://amanurrahman.com/blog-post/photography-website-cost

Curious how others handle image optimization on client sites. Do you bake it into the build price or quote it separately?

Debugging WooCommerce Cart Update Failures — A Triage Order That Actually Works

Tue, 29 Sep 2026 09:38:37 +0000

When a client reports "the cart doesn't update," the instinct is often to dive into the theme's cart.php template first. That's usually the wrong place to start — in most real cases, the cause is upstream of any custom code.

Here's the triage order that finds the cause fastest, based on frequency:

1. Caching — check this first, always. If cart, checkout, or my-account pages aren't excluded from a page-caching plugin (WP Rocket, W3 Total Cache, LiteSpeed, or hosting-level caching), the "update" the shopper sees may just be a cached snapshot. This single misconfiguration accounts for the large majority of cart-update reports. Confirm the exclusion is actually active — some plugins auto-detect WooCommerce pages but the detection can silently fail after a theme or plugin update.

2. Browser console, second. WooCommerce's cart updates run through AJAX. Any JavaScript error on the page — most often a jQuery version mismatch between two plugins loading incompatible copies — can silently break the update handler. This is a 30-second check that rules out or confirms a whole category of causes.

3. Session/cookie behavior, especially post-CDN-migration. If a store recently added Cloudflare or another CDN, check whether cookies are being stripped for logged-out visitors, and whether object caching (if in use) is caching session data that needs to stay dynamic per-visitor.

4. Template overrides, only after 1-3 are ruled out. If the mini-cart in the header updates correctly but the full cart page doesn't (or the reverse), that asymmetry is the tell that a theme or plugin has overridden a specific WooCommerce template file — check for a customized cart.php that's fallen out of sync with the installed WooCommerce version.

5. Stock/variation sync, for variable products specifically. If a variation goes out of stock while sitting in an active cart, WooCommerce's stock-hold behavior can reset the quantity on update — this one's easy to mistake for a "bug" when it's actually the intended stock-protection behavior working as designed.

Following this order instead of guessing saves most of the debugging time — caching and AJAX conflicts alone account for the majority of real-world cases.

Full write-up with fix steps for each: https://amanurrahman.com/blog-post/woocommerce-cart-not-updating-fix

The Silent WooCommerce Bug Nobody Notices Until a Customer Complains

Tue, 29 Sep 2026 09:35:33 +0000

Most WooCommerce "bugs" that store owners report to developers aren't bugs at all — they're server configuration issues wearing a WooCommerce costume. Email delivery is the best example.

Here's what actually happens: WooCommerce triggers WordPress's core wp_mail() function for every transactional email — order confirmations, admin alerts, password resets. By default, wp_mail() uses PHP's built-in mail() function, which sends with zero authentication. No SPF record, no DKIM signature, nothing tying the email to a verified domain.

Modern receiving mail servers (Gmail, Outlook, Yahoo) are aggressive about filtering unauthenticated mail. Some servers reject it outright. Others accept it and quietly drop it in spam. A few let it through fine — which is why this bug looks "random" to store owners. It isn't random at all; it's about which receiving server's spam filter caught it.

The diagnostic that saves the most time: test the WordPress password-reset email on the login page, completely separate from WooCommerce. If that also fails to arrive, you've confirmed the problem lives at the server/WordPress level, not inside WooCommerce's code — which means you can stop digging through WooCommerce settings entirely.

The actual fix is routing outgoing mail through authenticated SMTP instead of PHP's mail(). A dedicated SMTP plugin connected to a transactional provider (Brevo, SES, SendGrid — Gmail SMTP works too for very low volume) handles authentication properly, and adding SPF/DKIM DNS records for the sending domain is what actually resolves spam-folder placement, not the SMTP connection alone.

One thing worth flagging for anyone debugging this for a client: if SMTP is already configured and working (test emails send fine) but WooCommerce-specific emails still don't fire, check for a caching plugin caching the checkout/thank-you page — it can interfere with the order-completion hook that triggers the customer email. Excluding cart/checkout/my-account from caching resolves it.

Full breakdown with every failure mode (delayed emails via WP-Cron, plugin conflicts, recipient field issues) here: https://amanurrahman.com/blog-post/woocommerce-emails-not-sending-fix

WordPress Malware Protection Checklist: Everything You Need to Do

Thu, 24 Sep 2026 12:41:24 +0000

If your WordPress site went down tomorrow because a hacker injected malicious code, redirected your visitors to a phishing page, or got your domain blocked by Google, how quickly could you recover, and more importantly, could you have stopped it? WordPress powers over 43% of the web, making it the most targeted CMS for automated attacks, brute-force bots, and supply-chain malware delivered through outdated plugins. Most site owners think about security only after a breach. This checklist changes that.

Why WordPress Sites Get Infected (And Why “Just Keep It Updated” Is Not Enough)

The common advice is to keep WordPress, themes, and plugins updated. That is correct but incomplete. The majority of WordPress malware infections happen through three specific vectors:

Compromised plugins and themes: especially nulled (pirated) versions that ship with backdoors baked in. Even legitimate plugins can carry vulnerabilities for weeks before a patch ships.
Weak credentials and no login throttling: WordPress’s default login URL (/wp-login.php) is publicly known. Without brute-force protection, automated bots can cycle through thousands of username-password combinations with no friction.
Outdated PHP and server software: WordPress running on PHP 7.4 or below is exposed to vulnerabilities that have long been patched in PHP 8.1+. Your host’s server stack matters as much as WordPress itself.

Understanding where infections enter is what makes a checklist like this actionable rather than decorative.

The WordPress Malware Protection Checklist

The default WordPress login sits at /wp-login.php. Every bot on the internet knows this. Your first move is to reduce the attack surface at the point of entry.

Change the login URL using a plugin like WPS Hide Login. This removes your site from automated mass-scan targeting.
Enable two-factor authentication (2FA) for all admin and editor accounts. Wordfence, miniOrange, and WP 2FA handle this well.
Limit login attempts using Limit Login Attempts Reloaded. Lock accounts after 3 to 5 failed tries.
Disable XML-RPC if you do not use it. It is a legacy endpoint that attackers abuse for credential stuffing.

2. Audit and Control Your Plugins and Themes

Every plugin is an extension of trust. The more plugins you run, the wider your attack surface.

Remove inactive plugins and themes immediately. Even deactivated plugins can be exploited if they remain on the server.
Only install from the official WordPress.org repository or reputable commercial marketplaces. Never install nulled plugins.
Check plugin update frequency and active install counts before installing. A plugin with no updates in 18 months is a risk.
Use WPScan or Patchstack to audit installed plugins against known vulnerability databases.

⚠️ Never Use Nulled Plugins

Nulled (pirated) plugins are one of the most reliable ways to get your site infected. They frequently contain backdoors baked in by the distributor. The $40 plugin license is not worth gambling your entire site over.

3. Set Correct File Permissions

Incorrect file permissions are one of the most overlooked hardening steps. WordPress files should not be world-writable.

The correct permission structure: Files 644 | Directories 755 | wp-config.php 440 or 400

# Set correct permissions for all files
find /path/to/wordpress/ -type f -exec chmod 644 {} \;

# Set correct permissions for all directories
find /path/to/wordpress/ -type d -exec chmod 755 {} \;

# Lock down wp-config.php
chmod 440 wp-config.php

Also disable file editing from the WordPress admin panel by adding this to wp-config.php:

// Prevent admin file editor access
define('DISALLOW_FILE_EDIT', true);

4. Protect wp-config.php and Sensitive Files

wp-config.php contains your database credentials, secret keys, and table prefix. Block direct access via .htaccess:

# Block direct access to wp-config.php
<files wp-config.php>
  order allow,deny
  deny from all
</files>

# Block XML-RPC if unused
<files xmlrpc.php>
  order allow,deny
  deny from all
</files>

# Hide WordPress version from readme
<files readme.html>
  order allow,deny
  deny from all
</files>

5. Move wp-config.php One Level Up

WordPress automatically looks for wp-config.php one directory above the web root. Moving it there keeps it completely outside the publicly accessible file structure; zero plugins needed, maximum effect.

✅ Pro Tip: Simply move the file to the parent directory of your public_html or www folder via FTP/SFTP. WordPress will find it automatically. No config change required.

6. Install a WordPress Security Plugin (And Configure It Properly)

A security plugin is not a magic shield, but it gives you active monitoring, firewall rules, and malware scanning in one place. For websites that need more hands-on protection, WordPress malware protection services can also provide professional monitoring, malware cleanup, and ongoing security support. The three most widely trusted options:

Wordfence Security: includes a web application firewall (WAF), malware scanner, real-time traffic monitoring, and login protection. The free version is solid; the paid version gets real-time firewall rule updates.
Sucuri Security: strong on server-side scanning and blocklist monitoring. Pairs well with their CDN/WAF service if you want cloudside filtering.
iThemes Security (now Solid Security): good for non-technical users who want guided hardening steps.

Whichever you choose, configure it. Default settings don't provide maximum protection. Enable the firewall in “enforced” mode, schedule daily scans, and set up email alerts for critical events.

7. Run Regular Malware Scans

Run Wordfence or MalCare scans at least weekly.
Use Sucuri SiteCheck (free, online) to cross-reference against Google Safe Browsing, McAfee, and Norton blacklists.
On VPS/dedicated hosting, run ClamAV for filesystem-level scanning that plugin scanners cannot reach.

8. Use HTTPS and Force SSL Everywhere

Force HTTPS across your entire site with this .htaccess rule, then lock down the admin area in wp-config.php:

# Force HTTPS on all requests
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

// Force SSL for the admin dashboard
define('FORCE_SSL_ADMIN', true);

9. Implement HTTP Security Headers

Security headers tell browsers how to handle your site’s content. They prevent a class of attacks including cross-site scripting (XSS), clickjacking, and MIME-type sniffing.
Add these to .htaccess:

# Prevent clickjacking
Header always set X-Frame-Options "SAMEORIGIN"

# Prevent MIME-type sniffing
Header always set X-Content-Type-Options "nosniff"

# Enable XSS filtering in older browsers
Header always set X-XSS-Protection "1; mode=block"

# Control referrer information
Header always set Referrer-Policy "strict-origin-when-cross-origin"

# Restrict browser features
Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()"

💡 Test Your Headers: After adding these, test at securityheaders.com for an instant grade and any missing headers your server is not sending.

10. Change the Default Database Table Prefix

WordPress installs with wp_ as the default database table prefix. SQL injection attacks target this predictable naming. During a fresh install, change it to something like xk72m_ in wp-config.php:

// Change from default 'wp_' to a random prefix
$table_prefix = 'xk72m_';

⚠️ Existing Sites: Changing the prefix on a live site requires updating every table in your database. Use the Brozzme DB Prefix plugin and always take a full backup before proceeding.

11. Create Automated, Offsite Backups

Backups are not a malware prevention tool, but they are your recovery mechanism when everything else fails. You can recover an infected site with a clean backup in under an hour. An infected site without a backup is a crisis.

Use UpdraftPlus, BlogVault, or WPvivid to schedule automated backups.
Store backups offsite: Amazon S3, Google Drive, Dropbox, or a remote FTP. Never store backups only on the same server your site lives on.
Test your restore process at least once. A backup you have never restored is a backup you cannot trust.

12. Keep Everything Updated on a Schedule

PHP, WordPress core, themes, and plugins; all of it, weekly. Enable automatic minor core updates in wp-config.php:

// Enable automatic minor WordPress core updates
define('WP_AUTO_UPDATE_CORE', 'minor');

// Optional: disable all auto-updates (use with a manual update process)
// define('AUTOMATIC_UPDATER_DISABLED', true);

What to Do If Your WordPress Site Is Already Infected

If you suspect your site has been compromised, act in this order:

Take the site offline or put it in maintenance mode to stop the spread and protect visitors.
Scan with Wordfence or MalCare to identify infected files.
Restore from a clean backup if you have one and know when the infection occurred.
If no clean backup exists, use a professional malware removal service (Sucuri, Wordfence Care, or WP Buffs) rather than trying to clean every file manually.
Change all passwords: WordPress admin accounts, database password, FTP/SFTP credentials, and hosting panel login.
Request Google blocklist removal via Google Search Console once the site is clean.

🚨 Do Not Skip Step 5: If an attacker had admin access, they likely created backdoor accounts or stored credentials. Cleaning files without rotating all passwords leaves the door open for re-infection within hours.

Conclusion

WordPress malware protection is not a one-time setup. It is a layered, ongoing process: harden the login, audit your plugins, set correct permissions, run regular scans, enforce HTTPS, and back up consistently. None of these steps alone guarantees safety, but together they make your site a significantly harder target than most WordPress installations on the web. Attackers follow the path of least resistance. Make sure your site is not it.

Frequently Asked Questions

How do I know if my WordPress site has malware?

Common signs include unexpected redirects to unknown sites, new admin users you did not create, Google Search Console warnings about harmful content, your hosting provider suspending your account, or visitors reporting security warnings in their browsers. Run a scan with Wordfence or check your site with Sucuri SiteCheck for a fast, free diagnosis.

What is the best plugin to protect WordPress from malware?

Wordfence Security is the most widely used option and offers a strong firewall, malware scanner, and login protection in its free tier. Sucuri Security is preferred when you also want cloudside WAF filtering. MalCare is a good choice if you want automated daily scanning with one-click malware removal. The best plugin is whichever one you actually configure and monitor.

How often should I scan my WordPress site for malware?

At minimum, once a week. If you run an ecommerce store or handle sensitive user data, daily scanning is worth the overhead. Most security plugins let you schedule automated scans, so there is little reason to scan less frequently. Also scan immediately after installing a new plugin, after a WordPress core update, or if you notice unusual traffic or behavior.

Can malware infect WordPress through plugins?

Yes, and this is one of the most common infection vectors. Plugins can carry vulnerabilities that attackers exploit to inject malicious code. Nulled (pirated) plugins frequently contain backdoors by design. Even legitimate plugins from reputable developers can have unpatched security flaws. Use Patchstack or WPScan to monitor your installed plugins against known vulnerability databases.

Does updating WordPress remove malware?

No. Updating WordPress patches known software vulnerabilities but does not remove existing malware from your files or database. If your site is already infected, scan and clean it first, then update. Updating an infected site may close the entry point, but the malicious code already present will remain until you explicitly remove it.

Multiple Image Uploads in WPForms Lite: How I Built Multimage

Wed, 23 Sep 2026 19:24:10 +0000

WPForms Lite is one of the most popular free form builders in WordPress, but it has one gap that keeps coming up: there's no file upload field. If you want visitors to attach photos to a contact form, a support request, or a portfolio submission, the usual answer is "upgrade to Pro."

I wanted a lighter answer for that one use case, so I built Multimage – Image Uploads for WPForms, a free plugin on WordPress.org that adds a Multi Image Upload field to the WPForms builder, Lite included.

What it does

Once activated, a new Multi Image Upload field appears in the WPForms Standard Fields panel. Drag it into any form and configure it per field: maximum number of uploads, allowed file extensions, and maximum file size in MB.

On the front end, visitors can pick several images at once, see them listed with individual remove buttons, and submit. On the admin side, image URLs show up in the {all_fields} email template, and the images themselves are attached to notification emails.

The tricky part: AJAX submission

WPForms can submit forms with or without AJAX, and files don't travel nicely through form serialization. Building an upload field that only works in one mode would have been fragile.

So Multimage doesn't wait for the form submit. The flow looks like this:

When a visitor selects images, each file is uploaded immediately to a temporary folder through a secured AJAX endpoint.
The endpoint returns a lightweight token for each file.
Only those tokens travel with the form submission, not the files.
When the submission succeeds, the files are moved from the temp folder into the standard WordPress uploads directory (wp-content/uploads/year/month).

Because the heavy lifting happens before submit, it doesn't matter whether AJAX submission is on or off. Nothing gets lost.

Security decisions

Accepting files from anonymous visitors is where most upload plugins get into trouble, so validation happens server-side regardless of what the field settings say:

Content-based MIME detection, not just trusting the file extension
A hard image-only whitelist: jpg, jpeg, png, gif, and webp. Even if someone misconfigures the field, non-image files are rejected
Size limits enforced on the server
Automatic cleanup: temporary uploads that were never attached to a successful submission are deleted after 24 hours, so abandoned forms don't fill up your disk

Why images don't go into the Media Library

A deliberate choice: submitted images are saved to the uploads directory but are not registered as Media Library attachments. Visitor submissions are form data, not site content, and a busy form shouldn't bury your actual media under hundreds of random photos.

Where it fits

Any form where visitors need to send more than one photo: gallery or portfolio submissions, job or program applications, product damage and support requests, property or event photo forms. Need a single profile photo and a larger gallery in one form? Add two Multi Image Upload fields with different limits.

Privacy

Everything stays on your server. Images live in your uploads directory and are only emailed where you've configured WPForms notifications. No external services are involved.

Try it

Plugin: Multimage – Image Uploads for WPForms
Requirements: WordPress 5.8+, PHP 7.4+, WPForms Lite or Pro

It's a 1.0 release, so feedback, bug reports, and feature requests on the support forum are very welcome.

Multimage is an independent, third-party add-on and is not affiliated with, endorsed by, or sponsored by WPForms or Awesome Motive, Inc. "WPForms" is used only to describe compatibility.

What a WordPress Developer Actually Charges for an Optometrist Website — and Why

Tue, 22 Sep 2026 17:46:03 +0000

As a freelance WordPress/WooCommerce developer who's built healthcare-adjacent sites, I keep seeing the same confusion in optometry: two practices both say they "got a website built," one spent $600, the other spent $8,000, and neither can explain the gap in technical terms. Here's what actually separates those price points from a developer's side of the table.

The $600 build is almost always a page-builder theme (Divi, Astra, a Wix/Squarespace equivalent) with content swapped in. No custom post types, no structured schema beyond whatever the theme auto-generates, and booking is usually an iframe embed or a basic Contact Form 7 setup — not a real integration with practice-management software like Weave or Solutionreach.

The $2,500–$6,000 build is where real development work starts: custom ACF field groups for service pages, an insurance-plan page built as a maintainable custom post type (so front-desk staff can update it without touching code), FAQPage schema markup written by hand rather than auto-generated, and — critically — a booking flow that either uses a proper API integration or, at minimum, a purpose-built plugin configured correctly rather than dropped in with defaults.

The $6,000+ multi-location build adds the part most developers get wrong: location pages that don't trip Google's duplicate-content detection. That means genuinely different content per location (not a template with the city name swapped), a shared design system via a parent theme + child themes or a block-pattern library, and centralized content management so head office can push updates without a developer in the loop for every hours change.

A few technical details that matter more than people expect:

HIPAA-aware forms: if any health information moves through the contact form, you need to think about where it's stored and transmitted, not just slap an SSL cert on it and call it compliant.
Local SEO structure: city + service-specific service pages outperform a single generic "services" page for local search, but only if the content is genuinely differentiated, not spun.
Maintenance debt: unmaintained WordPress sites are the single most common reason I get hired for post-hack cleanup work — a $50–$200/month maintenance retainer is cheap insurance against a five-figure recovery bill.

Full cost breakdown with all four pricing tiers and a vendor-questions checklist for practice owners: https://amanurrahman.com/blog-post/optometrist-website-cost

White Label WordPress Development Scale Your Agency Without Hiring

Tue, 22 Sep 2026 13:37:23 +0000

Your agency can win more WordPress projects without hiring another developer, but the real challenge is delivering that extra work without stretching your existing team too thin. When client requests pile up, deadlines tighten, and your developers are already committed to other projects, white-label WordPress development can offer a practical way to increase delivery capacity while keeping your agency client-facing.

The model is straightforward: an external WordPress development team handles the technical work, while your agency manages the client relationship and presents the finished work under its own brand. The key question isn't whether outsourcing is possible, but whether the setup gives you enough control over quality, communication, timelines, and client experience to scale without creating another operational headache.

What Is White Label WordPress Development?

White-label WordPress development is a service model where a third-party WordPress team develops websites, custom features, fixes, or maintenance work on behalf of another agency. The agency then delivers that work to its own clients under its brand.

The client may never interact directly with the development partner. From the client’s perspective, the agency remains responsible for the project.

This makes white labeling different from simply referring a client to another company. The development partner works behind the scenes, allowing the agency to expand its technical capacity without building a larger in-house team.

Typical white-label WordPress work includes:

Custom WordPress website development
Theme customization
Plugin development and integration
WooCommerce development
Website migrations
WordPress maintenance and updates
Performance optimization
Bug fixing and technical support
Landing page development
API and third-party integrations

For agencies, the biggest benefit is capacity. Instead of turning down projects because your internal team is busy, you can outsource specific development work.

Why Agencies Use White Label Development to Scale

Hiring full-time developers is not always the right answer to increased demand.

A new employee brings salary costs, recruitment time, onboarding, management, equipment, benefits, and ongoing workload considerations. More importantly, agencies do not always have a consistent amount of development work throughout the year.

White-label development changes the equation.

For agencies with tight project budgets, affordable white-label WordPress development can help manage costs while leaving room for design, strategy, project management, and client support.

You can add external development capacity when project volume increases and scale back when demand slows. This creates a more flexible delivery model.

For example, imagine a small digital agency has three active WordPress projects. Its designers and account managers can handle the client-facing work, but the development team is already at capacity.

A new project arrives with a tight deadline.

Instead of hiring someone immediately, the agency can outsource the development portion while keeping strategy, design direction, communication, and project management internally.

That means the agency can potentially take on more work without increasing its permanent headcount at the same rate.

What Work Should You Keep In-House?

Not every part of a WordPress project needs outsourcing.

A practical approach is to keep activities that directly influence the client relationship in-house and delegate specialized production work when appropriate.

Usually worth keeping in-house:

Client communication
Discovery calls
Project strategy
Brand direction
UX decisions
Creative approvals
Account management
Final quality review

Often suitable for white-label delivery:

WordPress development
Theme implementation
Plugin configuration
Custom functionality
WooCommerce development
Technical troubleshooting
Website migration
Routine maintenance

This division gives your agency control over the parts clients value most, while letting an external team handle repetitive or specialized technical execution.

How White Label WordPress Development Works

The workflow does not need to be complicated.

1. Your agency wins the project

The client signs an agreement with your agency. Your team establishes the scope, requirements, timeline, and expected deliverables.

2. You prepare the development brief

The development partner receives everything required to start work. This can include designs, content, functionality requirements, technical specifications, hosting information, and acceptance criteria.

A detailed brief matters because vague instructions create unnecessary revisions.

3. The WordPress team builds the project

External developers work to your specifications and development standards.

Depending on the arrangement, they may work in a staging environment, Git repository, development server, or directly through your project management workflow.

4. Your agency reviews the work

Before the client sees anything, your team should test the website.

Check responsive layouts, forms, links, performance, browser behavior, content, integrations, and any functionality included in the original scope.

5. You deliver the project

Once the work meets your internal standards, your agency presents it to the client through your normal delivery process.

This final review is important. white-label does not mean removing your agency from quality control.

How to Choose a White Label WordPress Partner

The cheapest development partner isn't automatically the most useful.

Your priority should be predictable delivery.

Before starting a long-term relationship, look at several practical factors.

WordPress expertise: Make sure the developers understand WordPress beyond basic page building. Ask about custom WordPress themes, plugins, WooCommerce, security, performance, and integrations when relevant to your projects.
Communication: Delayed replies can quickly become client-facing delays. Establish communication expectations before work begins.
Development process: Ask how requirements, revisions, testing, staging, and handoffs are handled.
Code quality: A website that looks correct today can still create problems later if the underlying implementation is poor.
Confidentiality: Since the partner operates behind your agency, agreements covering confidentiality and client information should be clear.
Scalability: If your project volume doubles, can the partner handle additional work without sacrificing delivery quality?
Revision policy: Define how bugs, scope changes, and revision rounds are handled before the first project starts.

White Label vs. Hiring an In-House WordPress Developer

These two approaches solve different problems.

An in-house developer gives you direct control over daily work, internal processes, and team collaboration. It can make sense when development demand is consistently high and predictable.

White-label development provides flexibility. You can add technical capacity without immediately committing to another permanent employee.

The choice often depends on workload, not ideology.

If your agency has steady development work every month, building internal capacity may be worth considering. If demand fluctuates or you need specialist support for certain projects, a white-label arrangement can scale more easily.

Some agencies also use both models. An internal developer handles core projects while a white-label partner provides overflow capacity during busy periods.

Common Mistakes Agencies Should Avoid

white-label development can create problems when agencies treat it as a simple handoff instead of a delivery system.

One common mistake is sending incomplete project requirements. Developers cannot reliably deliver against a brief that keeps changing.

Another is skipping internal testing. Even if the development partner has its own QA process, your agency should perform a final review before the client receives the work.

Pricing can also be confusing. Agencies should understand development costs, project scope, revision limits, and their own margin before quoting clients.

Finally, avoid depending entirely on one external developer without documenting processes. If that person becomes unavailable, your agency should still have enough project information to continue the work.

How to Make White Label WordPress Development Work Long Term

The strongest setups usually have repeatable processes. If you are managing multiple projects, following practical WordPress web development tips such as using staging environments, documenting requirements, testing responsive layouts, and keeping development workflows consistent can help reduce avoidable issues.

Create a standard development brief for every project. Include design files, page requirements, functionality, integrations, content status, technical constraints, deadlines, and acceptance criteria.

Use a consistent staging and review process.

Keep communication centralized rather than sending scattered instructions across multiple channels.

Most importantly, document recurring tasks. When you repeat the same WordPress development process across projects, documentation reduces mistakes and makes onboarding easier.

The goal is not simply to outsource work. The goal is to create a reliable extension of your agency’s delivery team.

Conclusion

White-label WordPress development gives agencies another way to increase delivery capacity without immediately increasing permanent headcount. It works particularly well when project demand fluctuates, specialist WordPress skills are needed, or an internal team is already operating near capacity.

The model works best when responsibilities are clearly divided. Your agency controls strategy, client communication, project direction, and final quality, while the development partner handles agreed technical execution. With a clear, brief, reliable workflow, testing process, and well-defined expectations, white-label development can become a practical part of an agency’s operating model rather than a last-minute outsourcing solution.

Frequently Asked Questions

1. What is white-label WordPress development?

White-label WordPress development is when an external WordPress development team builds websites or technical features for an agency. The agency then delivers the completed work to its client under its own brand.

2. Can agencies use white-label WordPress development without hiring developers?

Yes. Agencies can use an external WordPress development team to increase technical delivery capacity without immediately adding full-time developers to their internal staff.

3. What WordPress services can be white-labeled?

Common services include custom WordPress development, theme customization, plugin development, WooCommerce, website migration, maintenance, performance optimization, bug fixing, and third-party integrations.

4. Is white-label WordPress development cheaper than hiring an in-house developer?

It can reduce fixed staffing costs when development demand is inconsistent, but total costs depend on project volume, scope, partner rates, revisions, and the agency’s internal management requirements.

5. How do agencies maintain quality with white label WordPress development?

Agencies can maintain quality by using detailed project briefs, defined development standards, staging environments, structured testing, clear revision rules, and an internal quality review before delivering the project to the client.

The 200-byte trap: why WordPress core updates break Arabic URLs

Tue, 22 Sep 2026 09:22:50 +0000

You update WordPress on a quiet afternoon, a routine release, the kind you've installed a hundred times. The dashboard says everything went fine. Then the 404s start: not a handful, but every long-headlined article in your archive, all at once, all in Arabic.

Nothing in the update log mentions it. No plugin changed. And the cruel part: the data that made those URLs work is already gone, shaved off inside a database-upgrade routine that ran for a few milliseconds and reported success. This isn't a freak accident or a broken plugin. It's three separate assumptions baked into WordPress core, each hard-coding the same number, 200, and Arabic sites are almost uniquely exposed to all three. We hit this running WordPress for Arabic newsrooms, the same high-traffic publishing we've written about surviving breaking-news spikes. We traced it to the exact lines in core and built a fix that survives every future update. Here's the whole story.

Why Arabic URLs hit a wall English never does

WordPress stores a post's slug in the post_name column of wp_posts, and a category or tag slug in the slug column of wp_terms. Both are VARCHAR(200) by default: room for 200 characters, which for an English headline is generous. "Everything you need to know about our new pricing" is barely fifty. You'd have to write a paragraph to run out.

Arabic is a different arithmetic, because of what WordPress actually stores in that column. It doesn't keep the raw Arabic text; it stores the percent-encoded form, the same %XX sequence that travels in the URL. Take a single word:

الذكاء  →  %d8%a7%d9%84%d8%b0%d9%83%d8%a7%d8%a1

Every Arabic letter is two bytes in UTF-8, and every byte becomes a three-character %XX token. So one Arabic character costs about six characters of column space. Do the division: VARCHAR(200) holds roughly 33 Arabic characters. A normal news headline, "القبض على المتهمين في قضية الاحتيال الإلكتروني", blows past that before it's halfway done.

So Arabic publishers learn early to widen the columns:

ALTER TABLE wp_posts MODIFY post_name VARCHAR(1024) NOT NULL DEFAULT '';
ALTER TABLE wp_terms MODIFY slug      VARCHAR(1024) NOT NULL DEFAULT '';

VARCHAR(1024) holds about 170 Arabic characters, comfortable. Permalinks resolve, the newsroom publishes, and the problem looks solved.

It isn't. It's about one-third solved, and the other two-thirds are waiting for the next core update. (This isn't only an Arabic problem, either: any non-Latin script that percent-encodes (Persian, Urdu, Hebrew, Greek) hits the same wall. Arabic publishers just hit it first; scripts that take three bytes a character, such as Hindi, Thai or Chinese, hit it harder still, at about 22 characters to Arabic's 33.)

The number 200 lives in three places, not one

Here's the insight that turns this from a recurring mystery into something you can actually close out. WordPress hard-codes "200" in three independent places, and widening the column only touches the first:

Layer	What it caps at 200	Does widening the column fix it?
1, Storage	the column that physically stores the slug	Yes, but a core update silently undoes it
2, Generation	every new slug, the moment it is created	No, it's PHP; needs a code override
3, De-duplication	slugs that collide and need a numeric suffix	No, but this only fires on collisions

Your ALTER fixes Layer 1's storage. But Layer 2 means that even with a 1024-wide column, every new slug is still cut to 200 bytes before it's ever saved, unless something on your site already overrode it. (If long Arabic slugs save correctly for you today, a plugin, your theme, or a past developer already patched Layer 2, which means you have an undocumented dependency you didn't know you were relying on.) And Layer 1, the storage you so carefully widened, is exactly the one a core update quietly reverts. Let's take each in turn.

Layer 1: how a core update erases your column width

WordPress keeps a canonical description of its own database schema, and on every major update it reconciles the live database against that description. The chain is short and deterministic:

A new release bumps $wp_db_version in version.php.
On the next admin request, wp_upgrade() notices the bump and runs the database upgrade.
That calls make_db_current_silent(), which calls dbDelta( wp_get_db_schema() ).
wp_get_db_schema() is the canonical schema, and it says, verbatim:

post_name varchar(200) NOT NULL default '',
...
slug varchar(200) NOT NULL default '',

dbDelta() then runs a DESCRIBE on every live table, compares each column to the canonical definition, and for any mismatch emits an ALTER TABLE … CHANGE COLUMN to "correct" it. Your post_name is VARCHAR(1024); the canonical says VARCHAR(200); they don't match, so dbDelta dutifully issues a CHANGE COLUMN back to 200, MySQL rebuilds the table, and every byte past the 200th is discarded.

Here's the detail that makes it unrecoverable. Years ago, core added downsize protection to dbDelta, but only for TEXT and BLOB columns (it was Trac #36748, born from exactly this kind of data loss). VARCHAR got no such guard. So a TEXT column is safe from accidental shrinking; your VARCHAR(1024) slug column is not. dbDelta shrinks it without hesitation, and restoring the column to 1024 afterwards brings back the width but not the data; those bytes were handed to MySQL and dropped.

That's why your fix keeps coming undone: always right after an update, always silently. It isn't a bug aimed at you; it's core doing exactly what it was designed to do, to a column you were never expected to change.

For accuracy: a separate routine, pre_schema_upgrade(), also runs hand-written
ALTERs, but those are version-gated to historic migrations and won't touch a
modern site's post_name. The reversion you're seeing is dbDelta.

The fix: don't repair the damage, prevent the shrink

The instinct is to write something that detects the reverted column and re-widens it after each update. Resist it. By the time you can detect the shrink, the data is already gone; you'd just be putting an empty wider column back over truncated slugs. The only fix that actually saves the data is one that stops the shrink from ever happening.

And core hands you the seam to do it. dbDelta exposes a filter, dbdelta_create_queries, that receives the canonical CREATE TABLE statements before they're compared to the live database. Rewrite the canonical post_name varchar(200) to varchar(1024) in that filter, and dbDelta's idea of "correct" now matches what's actually on disk. It sees no mismatch. It emits no CHANGE COLUMN. There is nothing to truncate.

<?php
/**
 * Plugin Name: Arabic Slug Schema Guard (must-use)
 * Description: Keeps wp_posts.post_name and wp_terms.slug at VARCHAR(1024) across
 *              core DB upgrades, so long Arabic slugs are never truncated.
 *              Prevention-first: dbDelta never even tries to shrink them.
 */
defined( 'ABSPATH' ) || exit;

const SLUG_COLUMN_LEN = 1024;

// Rewrite the canonical schema dbDelta diffs against, so "desired" already
// equals the live 1024-wide column, so no CHANGE COLUMN is ever emitted.
add_filter( 'dbdelta_create_queries', function ( $queries ) {
    global $wpdb;

    foreach ( array( $wpdb->posts => 'post_name', $wpdb->terms => 'slug' ) as $table => $column ) {
        if ( isset( $queries[ $table ] ) ) {
            $queries[ $table ] = preg_replace(
                '/(\b' . $column . '\s+varchar\()\s*200\s*(\))/i',
                '${1}' . SLUG_COLUMN_LEN . '${2}',
                $queries[ $table ]
            );
        }
    }
    return $queries;
} );

That single filter is the whole prevention story for Layer 1, and it's robust in a way an after-the-fact repair can never be: it runs inside dbDelta, so it covers every path that triggers a schema reconcile: the admin "database update required" screen, background auto-updates, and wp core update-db on the CLI alike.

Where this code lives matters as much as what it does. Put it in a must-use plugin (a single .php file in wp-content/mu-plugins/), not a regular plugin. MU-plugins always load, can't be deactivated from the dashboard, and load before the upgrade routine runs. And because a core update only ever replaces wp-admin, wp-includes and the root PHP files (it never touches wp-content), your guard is guaranteed to still be in place at the exact moment the upgrade fires. A regular plugin could be deactivated the one time it mattered; don't bet your archive on a toggle.

Layer 2: stop new slugs truncating at birth

Prevention on the column keeps your existing slugs safe. But Layer 2 is still cutting every new slug to 200 bytes at the moment of creation, inside sanitize_title_with_dashes(). The relevant line, unchanged in current core, is:

$title = utf8_uri_encode( $title, 200 );

That function is attached to the sanitize_title filter, so you can cleanly swap it for an identical copy that uses a larger byte budget:

// Layer 2: replace core's slug generator with a byte-for-byte copy whose only
// change is the encoding cap. The copy self-tests against core (see below), so a
// future core rewrite of this function is caught instead of drifting silently.
remove_filter( 'sanitize_title', 'sanitize_title_with_dashes' );
add_filter( 'sanitize_title', 'asg_sanitize_title_with_dashes', 10, 3 );

function asg_sanitize_title_with_dashes( $title, $raw_title = '', $context = 'display' ) {
    // … the body is line-for-line core, with one change:
    //     utf8_uri_encode( $title, 200 )  →  utf8_uri_encode( $title, 1000 )
    // 1000 leaves headroom under the 1024 column for a "-2" collision suffix.
}

Pick a sane budget: around 1000 bytes (≈ 160 Arabic characters) leaves room under the column for the numeric suffix WordPress adds to resolve duplicates. You don't want unlimited slugs; you want enough.

Layer 3 (_truncate_post_slug()) caps at 200 too, but it only runs when a slug collides and needs a -2 suffix. For unique news headlines that almost never fires, and it isn't filterable, so most sites can leave it alone. If you genuinely need more than 200 bytes even on collisions, you take over uniqueness through the pre_wp_unique_post_slug filter, an advanced case worth a footnote, not a paragraph.

Keeping the fork honest

Copying a core function buys a maintenance debt: the day WordPress rewrites sanitize_title_with_dashes(), your copy diverges, silently, which is the exact failure mode we're trying to kill. Pinning the copy to a core version and re-diffing by hand works right up until the release someone forgets to check, which on a long-lived site is when, not if. So don't rely on remembering. Make the plugin re-diff itself.

The lever: remove_filter() only unhooks the function; sanitize_title_with_dashes() stays callable. So you can use core's own current code as a live oracle and assert your fork still agrees with it on short inputs, where neither byte cap fires and the only thing left that could differ is the cleanup logic:

// Run once per core version. Short fixtures => neither length cap engages,
// so any difference is pure logic drift, not the byte budget.
foreach ( array( 'الذكاء الاصطناعي', 'عاجل: «مهم» اليوم', 'foo/bar — baz' ) as $f ) {
    if ( sanitize_title_with_dashes( $f, $f, 'save' )
         !== asg_sanitize_title_with_dashes( $f, $f, 'save' ) ) {
        // core changed the cleanup logic: log + email ops, and (optionally) fall
        // back to core's generator so slugs cap at 200 again: degraded, but safe
        // and known, never a malformed slug from a stale copy.
    }
}

This beats a source-hash check on two counts. It's semantic, not textual: it stays quiet when core only touches the length handling (which you override anyway) and fires only when a change actually breaks your output, so the alerts that do fire get acted on. And it degrades safely: on drift you fall back to core's exact behaviour: worst case, new slugs cap at 200 until you re-sync, never a half-encoded slug from a stale copy. Loud-and-safe beats silent-and-wrong. The full guard (with the per-core-version cache and the optional fail-safe switch) is in the complete plugin below.

A tripwire, because silent failure is the real enemy

The filter prevents the known incident. But the failure mode that actually hurt you was that it happened silently, so the last piece is making sure you'd never again learn about it from a drop in search traffic. The same MU-plugin can verify the column widths after every update and shout if anything is wrong:

Hook upgrader_process_complete to flag that a core update just ran.
On the next admin request, check the real column widths in information_schema and, if either has shrunk, write to the error log and email ops.
Expose a WP-CLI command for cron-based monitoring:

# Nightly: verify the slug columns, email ops if either has reverted.
0 3 * * *  cd /var/www/site && wp asg verify | grep -q REVERTED \
           && wp asg verify | mail -s "WP slug schema reverted on $(hostname)" *Emails are not allowed*

One discipline to internalise: this tripwire restores confidence, not data. If it ever reports a reverted column, treat it as an incident, not a self-healing event; the slugs longer than the new width are already gone and must come back from a backup. Prevention (the filter) and backups are your safety net; the tripwire just tells you when to reach for them.

"Isn't VARCHAR(1024) dangerous?": no, and the reason is reassuring

Widening these columns sounds risky (indexes, utf8mb4, InnoDB limits), and it's the part people most often get scared off by. It's almost entirely a non-issue, and one fact explains why:

The index on these columns is a fixed 191-character prefix, independent of the column's declared length. Core defines KEY post_name (post_name(191)); it indexes the first 191 characters whether the column is 200 wide or 1024. Widening the column doesn't enlarge the index by a single byte.

That dissolves the usual worries:

Index / InnoDB prefix limits. The old InnoDB prefix ceiling is 767 bytes; WordPress chose 191 because 191 × 4 (utf8mb4's worst case) = 764, just under it. Because the prefix stays at 191 no matter how wide the column grows, you never move towards that limit. (A quiet irony: slugs are stored as percent-encoded ASCII, so they were never going to hit four bytes per character anyway.)
Row size. VARCHAR stores the actual length of each value, not its declared maximum; a 30-character slug takes ~30 bytes in a VARCHAR(1024) exactly as it would in a VARCHAR(200). Rows don't get bigger because the ceiling moved up.
Query plans. Lookups use the same 191-prefix index to narrow, then verify the full value. Identical behaviour at 200 or 1024.
Plugins. SEO plugins, caches and CDNs read post_name and emit longer URLs without complaint.

The genuine risks aren't in steady state; they're tools that recreate the schema from an old definition: a migration plugin that runs its own CREATE TABLE, or, most commonly, restoring a SQL dump taken before you widened the columns. A dump of the current database preserves VARCHAR(1024) correctly; importing an old structure silently puts you back at 200. Write that one down in your runbook.

Doing it safely on a site with millions of posts

There's one operational gotcha, and it's about the migration itself, not the result. Going from VARCHAR(200) to VARCHAR(1024) cannot be an instant, in-place change. InnoDB only keeps a VARCHAR length change "in place" while both lengths stay in the same size class: values under 256 use one length byte, values 256 and over use two. Crossing 255 forces ALGORITHM=COPY: a full table rebuild. On a wp_posts with millions of rows, a raw ALTER means a long operation and a problematic lock.

So on a large live site, do the initial widening with an online schema-change tool, not a bare ALTER:

pt-online-schema-change \
  --alter "MODIFY post_name VARCHAR(1024) NOT NULL DEFAULT ''" \
  --chunk-time=0.5 --max-load Threads_running=50 \
  --execute D=wordpress,t=wp_posts

(gh-ost is an equally good triggerless alternative.) wp_terms is tiny and takes a plain ALTER without ceremony; wp_posts is the one that needs the online tool. The rollout that's bitten no one:

Back up, and confirm the dump shows VARCHAR(1024) afterwards.
Clone to staging, deploy the MU-plugin, and run a real major core update there. Confirm no CHANGE COLUMN appears and the verify command reports OK.
Deploy the MU-plugin to production before the next core update: prevention has to be in place ahead of the event it prevents.
Widen the production columns off-peak with pt-osc / gh-ost.
Add a nightly verify cron and a 404 monitor, so anything unexpected surfaces in hours, not in a month of lost rankings.
Keep the MU-plugin in version control, and never import a pre-widening structure dump.

The deeper fix: stop betting your URLs on a column width

Everything above makes Arabic slugs safe. But there's a more permanent way to think about it, and for a large news archive it's worth the shift: don't let the URL depend on the slug surviving at all.

Anchor your permalinks on the numeric post ID, and keep the Arabic slug as a descriptive (but cosmetic) suffix:

https://example.com/123456/الذكاء-الاصطناعي

Resolve the post by its ID, and the slug becomes decoration. If it's ever truncated, malformed, or edited, the URL still resolves to the right article instead of 404-ing, and WordPress can 301 to the canonical form. You keep the Arabic keywords in the URL for search relevance and you become structurally immune to the entire class of problem. (If you want to stop touching core tables altogether, you can go one step further and store the long slug in your own indexed routing table, which dbDelta has no opinion about, but for most teams, ID-anchored permalinks are the sweet spot.)

That's the difference between patching a bug and designing it out.

The complete plugin

Everything above, assembled into one must-use plugin. Drop it in wp-content/mu-plugins/wp-arabic-slug-schema-guard.php, widen the columns once with an online schema-change tool, and all three layers, plus the tripwire, are handled in a single place. The slug generator is a copy of core's sanitize_title_with_dashes(); only the byte cap differs.

📦 Prefer it ready-made? The plugin is open-source on GitHub as mantekio/wp-arabic-slug-schema-guard, or composer require mantekio/wp-arabic-slug-schema-guard. Star it, file an issue, or lift it whole.

<?php
/**
 * Plugin Name: Arabic Slug Schema Guard (must-use)
 * Description: Keeps wp_posts.post_name and wp_terms.slug at VARCHAR(1024) across
 *              core DB upgrades, lets core generate long URL-encoded Arabic slugs,
 *              and verifies + alerts after every update. Prevention-first:
 *              dbDelta never truncates, because the canonical schema it diffs
 *              against already says 1024. The slug fork self-tests against core
 *              on each update and can fail safe.
 */
defined( 'ABSPATH' ) || exit;

const ASG_COLUMN_LEN = 1024;  // physical column width (bytes)
const ASG_SLUG_BYTES = 1000;  // max generated slug length, under the column width
const ASG_SCHEMA_SIG = 'post_name:1024;slug:1024';
// define( 'ASG_ALERT_EMAIL', '*Emails are not allowed*' );  // optional, set in wp-config.php
// define( 'ASG_L2_FAILSAFE', true );               // optional: on Layer-2 drift, fall back to core (slugs cap at 200) until you re-sync

/* LAYER 1: PREVENTION
 * Rewrite the canonical CREATE TABLE dbDelta diffs against, so "desired" already
 * equals the live 1024-wide column and no destructive CHANGE COLUMN is emitted. */
add_filter( 'dbdelta_create_queries', function ( $queries ) {
    global $wpdb;
    foreach ( array( $wpdb->posts => 'post_name', $wpdb->terms => 'slug' ) as $table => $column ) {
        if ( isset( $queries[ $table ] ) ) {
            $queries[ $table ] = preg_replace(
                '/(\b' . $column . '\s+varchar\()\s*200\s*(\))/i',
                '${1}' . ASG_COLUMN_LEN . '${2}',
                $queries[ $table ]
            );
        }
    }
    return $queries;
} );

/* LAYER 2: GENERATION
 * Core caps new slugs at 200 bytes via utf8_uri_encode($title, 200). Swap in a
 * copy of sanitize_title_with_dashes() whose only change is the byte budget.
 * Installed conditionally: if the drift guard (below) flagged THIS core version
 * and ASG_L2_FAILSAFE is on, stay on core's default (caps at 200, degraded but
 * safe and known) rather than run a fork we know has drifted. */
if ( get_option( 'asg_l2_status' ) === 'drift:' . $GLOBALS['wp_version']
     && defined( 'ASG_L2_FAILSAFE' ) && ASG_L2_FAILSAFE ) {
    // Known-drifted on this core version → leave core's generator in place.
} else {
    remove_filter( 'sanitize_title', 'sanitize_title_with_dashes' );
    add_filter( 'sanitize_title', 'asg_sanitize_title_with_dashes', 10, 3 );
}

function asg_sanitize_title_with_dashes( $title, $raw_title = '', $context = 'display' ) {
    $title = strip_tags( $title );
    // Preserve already-encoded octets through the cleanup below.
    $title = preg_replace( '|%([a-fA-F0-9][a-fA-F0-9])|', '---$1---', $title );
    $title = str_replace( '%', '', $title );
    $title = preg_replace( '|---([a-fA-F0-9][a-fA-F0-9])---|', '%$1', $title );

    if ( seems_utf8( $title ) ) {
        if ( function_exists( 'mb_strtolower' ) ) {
            $title = mb_strtolower( $title, 'UTF-8' );
        }
        $title = utf8_uri_encode( $title, ASG_SLUG_BYTES );  // core hard-codes 200 here
    }

    $title = strtolower( $title );

    if ( 'save' === $context ) {
        // EVERYTHING here is copied verbatim from core. The ONLY sanctioned difference
        // between this fork and core is the byte budget above. Drop a line and you have
        // drifted, see the note under the drift guard below.

        // Turn non-breaking spaces, en/em dashes and slashes into hyphens.
        $title = str_replace( array( '%c2%a0', '%e2%80%93', '%e2%80%94' ), '-', $title );
        $title = str_replace( array( ' ', ' ', '–', '–', '—', '—' ), '-', $title );
        $title = str_replace( '/', '-', $title );

        // Strip these characters entirely. Note %c2%ab / %c2%bb: the guillemets Arabic
        // uses as quotation marks. And %e2%80%8e / %e2%80%8f: the LRM and RTL marks.
        $title = str_replace(
            array(
                '%c2%ad',                                            // soft hyphen
                '%c2%a1', '%c2%bf',                                  // iexcl, iquest
                '%c2%ab', '%c2%bb', '%e2%80%b9', '%e2%80%ba',        // angle quotes
                '%e2%80%98', '%e2%80%99', '%e2%80%9c', '%e2%80%9d',  // curly quotes
                '%e2%80%9a', '%e2%80%9b', '%e2%80%9e', '%e2%80%9f',
                '%e2%80%a2',                                         // bullet
                '%c2%a9', '%c2%ae', '%c2%b0', '%e2%80%a6', '%e2%84%a2',
                '%c2%b4', '%cb%8a', '%cc%81', '%cd%81',              // acute accents
                '%cc%80', '%cc%84', '%cc%8c',                        // grave, macron, caron
                '%e2%80%8b', '%e2%80%8c', '%e2%80%8d',               // zero-width chars
                '%e2%80%8e', '%e2%80%8f',                            // LRM, RTL mark
                '%e2%80%aa', '%e2%80%ab', '%e2%80%ac',
                '%e2%80%ad', '%e2%80%ae',
                '%ef%bb%bf',                                         // byte order mark
                '%ef%bf%bc',                                         // object replacement
            ),
            '',
            $title
        );

        // Convert × to 'x'.
        $title = str_replace( '%c3%97', 'x', $title );
    }

    $title = preg_replace( '/&.+?;/', '', $title );          // strip remaining entities
    $title = str_replace( '.', '-', $title );
    $title = preg_replace( '/[^%a-z0-9 _-]/', '', $title );  // keep only slug-safe chars
    $title = preg_replace( '/\s+/', '-', $title );
    $title = preg_replace( '|-+|', '-', $title );
    return trim( $title, '-' );
}

/* LAYER 2 DRIFT GUARD: self-test the fork against core's live implementation.
 * remove_filter() only unhooks sanitize_title_with_dashes(); the function stays
 * callable, so we use core's CURRENT code as a live oracle and assert our fork
 * still agrees on SHORT inputs (where neither byte cap engages, the only thing
 * the fork changed). Any divergence == core altered the cleanup logic and our
 * copy has drifted. Runs once per core version; shouts, and can fail safe. */
add_action( 'admin_init', 'asg_guard_layer2_drift' );

function asg_guard_layer2_drift() {
    $ok      = 'ok:' . $GLOBALS['wp_version'];
    $drifted = 'drift:' . $GLOBALS['wp_version'];
    if ( in_array( get_option( 'asg_l2_status' ), array( $ok, $drifted ), true ) ) {
        return;  // already settled for this core version
    }
    if ( ! function_exists( 'sanitize_title_with_dashes' ) ) {
        return;  // core refactored it away: no oracle to diff against; the fork
                 // still runs as a standalone copy (it needs no removed function).
    }

    // Deliberately SHORT fixtures so neither length cap fires; any difference is
    // pure cleanup-logic drift, not the byte budget.
    $fixtures = array(
        'الذكاء الاصطناعي',
        'عاجل: تطورات «مهمة» اليوم',
        'Mixed عربي + English — dash',
        'foo/bar — baz',
        'UPPER   multiple   spaces',
        '%d8%a7 pre-encoded octet',
    );

    $drift = array();
    foreach ( $fixtures as $f ) {
        $core = sanitize_title_with_dashes( $f, $f, 'save' );
        $ours = asg_sanitize_title_with_dashes( $f, $f, 'save' );
        if ( $core !== $ours ) {
            $drift[] = "in=[{$f}] core=[{$core}] ours=[{$ours}]";
        }
    }

    if ( $drift ) {
        $msg = "[Arabic Slug Schema Guard] Layer-2 DRIFT on WP {$GLOBALS['wp_version']}: core "
             . "sanitize_title_with_dashes() no longer matches our fork; re-sync the copy.\n"
             . implode( "\n", $drift );
        error_log( $msg );
        if ( defined( 'ASG_ALERT_EMAIL' ) && function_exists( 'wp_mail' ) ) {
            wp_mail( ASG_ALERT_EMAIL, 'WP slug Layer-2 drift: ' . wp_parse_url( home_url(), PHP_URL_HOST ), $msg );
        }
        update_option( 'asg_l2_status', $drifted, true );  // autoload: the fail-safe reads it every request
        return;  // do NOT cache "ok" while drifted
    }
    update_option( 'asg_l2_status', $ok, true );
}

/* LAYER 3: DE-DUPLICATION (optional)
 * _truncate_post_slug() also caps at 200, but only when a slug COLLIDES and needs
 * a "-2" suffix, rare for unique headlines, and it isn't filterable. If you need
 * >200 bytes even on collisions, take over uniqueness here. Most sites skip this.
 *
 * add_filter( 'pre_wp_unique_post_slug', 'asg_unique_post_slug', 10, 6 );
 */

/* TRIPWIRE: verify + alert after every core update
 * This only detects and alerts: it restores the COLUMN, never bytes already
 * truncated. Treat any revert as an incident: restore from backup. */
add_action( 'upgrader_process_complete', function ( $upgrader, $extra ) {
    if ( isset( $extra['type'] ) && 'core' === $extra['type'] ) {
        delete_option( 'asg_schema_sig' );  // force a re-check on the next admin_init
    }
}, 10, 2 );

add_action( 'admin_init', function () {
    if ( get_option( 'asg_schema_sig' ) === ASG_SCHEMA_SIG ) {
        return;  // fast path: already verified since the last update
    }
    $reverted = asg_reverted_columns();
    if ( $reverted ) {
        $msg = '[Arabic Slug Schema Guard] Column(s) reverted: ' . implode( ', ', $reverted )
             . '. Long slugs were truncated: restore from backup and check 404 logs.';
        error_log( $msg );
        if ( defined( 'ASG_ALERT_EMAIL' ) ) {
            wp_mail( ASG_ALERT_EMAIL, 'WP slug schema reverted: ' . wp_parse_url( home_url(), PHP_URL_HOST ), $msg );
        }
        return;  // do NOT cache "ok" while broken
    }
    update_option( 'asg_schema_sig', ASG_SCHEMA_SIG, false );
} );

function asg_reverted_columns() {
    global $wpdb;
    $reverted = array();
    foreach ( array( array( $wpdb->posts, 'post_name' ), array( $wpdb->terms, 'slug' ) ) as list( $table, $column ) ) {
        $len = (int) $wpdb->get_var( $wpdb->prepare(
            "SELECT CHARACTER_MAXIMUM_LENGTH FROM information_schema.COLUMNS
              WHERE TABLE_SCHEMA = %s AND TABLE_NAME = %s AND COLUMN_NAME = %s",
            DB_NAME, $table, $column
        ) );
        if ( $len && $len < ASG_COLUMN_LEN ) {
            $reverted[] = "{$table}.{$column} (now {$len})";
        }
    }
    return $reverted;
}

/* WP-CLI: `wp asg verify` for cron-based monitoring */
if ( defined( 'WP_CLI' ) && WP_CLI ) {
    WP_CLI::add_command( 'asg verify', function () {
        foreach ( asg_reverted_columns() ?: array( 'ok' ) as $row ) {
            WP_CLI::log( 'ok' === $row ? 'Schema OK: both columns at VARCHAR(1024).' : "REVERTED: {$row}" );
        }
    } );
}

A postscript: the drift guard caught us

The argument above is that a fork of a core function drifts silently, so the guard matters more than the copy. That turned out to be true in the least comfortable way.

Versions 1.0.0 through 1.2.0 of the released plugin shipped a fork that was missing core's entire "strip these characters entirely" block, along with the × to x mapping. The consequence lands exactly on the readers this post is written for: Arabic guillemets (« ») and the LRM/RTL direction marks survived into slugs as %c2%ab, %c2%bb, %e2%80%8f. The character filter at the end cannot remove them, because %c2%ab is built entirely from permitted characters.

The drift guard printed above would have caught it on the first admin_init. Its second fixture is 'عاجل: تطورات «مهمة» اليوم'. It never fired, because the guard is bound to admin_init and nobody had opened wp-admin on an install running that fork. A guard on a hook that never fires is a comment.

Both are fixed in v1.3.0: the fork is re-synced (the block above is now complete and verified against core by an offline oracle on every build), and wp asg verify evaluates the drift oracle itself rather than waiting for an admin page load. If you lifted this code before July 2026, take the str_replace block above.

This is the kind of problem that never shows up in a tutorial. It lives where WordPress internals, MySQL's storage rules, Arabic character encoding and SEO all overlap, and it only reveals itself at the worst possible moment. It's also the territory we work in every day: keeping Arabic publishing fast, multilingual and unbreakable on WordPress, right through to AWS at scale.

If you run a WordPress publication in Arabic and want it to survive its own updates, let's talk.

Is Custom WordPress Theme Development Worth the Investment?

Mon, 21 Sep 2026 14:00:00 +0000

You picked a theme from a marketplace, installed it, and three months later your site loads in 6 seconds, your developer can’t find anything in the code, and every plugin update breaks something new. Sound familiar? That’s not bad luck. That’s what happens when a pre-built theme built for thousands of different use cases meets the specific, real-world demands of one business. The question of whether custom WordPress theme development is worth it isn’t really about budget. It’s about what you’re actually paying for when you choose the cheaper path.

What “Custom WordPress Theme Development” Actually Means

Before the cost conversation, we need to unpack this term because people use it loosely.

When you develop a custom WordPress theme, you build it from scratch (or from a minimal starter like Underscores or a block-based foundation) specifically for your site. It includes only the templates, styles, and functionality your project actually needs. Nothing more.

This is different from:

A child theme built on top of a parent theme like Astra or GeneratePress. You’re still inheriting the parent’s bloat.
A page builder site using Elementor or Divi. These create themes, but the output is typically CSS-heavy, JavaScript-heavy, and difficult to maintain at the code level.
A heavily customized premium theme. You’re modifying someone else’s architecture, which compounds over time.

True custom development means a developer or agency writes the PHP template hierarchy, registers only the hooks your design needs, and structures the codebase so future changes don’t require archaeology.

The Real Cost of Not Going Custom

Most businesses compare the upfront cost of a premium theme ($60) against a custom build ($5,000 to $25,000+) and assume the math is obvious. That comparison misses what actually accumulates on the cheap side.

Performance overhead: Premium themes ship with feature sets for every possible user. Sliders you don’t use, font loaders you didn’t ask for, multiple CSS frameworks layered on top of each other. A theme like Avada, popular and well-reviewed, regularly ships with 20+ JavaScript files and CSS that runs into hundreds of kilobytes before you add a single plugin. Google’s Core Web Vitals measure real user experience, and a slow LCP or high CLS score directly affects your search visibility.
Developer hours on unmaintainable code: When a customization request comes in (“just change how the header behaves on scroll”), a developer working inside a complex premium theme spends significant time mapping unfamiliar hooks, overriding deeply nested CSS specificity, and testing against plugin conflicts. That $60 theme can cost $150/hour in developer time every time you need something done.
Security surface area: A theme with 50,000 lines of code has a larger attack surface than one with 8,000. More code means more potential vulnerabilities, more third-party libraries to keep updated, and more places where something can go wrong. Custom builds let you control exactly what runs.
Lock-in to the theme author’s decisions: When a premium theme drops support, changes its update model, or gets acquired, you’re left holding a dependency you can’t fully control.

Where Custom WordPress Themes Genuinely Earn Their Cost

Performance That Doesn’t Require Constant Maintenance

A well-built custom theme serves exactly what the page needs, one CSS file. JavaScript loaded conditionally. No redundant markup. Sites built this way routinely achieve 90+ Lighthouse scores without the ongoing optimization tax of stripping back a bloated theme.

This matters more than ever with Google’s page experience signals. Fast sites rank better, convert better, and reduce bounce rates. That's a measurable ROI, not a theoretical benefit.

Full Alignment with Block Editor Architecture

WordPress’s Full Site Editing (FSE) and the block editor changed what “theme” means at a code level. A custom theme built for FSE uses theme.json to define design tokens, registers block patterns specific to your content types, and integrates cleanly with the Site Editor. Pre-built themes retrofitted for FSE often carry legacy PHP template conflicts alongside their block implementations, creating inconsistencies that surface in unexpected places.

Building custom for FSE means you’re working with WordPress’s direction, not fighting it.

Maintainability Over a 3 to 5 Year Lifecycle

A custom theme built with a clear template hierarchy and documented custom hooks is significantly easier to hand off to a new developer, update after a WordPress core release, or extend with new functionality. The upfront investment in clean architecture pays dividends every time the site evolves.

Brand Precision Without Compromise

Design systems built inside pre-built themes are always approximations. You’re working within someone else’s component structure, overriding their spacing assumptions, fighting their typography defaults. A custom theme implements your design system directly. Typography scales, color tokens, spacing units. All defined once, applied consistently, no override specificity wars.

When Custom Theme Development Is Not the Right Call

Honesty matters here. Custom development is not always the right answer.

For small businesses with modest budgets and standard needs, a well-chosen minimal theme like GeneratePress or Kadence, kept lean and paired with a limited plugin set, can perform well and stay manageable for years. The key is choosing themes with small codebases and staying disciplined about the scope of customization.

For sites that need to launch fast, a Minimum Viable Product on a solid premium theme, with a plan to migrate to custom later, can make business sense. Ship, validate, then invest.

For projects without ongoing development support, a custom theme without a developer who understands it becomes a liability. Custom code requires custom expertise.

The decision should follow the site’s trajectory, not just its current state.

What Drives the Cost of Custom WordPress Theme Development

Custom WordPress theme development costs vary widely and for good reason. Here’s what actually drives the number:

Design complexity: Are you working from an existing brand system or starting from scratch? Custom illustrations, micro-interactions, and complex layout variations add time.
Number of content types and templates: A site with 12 post types needs 12 well-structured templates. Each one is scoped and built individually.
Block editor depth: Custom block patterns, custom blocks registered via register_block_type, and theme.json configuration add scope.
Performance targets: Building for 90+ Lighthouse scores across devices requires additional QA and optimization passes.
Third-party integrations: CRMs, membership plugins, WooCommerce, LMS platforms. Each integration adds complexity at the theme level.

Ballpark ranges: a mid-tier custom theme without complex integrations typically runs $5,000 to $15,000. Enterprise-grade builds with full FSE implementation and custom blocks can exceed $30,000.

How to Evaluate If the Investment Makes Sense for Your Project

Run this through four filters before deciding:

Lifespan: If you expect the site to serve the business for 3 or more years with ongoing content and feature growth, custom pays off. If you’re testing a concept for 12 months, it likely doesn’t.
Traffic and conversion value: If 1,000 monthly visitors converting at 2% represents significant revenue, improving load time from 5 seconds to 1.5 seconds can have a direct financial impact. Calculate what a 20% conversion lift would mean.
Brand differentiation: If your site is a primary sales channel and competitive differentiation matters, looking like every other business using the same Elementor template costs you real money.
Developer relationship: Custom themes work best with ongoing developer access. If you have a trusted developer or agency relationship, the investment is lower-risk. If you’ll be maintaining it yourself with no technical background, the calculus changes.

Conclusion

Custom WordPress theme development is worth the investment when the site has real performance, branding, and longevity requirements, and when a developer relationship supports it over time. It's not universally the right answer, but the "premium theme is cheaper" argument consistently underestimates what that choice costs across the site's actual lifecycle. Among the most practical WordPress web development tips any developer will give you: measure the total cost of a decision, not just the upfront one.

The real question isn't what you spend upfront. It's what you spend in total, across three years of developer hours, performance optimization, and brand compromises, against what a purpose-built foundation would have cost at the start.

Frequently Asked Questions

Is custom WordPress theme development better than using a premium theme?

Custom WordPress theme development is better for sites with specific performance targets, unique design requirements, and long-term growth plans. Custom themes contain only the code your site needs, which means faster load times, cleaner architecture, and lower long-term maintenance costs. Premium themes are more practical for smaller budgets, faster launches, or simpler sites without complex customization needs.

How much does custom WordPress theme development cost?

Custom WordPress theme development typically costs between $5,000 and $30,000 or more, depending on design complexity, number of page templates, Full Site Editing requirements, and third-party integrations. Simpler builds with standard layouts and minimal custom blocks sit at the lower end. Enterprise projects with custom block libraries, WooCommerce integration, and performance optimization requirements sit at the higher end.

How long does it take to build a custom WordPress theme?

A standard custom WordPress theme takes 4 to 12 weeks to build, depending on scope. Design-heavy projects or those requiring custom Gutenberg blocks, complex template structures, or WooCommerce templates take longer. Discovery, design sign-off, and content readiness most often extend timelines.

Does a custom WordPress theme improve SEO?

Yes, a well-built custom WordPress theme can directly improve SEO by reducing page weight, improving Core Web Vitals scores (particularly LCP and CLS), and generating clean, semantic HTML. Google’s page experience signals use real performance data as ranking inputs. A custom theme also allows precise control over structured data implementation and heading hierarchy, both of which contribute to search visibility.

Can I update WordPress core safely with a custom theme?

Yes, custom themes built against WordPress’s standard template hierarchy and hook system are generally safe across WordPress core updates, because they don’t rely on a parent theme’s implementation or a page builder’s proprietary rendering layer. The best practice is to test updates on a staging environment first and avoid modifying WordPress core files directly, which a well-built custom theme never requires.

A Gutenberg block that uses the Interactivity API — with no render callback and no framework on the front end

Sun, 20 Sep 2026 05:18:15 +0000

A YouTube embed looks innocent enough.

You drop an iframe into a page, give it a src, and you're done, right?

Except you're not.

Google's Lighthouse documentation puts a full embedded YouTube player at around 540 KB. On a live page, it's closer to 1.3 MB. And the cost doesn't get amortized when you add another embed — two players can mean roughly twice the payload because the resources aren't shared.

HTTP Archive data referenced by web.dev puts another horrifying metric on it: the median YouTube embed occupies the browser's main thread for more than 1.7 seconds.

And here's the part that bothered me most: All of that happens even if nobody presses Play.

The Solution: The Facade Pattern

The fix isn't new. It's the facade pattern:

Show a poster.
Show a play button.
Don't load the actual player.
Only load it when the visitor clicks.

Tools like lite-youtube-embed have been doing this for years.

I wanted to bring this exact same concept into a WordPress Gutenberg block—but not just for YouTube, and definitely not by shipping an entire JavaScript framework to the browser just to replace a JPEG with an iframe.

That experiment became the Story Video Block (now live on the WP repo, source on GitHub).

Here are the most interesting architectural decisions and technical gotchas I ran into while building it.

The Interactivity Dilemma

The actual interaction needed for a facade is tiny. Click. Swap in the embed. Play the video. That's basically it.

But traditional block solutions can be surprisingly expensive for such a small interaction:

You could enqueue a classic view.js and manually handle event delegation and DOM manipulation.
You could ship React to the front end (some block plugins actually do this). You're essentially sending a UI framework to someone's phone so a poster image can turn into an iframe.
You could use jQuery (please don't).

Enter WordPress's Interactivity API ⚡

Since WordPress 6.5, we have the Interactivity API. It gives blocks a declarative way to add client-side behavior. More importantly, the runtime is shared by all blocks on the page.

The opt-in is incredibly simple in your block.json:

"editorScript": "file:./index.js",
"style": "file:./style-index.css",
"viewScriptModule": "file:./view.js"

Notice one detail: viewScriptModule, not viewScript.
That registers the file through the Script Modules API and allows you to natively import the shared WP runtime:

import { store } from '@wordpress/interactivity';

Revelation: You Don't Need a Dynamic Block

This was my biggest misconception. Because almost every Interactivity API tutorial uses a dynamic block (render.php), I assumed they were mandatory. They aren't.

The directives are just HTML attributes. A static block's save() function can output them, and the frontend runtime will hydrate whatever it finds.

Here's how my static save() looks:

const blockProps = useBlockProps.save( {
	className: clsx( {
		[ `has-media-${ videoPosition }` ]: videoPosition,
		[ `card-style-${ cardStyle }` ]: cardStyle,
	} ),
	style: {
		'--story-video-block-bg': backgroundColor || undefined,
	},
	...( ! isFile
		? {
				'data-wp-interactive': 'create-block/story-video-block',
				'data-wp-context': JSON.stringify( {
					isPlaying: false,
					embedUrl,
					videoSrc: '',
				} ),
		  }
		: {} ),
} );

That JSON.stringify() is the whole server-state story for this block! The markup lives in post_content. There's no PHP render callback running on every request, yet each block instance gets its own scoped, reactive state.

The Performance Trick: The `iframe` with no `src`

You cannot render an iframe and just CSS hide it. If it has a src, the browser will load the player. Hidden doesn't mean unloaded.

So, the iframe is deliberately rendered without a src.

<div
	className="story-video-block__video"
	hidden
	data-wp-bind--hidden="state.isNotPlaying"
>
	<iframe
		title={ heading || __( 'Video', 'story-video-block' ) }
		data-wp-bind--src="context.videoSrc"
		allow="autoplay; fullscreen; picture-in-picture"
		allowFullScreen
	/>
</div>

Initially, context.videoSrc === ''. Because WP's data-wp-bind--* removes an attribute when its value is falsy, there is no src attribute at all. No request, no player.

Bonus UX win: Because the source is assigned inside the click handler, the browser treats playback as user-initiated. That means autoplay=1 actually works. One click, video starts. No double-clicking required.

Progressive Enhancement: The facade is a link

I didn't make the facade a <div>. JavaScript shouldn't be the only way to reach the video.

The facade is a real <a> tag pointing to the original video:

<a
	href={ videoUrl }
	target="_blank"
	rel="noopener noreferrer"
	className="story-video-block__facade"
	data-wp-on--click="actions.play"
	data-wp-bind--hidden="state.isPlaying"
>

Our Interactivity store then enhances it:

import { store, getContext } from '@wordpress/interactivity';

store( 'create-block/story-video-block', {
	state: {
		get isPlaying() { return getContext().isPlaying; },
		get isNotPlaying() { return ! getContext().isPlaying; },
	},
	actions: {
		play( event ) {
			const context = getContext();
			if ( context.isPlaying ) return;

			// If no direct-embed URL (like TikTok), let the original <a> link work!
			if ( ! context.embedUrl ) return;

			event.preventDefault();
			context.videoSrc = context.embedUrl;
			context.isPlaying = true;
		},
	},
} );

This gives us graceful degradation:

JS + Supported provider (YouTube/Vimeo): Plays inline seamlessly.
JS + No direct embed (TikTok): Acts as a normal link.
No JS enabled: Acts as a normal link.

A CSS Gotcha That Cost Me an Evening

The Interactivity API was working. The hidden attribute was toggling perfectly in the DOM. But the elements were still visible on the screen. Why?

Browsers have a default user-agent style:

[hidden] { display: none; }

But if your block's custom CSS applies an explicit display (like display: flex;), it overrides the low-specificity [hidden] rule.

The fix:

[hidden] {
	display: none !important;
}

Pro-tip: If you're using data-wp-bind--hidden and nothing is happening visually, check your CSS specificity before ripping apart your JavaScript!

Why skip WordPress oEmbed on the frontend?

WordPress has robust oEmbed support. Why did I write manual regex provider detection for the frontend?

Because the /oembed/1.0/proxy endpoint requires edit_posts permissions. An anonymous site visitor gets a 401 Unauthorized.

Instead, the block parses the URL itself (supporting YouTube, Vimeo, Dailymotion, Twitch, mp4s, etc.) and constructs the embed URL string locally. Zero network requests just to figure out a URL we already know how to build.

Final Thoughts

Building this reminded me of a golden rule in web development: Don't make every visitor pay for a feature that only some visitors will use.

A video doesn't need to be a 1MB+ third-party application just because someone might press Play. A static Gutenberg block doesn't need to become dynamic just to hold state. And a tiny bit of interactivity doesn't require shipping a massive JS runtime.

If you're building blocks for WordPress, give the Interactivity API a shot for your next frontend component!

The Story Video Block is currently v0.1.0, requires WP 6.8+, and is GPL. If you want to check out the full code or contribute, PRs are welcome on GitHub!

How to Choose the Right WordPress Plugins for Your Website

Fri, 18 Sep 2026 14:18:48 +0000

Scroll through the WordPress plugin directory for more than five minutes and you'll hit the same wall every business owner hits eventually: dozens of plugins claiming to do the exact same thing, half with outdated reviews, and no clear way to tell which one will actually help your site instead of slowing it down or breaking something else. Pick the wrong plugin and you end up with a slower site, a security gap, or a conflict that takes hours to untangle. This guide covers how to actually evaluate plugins before installing them, so you stop guessing and start making choices that hold up over time.

Start With What You Actually Need, Not What Looks Useful

Before searching for a plugin, write down the specific problem you're solving. "I need customers to book appointments" is a real need. "This plugin looks cool" is not. Businesses end up with bloated, slow sites because they install plugins for features they'll never use, just because a plugin bundled them in. Match every plugin to a specific, current requirement, and if you can't name the requirement clearly, skip the plugin for now.

Check Update Frequency and Support Activity

Open the plugin's page in the directory and check the "Last updated" date first. A plugin that hasn't been updated in over a year is a risk, even if it currently works, because it likely isn't being tested against the newest WordPress core updates. Also check the support forum tab. If recent questions are going unanswered for weeks, that tells you how responsive the developer will be when something breaks on your site.

Read Reviews and Ratings Critically

Star ratings alone don't tell the full story. Read the actual one and two star reviews, since they usually reveal specific problems like conflicts with common themes, performance issues, or support that goes silent after a purchase. A plugin with a 4.5 star rating and thoughtful negative reviews explaining edge cases is often more trustworthy than one with a perfect score and almost no reviews at all.

Test Performance Impact Before Committing

Every plugin adds some amount of load time, database queries, or script loading to your site, and some add far more than others. Install the plugin on a staging site first, then run a speed test before and after using a tool like GTmetrix or Google PageSpeed Insights. If a plugin drops your load time significantly for a feature that isn't essential, that's a clear signal to look for a lighter alternative.

Avoid Plugin Overlap and Redundancy

Running two SEO plugins, two caching plugins, or two security plugins at the same time doesn't double your protection, it usually causes conflicts and unpredictable behavior. Before installing something new, check what your existing plugins already handle. Consolidating overlapping functionality into fewer, well-maintained plugins keeps your site faster and easier to troubleshoot when something does go wrong.

Verify Compatibility and Security Practices

Check that the plugin is compatible with your current WordPress version and your theme before installing it on a live site. According to WordPress.org's plugin developer guidelines, plugins in the official directory must meet baseline security and coding standards, which is one reason sticking to the official directory over random third-party downloads reduces your risk considerably. Avoid pirated or "nulled" premium plugins entirely, since these are a common source of injected malware.

When Off-the-Shelf Plugins Aren't Enough

Sometimes the plugin you need doesn't exist, or an existing plugin does 80% of what you want but needs adjustments to fit your workflow. In these cases, businesses often turn to professional WordPress plugin customization services rather than forcing a mismatched plugin to work through workarounds and extra tools. A developer can modify an existing plugin's functionality, build a small custom feature, or resolve a specific conflict without adding more bloat to the site than necessary.

Building a Habit Around Plugin Management

Choosing the right plugin isn't a one-time decision, it's an ongoing practice. Review your installed plugins every few months, remove anything you're no longer using, and check that everything still receives regular updates. Treating this as routine maintenance rather than a one-off task is one of the simplest WordPress web development tips that consistently keeps sites fast, secure, and easier to manage as they grow.

Bringing It All Together

Choosing WordPress plugins comes down to matching real needs to well-maintained, actively supported tools, then checking their performance impact and security track record before they touch a live site. Skipping this evaluation is how sites end up slow, cluttered, and vulnerable over time. Build a habit of reviewing what's installed, question anything overlapping or outdated, and bring in help when a plugin needs to do something it wasn't built for out of the box. A smaller, well-chosen plugin list will almost always outperform a large one.

Frequently Asked Questions

1. How many plugins is too many for a WordPress site?
There's no fixed number. What matters is whether each plugin is actively used, well maintained, and not duplicating another plugin's function. A well-optimized site can run 20 plugins fine, while a poorly chosen 10 can slow it down.

2. Are free WordPress plugins safe to use?
Yes, as long as they come from the official WordPress plugin directory and are updated regularly. Avoid free versions of premium plugins found on third-party sites, since these are frequently modified to include malware.

3. How do I know if a plugin is slowing down my site?
Run a speed test before and after installing a new plugin using a tool like GTmetrix or PageSpeed Insights. A noticeable drop in load time points directly to that plugin as the cause.

4. Should I choose a plugin based on price or features?
Neither alone. Choose based on whether it solves your specific need, has active support, and doesn't duplicate something you already have installed. Price and feature count matter less than reliability.

How to Protect WordPress with a Self-Hosted WAF

Fri, 18 Sep 2026 10:31:58 +0000

How to Protect WordPress with a Self-Hosted WAF

WordPress powers a huge share of the web and attracts a matching share of attacks: login brute force, plugin exploits, SQL injection through forms, and xmlrpc abuse. A self-hosted WAF placed in front of WordPress blocks the bulk of that traffic before it ever reaches PHP.

Why put a WAF in front of WordPress

Plugin-level security (like Wordfence) runs inside WordPress and understands WP internals. A stack-level WAF like SafeLine runs as a reverse proxy in front of the whole server, so it protects WordPress and anything else on the host — and it still works even if a plugin or theme is compromised.

Step 1 — Install SafeLine

On the host that will sit in front of WordPress:

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

SafeLine runs as a container and needs only modest resources (1 CPU, 1 GB RAM, 5 GB disk minimum).

Step 2 — Add WordPress as the upstream

Open the console at https://<safeline-ip>:9443 and add a protected site:

Upstream server — where WordPress actually listens, e.g. http://127.0.0.1:80 if SafeLine shares the host with the web server.
Domain — your WordPress domain, e.g. blog.example.com.
Port — the public port SafeLine listens on (80 / 443).

Then point your DNS (or firewall port) at the SafeLine host so visitor traffic reaches it first.

Step 3 — Turn on the WordPress-relevant protections

SafeLine's semantic engine already blocks SQL injection and XSS generically — that covers most WordPress form and admin attacks out of the box. Two extra levers are especially useful for WP:

Rate limiting on /wp-login.php and /xmlrpc.php to stop credential-stuffing and the classic xmlrpc pingback floods.
Bot challenge (CAPTCHA) for suspicious automated clients, so scrapers and bad bots get stopped without affecting real visitors or Google.

Step 4 — Watch the logs

The dashboard shows every request: allowed, blocked, and challenged. If a legitimate plugin endpoint trips a false positive, add a whitelist rule for that specific path rather than disabling protection globally.

SafeLine vs a WordPress security plugin

	SafeLine (stack-level)	WP plugin (in-app)
Protects WordPress	Yes	Yes
Protects other apps on host	Yes	No
Works if WP is compromised	Yes	Weaker
Free tier	Community Edition (10 apps, 800 QPS)	Limited

You can also run both — SafeLine at the proxy edge plus an in-app plugin is defense in depth.

FAQ

Will it break my plugins?

Generally no. SafeLine forwards normal traffic untouched; only requests that look like attacks are blocked. Tune per-path if needed.

Do I still need to update WordPress?

Yes — a WAF reduces attack surface but isn't a substitute for patching core, themes, and plugins.

Can I protect multiple WP sites with one instance?

Yes — the free Community Edition covers up to 10 apps, so several WordPress installs behind one SafeLine is fine.

Does it affect SEO crawlers?

Real search-engine bots pass through normally; only abusive automated traffic is challenged.

That's it — your WordPress site now has a self-hosted WAF filtering traffic before PHP ever runs.

⭐ SafeLine WAF on GitHub — give it a star if you find it useful
🔗 Official Docs — installation guide, configuration, and API reference
🧪 Live Demo — see the dashboard in action (no login required)

Deploy it in minutes:

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

How to Secure a WordPress Website: A Complete Guide for Businesses

Thu, 17 Sep 2026 09:51:44 +0000

WordPress powers over 40% of all websites, and that popularity makes it the single most targeted content management system on the internet, yet most business owners only think about security after their site gets hacked, their rankings vanish overnight, or Google slaps a "This site may be hacked" warning right next to their business name in search results. If you're responsible for keeping a business site running, you already know the sinking feeling of an unexpected error, a strange redirect, or a client email asking why their homepage now sells discount sunglasses. This guide skips the fear-mongering and gets straight into what actually secures a WordPress site, based on fixes that hold up in the real world, not just checklist advice you've read a dozen times before, and it explains why most breaches trace back to hosting, plugins, or user habits, not WordPress itself, a distinction that changes everything about how you should approach protecting your site.

The Fastest Way to Improve Security: Fix What's Already Outdated

Before touching plugins or firewalls, check what's out of date. Outdated WordPress core files, themes, and plugins are the leading cause of hacked sites, because attackers scan the web for known vulnerabilities in old versions and exploit them automatically at scale. Log into your dashboard, go to Updates, and clear every pending update for core, themes, and plugins. Do this weekly, not "whenever you remember." If a plugin hasn't been updated by its developer in over a year, treat that as a warning sign and look for an actively maintained replacement, even if the old one still technically works. This kind of ongoing maintenance is exactly why security has to be baked into good WordPress web development practices from day one, not bolted on after a launch.

Choose Hosting That Takes Security Seriously

Your hosting provider is your first line of defense, and it matters more than most business owners realize. Shared hosting environments with poor server-level isolation let one compromised site on the same server spread malware to neighboring accounts, including yours. Look for hosts that offer automatic malware scanning, server-level firewalls, isolated environments, and free SSL certificates as standard. Managed WordPress hosting providers typically bake these protections in by default, which is worth the extra cost if your site handles customer data, payments, or lead forms.

Lock Down Logins Before Anything Else

Weak login credentials remain one of the easiest ways attackers get in, mainly through brute force attacks that guess usernames and passwords repeatedly until one works. Fix this in three steps:

Never use "admin" as a username. Create a unique username for every
account with access.
Enforce strong, unique passwords for every user, ideally generated
and stored in a password manager rather than something memorable.
Turn on two-factor authentication for all admin-level accounts, so a
stolen password alone isn't enough to get in.

Limiting login attempts is also worth setting up, since it locks out an IP address after a set number of failed tries, which stops automated bots cold.

Install a Security Plugin That Actually Does Something

A good security plugin handles the monitoring you don't have time to do manually: file change detection, malware scanning, firewall rules, and login attempt logging. Wordfence, Sucuri, and iThemes Security are widely used because they cover these basics without needing constant manual configuration. Install one, run the initial scan, and actually read the results instead of dismissing the notification. A plugin only helps if someone is paying attention to what it flags. According to WordPress.org's own security whitepaper, the platform's core code is rigorously audited, which is one more reason most breaches trace back to hosting, plugins, or user habits rather than WordPress itself.

Keep Backups That You've Actually Tested

Backups are the difference between a stressful afternoon and a business-ending event. Set up automated daily backups stored off-site, away from your hosting server, so a compromised server can't also wipe out your only copy of the backup. More importantly, test the restore process at least once. A backup you've never restored from is a backup you don't actually know works.

Reduce the Number of Ways In

Every plugin, theme, and user account is a potential entry point. Delete plugins and themes you're not using, even if they're deactivated, since inactive files sitting on your server can still be exploited. Review user roles regularly and remove access for anyone who no longer needs it, especially former employees or freelancers who worked on a one-off project. The smaller your site's footprint, the smaller the target.

Use SSL and Keep File Permissions Tight

An SSL certificate encrypts data moving between your site and your visitors, which protects login credentials, form submissions, and payment details from interception. Most hosts now offer this for free, so there's no reason to skip it. Alongside SSL, check your file and folder permissions. Files should generally be set to 644 and folders to 755, which allows the site to function without giving unnecessary write access that attackers could exploit if they got a foothold.

Monitor Activity, Don't Just React to It

Security isn't a one-time setup, it's an ongoing habit. Activity logs that track logins, plugin changes, and content edits let you catch suspicious behavior early, often before it becomes a full breach. If you're not checking these logs at least monthly, you're relying purely on luck to catch problems before they escalate. If none of this fits into your team's schedule, working with WordPress security consultants for businesses is a reasonable next step, since dedicated monitoring is often what separates a caught intrusion from a full-blown breach.

Bringing It All Together

Securing a WordPress website isn't about installing one plugin and forgetting it. It's a layered approach: current software, solid hosting, strong login practices, tested backups, and regular monitoring, all working together so that if one layer fails, the others still hold. Businesses that treat this as an ongoing habit rather than a one-time task rarely deal with the kind of breach that costs real money, real rankings, and real customer trust. Build these habits into your maintenance routine now, and you won't be scrambling to explain a hacked site to a client or a customer later.

Frequently Asked Questions

1. Is WordPress actually safe to use for a business website?
Yes. WordPress's core software is well audited and secure. Most hacks happen because of outdated plugins, weak passwords, or poor hosting, not flaws in WordPress itself.

2. How often should I update WordPress plugins and themes?
Check for updates weekly. If a plugin shows a security patch, apply it immediately rather than waiting for your usual update schedule.

3. Do I really need a security plugin if my host already offers protection?
Yes, use both. Hosting-level security protects the server, while a plugin like Wordfence or Sucuri monitors activity happening inside your specific WordPress installation.

4. What's the first thing to do if my WordPress site gets hacked?
Take the site offline or put it in maintenance mode, restore from your most recent clean backup, then change every password and API key before bringing it back online.

Design + Code + SEO: The 3 Skills That Turn a Website Into a Real Business Asset

Thu, 17 Sep 2026 09:01:50 +0000

A beautiful website is not automatically a successful website.

A technically perfect website is not automatically a successful website.

And ranking on Google is not enough if visitors arrive on your website and immediately leave.

In today’s digital world, successful websites are built where design, development, and SEO work together.

As a Graphic Designer, Web Developer, and SEO professional, I’ve learned an important lesson:

The best digital experiences happen when creativity, technology, and search strategy are connected from the beginning—not added one at a time at the end.

Let’s break down why these three areas matter and how they can work together.

1. GRAPHIC DESIGN: FIRST IMPRESSIONS MATTER

Before people read your content, they see your design.

They notice your colors.

They notice your typography.

They notice your logo.

They notice your spacing, images, buttons, icons, and overall visual structure.

Within seconds, a visitor starts forming an opinion about your brand.

Good graphic design isn't simply about making something "look beautiful."

It is about communication.

A strong design should answer questions such as:

Who is this brand?
What does this business offer?
What should the visitor look at first?
What action should the visitor take?
Does the brand feel trustworthy?

For example, imagine two websites selling the same service.

Website A has attractive graphics but confusing navigation.

Website B has simple graphics, clear hierarchy, readable typography, consistent branding, and obvious calls-to-action.

Even if Website A looks more artistic, Website B may provide a better user experience.

That is the difference between decoration and communication.

Great design should guide the visitor instead of distracting them.

2. WEB DEVELOPMENT: TURNING IDEAS INTO EXPERIENCE

Design creates the visual direction.

Web development turns that direction into an interactive experience.

A modern website needs much more than HTML and CSS.

Depending on the project, developers may work with:

• HTML
• CSS
• JavaScript
• Python
• Django
• PHP
• WordPress
• APIs
• Databases
• Responsive layouts
• Authentication systems
• Performance optimization
• Security

But technology itself isn't the final goal.

The goal is to create a website that works.

A website should load efficiently.

It should work on smartphones.

It should have logical navigation.

Forms should function correctly.

Buttons should behave as expected.

Content should be easy to access.

And users shouldn't have to fight with the interface to accomplish a simple task.

This is especially important because many users will experience a website from a mobile device rather than a desktop computer.

A website can have an incredible visual design, but if it loads slowly or becomes difficult to use on mobile, the design loses much of its value.

That's why design and development should communicate with each other throughout the project.

3. SEO: HELPING THE RIGHT PEOPLE FIND YOU

Now comes the third piece of the puzzle.

You can have an amazing design.

You can build a powerful website.

But what happens if nobody can discover it?

This is where SEO becomes important.

Search Engine Optimization is not simply about adding keywords to a page.

Modern SEO involves multiple areas, including:

🔹 Keyword research
🔹 Search intent
🔹 On-page SEO
🔹 Technical SEO
🔹 Internal linking
🔹 Content structure
🔹 Metadata
🔹 Image optimization
🔹 Website performance
🔹 Mobile usability
🔹 Structured data
🔹 Content quality
🔹 Authority and backlinks

One of the biggest mistakes businesses make is thinking about SEO after their website has already been built.

SEO should influence the website architecture from the beginning.

For example, keyword research can help determine:

What pages should exist?

How should those pages be organized?

What topics should the website cover?

What questions are potential customers asking?

What content should be placed on important landing pages?

What terms describe the services customers are actually searching for?

This means SEO isn't just a marketing activity.

It can influence website structure, content strategy, and user experience.

4. WHERE DESIGN, DEVELOPMENT & SEO MEET

This is where things become interesting.

Imagine building a website as constructing a modern store.

Graphic Design = How the store looks and how customers move through it.

Web Development = The structure, systems, doors, lights, security, and functionality.

SEO = The signs, location information, and digital directions that help people find the store.

You need all three.

If the store looks great but nobody can find it, that's a problem.

If people can find it but the store is difficult to navigate, that's a problem.

If the store works perfectly but looks untrustworthy, customers may hesitate.

The same principle applies to websites.

5. USER EXPERIENCE SHOULD BE THE COMMON LANGUAGE

Graphic designers, developers, and SEO professionals sometimes focus on different goals.

Designers may think about visual consistency.

Developers may think about functionality and performance.

SEO professionals may think about search visibility.

But the user experiences all three simultaneously.

The visitor doesn't care which team created which part.

They simply experience the website.

That's why one of the most valuable questions during a project is:

"What does the user need?"

Not:

"What looks impressive?"

Not:

"What technology can we use?"

Not:

"What keyword can we rank for?"

But:

"What will make this experience easier, clearer, faster, and more useful for the user?"

That question can improve almost every digital project.

6. SPEED IS PART OF THE EXPERIENCE

A beautiful website that takes too long to load can lose visitors.

Large images can increase page weight.

Unnecessary scripts can slow down pages.

Poor hosting can affect response time.

Unoptimized code can create performance problems.

That's why designers and developers need to work together.

Graphic designers can prepare appropriately optimized assets.

Developers can implement efficient code.

SEO professionals can identify technical and usability issues that may affect search visibility and user experience.

Performance is therefore not only a developer's responsibility.

It can be a team responsibility.

7. AI IS CHANGING THE WORKFLOW — BUT NOT THE FUNDAMENTALS

Artificial intelligence is changing how designers, developers, marketers, and SEO professionals work.

AI can help with:

• Brainstorming
• Research
• Content ideas
• Code assistance
• Image concepts
• Data analysis
• Keyword clustering
• Workflow automation
• Repetitive tasks

But tools don't replace fundamentals.

A person still needs to understand:

Why is this design effective?

Why does this code work?

Why would a user search for this topic?

Why would someone trust this website?

The professionals who benefit most from AI will likely be those who understand the fundamentals and use AI as a productivity tool rather than treating it as a substitute for thinking.

8. THE FUTURE BELONGS TO CROSS-DISCIPLINARY PROFESSIONALS

The boundaries between different digital professions are becoming increasingly connected.

A designer who understands UX can communicate better with developers.

A developer who understands SEO can build more search-friendly websites.

An SEO professional who understands design can create better content experiences.

A marketer who understands analytics can make better decisions.

You don't necessarily need to become an expert in every field.

But understanding how the fields connect can make you much more effective.

This is why I believe the future digital professional isn't simply someone who knows one tool.

It's someone who understands how different skills combine to solve a real business problem.

9. A SIMPLE FRAMEWORK FOR BETTER DIGITAL PROJECTS

Before starting a website or digital campaign, ask these questions:

STEP 1 — DESIGN

What should the user see and understand first?

STEP 2 — DEVELOPMENT

How can we make the experience fast, accessible, responsive, and functional?

STEP 3 — SEO

How will people discover the website through search?

STEP 4 — CONTENT

Does the content actually answer the user's question?

STEP 5 — ANALYTICS

How will we measure whether the website is achieving its goals?

STEP 6 — IMPROVEMENT

What can we learn from user behavior and continuously improve?

This creates a much stronger process than simply launching a website and hoping it succeeds.

10. MY BIGGEST TAKEAWAY

A website shouldn't exist just because a business "needs a website."

It should have a purpose.

Maybe the purpose is generating leads.

Maybe it's selling products.

Maybe it's building a personal brand.

Maybe it's providing information.

Maybe it's creating an online community.

Whatever the objective is, the design, development, SEO, and content strategy should support that objective.

Beautiful design gets attention.

Good development creates a usable experience.

Strong SEO creates discoverability.

Useful content creates value.

Analytics creates understanding.

And continuous improvement creates long-term growth.

FINAL THOUGHT

The digital world doesn't need more websites simply built to exist.

It needs websites that solve problems.

It needs designs that communicate.

It needs technology that works.

It needs content that helps people.

It needs SEO that connects businesses with genuine search intent.

And most importantly, it needs professionals who can think beyond their individual job titles.

Graphic Design + Web Development + SEO isn't just a combination of skills.

When used strategically, it becomes a way of thinking about the complete digital experience.

That is the direction I continue to explore: creative design, practical development, search visibility, and measurable digital growth working together.

What do you think is the most important factor for a successful website today: Design, Development, SEO, Content, or User Experience?

I'd love to hear your perspective in the comments.