标签：#WordPress

I started a gaming guide blog six weeks ago. Twenty-one articles later, it's getting traffic from Google, I have four affiliate programs set up, and I have never written a single line of code. This is not a "how to make money blogging" post. This is a practical breakdown of the tools, the workflow, and the mistakes I made so you can skip them. The blog is yxgonglue.com. It covers PC and console game guides — GTA VI pre-order comparisons, VPN setups for gaming, cloud gaming platform rankings, extraction shooter loot guides. Niche stuff. The kind of content people search for when they have a specific problem. Here is the stack that runs it. THE STACK WordPress + Kadence Theme Hosted on a standard shared hosting plan. Kadence is a free WordPress theme that loads fast and does not fight you. No page builder. No Elementor. Just the block editor and Kadence blocks for tables and formatting. The biggest lesson here: your theme does not matter as much as your content structure. Pick something lightweight. Stop theme-shopping. Start writing. Yoast SEO The free version. It gives you a red/yellow/green score for each post based on keyphrase density, subheading distribution, link count, and meta length. Is it perfect? No. Is it a useful checklist for someone who does not do SEO for a living? Absolutely. One thing Yoast taught me the hard way: Custom HTML blocks are invisible to the plugin. If you paste your article into a Custom HTML block, Yoast reads zero words, zero links, zero headings. Everything turns red. Use the regular editor. If you need a table, use a table block. Keep it simple. Google Search Console This is where you see what people actually searched before they clicked your article. The gap between what you think people search for and what they actually search for is enormous. Search Console closes that gap. Submit every new post URL manually. It takes ten seconds. Do not wait for Google to discover your site on its own. THE CONTENT WORKFLOW One Article Per Day Tw

If you drive the WordPress admin via Playwright for long enough, one day a screen you've never seen before will appear after login , and everything downstream stops working. Is admin@example.com still the correct admin email address? [ Yes, the email is correct ] [ Change the address ] That's WordPress's admin email confirmation screen . Roughly every six months, after the admin user logs in, this confirmation screen gets injected — standard behavior since WP 4.9. A human just clicks once. An automation script can't see it without explicit handling. Why automation gets stuck A straightforward Playwright login looks like: page . fill ( ' #user_login ' , user ) page . fill ( ' #user_pass ' , pwd ) page . click ( ' input[type= " submit " ] ' ) page . wait_for_load_state ( ' domcontentloaded ' ) # Assumes we're on the dashboard page . goto ( ' /wp-admin/plugins.php ' ) But on a "confirmation day," the URL right after wait_for_load_state is something like /wp-admin/profile.php?...action=confirm_admin_email... — the confirmation screen. You thought you were navigating to the plugins page, but the DOM you expected isn't there. Subsequent selectors fail, and everything downstream cascades into failure. A specific selector identifies the screen WordPress's confirmation screen has a uniquely-named submit button: <input type= "submit" name= "correct-admin-email" value= "Yes, the email is correct" /> If input[name="correct-admin-email"] exists on the page, you're on the confirmation screen. The same selector serves as both the detection signal and the click target , so handling is only a few lines: admin_email_confirm = page . locator ( ' input[type= " submit " ][name= " correct-admin-email " ] ' ) if admin_email_confirm . count () > 0 : logger . info ( " Confirmation screen detected — clicking ' email is correct '" ) admin_email_confirm . first . click () page . wait_for_load_state ( ' domcontentloaded ' , timeout = 30000 ) Insert this after the post-login wait_for_load_state

You open the "Updates" page in WordPress admin and see that Elementor Pro / ACF Pro / vk-blocks-pro have updates available. Then you run wp plugin update --all from your automation, and those exact plugins don't update. The asymmetry — "the admin sees it; WP-CLI doesn't" — traces back to how WordPress detects updates and how premium plugins layer proprietary update mechanisms on top of that. Here's the mechanism and how an automation tool can adapt. WordPress update detection is held by a transient cache WordPress doesn't decide "is there an update?" on every request. It caches the answer in the wp_options table as a transient, valid for up to 12 hours. The key entries: _site_transient_update_plugins — latest plugin versions _site_transient_update_themes — themes _site_transient_update_core — core If those transients are stale, even a version that just shipped on wordpress.org reads as "no update needed." WP-CLI consults the same transients, so stale cache = WP-CLI misses the update too . In one customer environment on ConoHa WING, we reproduced "version X is on wordpress.org, WP-CLI doesn't see it" directly. Trap 1 and fix 1 — force-refresh the transients before listing updates The first step was simple: at the start of a maintenance run, delete the three transients before querying the update list . def _flush_update_transients ( self , conn , wp_cmd , wp_path , site_name ): """ Delete update transients between DB backup and update step """ for t in ( " update_plugins " , " update_themes " , " update_core " ): conn . run ( f " { wp_cmd } transient delete { t } --path= { wp_path } " , warn = True , hide = True , ) Deleting the transients triggers a rebuild on the next wp plugin list --update=available . During the rebuild, WordPress reaches out to wordpress.org, so the returned list reflects the current release state . That handled the "we were just reading a stale cache" cases. But it didn't help with premium plugins. Trap 2 — with --skip-plugins , Pro updater filt

