So this time I built another one the same way, and before I touched a single line myself, I ran WordPress.org’s own security scanner against it. Then I went further, because a warning list isn’t proof of anything: I tried to actually break the thing.

Here’s the short version: the official tool found 21 issues. Two rounds of fixes took that to zero.

And the one bug I could actually exploit for real was never on that list at all.

What You Need

Everything here is free and runs on your own machine.

• A terminal-based AI coding assistant — I used Claude Code, but the method works with any of them
• A local WordPress install — Docker, LocalWP, whatever you already use
• WordPress Plugin Check — WordPress.org’s own scanner, install it like any plugin: wp plugin install plugin-check --activate
• About fifteen minutes, which I’ll come back to

The plugin, and why I picked this one

I asked the assistant for a “Was this helpful?” widget: Yes/No buttons under a post, votes stored in the database, a summary on an admin page. Nothing exotic.

I picked it on purpose. It touches every place a beginner plugin usually gets hurt: an AJAX endpoint anyone can hit without logging in, a database table the plugin owns, an admin page only the site owner should see, and a settings form an admin can change. Four different attack surfaces in maybe eighty lines of real logic — dense enough to be worth checking, small enough to actually finish checking in one sitting.

Compare that to what most “build a plugin with AI” tutorials show you: a shortcode that prints some text, or a widget that reads an option. Those genuinely have nothing to attack. This one does, and that’s exactly why it’s the more honest test.

The prompt I actually used had no security words in it anywhere — no “secure,” no “sanitize,” no “nonce.” Just what I wanted it to do. That’s the point: I wanted the default, not the graded version.

One honest caveat before anything else: the assistant that wrote this plugin is the same tool I use every day, tested by an isolated instance that had no idea an audit was coming. I’m not claiming a blind test — I’m claiming a single-blind one, and I’d rather tell you that than pretend otherwise.

AI generated WordPress plugin security: what Plugin Check actually said

I ran wp plugin check — WordPress Plugin Check, the tool WordPress.org uses to review real plugin submissions — against the first thing the assistant handed back.

21 findings: 2 errors, 19 warnings. And here’s the part that actually surprised me: zero nonce problems, zero missing capability checks, zero unescaped output. The code checked its nonce. It called wp_unslash() before sanitizing input, which is the exact mistake I’ve personally shipped before. It gated both admin pages behind current_user_can('manage_options').

What Plugin Check actually flagged was almost entirely one pattern, repeated: SQL built with {$table} and {$column} dropped straight into the query string instead of going through $wpdb->prepare() properly, plus a missing readme file and an outdated plugin header. Real findings — just not the ones I expected.

Which of those findings can actually hurt you?

This is the part nobody else checks. A tool telling you something is unsafe and something actually being unsafe are two different claims, and only one of them is provable.

So I logged in as a real WordPress user, grabbed a live nonce off the actual page, and fired six real requests at the running plugin — the same way an attacker, or just a careless script, would. Not curl commands typed by hand and eyeballed — a script that checks what actually landed in the database afterward, because a request that returns a friendly JSON response and a request that actually stored something are not the same event. I’ve been burned by that gap before: a tool I built once looked like it was working in every test, right up until someone checked whether the database row it claimed to write was actually there.

• No nonce at all. Rejected. The check held.
• A script tag as the vote value, trying for stored XSS. Rejected — the vote only ever accepts “yes” or “no,” so there was nothing to inject into.
• 1 OR 1=1 as the post ID, going for SQL injection. Rejected — absint() turned it into a plain integer before it ever reached the query.
• A Subscriber account with a genuinely valid session, trying the admin page directly. Blocked. A valid login proves who you are, not what you’re allowed to do — and the capability check actually enforced that.
• A quoted value, testing whether wp_unslash() was handled correctly. It was.

Five attacks, five failures. Plugin Check’s flagged SQL pattern — the raw {$table} interpolation — turned out to be exactly what it looked like: untidy, not exploitable. Every value going into those queries was already a validated integer or one of two hardcoded strings before the SQL ever ran.

One attack worked, and it wasn’t on Plugin Check’s list, or PHPCS’s, or PHPStan’s.

The comparison table

Fourteen is the honest number, not the raw one — Plugin Check and PHPCS flagged the same eight lines, just twice each, once per tool. I checked file-and-line for overlap rather than just adding the totals, because reporting 38 would have been a real number technically, and a misleading one in practice.

Does a nonce make my AJAX endpoint safe?

No — and this plugin proves both halves of that sentence.

The nonce genuinely stopped forged requests. What it doesn’t stop is the same valid request, repeated.

I wrote a tiny script that pulled a real nonce off the page and voted “Yes” twenty times in a row. The database accepted every single one — the count went from 1 to 21. The only thing standing between a visitor and unlimited votes was a note in the browser’s local storage, which a script simply doesn’t have.

That’s not a nonce failure. It’s a missing-rate-limit failure, and it’s invisible to every tool I ran, because none of them ask “what happens if this exact request runs a thousand times?”

How long does it take to get it actually clean?

I fed Plugin Check’s own output straight back to a fresh assistant session — the real 21-line report, not my summary of it — and asked it to fix every finding.

Round one: 21 → 2. It rewrote every SQL call to use WordPress 6.2’s %i placeholder correctly, added real object caching, and wrote a readme file that hadn’t existed. That readme immediately introduced two new findings of its own — an outdated “tested up to” version and a description that ran over the character limit.

Round two: 2 → 0, fixing exactly those two lines.

Two rounds. Roughly nine minutes total, timed for real rather than guessed at. And the vote-stuffing bug was still sitting there afterward, completely untouched — because getting Plugin Check to say “no errors found” was never the same question as “is this actually safe.”

Common Mistakes

Trusting “it works” as your only test. My own plugin from last year still has no security section written about it anywhere. It works. That was never the same claim as safe.

Auditing AI code with the same AI that wrote it. Asking the assistant to grade its own homework tells you what it believes about its own work, not what’s actually true. Use the tool the WordPress plugin reviewers actually use.

Treating a clean linter run as the finish line. Twenty-one violations really did go to zero. The one exploitable bug was never touched by that process, at any point, because static analysis reads code — it doesn’t run it against the questions that actually matter, like “what if someone sends this exact same request 500 times?”

Skipping wp_unslash() before sanitizing input. I’ve personally shipped this exact bug before. This plugin got it right on the first attempt, which is worth noticing precisely because it’s the mistake that’s easiest to make and hardest to catch by reading.

FAQ

Is AI generated code secure? WordPress builders keep assuming yes.
This one held against five of six real attacks — no nonce, XSS, SQL injection, missing capability checks. It did have one real gap: unlimited vote stuffing. Test your own before you trust “it works.”

What does Plugin Check actually test?
Coding standards, security patterns like unescaped output and unprepared SQL, and WordPress.org submission requirements. It’s static analysis — it reads your code, it doesn’t run it against real requests.

Does a valid nonce mean a request is safe?
It means the request came from an active session on your site. It says nothing about what that account is allowed to do, and nothing about how many times the exact same valid request gets repeated.

How long does it really take to build WordPress plugin with AI?
About four minutes to a working install, about nine to a Plugin-Check-clean one — both timed, not estimated. Getting to actually secure took a sixth check no automated tool ran.

Can I run these checks on my own plugin?
Yes — that’s the actual point of this piece. wp plugin check <your-plugin> costs nothing and takes under a minute. Every script and prompt behind this piece is published; run them against your own plugin and see what comes back.

What’s the actual fix for the vote-stuffing bug?
Track votes server-side per visitor instead of trusting the browser. A signed cookie, an IP-plus-post-ID row in the votes table, or a rate limit on the AJAX action itself would all close it. I haven’t shipped that fix here on purpose — the point of this piece is what the audit found, not a finished, hardened plugin.

So what do you actually do with this?

Run Plugin Check on whatever AI-generated code is already live on your site. It’s free, it’s the same tool plugin reviewers use, and it takes less time than reading this post.

Then go further than the tool does. Ask what happens if a valid request gets repeated. Ask whether a valid login actually proves permission, not just identity.

Those are the questions that catch what static analysis structurally can’t — because they’re about behavior, not patterns in the source.

Twenty-one violations reaching zero is a real, checkable win. It just isn’t the same win as “this plugin is secure.” Only one of those two claims was true here, and the tool that would have told you which one never got asked the question.

If you haven’t built your first AI-generated plugin yet, start here — then come back and run this checklist on it.

The post AI Generated WordPress Plugin Security, Tested for Real appeared first on The Beginner’s Playbook for Fixing WordPress Errors.

What I found was a table. One top-ranking guide publishes time-to-first-byte figures — 200 to 800 milliseconds for WordPress, 20 to 100 for static — and never says what hardware it ran on, what page it requested, what tool it used, or how many times it tried.

That is a range wide enough to be right no matter what happens — and Google’s AI summary already repeats those numbers back to me as fact.

So I stopped reading and built all three stacks on one machine at home, measured them with scripts I’m publishing, and got an answer that surprised me.

The short version: static beat WordPress by 96×. Then I turned caching on, and the gap collapsed to 0.08 milliseconds.

What You Need

Everything runs on one Linux machine with Docker. No cloud account, no card, nothing to sign up for.

• Docker and Docker Compose — the whole lab is containers
• WordPress 6.5, MariaDB 11, nginx 1.27 — official images
• Hugo 0.128.0 (extended) — for the build-time test
• wrk and wget — load generator and export tool
• About an hour, most of it waiting

Mine ran in a throwaway container on an Ubuntu Optiplex in my house — which is why I’m careful below about which numbers I’ll stand behind.

The setup: four doors into one WordPress site

Benchmark WordPress on one machine and a static site on another, with different themes and different content, and you haven’t compared platforms — you’ve compared two different websites. That’s why most of these numbers don’t mean much.

So I ran one WordPress install with 200 identical posts, behind four nginx server blocks:

For WordPress vs static HTML to mean anything, both sides need the same HTML — so the static side is a wget mirror of the WordPress site, not a separately-built Hugo one. That’s deliberate: it makes the HTML byte-identical.

A, B and A′ returned the same md5. C differed by 165 bytes — wget rewriting absolute URLs to relative ones, and nothing else.

So any speed difference belongs to the serving path. Not the theme, not the content, not the page size.

The control that makes the rest trustworthy

A′ is the important one, and no comparison I read had anything like it.

It’s the same stack as A, same PHP-FPM pool, identical config. It is A. If my measurements are any good the two must come out the same — and if they don’t, my machine is too noisy and every other number here is garbage.

I ran it first, 160 rounds, alternating which went first:

A  median TTFB   33.6958 ms
A' median TTFB   33.6912 ms
ratio            0.9999   (drift 0.01%)
gap              0.0047 ms   against an IQR of 0.75 ms

The two identical stacks landed 0.01% apart — under one percent of the ordinary jitter. That’s the receipt that lets me report everything else.

This is the check to demand from anyone showing you a benchmark. If they can’t tell two identical things apart, they can’t tell two different things apart either.

WordPress vs static site: is static actually faster?

Every static site vs WordPress speed claim you have read starts here, and this part is true: enormously faster — against WordPress with no caching.

I hit each stack 185 times, rotating the order every round so a busy moment on my machine couldn’t land on one stack and stay there.

Ninety-six times. That’s the number that sells the switch, and it’s real. It’s also the wrong comparison.

What happens when WordPress is properly cached

Look at the middle row again. Cached WordPress is 78× faster than uncached WordPress — and it’s the same WordPress. Same plugins, same theme, same database.

The only change is nginx keeping the finished HTML and handing it out instead of waking PHP.

Which puts static at 1.23× faster than cached WordPress. Not 96×. Not 10×.

In absolute terms that’s 0.082 milliseconds.

What does 0.082ms mean in practice? It is three orders of magnitude smaller than the time a packet takes to reach your server and come back. It vanishes into the noise of the internet before the page starts rendering.

Every guide comparing static to WordPress compares it to the uncached configuration. Nobody runs an uncached WordPress site on purpose.

Does it hold up when people arrive at once?

One visitor at a time is the easy case. I pushed 1, 10 and 50 concurrent connections at each stack, three runs each.

Uncached WordPress hits a wall at about 130 requests per second and stays there — PHP-FPM’s default of five worker processes. Five requests at a time, no matter how many people show up.

Cached WordPress and static both keep climbing, and stay within about 16% of each other all the way up. Zero failed responses anywhere, on any stack.

The honest headline isn’t “static is faster than WordPress”. It’s that caching is faster than not caching, by 78× — and static adds a rounding error on top.

The comparison table

Everything I measured, in one place:

Two rows deserve a second look, because they’re the ones that actually decide this.

Memory is where static wins properly. WordPress needs MariaDB, PHP-FPM and nginx — 463.9 MiB with traffic on it. Static needs nginx alone: 38.6 MiB.

That’s 12× less memory and 6× less disk, and unlike the speed difference it isn’t a rounding error. It’s the gap between DigitalOcean’s $4/month 512 MB droplet and the $6/month 1 GB one — a real, if modest, $24 a year.

And that “8 of 16” row is not static being lighter. I’ll get to it.

Does publishing get slower as your blog grows?

This is the static site generator vs WordPress question I actually wanted answered, and the one nobody measures. The only person I found writing about it was a developer in 2021 whose workflow fell apart as his archive grew — a good post, with no numbers in it.

So I measured the cost of publishing one more post at three archive sizes.

Both camps are a little wrong.

Static defenders are wrong that build time is nothing. Multiply the archive by 100 and the rebuild takes 7.4× longer. That curve is real and keeps going.

The 2021 post is wrong that it falls apart. At a thousand posts, a full rebuild takes 296 milliseconds. A third of a second. If you publish weekly, you will not notice this in your lifetime.

WordPress stays flat — 33 ms at a thousand posts, statistically identical to 35 ms at ten — because publishing is one database insert regardless of how much you’ve already written.

So the authoring-loop objection is directionally true and practically irrelevant at blog scale. Revisit it at 50,000 pages; under a few thousand it’s a non-issue.

What actually breaks when you go static

Here’s where the piece changed my mind.

I put the three things a normal blog has onto the WordPress site — a contact form, site search, comments — exported it the way someone without a paid plugin would, with wget, then tried every feature against the export.

Five of six were broken.

Search made me sit up. On the export, /?s=fixture returns HTTP 200 — not a 404, a completely normal successful response. A static server has no idea what ?s= means, so it ignores it and hands back the homepage.

My first version of this test checked status codes only, and told me “site search: still works.” It does not. I had to compare the page bodies to catch it — and if I’d trusted the status code, I’d have published the opposite of the truth.

And the contact page is worse, because it looks completely fine:

That’s the exported site. Name, email, subject, message, Submit — and a visitor who fills it in, hits the button, and 404s into nothing.

You don’t get an error report, because nothing looks broken. You just stop hearing from people.

This also explains the “8 of 16 assets” row above. The static page isn’t 90KB lighter because it’s leaner — it’s lighter because six files it asks for aren’t there, including the block-navigation CSS and JavaScript.

Common Mistakes

Benchmarking WordPress with caching off. This is the big one. Every “static is 10× faster” claim I could find compares against a configuration nobody deploys. Turn on page caching and you recover 78× of the 96×.

Trusting a static site vs WordPress speed table with no method attached. If it won’t tell you the hardware, the tool, the page and the number of runs — and shows no spread around its figures — it’s a guess with decimal points.

Costing the hosting but not the workflow. The $2/month you save is real. So is the afternoon spent rebuilding your contact form on a third-party service, and every future post going through a build step instead of a Publish button.

