标签：#wordpress

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