Before I released my own AI chatbot plugin, I ran it through a security review. It came back with 35...

You update WordPress on a quiet afternoon — a routine release, the kind you've installed a hundred times. The dashboard says everything went fine. Then the 404s start: not a handful, but every long-headlined article in your archive, all at once, all in Arabic. Nothing in the update log mentions it. No plugin changed. And the cruel part: the data that made those URLs work is already gone — shaved off inside a database-upgrade routine that ran for a few milliseconds and reported success. This isn't a freak accident or a broken plugin. It's three separate assumptions baked into WordPress core, each hard-coding the same number — 200 — and Arabic sites are almost uniquely exposed to all three. We hit this running WordPress for Arabic newsrooms, the same high-traffic publishing we've written about surviving breaking-news spikes . We traced it to the exact lines in core and built a fix that survives every future update. Here's the whole story. Why Arabic URLs hit a wall English never does WordPress stores a post's slug in the post_name column of wp_posts , and a category or tag slug in the slug column of wp_terms . Both are VARCHAR(200) by default — room for 200 characters, which for an English headline is generous. "Everything you need to know about our new pricing" is barely fifty. You'd have to write a paragraph to run out. Arabic is a different arithmetic, because of what WordPress actually stores in that column. It doesn't keep the raw Arabic text — it stores the percent-encoded form, the same %XX sequence that travels in the URL. Take a single word: الذكاء → %d8%a7%d9%84%d8%b0%d9%83%d8%a7%d8%a1 Every Arabic letter is two bytes in UTF-8, and every byte becomes a three-character %XX token. So one Arabic character costs about six characters of column space. Do the division: VARCHAR(200) holds roughly 33 Arabic characters. A normal news headline — "القبض على المتهمين في قضية الاحتيال الإلكتروني" — blows past that before it's halfway done. So Arabic publishers learn early

Static sites are great: fast, cheap to host, almost nothing to attack. Then you add a contact form and hit the same wall everyone hits — a static site can't process a submission. You need a backend. The usual answers are a third-party service (Formspree, Netlify Forms, Basin) or a small server you now have to babysit. Both add a dependency you don't control, a recurring bill, and — the part that bugs me most — your submission data lives on someone else's infrastructure. There's a third option I've been running for a while: one WordPress install, zero public pages, used purely as a form endpoint. Every form from every static site I own hits it. I own all the data. And because it serves no public HTML, its attack surface is close to nothing. The architecture Three pieces, each doing one job: WordPress — the backend. Locked down so hard it doesn't behave like a normal WP site anymore. A form plugin — handles building, validation, storage, email, file uploads. (I use CraftForms because it exposes a clean craftforms/v1 REST namespace and can also serve the form HTML to an external page — more on that below.) Your static frontend — Cloudflare Pages / Netlify / wherever. It either fetch es the REST endpoint on submit, or drops in an embed snippet. WordPress never serves a public request. It only processes submissions. The part that matters: locking it down The biggest WordPress attack vector isn't your host — it's outdated plugins . So the first move is brutal minimalism: one plugin, no theme, no page builder, no public frontend. A WP install with one plugin and a blocked frontend has almost no CVE surface, because none of the usual stuff is installed. The rest is one must-use plugin. Drop this in wp-content/mu-plugins/ (no activation needed) and you've blocked the four standard entry points: <?php if ( ! defined ( 'ABSPATH' ) ) exit ; // 1. Restrict the REST API to your form namespace only. // Kills user enumeration (/wp/v2/users), route discovery, the usual REST exploits