Assuming an export keeps things working. It doesn’t, and it fails quietly. Go static deliberately — pick a forms service, pick a search service (or drop search), pick a comments host. Don’t export a dynamic site and hope.

What I’m not claiming

My lab was a container on a home Optiplex that also runs my other work. That is not clean benchmark hardware and I won’t pretend otherwise.

So I claim the ratios between stacks, not the absolute milliseconds. Every stack was measured in the same rounds, in rotating order, minutes apart, and the null control resolved identical stacks to 0.01%.

Under those conditions “static is 1.23× cached WordPress” is solid. “Static serves in 0.35ms” is true of my box and nothing else.

I’m also not claiming anything about SEO — everyone asserts static ranks better, and I can’t test it in an afternoon. I didn’t test managed WordPress hosting or Netlify’s free tier either. Different question, different piece.

FAQ

Is a static site faster than WordPress?
On WordPress vs static HTML, against uncached WordPress, yes — 96× on my measurements. Against WordPress with nginx page caching, 1.23×, which is 0.08 milliseconds. On a real connection that difference is invisible.

Is a static site worth it for a blog I update weekly?
For speed alone, no — caching gets you within a rounding error. For a lower bill and less to maintain, maybe: 12× less memory and no database to patch.

Will my contact form work after converting to static?
No. Mine returned 404 while still displaying a perfectly normal form. If you go static you need a forms service, and you need to know that before you migrate, not after.

Can I keep WordPress and get static speed?
Largely, yes — that’s the finding. Full-page caching took the same WordPress install from 33.70 ms to 0.432 ms without changing a single plugin or theme file. It’s the cheapest performance work available to you.

How much does each one actually cost to host?
Static fits DigitalOcean’s $4/month 512 MB droplet; WordPress needs the $6/month 1 GB tier at minimum. Around $24 a year, before you count your own time.

What about search on a static site?
Site search stops working and does it silently — HTTP 200, homepage returned. You’d need a client-side index or a hosted search service.

So which should you build?

Here’s the rule I’d give a friend, and it isn’t the one I expected to write.

If your site has forms, comments, search, or anything a visitor submits — stay on WordPress and turn on full-page caching. That one change bought 78× on my measurements.

You keep everything that works, and the remaining gap is a fraction of a millisecond nobody will perceive.

Reach for a static site generator vs WordPress only when your site genuinely has nothing dynamic in it — a portfolio, documentation, a landing page, an archive that only you update. Then you get real wins: 12× less memory, a cheaper box, no database to keep patched, and nothing to break at 3am.

What should not decide it is a speed table with no method behind it. The 96× is real and it’s measuring the wrong thing.

If you take one thing from this: go and turn caching on. It’s free, it takes an afternoon, and it’s most of the benefit people switch platforms for. You might try it before you rebuild anything.

Every script and raw measurement behind this post is published — the null control, the timing harness, the export probes, all of it.

Run them on your own box and tell me if you get something different. I’d genuinely like to know.

Related: How I Connected WordPress to Claude AI With an MCP Server

The post WordPress vs Static Site: I Measured Both, Here’s the Truth appeared first on The Beginner’s Playbook for Fixing WordPress Errors.

Quick Answer: I built a small FastAPI email verification API — it checks every email against four things: valid syntax, a disposable-domain blocklist, role-based prefixes like info@ or admin@, and a live DNS MX record lookup, before anything is trusted. It’s live on my own tools API today, and you can build your own copy in about 10 minutes.

What You Need

• Python 3.9 or newer
• About 10 minutes and a terminal
• A Mautic instance or any signup form, if you want to wire this in for real — optional for just trying the API
• Basic FastAPI familiarity helps, but every route here is short enough to follow cold

What I Tried First — And Why It Wasn’t Enough

My first fix was a cleanup script, not a filter. I wrote mautic-cleanup.py to scan every contact already in Mautic through its REST API, flag anything on a disposable-domain list or still unconfirmed after 30 days, and delete the flagged ones.

DISPOSABLE_DOMAINS = {
    "mailinator.com", "guerrillamail.com", "tempmail.com", "throwaway.email",
    "yopmail.com", "sharklasers.com", "trashmail.com", "dispostable.com",
    # ...786 domains total in my full list
}
# In production this loads from a text file instead of a hardcoded set —
# same idea, just easier to keep adding to as new disposable domains show up.

CUTOFF_DAYS = 30  # unconfirmed contacts older than this are considered bots

def is_bot(contact):
    reasons = []
    email = (contact.get("fields", {}).get("core", {}).get("email", {}).get("value") or "").lower()
    if not email:
        reasons.append("no email")
        return reasons

    domain = email.split("@")[-1] if "@" in email else ""
    if domain in DISPOSABLE_DOMAINS:
        reasons.append(f"disposable domain: {domain}")

    confirmed = contact.get("fields", {}).get("core", {}).get("confirmed", {}).get("value")
    date_added_str = contact.get("dateAdded", "")
    if str(confirmed) in ("0", "false", "") and date_added_str:
        date_added = datetime.fromisoformat(date_added_str.replace("Z", "+00:00"))
        age_days = (datetime.now(timezone.utc) - date_added).days
        if age_days >= CUTOFF_DAYS:
            reasons.append(f"unconfirmed {age_days}d")

    return reasons

Any contact that comes back with a reason gets flagged. The script pulls every contact through Mautic’s /api/v2/contacts endpoint first, paginating 200 at a time, then runs this check against each one.

It ran as a dry run by default and only deleted with --delete. It worked — I cleared out a real batch of bots the first time I ran it. But it’s reactive: junk still landed in Mautic first, and I was cleaning up a mess instead of stopping it at the door.

What Actually Fixed It — Building a FastAPI Email Verification API

The real fix was moving the check to before a signup gets accepted, not after. So I built a standalone FastAPI endpoint — /email/verify — that scores every address before anything touches Mautic.

I keep it as its own router file, app/routers/email_tools.py, with the disposable-domain list in a separate app/data/disposable_domains.txt so it’s not baked into the code. One line in main.py wires it into the app:

app.include_router(email_tools.router, tags=["email_tools"])

That’s the same pattern most FastAPI apps use to stay organized as you add more tools — each feature gets its own router file instead of one giant main.py.

The Four Checks

Each email goes through four gates, in order, and stops at the first one it fails:

import re
import dns.resolver

SYNTAX_RE = re.compile(r'^[^@\s]+@[^@\s]+\.[^@\s]{2,}$')

ROLE_PREFIXES = {
    "info", "admin", "support", "noreply", "no-reply", "postmaster",
    "webmaster", "contact", "sales", "help", "billing", "abuse",
    "security", "hostmaster", "mailer-daemon", "marketing", "newsletter",
}

def check_mx(domain: str) -> bool:
    try:
        dns.resolver.resolve(domain, "MX")
        return True
    except Exception:
        return False

def verify_single(email: str) -> dict:
    email = email.strip().lower()
    checks = {"syntax": False, "has_mx": False, "is_disposable": False, "is_role_based": False}
    score = 0

    if not SYNTAX_RE.match(email):
        return {"email": email, "is_valid": False, "score": 0, "checks": checks, "reason": "Invalid email format"}
    checks["syntax"] = True
    score += 25

    local, domain = email.split("@", 1)

    if domain in DISPOSABLE_DOMAINS:
        checks["is_disposable"] = True
        return {"email": email, "is_valid": False, "score": score, "checks": checks, "reason": "Disposable email domain not accepted"}
    score += 25

    if local in ROLE_PREFIXES:
        checks["is_role_based"] = True
        return {"email": email, "is_valid": False, "score": score, "checks": checks, "reason": "Role-based addresses not accepted (e.g. info@, admin@)"}
    score += 25

    has_mx = check_mx(domain)
    checks["has_mx"] = has_mx
    if not has_mx:
        return {"email": email, "is_valid": False, "score": score, "checks": checks, "reason": "Email domain has no mail server (MX record missing)"}
    score += 25

    return {"email": email, "is_valid": True, "score": score, "checks": checks, "reason": None}

The scoring stops early. If the syntax is wrong, you get a score of 0 back immediately — there’s no point checking MX records on something that isn’t even shaped like an email. Each passed check adds 25 points, so a fully valid address always scores 100.

Dimu’s Note: the role-based rejection was the one I almost skipped. But info@company.com is a real inbox someone reads — just not the person who signed up for your newsletter. Blocking it kept my open-rate numbers honest.

Why the Checks Run in a Thread Executor

dns.resolver.resolve() is blocking — it waits on a real network call, and so does reading the disposable-domain file. Call either one directly inside an async def route and it freezes the whole event loop, not just that one request. Every other request waiting on your API stalls with it.

The fix is one line per call:

loop = asyncio.get_event_loop()
result = await loop.run_in_executor(None, verify_single, email)

run_in_executor pushes the blocking function onto a background thread pool and hands control straight back to the event loop. Your API stays responsive to every other request while that one DNS lookup is still working. This is the part most FastAPI tutorials skip — and it’s the difference between an endpoint that scales and one that falls over the moment two people hit it at once.

Three Endpoints

I exposed the checker three ways, so it fits however I end up calling it:

@router.get("/email/verify")
async def verify_email_get(email: str = Query(...)):
    loop = asyncio.get_event_loop()
    result = await loop.run_in_executor(None, verify_single, email)
    return {"success": True, "message": f"Email is {'valid' if result['is_valid'] else 'invalid'}", "result": result}

@router.post("/email/verify")
async def verify_email_post(body: dict):
    email = body.get("email", "")
    loop = asyncio.get_event_loop()
    result = await loop.run_in_executor(None, verify_single, email)
    return {"success": True, "message": f"Email is {'valid' if result['is_valid'] else 'invalid'}", "result": result}

@router.post("/email/verify-bulk")
async def verify_email_bulk(body: BulkEmailVerifyRequest):
    emails = body.emails[:50]  # hard cap so one request can't hammer DNS 5000 times
    loop = asyncio.get_event_loop()
    tasks = [loop.run_in_executor(None, verify_single, e) for e in emails]
    results = await asyncio.gather(*tasks)
    valid_count = sum(1 for r in results if r["is_valid"])
    return {"success": True, "result": {"results": results, "summary": {"total": len(results), "valid": valid_count, "invalid": len(results) - valid_count}}}

The bulk endpoint gathers all the executor calls concurrently with asyncio.gather, so 50 emails don’t verify one at a time — they all run in parallel threads at once.

Try It Yourself — Self-Host in About 10 Minutes

You don’t need my full tools API to run this — it’s one router file. Here’s the minimal setup:

pip install fastapi uvicorn dnspython

Drop verify_single, check_mx, and the three routes above into a single main.py, wire the router into a FastAPI app, then run it:

from fastapi import FastAPI, APIRouter, Query
from pydantic import BaseModel
from typing import List

router = APIRouter()

class BulkEmailVerifyRequest(BaseModel):
    emails: List[str]

# ...paste verify_single(), check_mx(), and the three @router routes here...

app = FastAPI()
app.include_router(router)

uvicorn main:app --host 0.0.0.0 --port 8000

Then test it:

curl "http://localhost:8000/email/verify?email=test@mailinator.com"

{
  "success": true,
  "message": "Email is invalid",
  "result": {
    "email": "test@mailinator.com",
    "is_valid": false,
    "score": 25,
    "checks": {"syntax": true, "has_mx": false, "is_disposable": true, "is_role_based": false},
    "reason": "Disposable email domain not accepted"
  }
}

FastAPI also builds an interactive docs page automatically — mine’s at /customdocs since I renamed the default route, yours will sit at localhost:8000/docs if you didn’t touch it. You can test all three endpoints straight from the browser there, no curl needed.

If you’re putting this on a real domain instead of localhost, I run mine on a Contabo VPS — cheap enough that a small side API like this barely registers on the bill.

Quick Reference

curl -X POST "http://localhost:8000/email/verify" \
  -H "Content-Type: application/json" \
  -d '{"email": "someone@gmail.com"}'

curl -X POST "http://localhost:8000/email/verify-bulk" \
  -H "Content-Type: application/json" \
  -d '{"emails": ["a@gmail.com", "b@mailinator.com", "info@company.com"]}'

Advanced Tips

My live version sits behind an API key, since it shares one FastAPI app with a dozen other tools I’ve built. Instead of decorating every single route with a dependency, I gate the whole app in one place:

class APIKeyMiddleware(BaseHTTPMiddleware):
    async def dispatch(self, request: Request, call_next):
        if request.url.path not in WHITELISTED_PATHS:
            api_key = request.headers.get(API_KEY_NAME)
            if api_key != API_KEY:
                return JSONResponse(status_code=401, content={"detail": "Invalid API key"})
        return await call_next(request)

app.add_middleware(APIKeyMiddleware)

One middleware class, one line to register it, every route protected except the ones I explicitly whitelist, like the docs page. If you’re only running the email verifier alone, you probably don’t need this yet — but the moment you add a second tool to the same app, it’s worth doing before you’re pasting the same Depends() onto every route.

The 50-email cap on the bulk endpoint is doing similar work. It’s not a technical limit, it’s a guardrail — without it, one request could try to trigger 5,000 DNS lookups and tie up your thread pool for everyone else.

Frequently Asked Questions

Does this replace SMTP-level email verification?

No. This checks that the domain can receive mail via its MX record, not that the specific mailbox exists. Full SMTP verification means connecting to the mail server and asking directly — slower, and a lot of providers block or fake that response anyway.

Why not just use a paid email verification API?

Cost, mostly. Most paid APIs charge per lookup once you’re past a small free tier. For a Mautic list that’s mostly WordPress and dev-tool signups, syntax plus disposable plus role plus MX catches the obvious junk without a monthly bill.

How do I keep the disposable domain list current?

Mine started small and grew every time a new one slipped through in Mautic — it’s at 786 domains now. There are public lists on GitHub you can seed from, then keep adding whatever gets past you.

Will this catch every bot signup?

No — a bot using a real Gmail address passes every check here. This stops the lazy, high-volume junk: disposable domains, malformed addresses, dead domains — which was most of what was hitting my Mautic list.

Final Thoughts

The real lesson wasn’t the code — it was catching the problem at the door instead of mopping up after. mautic-cleanup.py still runs occasionally as a backstop, but the verification API is what actually changed my numbers.

This endpoint isn’t wired into my Mautic signup form yet — that’s next. I’m also planning to open a version of this up as a free public tool on aibuilttools.com, where you’ll be able to grab an API key by joining my list — if that’s useful to you, keep an eye on that page.

The post FastAPI Email Verification API: How I Built It appeared first on The Beginner’s Playbook for Fixing WordPress Errors.

## What I Tried First (And Why It Didn’t Work)

The first thing I did was clear the browser cache and reload. That fixed nothing — the white screen of death is a server-side problem, not a client-side one. Still worth ruling out, but don’t count on it.

Next I tried logging into the WordPress admin to disable plugins the normal way. Couldn’t. The WSOD had locked me out of both the front end and the back end at the same time. This is the most frustrating version of the problem.

The advice Google returns first is usually “disable all plugins via FTP.” I’m running WordPress on Coolify with Docker, so traditional FTP isn’t part of my setup. But even if it were — disabling every plugin before you know which one caused the issue means you’re flying blind. You’d fix the symptom without knowing the cause. The next plugin update would probably do it again.

There’s also the `.maintenance` file trap. If a WordPress update was interrupted, a file called `.maintenance` can get left in your site root and produce a white screen indefinitely. Worth checking:

“`bash
# Check for a stuck maintenance file
ssh coolify-vps “docker exec wordpress-n0g4skoo8sgwgc848koog0ww ls /var/www/html/.maintenance”

# If it exists, delete it
ssh coolify-vps “docker exec wordpress-n0g4skoo8sgwgc848koog0ww rm /var/www/html/.maintenance”
“`

In my case it wasn’t there. The problem was something else — and I needed WordPress to tell me what.

## What Actually Fixed It

The fix started with one decision: make WordPress show me the actual error instead of a blank screen.

### Step 1: Enable WP_DEBUG

WordPress ships with debug mode off. That’s correct for production, but it means fatal PHP errors produce nothing visible — hence the white screen. Turning on debug mode writes errors to a log file you can read.

SSH into your VPS and edit wp-config.php:

“`bash
# Enter the WordPress container on Coolify
ssh coolify-vps
docker exec -it wordpress-n0g4skoo8sgwgc848koog0ww bash

# Open wp-config.php
nano /var/www/html/wp-config.php
“`

Add these three lines near the top, before the `/* That’s all, stop editing! */` comment:

“`php
define( ‘WP_DEBUG’, true );
define( ‘WP_DEBUG_LOG’, true );
define( ‘WP_DEBUG_DISPLAY’, false );
“`

`WP_DEBUG_DISPLAY` is deliberately `false`. You don’t want raw PHP errors printed on your live site where visitors can see them. The log file is where you’ll look.

Save the file and reload your site. The white screen will probably still be there — but WordPress is now silently logging what caused it.

### Step 2: Read the Debug Log

“`bash
tail -50 /var/www/html/wp-content/debug.log
“`

This is where the case gets solved. In my situation the log showed:

“`
[04-Jun-2025 08:41:22 UTC] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted
(tried to allocate 20480 bytes) in /var/www/html/wp-content/plugins/advanced-custom-fields/includes/acf-value-functions.php on line 412
“`

Memory exhaustion. Not a code corruption, not a version conflict — a plugin trying to allocate more RAM than WordPress had budgeted. The log told me exactly which plugin file triggered it, which means I didn’t have to guess.

Common things you’ll see in the log and what they mean:

– **`Allowed memory size exhausted`** → PHP memory limit too low, or a plugin has a memory leak
– **`Call to undefined function`** → A plugin or theme is calling a function that doesn’t exist (usually a missing dependency or a version mismatch)
– **`Parse error: syntax error`** → A PHP file has broken syntax (often from a manual edit gone wrong)
– **`Maximum execution time exceeded`** → A script is running too long (database query, external API call)

### Step 3: Deactivate the Problem Plugin

Once the log pointed me to the specific plugin, I deactivated it via WP-CLI without needing admin access:

“`bash
# List all active plugins to confirm the folder name
docker exec wordpress-n0g4skoo8sgwgc848koog0ww wp plugin list –status=active –allow-root

# Deactivate the specific plugin
docker exec wordpress-n0g4skoo8sgwgc848koog0ww wp plugin deactivate advanced-custom-fields –allow-root
“`

After deactivating, I reloaded the site. White screen gone. Now I knew the cause and could fix it properly instead of just disabling something and hoping.

### Step 4: Fix the Root Cause

The plugin itself wasn’t broken — it just needed more memory than WordPress’s default 128MB allows. The actual fix was a one-line addition to wp-config.php:

“`php
define( ‘WP_MEMORY_LIMIT’, ‘256M’ );
“`

Add this just above the “stop editing” comment in wp-config.php. Then reactivate the plugin:

“`bash
docker exec wordpress-n0g4skoo8sgwgc848koog0ww wp plugin activate advanced-custom-fields –allow-root
“`

Reloaded the site. Everything back to normal.

If your log shows a **syntax error** instead of a memory issue, the fix is different — find the file the log mentions, open it, and look for broken PHP near the line number it reports. This usually happens after manually editing functions.php or adding a code snippet in the wrong place.

### Step 5: Turn Off Debug Mode

Easy to forget. Leave `WP_DEBUG` on in production and your debug.log will grow indefinitely. It can also expose internal file paths and error details that you’d rather not be public.

Go back to wp-config.php and set:

“`php
define( ‘WP_DEBUG’, false );
“`

Or remove the three debug lines entirely — WordPress defaults to debug off.

## Quick Reference

“`bash
# ── DIAGNOSIS ──

# Enter WordPress container (Coolify — replace container name with yours)
ssh coolify-vps
docker exec -it YOUR_WP_CONTAINER bash

# Check for stuck maintenance file
ls /var/www/html/.maintenance
rm /var/www/html/.maintenance # if it exists

# Enable debug logging (edit wp-config.php)
nano /var/www/html/wp-config.php
# Add these three lines:
# define( ‘WP_DEBUG’, true );
# define( ‘WP_DEBUG_LOG’, true );
# define( ‘WP_DEBUG_DISPLAY’, false );

# Read the debug log
tail -50 /var/www/html/wp-content/debug.log

# ── FIX ──

# List active plugins
wp plugin list –status=active –allow-root

# Deactivate a specific plugin
wp plugin deactivate PLUGIN-FOLDER-NAME –allow-root

# Increase memory limit (add to wp-config.php)
# define( ‘WP_MEMORY_LIMIT’, ‘256M’ );

# Reactivate plugin after fixing root cause
wp plugin activate PLUGIN-FOLDER-NAME –allow-root

# Switch to a default theme (if theme is the culprit)
wp theme activate twentytwentyfour –allow-root

# ── CLEANUP ──

# Turn off debug mode when done
# Set: define( ‘WP_DEBUG’, false );

# Flush cache after fix
wp cache flush –allow-root
“`

## Frequently Asked Questions

**What is the most common cause of the WordPress white screen of death?**

Plugin conflicts and PHP memory exhaustion are the two most common causes. A recently updated plugin may conflict with your PHP version, another plugin, or your theme. Memory exhaustion happens when a plugin needs more RAM than WordPress’s default 128MB limit allows — common on shared hosting or VPS setups with tight default resource allocation.

**How do I fix WordPress white screen without access to the admin dashboard?**

Use WP-CLI from SSH. You can deactivate all plugins with `wp plugin deactivate –all –allow-root`, or target a specific plugin if you know which one caused the issue. You can also switch to a default theme with `wp theme activate twentytwentyfour –allow-root`. Neither requires admin dashboard access.

**Does clearing the cache fix the WordPress white screen of death?**

Not on its own — the white screen is caused by a PHP error, not a caching problem. But after you’ve fixed the root cause, running `wp cache flush –allow-root` ensures visitors aren’t still being served a cached blank page. It’s a useful cleanup step, not a primary fix.

**How do I know which plugin caused the white screen?**

Enable `WP_DEBUG` and `WP_DEBUG_LOG` in wp-config.php, then reload your site and read `/wp-content/debug.log`. The log entry will include the full file path of the plugin that triggered the fatal error. No guessing — the log tells you exactly where to look.

**Can a theme cause the WordPress white screen of death?**

Yes. The WSOD after activating a new theme or running a theme update is a classic scenario. The fix is the same — enable debug mode, read the log, and if the error points to a theme file, switch to a default theme via WP-CLI: `wp theme activate twentytwentyfour –allow-root`.

## Final Thoughts

The white screen of death sounds catastrophic but it almost always has one specific, readable cause. Enable debug mode, read the log, fix what the log tells you. That three-step process has resolved every WSOD I’ve hit on my Coolify-hosted sites.

If you’re setting up WordPress on a VPS and want to avoid this class of errors from the start, the next post worth reading is [LINK: how to set up WordPress on Coolify with proper debug logging]. It covers the configuration I use so that errors surface as log entries instead of blank screens.

*Steps verified on WordPress 6.x / PHP 8.2 as of June 2025. The WP_DEBUG constants and WP-CLI commands haven’t changed in several major versions — they should work on any current WordPress install.*

—

*Some links in this post are affiliate links. I only recommend tools I actually use on my own sites.*

The post How I Fixed WordPress White Screen of Death — What Actually Worked appeared first on The Beginner’s Playbook for Fixing WordPress Errors.

Every time I wanted Claude to help me update a post, add a new page, or check my plugin list, I was copying and pasting. Text in. Text out. Then manually clicking through the WordPress dashboard to actually apply it.

There had to be a better way. And there was — it just took me a full weekend of broken Node.js paths and permission errors to find it.

What I Tried First — And Why It Didn’t Work

My first instinct was to use a REST API approach. WordPress has a built-in REST API, so I figured I’d just point Claude at it with an API key and call it a day.

Two problems showed up immediately.

First problem: Claude Code doesn’t natively “call” REST APIs on its own during a conversation — it needs a tool or server to bridge that connection. The REST API is great for building apps, but it isn’t a conversational interface.

Second problem: My WordPress site runs inside a Docker container on a Coolify VPS. It’s not publicly accessible via REST during dev work — I’d have to expose ports and deal with auth tokens just to test a simple post update. That felt like overkill for what I needed.

I also tried a plugin called “AI Power” which connects WordPress to OpenAI. Useful for content generation — but it doesn’t let Claude control WordPress. It just uses GPT inside the WordPress editor. That’s the opposite direction from what I wanted.

What I actually needed was an MCP server — a small Node.js process that exposes WordPress tools (create post, get posts, update page, list plugins) to Claude Code via the Model Context Protocol.

So I built one.

What Actually Fixed It — The MCP Server Setup

Here’s exactly how I set it up. My stack: Coolify VPS + Docker WordPress container + Node.js MCP server.

Step 1 — SSH into the VPS and set up a working directory

ssh coolify-vps
mkdir -p /home/coolify-service/wp-mcp
cd /home/coolify-service/wp-mcp

I created a dedicated folder outside the Docker container. The MCP server runs on the host — it communicates with WordPress via WP-CLI commands executed inside the container.

Step 2 — Install Node.js on the VPS host

curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
sudo apt-get install -y nodejs
node --version  # should show v20.x.x

If you’re on a minimal Coolify VPS like mine, Node.js won’t be pre-installed. Don’t skip this check.

Step 3 — Initialize the project and install the MCP SDK

cd /home/coolify-service/wp-mcp
npm init -y
npm install @modelcontextprotocol/sdk

The @modelcontextprotocol/sdk is the official Anthropic MCP package. It handles all the protocol handshake — you just define tools.

Step 4 — Write the server.js file

This is the core of the whole setup. Here’s a simplified version of what my server.js looks like:

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { CallToolRequestSchema, ListToolsRequestSchema } from "@modelcontextprotocol/sdk/types.js";
import { execSync } from "child_process";

const WP_CONTAINER = "wordpress-n0g4skoo8sgwgc848koog0ww";

function runWpCli(command) {
  const full = `docker exec ${WP_CONTAINER} wp --allow-root ${command}`;
  return execSync(full, { encoding: "utf8" });
}

const server = new Server(
  { name: "wordpress-mcp", version: "1.0.0" },
  { capabilities: { tools: {} } }
);

server.setRequestHandler(ListToolsRequestSchema, async () => ({
  tools: [
    {
      name: "wp_get_posts",
      description: "List recent WordPress posts",
      inputSchema: {
        type: "object",
        properties: {
          count: { type: "number", description: "Number of posts to retrieve" }
        }
      }
    },
    {
      name: "wp_create_post",
      description: "Create a new WordPress post",
      inputSchema: {
        type: "object",
        properties: {
          title: { type: "string" },
          content: { type: "string" },
          status: { type: "string", enum: ["draft", "publish"] }
        },
        required: ["title", "content"]
      }
    }
  ]
}));

server.setRequestHandler(CallToolRequestSchema, async (request) => {
  const { name, arguments: args } = request.params;

  if (name === "wp_get_posts") {
    const count = args.count || 5;
    const result = runWpCli(`post list --posts_per_page=${count} --fields=ID,post_title,post_status --format=json`);
    return { content: [{ type: "text", text: result }] };
  }

  if (name === "wp_create_post") {
    const { title, content, status = "draft" } = args;
    const result = runWpCli(`post create --post_title="${title}" --post_content="${content}" --post_status=${status}`);
    return { content: [{ type: "text", text: result }] };
  }

  throw new Error(`Unknown tool: ${name}`);
});

const transport = new StdioServerTransport();
await server.connect(transport);

The key insight here: every tool just runs a WP-CLI command inside the Docker container via docker exec. No REST API. No auth tokens. Direct shell access.

Step 5 — Add the MCP server to Claude Code config

On your local machine (not the VPS), open your Claude Code MCP config file. On Windows it’s at:

C:\Users\YourName\AppData\Roaming\Claude\claude_desktop_config.json

Add this block:

{
  "mcpServers": {
    "wordpress": {
      "command": "ssh",
      "args": [
        "coolify-vps",
        "node /home/coolify-service/wp-mcp/server.js"
      ]
    }
  }
}

This tells Claude Code: when you need WordPress tools, SSH into my VPS and run the Node.js server. The MCP protocol runs over stdio — so SSH becomes the transport pipe.

Step 6 — Test it

Restart Claude Code. In the chat, try:

List my last 5 WordPress posts

If it works, you’ll see Claude call the wp_get_posts tool and return your actual post titles. That moment — the first time Claude listed my real posts from ceeveeglobal.com without me touching the dashboard — genuinely felt like magic.

Quick Reference

# SSH into VPS
ssh coolify-vps

# Start MCP server manually (for testing)
node /home/coolify-service/wp-mcp/server.js

# Test WP-CLI directly (check connection works)
docker exec wordpress-n0g4skoo8sgwgc848koog0ww wp --allow-root post list

# Check Node.js version on VPS
node --version

# Reinstall SDK if something breaks
cd /home/coolify-service/wp-mcp && npm install

Claude Code config location (Windows):

%APPDATA%\Claude\claude_desktop_config.json

Claude Code config location (Mac):

~/Library/Application Support/Claude/claude_desktop_config.json

Frequently Asked Questions

Q: Do I need a special WordPress plugin for this to work?

No plugin needed. The MCP server communicates with WordPress through WP-CLI running inside the Docker container. As long as WP-CLI is installed in your container (it is by default in most WordPress Docker images), you’re good to go. No REST API, no extra plugins — just shell commands.

Q: Is this secure? I don’t want to expose my WordPress to the internet.

It’s actually more secure than the REST API approach. The MCP server runs on your VPS host and only accepts connections via SSH. Nothing is exposed publicly. Claude Code connects through your existing SSH key pair — same as if you logged in manually. Your WordPress dashboard URL stays private.

Q: What happens if the Docker container name changes after a Coolify update?

This caught me once. After a Coolify update, my container got recreated with a different ID. I store the container name as a constant at the top of server.js — so I just update that one line and restart. To find your current container name:

docker ps --filter "name=wordpress" --format "{{.Names}}"

Final Thoughts

This setup changed how I work with my WordPress sites. Instead of switching between Claude and the dashboard, I just describe what I want and it happens — new posts drafted, plugin lists checked, page content updated, all through conversation.

It’s not a product you can buy. It’s something you build, and that’s the point. If you want to go further — more tools, more sites, a shared MCP config — I’ve packaged some of these patterns into ready-to-use tools at aibuilttools.com.

Start with one tool. Get it working. Build from there.

The post How I Connected WordPress to Claude AI With an MCP Server appeared first on The Beginner’s Playbook for Fixing WordPress Errors.

Understanding the Issue: Why is Mautic 5 Missing in Coolify?

When you open Coolify, looking for Mautic under the “Add Resource” section, it can be frustrating to find nothing. The absence of a one-click app or template for Mautic 5 in Coolify is due to recent updates and changes in the Coolify ecosystem, necessitating a manual workaround.