If you're shipping a commercial WordPress plugin, sooner or later you'll need a licensing system. Something that lets paying customers activate the plugin on their site, locks it to that domain, and stops people from sharing the same key across fifty sites. The default answer in the WordPress world is Freemius or EDD Software Licensing. They're great. They're also a revenue share, a third-party dependency, and a black box you don't control. When we built RideCab WP , a commercial WooCommerce taxi booking plugin, we decided to build our own. Here's the architecture, the code, and the gotchas we hit along the way. What a Licensing System Actually Needs to Do Before writing any code, get clear on the requirements. A real plugin licensing system needs to: Generate unique license keys when someone buys Let the customer activate the key on their site Bind that key to one (or N) domains Validate the key periodically so revoked or expired keys stop working Handle deactivation when a customer moves to a new domain Fail gracefully — never lock a paying customer out because your license server hiccuped Optionally: deliver plugin updates only to valid license holders We'll cover 1 through 6 in this post. Update delivery is a separate beast and I'll write it up next. The Architecture The system has two halves that live in two different places. The license server runs on your own infrastructure — for us, it's a WordPress must-use plugin (mu-plugin) on the same WordPress install that powers our marketing site. It: Stores license keys in a custom database table Exposes a small REST API for activate, deactivate, and validate calls Provides an admin dashboard to view, create, and revoke keys The client is a PHP class shipped inside the commercial plugin (RideCab WP, in our case). It: Adds a license settings page to the plugin Calls home on activation Caches the validation result Re-validates quietly in the background Two pieces, talking over HTTPS, with the customer's domain as the b

WordPress VIP’s latest survey suggests consumers are wary of AI-generated answers even as companies increasingly view AI search as an important referral channel.

WordPress maintenance automation has a long-running market, especially outside Japan. ManageWP, MainWP, WP Umbrella, InfiniteWP — each has more than a decade of history behind it. While building our comparison pages, we surveyed all four side by side. An interesting pattern emerged: three things none of the four tools offer . Each is a gap the industry has long treated as "not feasible," and there are structural reasons why. Here's a look at those three unsolved areas — and why they remain unsolved. Gap 1 — Per-plugin updates with HTTP checks between each one In most maintenance tools, plugin updates run in bulk . After the batch, the tool takes a sitewide screenshot diff or HTTP status check, and if anything is broken, "Safe Updates" or "Atomic Updates" features roll everything back at once . Why isn't "one at a time with an HTTP check between each" the standard? The main reason is API design constraints . WordPress's built-in wp_ajax_update-plugin and Worker-plugin APIs (like ManageWP Worker) are designed around batch processing. Doing an HTTP probe from an external host after every single update would add significant per-update overhead. The industry has settled on "bulk update → bulk check" as the natural granularity. The side effect: identifying which plugin caused the breakage often falls to the operator's manual investigation. Gap 2 — Pinpoint rollback (only the one that broke) The industry-standard "Safe Updates" feature is fundamentally a "roll back everything" design. If 20 plugins are batched together and one breaks the site, all 20 updates revert. It's a safety-first choice — but operationally, it means the 19 that finished cleanly are also lost. Why isn't pinpoint rollback (revert only the one that broke) the standard? The root cause is state-management complexity . To pinpoint rollback, you need to keep the pre-update files of each plugin individually. Storage, transfer cost, and dependency consistency checks become impractical over a Worker-plugin HTT

Among WordPress maintenance tools, InfiniteWP is one of the most established names. Released by Revmakx in 2011, the tool has been operated continuously for over a decade. It enjoys deep loyalty from agencies that have invested years building operational know-how around it . We at WP Maintenance Manager take a different approach, and our comparison pages outline where the two diverge. But before talking about differences, the strengths of InfiniteWP deserve to be stated honestly . Here are the five points where InfiniteWP fits an agency particularly well. 1. Over a decade of operational track record InfiniteWP's biggest structural advantage is trust built across more than a decade of continuous operation . Released in 2011 — one of the oldest tools in the space A large base of long-time English-speaking users with shared operational patterns Well-defined upgrade paths from older versions Backward compatibility with existing workflows and scripts has been maintained for years For agencies already invested in InfiniteWP, switching tools means more than "migration work" — it means rebuilding the operational know-how accumulated over years . Continuing to use a tool with proven track record is, in itself, a strength that long-running platforms have. The temporal depth that newer tools simply cannot replicate is a meaningful selection reason for conservative industries — those reluctant to substantially change established workflows. 2. Self-hosted — full control of the dashboard InfiniteWP is self-hosted by default , letting you place the dashboard on your own server (a cloud-hosted version is available separately). Host on infrastructure you own Complete data ownership No dependency on external SaaS Arbitrary customization possible When the constraint is "client data must not sit in a third-party SaaS" or "our security policy doesn't permit SaaS," InfiniteWP's self-hosted architecture is a direct answer. If your team has experience operating PHP / WordPress infrastructu