Why Mautic Matters for WordPress Users

Mautic is a powerful open-source marketing automation tool, seamlessly integrating with WordPress to enhance customer engagement and conversion rates. Its absence from Coolify means WordPress users need an alternative method to keep their automation processes running smoothly.

Prerequisites

Before diving into the deployment process, ensure you have the following prerequisites:

• Basic understanding of Docker and Docker Compose.
• Access to a server with Docker installed.
• Admin access to a Coolify account.
• A domain name if you plan to use a custom URL.

Step-by-Step Implementation: Deploying Mautic 5 with Docker Compose

Despite its absence in Coolify, deploying Mautic 5 is straightforward with Docker Compose. Follow these steps to get started:

1. Create a New Project in Coolify: Navigate to your Coolify dashboard and click New. Name your project (e.g., “Mautic”), then proceed with Continue.
2. Add a Resource: Choose Add Resource and select Docker Compose Empty to initiate your custom setup.
3. Insert the Docker Compose File: Copy the Docker Compose file provided in the resource link and paste it into the designated area. Click Save, then Deploy to start the process.
   Access Your Mautic Instance: Once deployed, go to Links in Coolify and click the generated URL to complete your Mautic setup.

version: "3.9"

services:
  db:
    image: mysql:8.0
    environment:
      - MYSQL_ROOT_PASSWORD=${SERVICE_PASSWORD_64_MYSQLROOT}
      - MYSQL_DATABASE=${MYSQL_DATABASE:-mautic}
      - MYSQL_USER=${SERVICE_USER_MYSQL}
      - MYSQL_PASSWORD=${SERVICE_PASSWORD_64_MYSQL}
    volumes:
      - mysql-data:/var/lib/mysql
    healthcheck:
      test: mysqladmin ping --silent --user=$${SERVICE_USER_MYSQL} --password=$${SERVICE_PASSWORD_64_MYSQL}
      start_period: 30s
      interval: 10s
      timeout: 5s
      retries: 5

  rabbitmq:
    image: rabbitmq:3
    environment:
      - RABBITMQ_DEFAULT_VHOST=${RABBITMQ_DEFAULT_VHOST:-mautic}
    volumes:
      - rabbitmq-data:/var/lib/rabbitmq

  mautic_web:
    image: mautic/mautic:latest
    ports:
      - "8880:80"
    volumes:
      - mautic_data/config:/var/www/html/config:z
      - mautic_data/logs:/var/www/html/var/logs:z
      - mautic_data/media/files:/var/www/html/docroot/media/files:z
      - mautic_data/media/images:/var/www/html/docroot/media/images:z
      - mautic_data/plugins:/var/www/html/docroot/plugins:z
      - mautic_data/vendor:/var/www/html/vendor:z
      - mautic_data/bin:/var/www/html/bin:z
      - mautic_data/cron:/opt/mautic/cron:z
    environment:
      - SERVICE_FQDN_MAUTIC_80
      - DOCKER_MAUTIC_LOAD_TEST_DATA=${MAUTIC_LOAD_TEST_DATA:-false}
      - DOCKER_MAUTIC_RUN_MIGRATIONS=${MAUTIC_RUN_MIGRATIONS:-false}
      - MAUTIC_DB_HOST=${MYSQL_HOST:-db}
      - MAUTIC_DB_PORT=${MYSQL_PORT:-3306}
      - MAUTIC_DB_DATABASE=${MYSQL_DATABASE:-mautic}
      - MAUTIC_DB_USER=${SERVICE_USER_MYSQL}
      - MAUTIC_DB_PASSWORD=${SERVICE_PASSWORD_64_MYSQL}
      - MAUTIC_MESSENGER_DSN_EMAIL=amqp://guest:guest@rabbitmq:5672/mautic/messages
      - MAUTIC_MESSENGER_DSN_HIT=amqp://guest:guest@rabbitmq:5672/mautic/messages
    depends_on:
      db:
        condition: service_healthy
      rabbitmq:
        condition: service_started
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost"]
      interval: 15s
      timeout: 10s
      retries: 15

  mautic_cron:
    image: mautic/mautic:latest
    volumes:
      - mautic_data/config:/var/www/html/config:z
      - mautic_data/logs:/var/www/html/var/logs:z
      - mautic_data/media/files:/var/www/html/docroot/media/files:z
      - mautic_data/media/images:/var/www/html/docroot/media/images:z
      - mautic_data/plugins:/var/www/html/docroot/plugins:z
      - mautic_data/vendor:/var/www/html/vendor:z
      - mautic_data/bin:/var/www/html/bin:z
      - mautic_data/cron:/opt/mautic/cron:z
    environment:
      - DOCKER_MAUTIC_ROLE=mautic_cron
      - MAUTIC_DB_HOST=${MYSQL_HOST:-db}
      - MAUTIC_DB_PORT=${MYSQL_PORT:-3306}
      - MAUTIC_DB_DATABASE=${MYSQL_DATABASE:-mautic}
      - MAUTIC_DB_USER=${SERVICE_USER_MYSQL}
      - MAUTIC_DB_PASSWORD=${SERVICE_PASSWORD_64_MYSQL}
      - MAUTIC_MESSENGER_DSN_EMAIL=amqp://guest:guest@rabbitmq:5672/mautic/messages
      - MAUTIC_MESSENGER_DSN_HIT=amqp://guest:guest@rabbitmq:5672/mautic/messages
    depends_on:
      mautic_web:
        condition: service_healthy

  mautic_worker:
    image: mautic/mautic:latest
    volumes:
      - mautic_data/config:/var/www/html/config:z
      - mautic_data/logs:/var/www/html/var/logs:z
      - mautic_data/media/files:/var/www/html/docroot/media/files:z
      - mautic_data/media/images:/var/www/html/docroot/media/images:z
      - mautic_data/plugins:/var/www/html/docroot/plugins:z
      - mautic_data/vendor:/var/www/html/vendor:z
      - mautic_data/bin:/var/www/html/bin:z
      - mautic_data/cron:/opt/mautic/cron:z
    environment:
      - DOCKER_MAUTIC_ROLE=mautic_worker
      - MAUTIC_DB_HOST=${MYSQL_HOST:-db}
      - MAUTIC_DB_PORT=${MYSQL_PORT:-3306}
      - MAUTIC_DB_DATABASE=${MYSQL_DATABASE:-mautic}
      - MAUTIC_DB_USER=${SERVICE_USER_MYSQL}
      - MAUTIC_DB_PASSWORD=${SERVICE_PASSWORD_64_MYSQL}
      - MAUTIC_MESSENGER_DSN_EMAIL=amqp://guest:guest@rabbitmq:5672/mautic/messages
      - MAUTIC_MESSENGER_DSN_HIT=amqp://guest:guest@rabbitmq:5672/mautic/messages
    depends_on:
      mautic_web:
        condition: service_healthy

volumes:
  mysql-data:
  rabbitmq-data:
  mautic_data:

Connecting a Custom Domain

For personalised branding, connecting a custom domain to your Mautic instance is beneficial. Here’s how:

• Log in to your domain provider (e.g., Namecheap) and access Advanced DNS settings.
• Add a new record, select A Record, enter your subdomain (e.g., “mautic”), and point it to your server’s IP.
• Save the changes. After DNS propagation, return to Coolify, open your Mautic service, navigate to Settings, and add your subdomain.

Advanced Insights: Expert Tips for Optimising Your Setup

Deploying Mautic through Docker Compose opens avenues for customization and optimization. Here are expert-level tips:

• Optimize Performance: Configure Docker resources such as CPU and memory allocation to ensure Mautic runs efficiently.
• Regular Backups: Set up automated backups for your Mautic data to prevent data loss. Tools like DigitalOcean Spaces can be valuable here.
• Enhance Security: Use SSL certificates for secure communication. Services like Let’s Encrypt provide free SSL certificates.

Integrating Affiliate Recommendations

For an all-in-one solution, consider hosting providers like Vultr or InterServer for reliable and cost-effective hosting solutions. Additionally, Namecheap remains a top choice for domain management.

Troubleshooting Common Issues

If you encounter issues during the installation or deployment process, consider the following tips:

• Port Conflicts: Ensure no other services are using the ports Mautic requires.
• Check Logs: Use Docker logs to identify any errors during deployment.
• Network Settings: Verify your server’s firewall and network settings allow necessary traffic.

Conclusion: Bringing Mautic Back to Coolify

While the absence of Mautic 5 in Coolify might initially seem daunting, the manual deployment using Docker Compose is a robust alternative. By following the steps outlined above, WordPress users can regain the powerful marketing automation capabilities Mautic offers. Embrace these changes, and enhance your online strategies with a tailored approach.

FAQs: Mautic 5 Missing in Coolify

• Why is Mautic 5 not showing in Coolify? Coolify has undergone updates, removing the direct one-click Mautic installation, necessitating a manual setup.
• Can I still use Mautic with Coolify? Yes, by utilizing Docker Compose, you can manually deploy Mautic 5 on your server.
• Is Docker Compose difficult to use? Docker Compose simplifies the deployment process, especially when following detailed guides like this one.

Summary

To recap, deploying Mautic 5 in Coolify involves creating a new project, adding a Docker Compose resource, and configuring your domain. With these steps, you can restore Mautic’s capabilities even without direct Coolify support.

Have questions or need further clarification? Feel free to leave a comment below, and we’ll be happy to assist you.

Explore more WordPress tips and tricks|/wordpress-tips-tricks
Learn how to optimize your WordPress site for SEO|/wordpress-seo-optimization

The post Mautic 5 Missing in Coolify? Here’s How to Fix It with Docker Compose appeared first on The Beginner’s Playbook for Fixing WordPress Errors.

Most beginners copy-paste WordPress code from Stack Overflow without understanding what it actually does. I did the same thing for months until I realized I was just guessing. One wrong character in functions.php, and boom — White Screen of Death.

Here’s the truth: you don’t need to memorize thousands of functions. I’ll show you 8 WordPress code concepts that power every WordPress site — from simple blogs to complex e-commerce stores.

Understanding these core WordPress code concepts will transform how you build and customize WordPress sites. No more guessing. No more breaking things accidentally.

By the end of this guide, you’ll understand:

• What each WordPress code concept is (in plain English)
• How to use it properly (with working code examples)
• Real-world problems it solves (not just theory)

Let’s start with the most important warning before diving into these WordPress code concepts.

⚠️ CRITICAL WARNING: Before You Edit functions.php

Editing functions.php can break your entire site if you make one syntax error. I learned this the hard way when my client’s site went down.

Always follow these rules:

✅ Backup your site first — Don’t waste money on backup plugins. Watch how I built my own backup system in 15 minutes using AI (saves you $840/year)

✅ Use a child theme — Never edit parent theme files directly

✅ Test on staging site — If you have one available

✅ Or use Code Snippets plugin — Much safer than editing functions.php

One missing semicolon = White Screen of Death. You’ve been warned.

Now let’s dive into the essential WordPress code concepts that every developer should know.

Why Understanding WordPress Code Concepts Matters

Before we jump into specific WordPress code concepts, let’s talk about why this matters.

WordPress powers 43% of all websites. But here’s what most people don’t know: every WordPress plugin, theme, and custom functionality uses the same 8 core WordPress code concepts.

When you understand these WordPress programming fundamentals, you can:

• Debug WordPress errors faster
• Build custom features without expensive plugins
• Understand how WordPress plugins actually work
• Optimize your site’s performance
• Fix broken functionality yourself

These WordPress code concepts are the building blocks. Master them, and you’ll never feel helpless staring at WordPress code again.

Concept 1: add_action() Hook — The Foundation of WordPress

What is add_action()?

The add_action() hook is one of the most important WordPress code concepts. It lets you add custom code at specific points in WordPress without modifying core files.

Think of WordPress actions as “when X happens, do Y.” It’s event-driven programming made simple.

How to use add_action():

add_action('wp_footer', 'add_footer_text');
function add_footer_text() {
    echo '<div style="text-align: center; padding: 20px; background: #f0f0f0;">
        Built with ❤️ by Dimu | <a href="https://ceeveeglobal.com">Visit My Site</a>
    </div>';
}

What this does: Adds a custom footer message to every page on your site.

How to Test If It’s Working:

1. Add the code above to Code Snippets plugin (or functions.php)
2. Save and activate
3. Visit any page on your site
4. Scroll to the bottom

You should see: A gray box with “Built with ❤️ by Dimu” at the footer.

If you don’t see it: Check for syntax errors. One missing semicolon or bracket breaks everything.

Common Beginner Mistake:

Many tutorials use console.log() in examples like this:

echo '<script>console.log("Hello");</script>';

This does work — but you can’t see it on your page. You have to open browser Developer Console (F12) to see the message. That’s why beginners think their code failed.

Always test with visible output first (text, colors, borders) so you know your code is running.

Real-world problems add_action() solves:

• Add Google Analytics or tracking codes to footer automatically
• Insert custom content after every blog post
• Load scripts at the right time (not too early, not too late)
• Modify WordPress behavior without touching core files
• Hook into WordPress events like user login, post publishing

When to use add_action():

When you need to add functionality at specific WordPress events. Like adding a banner after every blog post or loading custom CSS on specific pages.

I use add_action() constantly. My AI tools page uses add_action to load custom JavaScript only on that page — not sitewide. Result? Faster load times and better performance.

More Practical Examples:

Example 2: Add Custom CSS to All Pages

add_action('wp_head', 'my_custom_styles');
function my_custom_styles() {
    echo '<style>
        body { border-top: 5px solid #ff6b6b; }
    </style>';
}

What you’ll see: Red border at the top of every page.

Example 3: Admin Dashboard Notice

add_action('admin_notices', 'my_admin_notice');
function my_admin_notice() {
    echo '<div class="notice notice-success">
        <p>Your custom code is working! 🎉</p>
    </div>';
}

Where to see it: WordPress Admin Dashboard (top of the page when you log in).

Pro tip: The most common WordPress actions are wp_head, wp_footer, init, wp_enqueue_scripts, and admin_init. Start with these.

Concept 2: add_filter() Hook — Transform WordPress Content

What is add_filter()?

Filters are another crucial WordPress code concept. While actions “do something,” filters modify existing data before WordPress displays it.

This is how WordPress lets you transform content, change titles, modify excerpts, and customize output without editing template files.

How to use add_filter():

add_filter('the_content', 'add_reading_time');
function add_reading_time($content) {
    // Only add to single posts
    if (is_single()) {
        $word_count = str_word_count(strip_tags($content));
        $reading_time = ceil($word_count / 200);
        $message = "<p style='background: #e3f2fd; padding: 15px; border-left: 4px solid #2196f3;'><strong>⏱️ Reading time: " . $reading_time . " minutes</strong></p>";
        return $message . $content;
    }
    return $content;
}

This automatically adds reading time to every post. No manual work needed.

How to Test If It’s Working:

1. Add the code to Code Snippets plugin
2. Save and activate
3. Visit any blog post (not page)
4. Look at the top of the content

You should see: A blue box with reading time estimate.

Real-world problems add_filter() solves:

• Add custom content before/after posts automatically
• Modify excerpt length from default 55 words
• Change post titles programmatically
• Filter search results by custom criteria
• Add disclaimers to specific post types
• Customize WordPress login messages

When to use add_filter():

When you need to transform existing content. I use filters to add custom CTAs at the end of my WordPress error fix posts. One filter updates 40+ posts automatically.

More Practical Examples:

Example: Change Excerpt Length

add_filter('excerpt_length', 'custom_excerpt_length');
function custom_excerpt_length($length) {
    return 30; // Change from default 55 words to 30
}

Example: Add Text After Every Post

add_filter('the_content', 'add_cta_after_post');
function add_cta_after_post($content) {
    if (is_single()) {
        $cta = '<div style="background: #fff3cd; padding: 20px; margin-top: 30px; border-radius: 5px;">
            <h3>Need Help with WordPress Errors?</h3>
            <p>Try my <a href="https://ceeveeglobal.com/wp-error-expert/">WP Error Expert Tool</a> - AI-powered error diagnosis!</p>
        </div>';
        return $content . $cta;
    }
    return $content;
}

Key difference: Actions add new functionality. Filters modify existing data. Both are essential WordPress code concepts you’ll use daily.

Concept 3: WP_Query — Custom WordPress Loops

What is WP_Query?

WP_Query is WordPress’s powerful way to fetch posts from the database. It’s one of the most flexible WordPress code concepts for displaying content.

The default WordPress loop shows all posts. WP_Query lets you get specific posts based on any criteria you want — categories, tags, custom fields, dates, and more.

How to use WP_Query:

function display_custom_posts() {
    $args = array(
        'posts_per_page' => 5,
        'category_name' => 'wordpress-errors', // Change to your category slug
        'orderby' => 'date',
        'order' => 'DESC'
    );
    $query = new WP_Query($args);

    if ($query->have_posts()) {
        echo '<div class="custom-posts">';
        while ($query->have_posts()) {
            $query->the_post();
            echo '<div style="margin-bottom: 20px; padding: 15px; border: 1px solid #ddd; border-radius: 5px;">';
            echo '<h3><a href="' . get_permalink() . '">' . get_the_title() . '</a></h3>';
            echo '<p>' . get_the_excerpt() . '</p>';
            echo '<a href="' . get_permalink() . '" style="color: #0073aa;">Read More →</a>';
            echo '</div>';
        }
        echo '</div>';
    } else {
        echo '<p>No posts found.</p>';
    }
    wp_reset_postdata();
}

// Add shortcode to use anywhere
add_shortcode('custom_posts', 'display_custom_posts');

How to Test If It’s Working:

Using Code Snippets Plugin (Recommended):

1. Add the code to Code Snippets plugin
2. Change 'category_name' => 'wordpress-errors' to match your actual category slug
3. Edit any post or page
4. Add this shortcode: [custom_posts]
5. Publish and view the page

You should see: A styled list of 5 posts from that category with borders and read more links.

If you see “No posts found”: Your category slug might be wrong. Go to Posts → Categories and check the actual slug.

Real-world problems WP_Query solves:

• Create custom post grids (like my tools page layout)
• Display posts from specific categories only
• Build “Related Posts” sections based on tags or categories
• Show posts by custom field values
• Create portfolio sections with filtering options
• Display posts from multiple post types

When to use WP_Query:

When the default WordPress loop isn’t flexible enough. I use WP_Query on the homepage to show only featured WordPress error fixes — not all 45+ posts.

Useful WP_Query Parameters:

$args = array(
    'posts_per_page' => 10,        // Number of posts
    'category_name' => 'tutorials', // Category slug
    'tag' => 'beginner',           // Tag slug
    'orderby' => 'date',           // Sort by date
    'order' => 'DESC',             // Newest first
    'post_type' => 'post',         // Post type
    'meta_key' => 'featured',      // Custom field key
    'meta_value' => 'yes'          // Custom field value
);

Important: Always use wp_reset_postdata() after custom queries to avoid conflicts with the main loop. This resets global post data.

Concept 4: WordPress Shortcodes — Reusable Content Blocks

What are WordPress shortcodes?

Shortcodes are reusable code snippets you can insert anywhere using simple brackets. They’re essential WordPress code concepts for creating custom, reusable elements.

Think of shortcodes like creating your own Gutenberg blocks, but lighter and more flexible.

How to use WordPress shortcodes:

add_shortcode('cta_button', 'my_button_shortcode');
function my_button_shortcode($atts) {
    // Set default values
    $atts = shortcode_atts(array(
        'text' => 'Click Here',
        'url' => '#',
        'color' => 'blue'
    ), $atts);
    
    // Return the button HTML
    return '<a href="' . esc_url($atts['url']) . '" style="display: inline-block; padding: 12px 24px; background: ' . esc_attr($atts['color']) . '; color: white; text-decoration: none; border-radius: 5px; font-weight: bold;">' . esc_html($atts['text']) . '</a>';
}

How to Test If It’s Working:

1. Add the code above to the Code Snippets plugin

2. Save and activate

3. Edit any post or page

4. Add this shortcode to the content:

[cta_button text="Try Free Tool" url="https://ceeveeglobal.com/tools/" color="green"]

You should see: A green button with “Try Free Tool” text.

More Shortcode Examples:

Example: Simple Contact Box

add_shortcode('contact_box', 'contact_box_shortcode');
function contact_box_shortcode() {
    return '<div style="background: #f8f9fa; padding: 20px; border-left: 4px solid #007bff; margin: 20px 0;">
        <h3>Need WordPress Help?</h3>
        <p>Contact me: <a href="https://ceeveeglobal.com/contact/">Click Here</a></p>
    </div>';
}

Usage: [contact_box]

Real-world problems shortcodes solve:

• Add custom CTAs without page builders
• Insert contact forms anywhere in content
• Display pricing tables consistently across pages
• Embed custom widgets in posts and pages
• Create reusable content blocks that update globally

When to use shortcodes:

When you need the same element across multiple posts or pages. I use shortcodes for tool promotion boxes in my blog posts. Update one shortcode function, and all posts update automatically.

Shortcodes are perfect for WordPress performance optimization too — they’re lighter than page builder elements and load faster.

Concept 5: wp_enqueue_script() & wp_enqueue_style() — Load Assets Properly

What is wp_enqueue?

These functions represent critical WordPress code concepts for properly loading CSS and JavaScript. Never add scripts directly to header.php or footer.php — always use wp_enqueue.

How to use wp_enqueue properly:

function load_my_assets() {
    // Load CSS
    wp_enqueue_style('my-custom-style', get_stylesheet_directory_uri() . '/custom.css', array(), '1.0.0');
    
    // Load JavaScript with jQuery dependency
    wp_enqueue_script('my-custom-script', get_stylesheet_directory_uri() . '/custom.js', array('jquery'), '1.0.0', true);
}
add_action('wp_enqueue_scripts', 'load_my_assets');

Explanation:

• get_stylesheet_directory_uri() gets your theme’s URL
• array('jquery') means “load jQuery first, then my script”
• '1.0.0' is version number (for cache busting)
• true at the end means “load in footer for better performance”

How to Test If It’s Working:

1. Create a file called custom.js in your theme folder
2. Add this code to it:

jQuery(document).ready(function($) {
    $('body').prepend('<div style="background: yellow; padding: 10px; text-align: center;">Custom JS Loaded!</div>');
});

3. Add the wp_enqueue code above to your functions.php or Code Snippets
4. Refresh your site

You should see: Yellow banner at the top saying “Custom JS Loaded!”

Real-world problems wp_enqueue solves:

• Prevents jQuery conflicts (the #1 WordPress JavaScript error)
• Loads scripts in correct order with proper dependencies
• Avoids loading same script twice (duplicate loading)
• Improves page speed by controlling what loads where
• Makes debugging easier with proper script handles
• Enables conditional loading (only load on specific pages)

Conditional Loading Example:

function load_my_assets() {
    // Only load on homepage
    if (is_front_page()) {
        wp_enqueue_script('homepage-slider', get_stylesheet_directory_uri() . '/slider.js', array('jquery'), '1.0.0', true);
    }
    
    // Only load on single posts
    if (is_single()) {
        wp_enqueue_style('single-post-style', get_stylesheet_directory_uri() . '/single-post.css');
    }
}
add_action('wp_enqueue_scripts', 'load_my_assets');

When to use wp_enqueue:

Always. This is not optional for WordPress development. If you’re adding CSS or JavaScript to WordPress, use wp_enqueue_style() and wp_enqueue_script(). Period.

I use wp_enqueue to load my custom scripts only on pages that need them. My WordPress Plugin Finder tool loads specific JavaScript — not on every page. This keeps the site fast.

Common mistake: Loading scripts in wp_head action. Use wp_enqueue_scripts action instead for proper loading. Need help debugging JavaScript errors? Check my WordPress Error Log guide.

Concept 6: Custom Post Types — Organize Content Better

What are custom post types?

Custom post types are powerful WordPress code concepts that let you create your own content types beyond default posts and pages.

Think of custom post types as adding new categories of content with their own admin menus, templates, and archive pages.

How to create custom post types:

function create_tools_post_type() {
    $args = array(
        'labels' => array(
            'name' => 'Tools',
            'singular_name' => 'Tool',
            'add_new' => 'Add New Tool',
            'add_new_item' => 'Add New Tool',
            'edit_item' => 'Edit Tool'
        ),
        'public' => true,
        'has_archive' => true,
        'supports' => array('title', 'editor', 'thumbnail', 'excerpt'),
        'menu_icon' => 'dashicons-admin-tools',
        'rewrite' => array('slug' => 'tools'),
        'show_in_rest' => true  // Enables Gutenberg editor
    );
    
    register_post_type('tools', $args);
}
add_action('init', 'create_tools_post_type');

How to Test If It’s Working:

1. Add the code above to Code Snippets plugin

2. Save and activate

3. Go to WordPress Admin Dashboard

4. Go to Settings → Permalinks (IMPORTANT!)

5. Click “Save Changes” (this flushes rewrite rules)

6. Look in the left sidebar

You should see: A new “Tools” menu item with “Add New Tool” option.

If you get 404 errors:You forgot step 4-5. Always flush permalinks after registering custom post types. Read my WordPress 404 Error guide for more solutions.

Real-world problems custom post types solve:

• Build portfolio sections separate from blog posts
• Create testimonial systems with custom fields
• Add product showcases for services or digital products
• Organize different content types (like my AI tools collection)
• Keep blog posts and other content completely separate
• Create custom taxonomies for better organization

When to use custom post types:

When posts and pages aren’t enough for your content structure. My AI tools collection uses custom post types. Each tool has its own entry, separate from blog posts.

Pro tip: After registering custom post types, always go to Settings → Permalinks and click “Save Changes” to flush rewrite rules. Otherwise, you’ll get 404 errors on your custom post type pages.

Concept 7: WordPress REST API — Access Data Anywhere

What is WordPress REST API?

The WordPress REST API is one of the most modern WordPress code concepts. It lets you access your WordPress content via URLs that return JSON data.

Think of it as opening a window into your WordPress database from anywhere — mobile apps, external websites, JavaScript applications.

How to use WordPress REST API:

You don’t need to write code to use REST API. Just access these URLs in your browser:

Get all posts:

https://yoursite.com/wp-json/wp/v2/posts

Get 5 posts from specific category:

https://yoursite.com/wp-json/wp/v2/posts?per_page=5&categories=12

Search posts:

https://yoursite.com/wp-json/wp/v2/posts?search=wordpress

How to Test If It’s Working:

1. Replace yoursite.com with your actual domain
2. Try this URL in your browser:

https://ceeveeglobal.com/wp-json/wp/v2/posts?per_page=3

You should see: JSON data with post information (title, content, excerpt, etc.)

Common REST API Parameters:

• per_page: Number of posts to return (default: 10)
• categories: Filter by category ID
• tags: Filter by tag ID
• search: Search posts by keyword
• orderby: Sort by date, title, modified, etc.
• order: ASC (ascending) or DESC (descending)
• page: Pagination for large datasets

Using REST API in JavaScript:

fetch('https://yoursite.com/wp-json/wp/v2/posts?per_page=5')
    .then(response => response.json())
    .then(posts => {
        posts.forEach(post => {
            console.log(post.title.rendered);
        });
    });

Real-world problems REST API solves:

• Build headless WordPress sites (WordPress backend, custom React/Vue frontend)
• Create mobile apps that pull WordPress content
• Fetch data for JavaScript applications without page reload
• Integrate WordPress with external services and platforms
• Display WordPress posts on non-WordPress pages
• Build custom dashboards that pull WordPress data

When to use REST API:

When you need WordPress data outside WordPress itself. I use REST API to power some of my FastAPI tools that interact with WordPress data programmatically.

Security note: WordPress REST API is public by default. For sensitive data, use authentication. Most sites disable /wp-json/wp/v2/users endpoint for security. Learn more in my WordPress Security Audit guide.

Concept 8: WordPress Transients — Built-in Caching

What are WordPress transients?

Transients are WordPress’s built-in caching system — one of the most underrated WordPress code concepts for performance optimization.

They provide temporary data storage with automatic expiration. No Redis, Memcached, or external caching plugins required.

How to use WordPress transients:

function get_popular_posts() {
    // Try to get cached data
    $popular_posts = get_transient('my_popular_posts');
    
    // If no cache exists or expired
    if ($popular_posts === false) {
        // Run expensive query
        $args = array(
            'posts_per_page' => 10,
            'meta_key' => 'post_views',
            'orderby' => 'meta_value_num',
            'order' => 'DESC'
        );
        $popular_posts = new WP_Query($args);
        
        // Store in cache for 1 hour (3600 seconds)
        set_transient('my_popular_posts', $popular_posts, 3600);
    }
    
    return $popular_posts;
}

How to Test If It’s Working:

Add this code to test transient speed:

function test_transient_speed() {
    // First load (no cache)
    delete_transient('test_data');
    $start = microtime(true);
    $data = get_transient('test_data');
    if ($data === false) {
        sleep(2); // Simulate slow query
        $data = "Slow data loaded";
        set_transient('test_data', $data, 3600);
    }
    $first_load = microtime(true) - $start;
    
    // Second load (from cache)
    $start = microtime(true);
    $data = get_transient('test_data');
    $second_load = microtime(true) - $start;
    
    echo "First load: " . round($first_load, 4) . " seconds<br>";
    echo "Second load: " . round($second_load, 4) . " seconds<br>";
    echo "Speed improvement: " . round($first_load / $second_load) . "x faster";
}
add_action('wp_footer', 'test_transient_speed');

You should see: First load takes ~2 seconds, second load is almost instant (0.0001 seconds).

Real-world problems transients solve:

• Speed up slow database queries dramatically
• Cache external API responses (like OpenAI, Google APIs)
• Reduce server load on high-traffic WordPress sites
• Improve page load times without complex caching plugins
• Store temporary data without creating custom database tables
• Cache RSS feeds, social media data, weather info

When to use transients:

When you have expensive operations that don’t change frequently. My WP Error Expert tool caches AI responses using transients. Same error searched twice? Instant results from cache instead of calling the API again.

Practical Caching Example:

function get_latest_tools() {
    $tools = get_transient('latest_tools_cache');
    
    if ($tools === false) {
        $args = array(
            'post_type' => 'tools',
            'posts_per_page' => 10,
            'orderby' => 'date',
            'order' => 'DESC'
        );
        $query = new WP_Query($args);
        $tools = $query->posts;
        
        // Cache for 6 hours (21600 seconds)
        set_transient('latest_tools_cache', $tools, 21600);
    }
    
    return $tools;
}

I once reduced a page load time from 8 seconds to 1.2 seconds just by caching one slow WP_Query with transients. That’s the power of proper caching.

Important: Transients are stored in wp_options table by default. For high-traffic sites, use persistent object caching (Redis) for better performance. Check my WordPress Performance Analyzer to see if you need it.

Mastering WordPress Code Concepts: Quick Reference Guide

Here’s a cheat sheet for choosing the right WordPress code concept for your needs:

Save this table. You’ll reference it constantly when building WordPress sites.

How to Practice These WordPress Code Concepts

Understanding WordPress code concepts is one thing. Actually using them is different.

Here’s my recommended learning path:

Week 1: Master WordPress Hooks

• Create one add_action() to add visible content to footer
• Create one add_filter() to modify post content
• Break something, then fix it (seriously, this teaches you)

Week 2: Work with Data

• Build a custom post grid using WP_Query
• Create a simple shortcode for a CTA button
• Test different query parameters

Week 3: Asset Management & Custom Content

• Properly enqueue one CSS file and one JS file
• Register a simple custom post type
• Understand the loading order

Week 4: Advanced Concepts

• Test REST API endpoints on your site
• Implement transient caching on one slow query
• Measure the performance improvement

Don’t try to learn all 8 WordPress code concepts at once. Master one per week. That’s how I learned, and that’s what works.

Common WordPress Code Mistakes to Avoid

After teaching these WordPress code concepts for years, I’ve seen the same mistakes repeatedly:

1. Editing parent theme files directly Always use child themes. Theme updates wipe your changes otherwise. Learn how to create a child theme properly.

2. Forgetting wp_reset_postdata() after WP_Query This causes weird bugs with your main loop. Always reset. I’ve spent hours debugging this mistake.

3. Not sanitizing shortcode attributes Use esc_url(), esc_attr(), and esc_html() to prevent security issues. Never trust user input.

4. Loading scripts without dependencies If your script needs jQuery, specify it: array('jquery'). Otherwise, you’ll get “$ is not defined” errors.

5. Not setting transient expiration Without expiration, transients become permanent database clutter. Always set a reasonable expiration time.

6. Hardcoding instead of using WordPress functions Use get_template_directory_uri() instead of hardcoded paths. Your code will break when you change themes.

7. Not flushing permalinks after custom post types Register a custom post type, then go to Settings → Permalinks → Save. Otherwise, you’ll get 404 errors.

Learn from my mistakes. I’ve made all of these errors and spent hours debugging them.

Tools to Help You Learn WordPress Code Concepts

You don’t have to learn these WordPress code concepts alone. Here are tools that helped me:

1. Code Snippets Plugin — Practice WordPress code safely without editing functions.php directly. If something breaks, just disable the snippet. No White Screen of Death. Download from WordPress.org

2. Query Monitor Plugin — See exactly which hooks fire, database queries run, and where your code slows down. Essential for learning WordPress code concepts. Shows every SQL query, PHP error, and HTTP request.

3. WordPress Code Reference — Official documentation at developer.wordpress.org. Search any function, hook, or class. Bookmark it.

4. My AI-Powered WordPress Tools:

• WordPress Plugin Finder — Find plugins by functionality
• WP Error Expert — AI-powered error diagnosis using my knowledge base
• WordPress Performance Analyzer — Analyze Core Web Vitals and get optimization tips

These tools use the same WordPress code concepts I just taught you. Study how they work.

5. Local Development Environment — Test code on your computer before deploying live. I use Local by Flywheel. Watch my Local by Flywheel tutorial to set it up.

Conclusion: Your WordPress Code Concepts Journey Starts Now

These 8 WordPress code concepts power every WordPress site you’ve ever used — from simple blogs to WooCommerce stores to complex membership sites.

Understanding these fundamental WordPress code concepts transforms you from someone who installs plugins to someone who builds solutions. That’s the difference between WordPress users and WordPress developers.

You don’t need to master all 8 WordPress code concepts today. Start with add_action() and add_filter() — they’re the foundation everything else builds on.

Here’s your action plan:

This week: Try adding one action hook with visible output (like the footer text example)
Next week: Create a simple filter to add reading time to posts
Week 3: Build something custom with WP_Query
Week 4: Start exploring REST API and transients

I learned these WordPress code concepts by breaking things. You will too. That’s okay. Just keep your backups current and learn from every error.

Pro tip from 15 years of WordPress experience: Use the Code Snippets plugin instead of editing functions.php directly. It’s safer, easier to debug, and you can disable snippets without deleting code.

Don’t forget to set up backups before experimenting. Watch my video: Stop Paying for Backup Plugins – Build Your Own with AI in 15 Minutes. I’ll show you exactly how to create a custom backup system that costs $0.

These WordPress code concepts are your foundation. Build on them, experiment with them, break things and fix them. That’s how you become a real WordPress developer.

Which WordPress code concept are you trying first? Drop a comment below. I read every single one and reply with help if you’re stuck. Let’s build something together.

Frequently Asked Questions About WordPress Code Concepts

What are the most important WordPress code concepts for beginners?

The most important WordPress code concepts for beginners are add_action() and add_filter() hooks. These two WordPress code concepts form the foundation of WordPress development. Master hooks first, then move to WP_Query, shortcodes, and wp_enqueue functions. Start with actions and filters — everything else builds on understanding how WordPress hooks work.

What’s the difference between add_action and add_filter in WordPress?

add_action() adds new functionality at specific WordPress events, while add_filter() modifies existing data before display. Actions “do something” (add tracking code, send emails), filters “change something” (modify post content, change titles). Both are essential WordPress code concepts, but serve different purposes. Use actions to insert new features, use filters to transform existing content.

Do I need to edit functions.php to use WordPress code concepts?

No, you don’t have to edit functions.php directly. Use the Code Snippets plugin for safer WordPress code management, or create a custom plugin. Only edit functions.php if you’re using a child theme. Never edit parent theme files — updates will erase your changes. Code Snippets is the safest way to practice WordPress code concepts without risking your site.

Which WordPress code concepts should I learn first?

Learn WordPress code concepts in this order: 1) add_action() and add_filter() hooks (foundation), 2) WP_Query for custom loops, 3) wp_enqueue for loading assets properly, 4) shortcodes for reusable content, 5) custom post types, 6) REST API, and 7) transients. Master hooks first — they’re used in all other WordPress code concepts and understanding them makes everything else easier.