📝 Originally published on unfoldcms.com — reposted here for the DEV community. (I work on UnfoldCMS.) WordPress's market share among CMS-using websites dropped from 65.2% in 2023 to 60.2% by Q1 2026, contracting -2.9% year-over-year for the first time in over a decade. The platform that built the modern web is losing share to Wix, Squarespace, Shopify, and an emerging headless category — and the trend is steeper among newly-built sites than the headline number suggests. This post is the data-driven take on WordPress market share declining in 2026 — where the numbers actually come from, where the lost share is going, what age-cohort analysis reveals about the trajectory, and what the developer-signal data (Stack Overflow, GitHub) shows about who's still building on WordPress versus moving on. TL;DR : WordPress isn't collapsing — 60% market share is still dominant — but the lead has shrunk for the first time in 10 years, the cohort of new sites is breaking away faster than the overall number suggests, and the developer mindshare is leaving even faster than market share. The structural pressures (security, performance, plugin tax, modern stack expectations) all point the same direction. The audience: developers, agencies, and CTOs trying to read the WordPress market trend before committing to a multi-year platform decision. If you've been told "WordPress is sinking" or "WordPress is fine, market share gossip is overstated," this post puts numbers behind the actual movement. For the broader context on why WordPress is losing share, see why developers are leaving WordPress: 7 pain points and WordPress vs modern CMS: honest feature comparison . The Headline Numbers Three primary sources track CMS market share. They don't agree exactly, but they all show the same direction: W3Techs (the most-cited dataset, scans the top 10M websites): Metric 2023 Q1 2024 Q1 2025 Q1 2026 Change WordPress share among CMS-using sites 65.2% 64.1% 62.4% 60.2% -5 points in 3 years WordPress shar

"How do I hide wp-admin" is one of the most-searched WordPress security questions, and most answers give the same advice: install a plugin that renames your login URL. That advice isn't wrong. It's just answering a smaller question than the one being asked. Renaming /wp-login.php to /my-login moves the login form. It does not change what answers at the old path, what your plugin folders advertise, or what your home page tells a scanner about the stack underneath. If your only problem is the password-guessing bot hammering the default form, a renamer solves it. If your problem is "stop my site from being identified and targeted as WordPress," you've solved maybe a third of it. Here are the three leaks a login rename leaves open. Leak 1: the old path still costs a full WordPress boot When a login-URL renamer "blocks" the default path, the request to /wp-login.php still loads WordPress. PHP starts, the plugin stack initializes, and only then does the plugin decide to return a 404 to the logged-out visitor. The visitor sees a 404. Your server still did the work of booting WordPress to produce it. On a quiet site, nobody notices. On a site taking tens of thousands of probes a day, that's tens of thousands of full WordPress boots spent generating 404s. Your security dashboard's "attempts blocked" counter looks great. Your CPU graph disagrees. The architectural alternative is to reject the request at the rewrite layer, before PHP runs: # Apache .htaccess — reject the default login path at the server level < IfModule mod_rewrite.c > RewriteEngine On RewriteCond %{REQUEST_URI} ^/(wp-login\.php|wp-admin) [NC] RewriteCond %{HTTP_COOKIE} !wordpress_logged_in [NC] RewriteRule .* - [R=404,L] </ IfModule > # nginx — same idea, requires a config reload after change location ~ * ^/(wp-login \ .php|wp-admin) { if ( $http_cookie !~* "wordpress_logged_in") { return 404 ; } } The probe to the old path returns 404 from the server, WordPress never loads, and the request costs almost nothi

Every headless WordPress conversation starts the same way — someone draws an architecture diagram with arrows pointing from a REST API to a shiny Next.js frontend, and it looks clean. Too clean. This is a post about what happens when you close the whiteboard and open the actual codebase. The Stack Decision: GraphQL vs. REST vs. Direct MySQL This is usually the first fork in the road. For this build, the client already had a well-indexed WooCommerce site. The product catalog, slugs, and taxonomy structure were already doing heavy SEO work. So the constraint was simple: nothing about the data layer changes, only how we consume it. WPGraphQL was a real option — but it meant adding a plugin dependency to a WordPress install we were actively trying to slim down. The WP REST API was already there, no installation required, and exposed exactly what we needed: products, categories, pages, and media — all queryable by slug. The decision: WP REST API, consumed server-side via Next.js fetch in Server Components. // Fetching a product by slug — preserving the existing URL structure const res = await fetch ( ` ${ process . env . WP_API_BASE } /wp/v2/product?slug= ${ params . slug } &_embed` , { next : { revalidate : 3600 } } ); const [ product ] = await res . json (); No new dependencies on the WordPress side. The legacy install runs as a lean shell — no active theme, minimal plugins, just the REST API and the data. The Site Kit Problem: Bridging Familiar Workflows This is where most migrations quietly fail the client. The previous team lived inside WordPress admin. Google Site Kit gave them traffic stats, Search Console data, and Analytics — all surfaced in a UI they knew. Ripping that away and telling them "just use Google Analytics directly" is a workflow regression, not an upgrade. The pivot here was building a lightweight admin dashboard as part of the Next.js project — not a full replacement for Site Kit, but a mirror of the metrics they actually checked daily: Page views