Can WordPress code concepts break my site?

Yes, syntax errors in WordPress code can cause the White Screen of Death. Always backup before adding custom code. Use a child theme or Code Snippets plugin. Test on staging sites first. One missing semicolon can break everything. Learn proper WordPress code concepts to avoid common mistakes and keep your site safe. Read my White Screen of Death guide for recovery steps.

How do WordPress hooks work with themes and plugins?

WordPress hooks (actions and filters) work the same in themes and plugins. They’re core WordPress code concepts that let themes and plugins interact with WordPress without modifying core files. Plugins use hooks to add features, themes use hooks to modify display. Both follow the same WordPress code concepts and execution order. Hooks are the standard way to extend WordPress functionality.

What are WordPress transients used for?

WordPress transients cache temporary data with automatic expiration. Use transients to cache slow database queries, external API responses, or expensive calculations. Transients are essential WordPress code concepts for performance optimization. They reduce server load and speed up sites without external caching plugins. Set appropriate expiration times — I use 1 hour for frequently updated data, 24 hours for static content.

How does WP_Query differ from the default WordPress loop?

WP_Query gives you complete control over which posts display, while the default loop shows all posts. WP_Query is one of the most flexible WordPress code concepts — filter by category, tag, custom fields, dates, post types, and more. Use WP_Query when the default loop isn’t flexible enough. Always use wp_reset_postdata() after custom queries to avoid conflicts with the main loop.

How can I test if my WordPress code is working?

Test WordPress code by adding visible output first. Use echo statements with HTML and CSS styling so you can see results immediately. Don’t use console.log() for initial testing — it’s invisible unless you open browser Developer Console. Start with simple examples like adding colored text or borders. Once you confirm code works, then optimize it. Check my WordPress Error Log guide for debugging tips.

Are WordPress code concepts the same across all WordPress versions?

Core WordPress code concepts (hooks, WP_Query, shortcodes, wp_enqueue) have been stable for years and work across all modern WordPress versions. However, newer features like REST API and Gutenberg support require WordPress 4.7+ and 5.0+ respectively. Always check WordPress documentation for version-specific features. These fundamental WordPress code concepts you learned will work on any WordPress site running version 4.0 or newer.

The post 8 Essential WordPress Code Concepts Every Beginner Should Master (With Real Examples) appeared first on The Beginner’s Playbook for Fixing WordPress Errors.

Why did I create an AI chatbot for my website?

Users coming to my website come from different countries. Their arrival times vary depending on the countries they live in. So if I go to chat with them, I have to put my life under my website.

I wanted to overcome that barrier and provide instant responses to user queries, improving engagement and satisfaction.

It also allowed me to increase my website’s efficiency, automate repetitive tasks, and free up time for more complex issues. Plus it allowed me to increase conversions.

How would you like to be able to go to a website and get instant answers to your questions without waiting for someone to respond?

Basically, that is the main task an AI chatbot can do for your website!

Hence, AI chatbots are becoming a must for any website. That’s because it can accomplish tasks ranging from improving user experience to improving website efficiency and increasing conversions.

Here, I will introduce you to the steps to create a similar or more improved AI chatbot for your website. You can try using the click icon on the bottom right of this page.

By adding an AI chatbot to your website, you can:

Improving user experience

The biggest advantage of an AI chatbot is that it can give very accurate answers to user queries instantly. Imagine a user lands on your website in the middle of the night with a question. A chatbot can provide an immediate response instead of waiting for someone to get back to them. This will make your website more attractive and make your visitors happy.

Increasing efficiency

By automating repetitive tasks, an AI chatbot saves you time. Think about it. Instead of answering the same questions over and over again, you can do it through your chatbot. This allows you to focus on the more complex and important tasks of your website.

Increase conversions

AI chatbots can guide users through your website, helping them find what they’re looking for faster. This can lead to more sales, signups, or whatever else your website may be aiming for and have a positive impact.

In this guide, I’ll walk you through everything you need to know to build your own AI chatbot and integrate it into your WordPress site.

Understanding AI Chatbots: The Core Structure

Before we dive into the technical aspects, it is essential to understand the basic structure of an AI chatbot. It will be very useful for you while building or improving this chatbot.

Key components of an AI chatbot

User Interface (UI): The visual part through which users interact with the chatbot. This is shown in the image above.

Backend: Server-side logic that processes user input and generates responses.

AI Integration: The chatbot’s brain is powered by models like OpenAI.

Overview of how it works

Chatbots capture user input, send it to the backend, where AI processes it, and then displays the response to the user on the frontend.

Step-by-step guide to building your AI Chatbot

Now that you have a basic understanding of AI Chatbot, let’s start building your Chatbot.

I will guide you step by step. Follow these steps very carefully. I have used PHP, HTML, CSS, and JavaScript for this process. Don’t worry I’m not an expert in these things like you. But you can make this process very easy by using ChatGPT or Claude as a support.

However, I am providing all the codes you need here.

AI Chatbot For WordPress

Creating a Chatbot UI

First impressions are the foundation of anything. A good-looking chatbot makes a big difference to your website. Here’s how to design a simple yet attractive chatbot interface.

Essential UI elements

Chat Box: This is where the conversation happens. It shows the chat history between the user and the chatbot.

Input Field: Allows users to type their messages here.

Send Button: This is used to send the message to the chatbot.

To create this UI, you will use HTML and CSS. You can download all related files below.

After entering the AI-chatbot folder, you can see two folders: front and back. Go inside the front folder. There are 4 files as shown below.

Here the chatbot.html file contains everything. But the Index.html, script.js, and style.css files contain only the related things. From there you can use these files appropriately.

Either way, open chatbot.html or Index.html in your browser. Then you will see the chatbot as below.

But you still can’t chat with this.

Set up Chatbot code in the backend

Now that your UI is ready, it’s time to access the code that will make your chatbot work.

1. Install and activate WPCode Lite.

2. Paste the code in the back folder here. Note, the Code Type should be changed to PHP Snippet.
3. Connecting the OpenAI API Key.
   Register on the OpenAI website and get an OpenAI API key. Because our chatbot is powered by the OpenAI API.  Keep this confidential. Next, enter the OpenAI API key in the snippet and save the snippet.

Linking the UI with the backend

Now that your front and back panels are ready, it’s time to connect them together. This is where JavaScript comes into play.

Now open the script.js file in the front folder. You can use Notepad for this. Go there and update your domain name and save the file.

Eg: replace https://YourWebsite.com with your site domain name.

If you did everything correctly, now you just have to open the index.html file again. To your surprise, your chatbot will work like the image below.

Advanced Customisation: Taking Your Chatbot to the Next Level

This chatbot is designed to suit my site. That is, only matters related to WordPress can be chatted through this chat button. When asked about a matter not related to WordPress, it replies, “I am trained to assist with WordPress-related questions. Feel free to ask me anything about WordPress”.

So, how to customise this chatbot for you?

System Prompt Customisation

Customising your AI chatbot’s system prompt is essential to ensure it aligns with the specific needs of your website and the type of interaction you want to have with your users. So here’s how to adjust your system prompt to suit different websites:

1. Understand the purpose of your website

Identify the primary function of your website. Is it an e-commerce site, a blog, a tech support platform or a content-driven site? Your chatbot’s system prompt should reflect the primary purpose and type of queries users might have.

2. Define the scope of the interaction

Clearly state the purpose for which your chatbot is designed. For example, if your website focuses on e-commerce, chatbots can assist with product inquiries, order tracking, or product recommendations. The scope should be narrow enough to keep the chatbot focused but broad enough to handle common user needs.

3. Crafting the System Prompt

Change the language and focus of the system prompt based on the context of the site. Here’s how you can adjust the provided trigger for different types of websites:

Example 1: E-commerce Website:

You are a knowledgeable shopping assistant on our online store. Your task is to help users find products, answer questions about orders, provide product recommendations, and assist with any inquiries related to our store. Engage users in friendly conversations to enhance their shopping experience. Do not respond to questions unrelated to shopping or our products. If asked, politely state that you are here to assist with shopping-related queries.

Example 2: Tech Support Website

You are a tech support specialist. Your task is to help users troubleshoot technical issues, provide guidance on software and hardware products, and assist with inquiries related to our tech support services. Engage users in problem-solving conversations to resolve their technical problems. Do not respond to questions outside of tech support. If asked, politely inform them that you specialize in providing tech support assistance.

Example 3: Blog or Content-Focused Website

You are an expert content guide for our website. Your task is to help users find articles, explain content topics, suggest related posts, and assist with any questions about our blog content. Engage users in informative conversations to enrich their reading experience. Do not respond to questions unrelated to our content. If asked, gently redirect them to the relevant blog topics.

Example 4: Educational Platform

You are an educational assistant for our online learning platform. Your task is to help users navigate courses, answer questions about course content, provide study tips, and assist with any inquiries related to learning on our platform. Engage users in supportive conversations to enhance their learning journey. Do not respond to questions outside of education-related topics. If asked, kindly direct them to the appropriate course material.

4. Enter the brand identity

Make sure the tone and style of the prompt aligns with your brand’s voice. If your brand is casual and fun, the query should reflect that. For a more professional brand, use formal and precise language.

5. Test and Iterate

After customizing your system prompt, test it with real user interactions to see if it meets the intended objectives. Gather feedback and make adjustments as needed to fine-tune the chatbot’s performance.

By customizing your chatbot’s system prompts, you can ensure that it provides relevant, useful and on-brand responses, making your website’s user experience more engaging and effective.

After you prepare your prompt, go to “Add the last prompt to the conversation history” in the Backend Snippet and enter the prompt you prepared.

Then save the code snippet. Depending on the success of your prompting, the output of your chatbot will be successful.

Icon Customization

But your chatbot still has the same icon as my chatbot. Let’s change that too.

Go to “load_chat_bot_base_configuration” and change your user_avatar_url and bot_image_url to the icon you require.

Other minor changes

You can change the Startup Message to suit you. You can also change the font size and commonButtons of your chatbot.

Final Steps: Publishing Your Chatbot on WordPress

Now you can integrate your chatbot into your WordPress website pages.
For that, we are again asking for help in the code snippet.

Go to Header and Footer in the code snippet. Go there and paste the full code, HTML, CSS, and JavaScript, in the footer.

Bonus Tip: If you run into any WordPress errors while setting up your chatbot, don’t worry. My WP Error Expert AI tool can help you fix many errors easily. And if you’re a web developer, check out my other AI tools designed to make your life easier.

Conclusion

In conclusion, integrating an AI chatbot into your WordPress site can significantly enhance user experience, increase efficiency, and drive conversions.

By automating responses to common queries, an AI chatbot ensures that visitors receive instant support, no matter the time of day.

This guide provides a comprehensive, step-by-step process to build and customize an AI chatbot that aligns with your website’s specific needs, whether it’s for e-commerce, tech support, content guidance, or education.

By following these steps, you can create a chatbot that improves customer satisfaction and optimizes your website’s performance, ultimately leading to better engagement and outcomes.

AI Chatbot For WordPress

The post How to Build and Integrate an AI Chatbot into Your WordPress Site: A Complete Guide appeared first on The Beginner’s Playbook for Fixing WordPress Errors.

There, I said it.

Elementor, Divi, Beaver Builder—they’re all fine tools. But they add bloat, slow down your site, and lock you into a subscription just to move a button 10 pixels to the left.

Last month, I rebuilt the hero section for WP Error Expert (my AI tool that fixes WordPress errors). The old one wasn’t converting. Visitors would land, scroll for 3 seconds, and bounce.

I knew I needed a redesign, but I wasn’t about to install Elementor and deal with another $60/year subscription.

Instead, I used Claude AI to generate the entire code for me—complete hero section with headline, CTA button, trust indicators, and a modern gradient background—then pasted it into the free Code Snippets plugin.

Total time: 8 minutes.
Total cost: $0.
Result: A professional Hero Section that actually converts.

Let me show you exactly how to add custom code to WordPress without touching your theme files, without hiring a developer, and without any page builder bloat.

Why I Stopped Using Page Builders (And What I Use Instead)

Look, page builders are great for designers who want drag-and-drop control. But here’s what nobody tells you:

Page builders slow down your site. Elementor alone can add 500KB+ of CSS and JavaScript to every page—even pages that don’t use it. If you’ve dealt with WordPress performance issues or 500 internal server errors, you know speed matters.

They lock you in. Switch themes? Your entire design breaks. Cancel your subscription? Half your features disappear.

They’re overkill. Most of us just need to add a hero section, a CTA block, or some custom styling. Installing a 2MB plugin for that is like buying a bulldozer to plant a flower.

The better way: Use the Code Snippets plugin to add custom code directly to WordPress, and let Claude AI write the code for you.

• No theme file editing
• No subscriptions
• Full control over your code
• Lightweight and fast

This is how I build everything now. And it’s exactly how I rebuilt my hero section in 8 minutes.

What Is the Code Snippets Plugin? (And Why You Need It)

The Code Snippets plugin is a free WordPress plugin with 1+ million active installs. It lets you add PHP, CSS, JavaScript, and HTML to your site without editing your theme’s functions.php file.

Why this matters:

• If you edit functions.php and make a mistake, your site breaks
• If you update your theme, all your custom code disappears
• Code Snippets keeps everything safe, organized, and easy to turn on/off

Think of it like this: instead of modifying your car’s engine, you’re adding a plug-and-play accessory that you can remove anytime.

What you can build with Code Snippets:

• Custom hero sections
• Landing page elements
• Custom styling without CSS bloat
• Shortcodes for reusable content
• Custom functionality without full plugins and more.

I use Code Snippets on every site I build. It’s the first plugin I install after WordPress.

The Problem I Was Trying to Solve

My WP Error Expert homepage had a hero section that looked… okay. But “okay” doesn’t convert visitors.

Here’s what was wrong:

Generic headline that didn’t immediately explain what the tool does
Multiple CTAs competing for attention (classic mistake)
No trust indicators or social proof
Bland white background that looked like every other WordPress site
No clear path from problem → solution → action

The result? People landed, got confused about what the tool did, and left.

I needed a hero section that did one thing well: explain the value in 3 seconds and get people to click.

What I Wanted in My New Hero Section

I simplified everything down to the essentials:

Problem Statement: “WordPress error? Don’t know how to fix it?”
Solution: “Paste error → Get AI solution in seconds”
One Clear CTA: “Try it free now” button
Trust Line: “10,000+ errors solved”
Modern Design: Blue-to-purple gradient (feels like an AI tool)

That’s it. No feature lists, no distractions, no secondary CTAs.

If you’ve ever looked at WordPress 404 errors or database connection problems and felt overwhelmed, you know the power of instant clarity. That’s what I wanted my hero section to deliver.

https://youtu.be/yYfh9Z0vwGU

How to Add Custom Code to WordPress Using Claude AI (Step-by-Step)

Step 1: The Exact Prompt I Used (Copy This!)

Here’s the prompt I gave Claude AI. You can copy this and customize it for your own hero section (Created by Mr Hasan):

Your task is to create a complete and working "Hero section" WordPress code snippet that I can paste directly into the Code Snippets plugin on my WordPress site.

What I Want This Snippet To Do:
Hero section Get attention + one action (click CTA)
Problem: "WordPress error? Don't know how to fix it?"
Solution: "Paste error → Get AI solution in seconds"
Action: "Try it free now" button

Hero section elements (final list):
- Headline
- Subheadline (1 line)
- CTA button
- Trust line (1 line: "10,000+ errors solved")
- Visual (screenshot/demo)
- Background design

Requirements:
- The code should be self-contained
- Focus on making it functional first. I will ask for polishing/optimization later.
- If you want to call an API, don't use ajax, call it from JS using "await fetch"

Shortcode & CSS Naming Rules:
- Prefix all shortcodes with wp-error-hero to avoid naming conflicts.
- If the snippet includes CSS, prefix all class names with wp-error-hero to avoid conflict with the site's theme.

Before generating any code, ask me several clarifying questions to ensure you fully understand what I want. Then generate the full, working snippet only — no explanation or extra text.

Why this prompt works:

1. Clear deliverable — WordPress code snippet for Code Snippets plugin
2. Specific elements — Headline, CTA, trust line, design
3. Technical requirements — Self-contained, no conflicts
4. Naming conventions — Prevents theme conflicts
5. Clarifying questions — Claude asks before generating (critical!)

Step 2: Claude Asks Clarifying Questions (Answer These!)

When I pasted this prompt into Claude AI (free version works fine), it didn’t just spit out code immediately.

Instead, Claude asked me:

• “What URL should the CTA button link to?”
• “Do you want me to include the visual/screenshot in the code, or will you add it separately?”
• “What’s your preferred color scheme for the gradient?”
• “Should this be mobile-responsive by default?”

This is important. Claude’s clarifying questions ensure the code actually fits your needs. Don’t skip this step.

I answered:

• CTA links to /wp-error-expert/
• I’ll add the screenshot separately via WordPress media
• Blue-to-purple gradient
• Yes, fully mobile-responsive

Step 3: Claude Generates the Complete Code

Once I answered, Claude generated a full, working code snippet:

PHP shortcode function (creates [wp-error-hero] shortcode)
Inline CSS (scoped with wp-error-hero prefix to avoid theme conflicts)
HTML structure (headline, subheadline, CTA, trust line)
Responsive design (mobile-first approach)

The code was clean, self-contained, and ready to paste into WordPress.

My Note: This is why I love using AI for WordPress customization. Claude doesn’t just give you generic code—it generates production-ready snippets tailored to your exact needs. If you’re dealing with WordPress installation problems or want to automate fixes, AI can help with that too.

Step 4: Install the Code Snippets Plugin (If You Don’t Have It)

If you don’t already have the Code Snippets plugin installed:

1. Go to Plugins → Add New in your WordPress dashboard
2. Search for “Code Snippets”
3. Install and activate (it’s free, 1+ million active installs)

This plugin lets you add PHP, CSS, JavaScript, and HTML to your site without editing theme files.

Why Code Snippets is better than editing functions.php:

• Mistakes won’t break your site
• Code survives theme updates
• Easy to activate/deactivate snippets
• Organized in one central location

Step 5: Add the Code to Code Snippets Plugin

1. In WordPress admin, go to Snippets → Add New
2. Name the snippet: “Hero Section – WP Error Expert”
3. Paste the entire code Claude generated
4. Set “Run snippet” to “Everywhere” (or “Only on Front End”)
5. Auto Insert: OFF (we want manual control via shortcode)
6. Save and Activate

That’s it. The code is now live on your site, ready to use with a shortcode.

Step 6: Add the Shortcode to Your Homepage

1. Go to Pages → Edit Homepage
2. Add a Shortcode block (Gutenberg/Block Editor)
3. Paste: [wp-error-hero]
4. Update/Publish the page

Refresh your homepage—boom, there’s your new hero section.

The Result: A Hero Section That Converts (No Page Builder Required)

Here’s what my final hero section includes:

Bold headline — Explains what the tool does in 5 seconds
Clear subheadline — Shows the solution in one line
One big CTA button — No competing actions
Trust indicator — “10,000+ errors solved” builds credibility
Modern gradient background — Looks like a professional AI product
Fully responsive — Looks great on mobile and desktop

Best part? It’s just one shortcode. You can:

• Move it anywhere on your site
• Duplicate it for different pages
• Edit the code once and update it everywhere

Why This Method Beats Page Builders

I’ve used Elementor, Divi, and every other major page builder. Here’s why I prefer this approach:

1. No Bloat

Page builders load hundreds of KB of CSS and JavaScript you don’t need. This method only loads the exact code you use.

2. No Subscriptions

Elementor Pro costs $59/year. This? Free. Forever.

3. Full Control

You own the code. Want to tweak something? Edit the snippet. No fighting with a page builder’s interface.

4. Theme-Independent

Switch themes? Your hero section stays intact. No broken layouts. No redesigns.

5. Speed

Lightweight code = faster page load times. Critical for WordPress performance.

If you’ve ever dealt with fatal errors or mixed content warnings caused by page builder conflicts, you know how frustrating plugin bloat can be. This method avoids all of that.

How to Customize This for Your Own WordPress Site

The beauty of this approach? You can adapt it for any WordPress customization you need.

Want a Different Design?

Modify the Claude AI prompt:

• Change the problem/solution statements
• Adjust the color scheme
• Add/remove elements (testimonials, demo videos, trust badges)

Want Multiple Hero Sections?

• Create different snippets with unique prefixes (wp-hero-services, wp-hero-pricing)
• Use different shortcodes for different pages

Want to A/B Test Headlines?

• Create two versions of the snippet
• Test conversions with a WordPress A/B testing plugin

WordPress Code Snippets Plugin Tutorial: Common Questions

“Do I need coding knowledge to do this?”

Nope. If you can copy/paste and follow instructions, you can do this. Claude AI generates the code—you just paste it into the Code Snippets plugin and add the shortcode to your page.

“What if I want to change the headline later?”

Edit the snippet in Code Snippets. Find the headline text in the code, change it, save. The shortcode updates automatically everywhere you’ve used it.

“Can I use this with any WordPress theme?”

Yes! The code is scoped with unique class names (wp-error-hero) so it won’t conflict with your theme’s styles. I’ve tested this with default WordPress themes, Astra, GeneratePress, and custom themes—works every time.

“What if something breaks?”

If you run into issues, check out my guide on enabling WordPress error logs—it’ll help you debug any problems. You can also deactivate the snippet instantly in Code Snippets without affecting your site.

“Is this better than using Gutenberg blocks?”

For simple content, Gutenberg is fine. But for custom functionality with specific design requirements, custom code gives you way more control. Plus, it’s faster and doesn’t require any plugins beyond Code Snippets.

Real-World Use Cases for Custom WordPress Code

Once you learn how to add custom code to WordPress using this method, here are other things you can build:

Landing Page Elements

• Features section
• Pricing tables
• FAQ accordions
• Testimonial carousels

Custom Styling

• Unique button designs
• Custom fonts and colors
• Special hover effects
• Dark mode toggles

Functionality

• Custom shortcodes for reusable content
• Form enhancements
• Custom navigation menus
• WordPress error handling

E-commerce Tweaks

• Custom product displays
• Special checkout messages
• Trust badges
• WooCommerce customizations

The Code Snippets plugin handles all of these without touching your theme files.

Next Steps: Build Your Complete Landing Page with AI

This hero section was just the beginning. In my next tutorial, I’m building the complete landing page:

• Features section (with icons and descriptions)
• How it works (step-by-step visual)
• Pricing/CTA block
• Footer with social proof

All using the same method—Claude AI generates the code, Code Snippets plugin manages it.

Want to follow along? Here’s what to do:

1. Try the hero section prompt I shared above with Claude AI
2. Install Code Snippets plugin if you haven’t already
3. Experiment with the code—change colors, headlines, CTAs
4. Check out my other AI tools at ceeveeglobal.com/tools—I’ve built free tools for content creation and WordPress management

Related WordPress Guides:

• How to Fix WordPress 404 Errors
• Resolving Database Connection Errors
• Fixing 500 Internal Server Errors
• Troubleshooting Publishing Failed Errors
• Understanding 301 Redirects

Final Thoughts: WordPress Customization Without the Bloat

Look, I’m not anti-page-builder. If you love Elementor, use it. But if you’re like me and want:

Fast-loading pages
Full control over your code
No subscriptions
Theme-independent customizations

Then this method is perfect.

I rebuilt my WP Error Expert hero section in 8 minutes using Claude AI and the Code Snippets plugin. It converts better, looks more professional, and didn’t cost me a dime.

Start simple. Build fast. Learn by doing.

That’s how I’ve always approached WordPress development, and it works.

Your Turn: Try This Method

If you try this method, I want to hear about it. Drop a comment below and let me know:

• What did you build?
• Did Claude AI’s code work on the first try?
• What issues did you run into?

And if you get stuck, I’m here to help—just leave your question below and I’ll walk you through it.

Thanks for reading. Now go build something that converts.

Frequently Asked Questions

How do I add custom code to WordPress without breaking my site?

Use the Code Snippets plugin instead of editing your theme’s functions.php file. Code Snippets provides a safe environment for custom code, and you can deactivate snippets instantly if something goes wrong. Always test code on a staging site first.

What’s the best WordPress code snippets plugin for beginners?

The Code Snippets plugin is the best option with 1+ million active installs. It’s free, beginner-friendly, and supports PHP, CSS, JavaScript, and HTML. The WPCode plugin is another excellent alternative.

Can Claude AI write WordPress code for me?

Yes! Claude AI can generate complete WordPress code snippets, including hero sections, custom functionality, and styling. Use specific prompts with clear requirements and answer Claude’s clarifying questions for best results.

Do I need a page builder for WordPress customization?

No. You can build custom WordPress layouts using Claude AI to generate code and the Code Snippets plugin to implement it. This approach is faster, lighter, and gives you more control than page builders like Elementor or Divi.