Hey everyone! Our team and I (acting as a junior backend) recently finished rebuilding GlobeVM (an enterprise Cloud, IT, and Cybersecurity provider) from a traditional monolithic WordPress site into a Headless architecture. I wanted to share our entire journey, our tech stack, the massive headaches we faced, and the solutions we engineered. If you are planning a Headless WP build soon, grab a this might save you weeks of debugging! The Tech Stack Frontend: Next.js (App Router), React, deployed on Vercel. Backend: WordPress hosted on Cloudways (Purely as a headless CMS). Data Structure: Advanced Custom Fields (ACF Pro) + Custom Post Type UI (CPT UI). SEO: Yoast SEO Premium (via REST API). Caching: Vercel Edge Cache (ISR) + Redis Object Cache on Cloudways. During the development and deployment of this website we faced several issues containing the frontend stack itself and traditional features of WordPress. I tried my best to save them all and show them all up here for everyone so that we can discuss on every section of it, maybe we could reach to even something more special :) Challenge 1: The API Was a Mess ("BFF" Architecture) When we first started, we were using the default WordPress REST API. Our Next.js frontend was making 8 different fetch() calls just to build the Blog Homepage (fetching posts, authors, categories, tags, ACF fields, etc.). We were also using messy URLs like ?_fields=id,title,acf&_embed. The Solution: We built a Backend-For-Frontend (BFF). Instead of Next.js doing the heavy lifting, we wrote a custom PHP plugin in WordPress. We created a single master endpoint (/wp-json/gvm/v1/blog-home). WordPress ran all the complex database queries, bundled the Tags, Hero Article, and Categories into one beautiful JSON array, and cached it in RAM using Transients & Redis. Only one of WordPress default api was used for our categories. Result: Next.js made one fetch call. The page loads instantly.' Challenge 2: Handling Vector Icons & ACF Our design heavily re

The Hook: The 48-Hour Re-Infection Nightmare It’s a scenario that keeps e-commerce founders and agency directors awake at night: You wake up to a critical alert that your flagship WordPress site is redirecting users to a spam domain. You immediately deploy a premium security plugin, run a deep scan, quarantine three suspicious files, and breathe a sigh of relief. The scanner gives you a green checkmark. You're safe. Then, exactly 48 hours later, the redirects return. What went wrong? The automated scanner checked the surface, but the attacker had already established a foothold deeper in the architecture. They didn't rely on a loose PHP file in your uploads directory; instead, they weaponized an overlooked, unauthenticated WordPress REST API endpoint to re-inject the payload the moment your scanner turned its back. When high-value enterprise sites are compromised, treating the symptoms with standard security plugins is like putting a band-aid on a structural fracture. To truly remediate a persistent infection, you must think like a forensic analyst, hunt down hidden persistence mechanisms, and harden the application perimeter. The Anatomy of Persistence: Where Malware Hides Modern WordPress malware is sophisticated. Attackers know that standard security tools look for modified core files or rogue scripts in the /wp-content/plugins/ directory. To survive cleanups, they embed themselves into the core infrastructure of your site using three primary vectors: 1. wp-config.php Pre-Loading Attackers frequently inject obfuscated code directly into the top of wp-config.php . Because this file executes before the rest of the WordPress core loads, malware can hook into the initialization process, silently recreating deleted malicious files every time a page is requested. 2. Malicious Must-Use (MU) Plugins Files placed in /wp-content/mu-plugins/ are executed automatically by WordPress and cannot be disabled from the admin dashboard . Attackers love this directory. They will ofte

Recently, I started building a website for a local car showroom. The budget? 800,000 Indonesian Rupiah (around $50 USD). At first, it sounded impossible. But when working with small businesses in Indonesia, budgets are often very different from what many developers in the US or Europe are used to. Instead of building a complex custom platform, I focused on solving the showroom's real problems. What the client gets Vehicle Management Add and edit car listings Manage prices Vehicle specifications Featured inventory Vehicle Search & Filters Visitors can filter cars by: Brand Model Year Price Condition Built-in CMS The showroom can publish: Car buying guides Automotive news SEO articles Promotions Lead Generation Every car listing includes direct WhatsApp contact buttons to maximize inquiries. Extra Services Included For the same price: Free maintenance for simple issues Free consultation and support 3 free blog articles during the first month AI-powered statistics assistant Why WordPress? Many developers immediately think about Laravel, React, Next.js, microservices, and other modern stacks. For this project, WordPress was the right tool. The client needed: A website they could update themselves Better Google visibility A simple inventory system More WhatsApp leads WordPress delivered all of that quickly. A Lesson I've Learned Small businesses rarely care about technology. They care about outcomes. They don't ask: "Does it use React?" They ask: "Will this help me sell more cars?" And honestly, that's probably the better question. What would you include in a low-budget car showroom website?

A WordPress plugin update breaks the site. You SSH in to roll back the bad plugin with WP-CLI, and you get this: Fatal error : Uncaught Error : ... in / path / to / broken - plugin / main . php : 42 The plugin you came to fix has now stopped the tool you came to fix it with. It looks contradictory, but it makes sense once you know how WP-CLI starts up — and there's a flag pair that gets you out. Why WP-CLI itself crashes When you run a rollback command like wp plugin install <name> --version=X --force , WP-CLI internally boots WordPress before doing anything else . Plugin registration and option loading all happen during WordPress's startup, so a broken plugin gets loaded there, throws a fatal, and takes the WP-CLI process down with it. The sequence: WP-CLI boots WordPress WordPress loads the active plugins The broken plugin throws a fatal WP-CLI exits before ever reaching the file-replace step The actual rollback (downloading the PHAR, overwriting the plugin directory) never gets a chance to run. The fix — safe-mode flags WP-CLI has two startup flags, --skip-plugins and --skip-themes . With both set, WordPress's startup skips loading any plugins and themes at all . wp plugin install <name> --version = X --force --skip-plugins --skip-themes File-system operations (downloading the PHAR, unpacking it, replacing files) don't depend on plugin code, so they run fine. The broken plugin never gets loaded at boot, so it never fatals, and the rollback completes. Should you set these flags everywhere? You might think "why not just add these to every WP-CLI command by default?" But some commands genuinely need plugins or themes loaded. wp cache flush relies on the object-cache plugin's hooks. wp doctor reads diagnostic information that plugins register. Setting safe-mode flags on those would break them in subtle ways. The practical split: file-operation commands always get --skip-plugins --skip-themes . Cache and diagnostic commands don't. That single rule eliminates the worst

If you have ever run a Lighthouse audit on a content-heavy WordPress site, you know the usual verdict: "Serve images in next-gen formats." Translation: your JPEGs and PNGs are too heavy, and WebP would cut them down a lot. The problem is that nobody wants to convert images by hand, and most automated options either run as a bulk job you have to remember to trigger, or push your images to a cloud service with a monthly quota. I wanted something simpler: upload an image, get a WebP, done. So I built a free plugin called Pixellize Image Optimizer , and this post walks through the problem, how the plugin solves it, and how it works under the hood. Why WebP is worth it WebP files are usually 25 to 35 percent smaller than the equivalent JPG or PNG at the same visual quality. On an image-heavy page that is a real difference: Faster Largest Contentful Paint, which is one of the Core Web Vitals Google uses for ranking. Less bandwidth, which matters if you pay for CDN traffic. No visible quality loss at sensible quality settings. Browser support is no longer a concern. Every current browser handles WebP. The approach: convert on your own server, on upload Instead of a cloud API, the plugin converts images locally with the PHP GD or Imagick extension (almost every host has one). There is no account, no API key, and no paid tier. The core flow: You upload an image to the Media Library as usual. The plugin generates a WebP version of the full image and every thumbnail size. Your front end serves the WebP automatically. How it works under the hood For WordPress developers, here is the interesting part. The plugin hooks into the standard upload and rendering pipeline rather than fighting it: On upload, it taps into the attachment metadata generation so it can convert the full image and every registered sub-size, not just the original. That matters because responsive images use srcset , and a half-converted set defeats the purpose. On the front end, it rewrites image URLs to the We