Will custom code snippets slow down my WordPress site?

No, if implemented correctly. Custom code snippets using the Code Snippets plugin are typically much lighter than page builders. They only load the exact code you need, unlike page builders that load hundreds of KB of unused CSS and JavaScript.

The post How to Add Custom Code to WordPress Without a Page Builder (Using Claude AI + Code Snippets Plugin) appeared first on The Beginner’s Playbook for Fixing WordPress Errors.

But it’s also the file that scares people the most. One wrong edit, and your site can go completely blank.

That’s exactly why I wrote this guide. I’ll show you how to safely find, access, and edit the wp-config.php file — even if you’ve never touched code before. Plus, I’ll share the exact tweaks I use on every site I build.

Let’s dive in.

What is the wp-config.php File? (And Why It Matters)

The wp-config.php file is WordPress’s main configuration file. Think of it as the bridge between your WordPress software and your database.

Without this file, WordPress can’t:

• Connect to your database
• Load your content
• Authenticate users
• Run your site

Here’s what it controls:

• Database connection details (name, username, password, host)
• Security keys and salts (protects against hackers)
• Debug mode settings (shows errors for troubleshooting)
• Memory limits (prevents crashes from resource-heavy plugins)
• Table prefix (adds security layer to your database)

The file gets created automatically when you install WordPress. But knowing how to edit it gives you total control over your site’s behaviour.

Note: I’ve edited wp-config.php hundreds of times over the years. It’s intimidating at first, but once you understand the basics, it becomes one of your most powerful troubleshooting tools. Just always — and I mean ALWAYS — backup first.

Where to Find the wp-config.php File

The wp-config.php file lives in your WordPress root directory. Depending on your hosting setup, this folder is usually called:

• public_html
• www
• htdocs
• Your domain name (e.g., example.com)

You can access this file three ways:

Method 1: File Manager (cPanel)

This is the easiest method if your host uses cPanel.

1. Log in to your hosting cPanel
2. Navigate to Files → File Manager
3. Open the public_html folder (or your site’s root folder)
4. Scroll down until you see wp-config.php
5. Right-click and select Edit

A warning will pop up about editing code. Click Edit again to proceed.

Method 2: FTP Client (FileZilla)

If you prefer FTP access or don’t have cPanel:

1. Download and install FileZilla (it’s free)
2. Get your FTP credentials from your hosting provider
3. Connect to your server using FileZilla
4. Navigate to your WordPress root directory
5. Right-click wp-config.php and select View/Edit

FileZilla will open the file in your default text editor. Make changes, save, and FileZilla will upload the updated file automatically.

Method 3: SSH Terminal (Advanced)

For those comfortable with the command line:

cd /path/to/your/wordpress/
nano wp-config.php

Make your edits, then press Ctrl + X, then Y, then Enter to save.

Pro Tip: On localhost setups like XAMPP or Local by Flywheel, navigate to xampp/htdocs/your-site-folder or wherever your local WordPress installation lives.

CRITICAL: Always Back Up Before Editing

Before you touch wp-config.php, create a backup. This isn’t optional.

If you make a mistake, your entire site can go down instantly. Here’s why:

• One missing semicolon = site crash
• Wrong database password = database connection error
• Incorrect syntax = white screen of death

How to back up wp-config.php:

Option 1: Download via FTP

• Right-click the file in FileZilla
• Select Download
• Save it to your computer as wp-config-backup.php

Option 2: Duplicate via File Manager

• Right-click wp-config.php
• Select Copy
• Name the copy wp-config-backup.php

Option 3: Full Site Backup If your hosting has automatic backups (like Cloudways or WP Engine), create a manual backup before editing anything critical.

My Reality Check: I learned this lesson the hard way. A few years ago, I edited wp-config.php without backing up first. I mistyped one character, hit save, and the entire site went blank. Took me 2 hours to figure out what went wrong. Now I back up every single time — no exceptions.

Understanding the wp-config.php File Structure

Let’s break down the main sections you’ll see when you open wp-config.php.

1. Database Settings

This section connects WordPress to your MySQL database:

// ** MySQL settings ** //
define( 'DB_NAME', 'your_database_name' );
define( 'DB_USER', 'your_database_username' );
define( 'DB_PASSWORD', 'your_database_password' );
define( 'DB_HOST', 'localhost' );

When you’d change this:

• Moving to a new host
• Fixing “Error Establishing Database Connection”
• Restoring from backup with different database credentials

2. Authentication Keys and Salts

These are random strings that encrypt your login cookies:

define('AUTH_KEY',         'put your unique phrase here');
define('SECURE_AUTH_KEY',  'put your unique phrase here');
define('LOGGED_IN_KEY',    'put your unique phrase here');
define('NONCE_KEY',        'put your unique phrase here');
define('AUTH_SALT',        'put your unique phrase here');
define('SECURE_AUTH_SALT', 'put your unique phrase here');
define('LOGGED_IN_SALT',   'put your unique phrase here');
define('NONCE_SALT',       'put your unique phrase here');

When you’d change this:

• After your site gets hacked
• As part of regular security maintenance (every 6-12 months)

How to generate new keys: Visit the WordPress.org Secret Key Generator and copy-paste the generated keys into your file.

3. Database Table Prefix

$table_prefix = 'wp_';

The default is wp_, but you can change it to add a security layer:

$table_prefix = 'wp_a7x9_';

Warning: Only change this during initial setup. Changing it on an existing site requires updating your entire database structure.

4. Debug Mode (Turned Off by Default)

define( 'WP_DEBUG', false );

This controls whether WordPress displays errors on your screen.

5 Essential wp-config.php Edits Every WordPress User Should Know

Now let’s get into the practical stuff. These are the most common edits I make on WordPress sites.

Edit #1: Enable Debug Mode (Troubleshooting Errors)

When something breaks on your site but you can’t see what’s wrong, enable debug mode.

Find this line:

define( 'WP_DEBUG', false );

Change it to:

define( 'WP_DEBUG', true );

What this does:

• Shows PHP errors, warnings, and notices on your screen
• Helps identify plugin conflicts
• Reveals theme issues

Save the file, then visit your site. You’ll now see error messages that were previously hidden.

Important: Turn debug mode OFF once you’ve fixed the issue. Leaving it on exposes sensitive information to visitors and slows down your site.

Bonus: Log Errors to a File Instead If you don’t want errors displayed publicly, log them to a file:

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

This creates a debug.log file in /wp-content/ with all errors recorded privately.

My Tip: I always use the log file method on live sites. It lets me troubleshoot without exposing errors to visitors. Check the WordPress Enable Error Log guide for more details.

Edit #2: Increase WordPress Memory Limit (Fix “Memory Exhausted” Errors)

If you see errors like “Fatal error: Allowed memory size exhausted,” your site is running out of PHP memory.

Add this line before “That’s all, stop editing”:

define( 'WP_MEMORY_LIMIT', '256M' );

What this does:

• Increases PHP memory from the default 40MB to 256MB
• Prevents crashes from resource-heavy plugins
• Allows larger image uploads

You can try 128M first and increase if needed. Most shared hosting plans allow up to 256M or 512M.

Why this happens: Page builders, e-commerce plugins, and image-heavy sites consume lots of memory. This edit gives WordPress more room to work.

For more context on fixing memory issues, check out How to Fix WordPress Memory Size Exhausted.

Edit #3: Change Database Table Prefix (Security Enhancement)

Hackers know the default database prefix is wp_, making it easier to target your tables with SQL injection attacks.

During initial setup, change this:

$table_prefix = 'wp_';

To something random like:

$table_prefix = 'wp_secure2024_';

Only use letters, numbers, and underscores. No special characters.

CRITICAL WARNING: Do NOT change this on an existing site unless you also update every table name in your database via phpMyAdmin. One mistake will break your entire site.

Edit #4: Regenerate Security Keys (After a Hack)

If your site was hacked or you suspect unauthorized access, regenerate your security keys immediately.

Step 1: Visit WordPress.org Secret Key Generator

Step 2: Copy all 8 generated lines

Step 3: Find the authentication section in wp-config.php and replace the existing keys with the new ones:

define('AUTH_KEY',         'new-unique-key-here');
define('SECURE_AUTH_KEY',  'new-unique-key-here');
// ... (replace all 8 lines)

What this does:

• Logs out all users immediately (including hackers)
• Forces everyone to log in again with fresh, encrypted sessions

Dimu’s Security Practice: I regenerate these keys every 6 months as preventive maintenance. Takes 2 minutes and significantly reduces security risks.

For more security hardening tips, see Understanding SSL, HTTP, and HTTPS.

Edit #5: Disable Automatic Updates (Optional)

WordPress auto-updates for security by default. But if you want manual control:

Add this line:

define( 'AUTOMATIC_UPDATER_DISABLED', true );

When you’d do this:

• You prefer testing updates on staging first
• You manage updates manually via WP-CLI or hosting tools
• You have a managed WordPress host that handles updates

Important: Only disable this if you have a reliable update system in place. Security updates protect against known vulnerabilities.

Advanced wp-config.php Tweaks (For Developers)

These are more technical edits that solve specific problems.

Disable Post Revisions (Save Database Space)

WordPress saves every edit as a revision. On large sites, this bloats your database.

Disable completely:

define( 'WP_POST_REVISIONS', false );

Or limit to 5 revisions:

define( 'WP_POST_REVISIONS', 5 );

Change Autosave Interval

Default is 60 seconds. Increase to reduce server load:

define( 'AUTOSAVE_INTERVAL', 300 ); // 5 minutes

Increase Upload File Size Limit

If you need to upload large files:

@ini_set( 'upload_max_size' , '64M' );
@ini_set( 'post_max_size', '64M');
@ini_set( 'max_execution_time', '300' );

Force SSL for Admin Area

define( 'FORCE_SSL_ADMIN', true );

This forces HTTPS for your WordPress admin login and dashboard. For full SSL setup, read Understanding SSL and HTTPS for WordPress.

Move wp-content Directory (Security)

Advanced users can move the wp-content folder to a custom location:

define( 'WP_CONTENT_DIR', '/path/to/new/wp-content' );
define( 'WP_CONTENT_URL', 'https://example.com/new-content' );

Common wp-config.php Errors and How to Fix Them

Error: “Error Establishing a Database Connection”

Cause: Wrong database credentials in wp-config.php

Fix:

1. Check your database name, username, and password
2. Verify with your hosting provider
3. Try changing DB_HOST from localhost to 127.0.0.1

For a complete guide, see Resolving Database Connection Errors.

Error: “White Screen of Death”

Cause: Syntax error in wp-config.php (missing semicolon, quote, etc.)

Fix:

1. Restore your backup immediately
2. Check every line you edited for typos
3. Use a code validator to check syntax

Full troubleshooting guide: Fix WordPress White Screen of Death.

Error: “500 Internal Server Error” After Editing

Cause: PHP syntax error or permission issue

Fix:

1. Revert to your backup
2. Check file permissions (should be 644 for wp-config.php)
3. Review the exact line you changed

More details: Fixing HTTP Error 500 in WordPress.

Best Practices for Editing wp-config.php Safely

After 15 years of working with WordPress, here’s what I’ve learned:

DO:

• Always back up before editing
• Use a plain text editor (Notepad++, Sublime Text, VS Code)
• Test changes on a staging site first
• Document what you changed and why
• Keep your backup file outside the web root

DON’T:

• Never use Microsoft Word or Google Docs (they add hidden formatting)
• Don’t edit directly on a live site without backup
• Don’t share your wp-config.php file publicly (contains database passwords)
• Never leave debug mode enabled on production sites
• Don’t change table prefix on existing sites without database updates

My Workflow:

1. Download the current wp-config.php via FTP
2. Save as wp-config-backup-[DATE].php on my computer
3. Make edits in a local text editor
4. Test the syntax in a code validator
5. Upload to staging site first
6. If everything works, upload to live site
7. Immediately check if site loads properly

Quick Reference: wp-config.php File Location

Shared Hosting (cPanel): public_html/wp-config.php

VPS/Dedicated Server: /var/www/html/wp-config.php /home/username/public_html/wp-config.php

Localhost (XAMPP): C:/xampp/htdocs/your-site/wp-config.php

Localhost (MAMP): /Applications/MAMP/htdocs/your-site/wp-config.php

Localhost (Local by Flywheel): ~/Local Sites/your-site/app/public/wp-config.php

Wrapping Up: Your wp-config.php Cheat Sheet

The wp-config.php file is one of the most powerful files in WordPress. It’s your direct line to:

• Troubleshooting critical errors with debug mode
• Boosting security by changing database prefixes and regenerating keys
• Improving performance by increasing memory limits
• Controlling WordPress behavior at the core level

Key takeaways:

1. Always backup first — One wrong character can crash your site
2. Use debug mode for troubleshooting — It reveals hidden errors instantly
3. Regenerate security keys regularly — Simple 2-minute security boost
4. Increase memory limits if needed — Fixes “memory exhausted” errors
5. Turn off debug mode when done — Never leave it on in production

Dimu’s Final Tip: Bookmark this guide. You won’t edit wp-config.php often, but when you need to, having a trusted reference makes all the difference. I still reference my own notes before making changes — even after 15 years.

Need more help with WordPress errors? Check out:

• How to Clear Cache in WordPress
• Fix the 404 Error in WordPress
• WordPress 500 Internal Server Error
• Use AI to Detect WordPress Errors

Or try the WP Error Expert tool for AI-powered WordPress error analysis.

Have questions about editing wp-config.php? Drop a comment below. I personally respond to every question because I remember what it was like learning this stuff. We’re all in this together.

Frequently Asked Questions (FAQs)

Can I delete the wp-config.php file?

No. Deleting wp-config.php will completely break your WordPress site. WordPress needs this file to connect to the database. If it’s missing, you’ll see the WordPress installation screen instead of your site.

Where is the wp-config.php file located in WordPress?

The wp-config.php file is in your WordPress root directory, usually public_html or www. Access it via FTP, File Manager (cPanel), or SSH terminal.

What happens if I edit wp-config.php wrong?

If you make a syntax error, your site will likely show a white screen, “Error Establishing Database Connection,” or 500 Internal Server Error. This is why backing up before editing is critical — you can restore the working version immediately.

Is it safe to edit wp-config.php?

Yes, as long as you follow best practices: backup first, use a plain text editor, avoid Microsoft Word or Google Docs, test on staging first, and document your changes. Thousands of WordPress developers edit this file daily without issues.

How do I enable debug mode in WordPress?

Open wp-config.php and change define( 'WP_DEBUG', false ); to define( 'WP_DEBUG', true );. This displays PHP errors on your site. Turn it off after troubleshooting by changing it back to false.

Can I edit wp-config.php from WordPress dashboard?

No. WordPress intentionally does not allow editing wp-config.php from the dashboard because one mistake could lock you out completely. You must access it via FTP, File Manager, or SSH.

What are WordPress security keys and salts?

Security keys and salts are random strings in wp-config.php that encrypt your login cookies. They protect against session hijacking and brute force attacks. Regenerate them regularly for better security using the WordPress.org key generator.

How do I increase the WordPress memory limit?

Add this line to wp-config.php before “That’s all, stop editing”: define( 'WP_MEMORY_LIMIT', '256M' );. This increases memory from 40MB to 256MB and prevents “memory exhausted” errors.

The post How to Edit wp-config.php File in WordPress: Complete Beginner’s Guide (Security, Debug & Performance) appeared first on The Beginner’s Playbook for Fixing WordPress Errors.