标签：#WordPress

This post has two halves: what "escape your output" actually means once the obvious answer stops working, and then a study of whether current AI assistants get that harder version right. It continues a series on what coding assistants actually produce when a non-expert asks them for WordPress code. Start with a line that passes review and still leaves a hole: echo '<a href="' . esc_html ( $url ) . '">Visit</a>' ; There is an escaping function wrapped around the value. A grep for esc_ finds it. A quick review passes it. Now set $url to javascript:alert(document.cookie) . The link still runs when the visitor clicks it. esc_html() escapes characters that matter in HTML text, like < and > . It does nothing about a dangerous URL scheme. The code is escaped. It is escaped for the wrong context. From the outside, correct escaping and wrong-context escaping look identical. A URL is a different context and needs its own escaper. That escaper is esc_url() , and it returns an empty string for a javascript: URL. Which escaper goes where Escaping is context-dependent. "Sanitize on input, escape on output" is the rule the first post of this series covers, but "escape on output" hides a second decision: which escaper. The answer depends on where the value lands on the page. Where the value lands Escaper Visible text between tags ( <p>HERE</p> ) esc_html() Inside an attribute ( title="HERE" ) esc_attr() A URL slot ( href="HERE" , src="HERE" ) esc_url() , which also enforces a safe scheme Inside a tag attribute that holds JavaScript ( onclick="greet('HERE')" ) esc_js() , scoped to this slot by core's own documentation Any value handed to JavaScript inside a <script> block ( var data = HERE ) wp_json_encode() , which writes its own quotes; add JSON_HEX_TAG when the value is untrusted HTML you want to keep, like a formatted post body wp_kses() with an explicit allow-list Six functions, one job each. The mistake is almost never "forgot to escape". It is "escaped for the wrong context",

Every A/B testing tutorial ends the same way: run the test, wait for significance, ship the winner. Then you run a real test and variant B converts 12% better on newsletter signups, brings in 4% less revenue per visitor, and bounce is flat. Nothing is significant except the signups. Ship it? I spent an embarrassing amount of time on this question while building an A/B engine, and most of what I read online didn't help, because most of it assumes one metric. This post is what I ended up with. It's not novel — the statistics are decades old — but I couldn't find it written down in one place with working code, so here it is. Why the p-value doesn't answer the question you're asking Two problems, and the second one is the bad one. Multiple comparisons. Three metrics at α = 0.05 means roughly a 14% chance of at least one false positive if nothing is actually different. Bonferroni fixes this, but now you need α = 0.017 per metric and your test needs to run three times as long. On a site doing 300 conversions a month that's not a fix, it's a refusal. The p-value is answering a different question. It tells you the probability of your data assuming no difference exists. What you actually want to know is: if I ship B, how much do I expect to lose if I'm wrong? Those are not the same question and no amount of Bonferroni turns one into the other. There's also the peeking problem — everyone checks the dashboard daily and stops when it goes green, which quietly inflates the false positive rate well past whatever α you wrote down. I'll come back to that, because Bayesian methods do not magically solve it, whatever you may have read. Posterior first, decision second For a conversion rate, the Beta-Binomial conjugate pair gives you the posterior in one line. With a uniform prior, after c conversions out of n visitors: p | data ~ Beta ( 1 + c , 1 + n - c ) That's it. No closed-form comparison between two Betas that's worth implementing, so sample. PHP has no Beta sampler in core, and

Most dev-to content about longevity comes from people who scaled one product for a decade. My version of 18 years is different: 235+ separate small projects, each with a different client, budget, and expectation. That produces a completely different set of lessons. Every project restarts the trust clock. In a startup, trust compounds — the team, the codebase, the client relationship all carry forward. In agency work for small businesses, you start from zero credibility on every single engagement. The client has no idea if you're competent until you prove it, usually within the first draft. That reality shaped how we scope: front-load a visible win early, even a small one, rather than saving the "impressive part" for the end. Most client requests aren't really about the website. "Can we change the homepage headline" is often actually "I'm nervous this won't generate leads" or "my business partner didn't like it." Treating every request as a literal design brief instead of what it's actually about leads to a lot of pointless revision cycles. Asking one clarifying question — "what's this in response to?" — before touching the page has cut our revision count more than any process change. Consistency beats innovation for this client base. A small business owner doesn't want a novel UX pattern. They want their site to look like the successful competitor's site, load fast, and not embarrass them. Chasing design trends for this audience is optimizing for the wrong judge — they're not evaluating craft, they're evaluating "does this look like it'll work." The real skill is saying no to the wrong project, not saying yes to more of them. Early on I took every lead. Now the highest-leverage thing I do is a 10-minute pre-call that filters out projects where the client's expectations and budget don't match — before either of us spends real time on it. That single filter has done more for margin than any pricing change. None of this shows up in a portfolio. But if you're a develope

A few weeks ago I wrote about the WordPress Abilities API — what it is, why WordPress 6.9 shipped it, and what it means for how plugins will talk to each other and to AI agents going forward. That post was theory. This one is the part where theory meets a composer.json file and a stubborn bug at 1 AM. This is the story of building AbilityGuard — a plugin that monitors Abilities API usage in production, so you actually know what's happening when abilities get registered, called, and (occasionally) abused. 👀 Why monitoring, and why now Here's the thing about the Abilities API that got me nervous the first time I really understood it: it's a capability surface . Any plugin can register an ability. Any authorized caller — a human-triggered action, an automation, or increasingly, an AI agent — can invoke one. That's the whole point of the API, and it's genuinely exciting. But it also means your site now has a growing list of "things that can be done to it programmatically," and most WordPress admins have zero visibility into that list. I've spent enough years debugging WordPress sites in production to know what happens when you can't see something: you find out about it during an incident, not before. Slow queries, rogue cron jobs, plugin conflicts — they all follow the same pattern. Nobody notices the small thing until the small thing becomes the outage. So the idea for AbilityGuard was simple: give site owners a dashboard and a log for every ability registered on their site, every time one gets called, and by whom. Not another abstract "security scanner" — just honest, readable visibility into a part of WordPress that's brand new and mostly invisible right now. 🔌 Where I started: hooking into the registry, not fighting it The Abilities API exposes a central registry ( wp_get_ability_registry() under the hood, with helper functions layered on top). My first instinct was to intercept ability calls by wrapping core functions — and I killed that idea within the hour. Wrapp

A post scheduled to publish at a specific time doesn't go live when expected. A plugin's recurring email notification never arrives. This tends to happen on low-traffic sites, and there's a specific reason for it. Note: WP-Cron is WordPress’s built-in scheduling system. It sounds like the OS-level cron daemon, but the underlying mechanism is quite different. WordPress’s WP-Cron doesn’t work like a real OS cron daemon. On every page load, WordPress checks whether any scheduled task is past its due time and, if so, runs it. This is what's known as "pseudo-cron" — and its weakness is that nothing runs without a page visit . Schedule a post to publish at 3am on a site with little overnight traffic, and the publish task can sit unexecuted until the next visitor happens to load a page. WP-CLI lets you look inside this otherwise invisible system and run exactly the task you need, right now. Listing what's scheduled wp cron event list hook next_run_gmt recurrence publish_future_post 2026-06-20 03:00:00 - wp_version_check 2026-06-20 06:12:00 12 hours wp_scheduled_delete 2026-06-21 00:00:00 daily hook is the task's identifier, next_run_gmt is the next scheduled run time in UTC, and recurrence is the repeat interval. If publish_future_post is still listed despite its time having already passed, that confirms the task is overdue simply because no page load has triggered it yet. Running a task right now To trigger a specific task immediately: # Run a specific hook right now wp cron event run publish_future_post # Run every overdue task at once wp cron event run --due-now --due-now finds every task whose scheduled time has passed but hasn't run yet, and executes all of them. Instead of waiting for a visitor to trigger the check, this one command runs the post publish, the email notification, or whatever else is pending. Confirming WP-Cron itself is working wp cron test This checks whether the WP-Cron scheduler is functioning at all. On sites where wp-config.php has define('DISABL

Everyone evaluating AI avatar platforms focuses on voice quality. The bigger UX killer is almost always latency — and it's a harder problem than picking a good TTS provider. Where the delay actually comes from: User speaks/types → STT (if voice input) → LLM generates response (streaming helps, but first-token latency matters) → TTS converts text to audio → Audio playback + lip-sync rendering Each hop adds latency. A naive implementation that waits for the full LLM response before starting TTS can easily hit 2-4 seconds of dead air — long enough for a user to assume the bot is broken. How production systems actually solve this: Token streaming into TTS — start synthesizing audio on partial LLM output (sentence-by-sentence chunks) instead of waiting for the full response Speculative rendering — start lip-sync animation slightly ahead of audio using predicted phoneme timing WebSocket/SSE persistent connections — avoid the overhead of repeated HTTP round-trips per turn Regional API routing — TTS/LLM provider latency varies a lot by user geography; this matters more than most benchmarks show A practical note: platforms that advertise "real-time" avatars but load all logic behind a single request/response cycle will feel noticeably worse than ones built around streaming pipelines, even if they use the identical LLM and TTS providers underneath. If you're evaluating a platform (or building one), test with realistic network conditions, not office wifi — that's where the architecture differences actually show up. Bottom line: the voice provider matters less than people think. The orchestration around it — how aggressively you stream and pipeline each stage — is what separates a "wow" demo from a production-ready conversational agent.

A forgotten password, a security plugin that blocked your own IP by mistake, a plugin bug that turns the admin screen white — the causes vary, but the result is the same: you can’t log in to wp-admin. Note: WP-CLI is a command-line tool for managing WordPress, invoked as wp . It operates directly on the server, without going through a browser. This is exactly the situation where WP-CLI is useful. It works here because it never touches wp-login.php — it reads and writes the WordPress database and filesystem directly, so a broken login screen doesn’t affect it at all. Why WP-CLI keeps working when wp-admin doesn't A normal login follows the path: browser → wp-login.php → authentication → wp-admin. If anything along that path is broken — a plugin throwing a fatal error during authentication, a security plugin blocking your IP, a fatal error in the admin theme — the login itself can’t complete. WP-CLI connects over SSH and reads/writes the wp_users and wp_options tables (and the filesystem) directly. The code in wp-login.php is never executed, so problems on that path don’t matter. This does require that SSH access itself still works — on most hosting providers, SSH is a separate access path from the admin dashboard, so it usually still works even when wp-admin doesn’t. Scenario 1: Forgotten password # List administrator accounts wp user list --role = administrator --fields = ID,user_login,user_email # Overwrite the password directly wp user update 1 --user_pass = 'a-strong-new-password' wp user update writes the new password directly to the database row — no password-reset email, no token, no waiting on a delivery that might land in spam or not arrive at all. Scenario 2: A security plugin blocked your own IP Login-attempt-limiting plugins occasionally misclassify legitimate activity as an attack and add the working IP to a block list. # Deactivate the plugin responsible for the block wp plugin deactivate <plugin-causing-the-lockout> # Re-enable it later, after reviewin

I’ve released Cross Post for Dev.to , a WordPress plugin that mirrors a post to Dev.to the moment you publish it on your own site. The plugin itself is simple: one hook, one API call, one published mirror. The interesting part of this release isn’t the feature. It’s what had to be true for a zero-dependency plugin to stay trustworthy over time without me babysitting it. The problem Most small WordPress plugins rot over time. They’re built against whatever WordPress version happens to be current, they lean on a third-party library or two to save time, and neither the plugin nor the library gets revisited until something breaks. Usually a major WordPress release, sometimes a PHP version bump. At that point the maintainer generally abandons the project and so many of these lesser used plugins become useless for users. Cross-Post for Dev.to needed to cross-post reliably from WordPress to Dev.to without letting that happen so easily. No bundled third-party SDKs, no external service sitting between the plugin and the Dev.to API, no dependency that could go unmaintained while the plugin using it kept shipping. Why zero-dependency isn’t the whole answer Removing dependencies fixes one kind of rot but not the other. A plugin with no third-party packages can still quietly break against a new WordPress release; deprecated hooks, changed REST behaviour, PHP version drift. Zero dependencies means less that can fail underneath you; it says nothing about whether the plugin still works today. Those are two different guarantees, and conflating them is how “lightweight” plugins end up just as unmaintained as heavy ones, only with fewer visible warning signs. So the actual problem wasn’t “avoid dependencies.” It was “know, continuously and automatically, whether this plugin still works”. Which is a validation problem, not a packaging problem. The validation loop Two layers of the same idea, one local and one continuous. Locally , a pre-push hook runs before any commit leaves my machin

After a domain migration or HTTPS switch, "all plugin settings are gone" or "Elementor layouts are broken" is a common outcome. The cause, in most cases, is running a string replacement against the WordPress database without accounting for PHP serialized data. WordPress stores plugin configurations, custom field values, and widget settings in PHP’s serialized format. Standard SQL replacements — phpMyAdmin’s find-and-replace, raw UPDATE statements, sed on a .sql dump — rewrite the string value without updating the length metadata that serialization embeds alongside it. The result is a database that appears intact but returns false on every read of the affected values. wp search-replace handles this correctly. Understanding why makes the pre- and post-execution steps more deliberate. What PHP serialization stores alongside the value A serialized entry in WordPress looks like this: a : 2 : { s : 4 : "home" ; s : 22 : "http://example.com/top" ; s : 5 : "title" ; s : 8 : "My Site" ;} The segment s:22:"http://example.com/top" means "a string of 22 bytes." The s:N: prefix records the byte length. When a simple string replacement changes http://example.com to https://example.com : Before: s:22:"http://example.com/top" (22 bytes) After: s:22:"https://example.com/top" (23 bytes) The s:22 stays unchanged even though the actual string is now 23 bytes. PHP’s unserialize() detects this mismatch and returns false . The plugin reads false instead of its configuration array and behaves as though the settings were never saved. phpMyAdmin’s find-and-replace executes a SQL UPDATE at the storage layer. No PHP context exists there — it can’t know the column contains serialized data, and it doesn’t adjust the length prefix. How wp search-replace handles it wp search-replace operates at the PHP layer, not the SQL layer: Reads each column value Checks whether it’s serialized using is_serialized() If serialized: calls unserialize() to expand it into a PHP array or object Applies the string r

A few months ago, I submitted a talk proposal to WordCamp US without really knowing what to expect. Today, I'm happy to say that it was accepted, and I'll be speaking at one of the largest WordPress conferences in the world. WordCamp US has always been one of the events I've looked up to in the WordPress ecosystem. As someone who has spent over a decade building content platforms with WordPress, contributing to open source, and working with teams across different countries, having the opportunity to share my experience on that stage is something I don't take for granted. My session is: Stop Blaming WordPress: Building a Real Editorial Workflow Without Leaving the Ecosystem Throughout my time working with WordPress, I've noticed a recurring pattern. When editorial teams struggle to publish content efficiently, WordPress often gets the blame. But after working with organizations of different sizes, I've learned that the CMS is rarely the real problem. The real challenges are usually: disconnected editorial processes; unclear content ownership; missing approval workflows; inconsistent governance; too much reliance on manual work. In this session, I'll share practical strategies for building scalable editorial workflows while keeping WordPress at the center of the ecosystem. The goal isn't to introduce another platform, it's to make the existing one work better. Speaking at WordCamp US is especially meaningful because I've been part of the WordPress ecosystem for many years. Being able to give something back to this community is an opportunity I'm genuinely grateful for. If you'll be at WordCamp US 2026 in Phoenix, I'd love to connect. 🎟️ Get your ticket: https://us.wordcamp.org/2026/tickets/ 💸 Use my speaker discount: speaker-friend20 during checkout for a discount on your ticket. See you at WCUS! 🚀

I woke up to two emails that immediately caught my attention. One was from my website monitoring service (I use UptimeRobot, no affiliation) reporting that a client's website was down. The other was from my VPS provider informing me that they had suspended my VPS due to abuse. I logged into the control panel and immediately noticed a massive CPU spike. The server had gone from its usual 15–20% CPU usage to a sustained 100% for nearly four hours before the provider shut it down under their fair usage policy. My first clue was xmlrpc.php . It was consuming a significant amount of resources, so I started researching it. I'm not primarily a WordPress/PHP developer, and I was surprised to learn that XML-RPC exposes functionality for remote management of WordPress. I disabled XML-RPC, brought the VPS back online, and thought the problem was solved. It wasn't. The next day I woke up to the exact same two emails. This time my VPS provider had already imposed CPU limits on the server. I noticed a few kernel-looking processes consuming CPU, assumed they were related to the throttling, and restarted the VPS. A few hours later, it was offline again. At that point I knew I was dealing with a compromise rather than a performance issue. I began investigating the WordPress installation and immediately found obvious signs of infection. There were numerous malicious PHP files ( index.php , cache.php , etc.) buried inside recursively nested directories such as: image / image / image / image / cache . php The deeper I looked, the worse it became. The attackers had created: A rogue WordPress administrator account An unauthorized SSH key A root-level user on the VPS An administrator account inside CyberPanel This wasn't just a compromised website anymore. It was a full VPS compromise. My working theory was that the attackers exploited a vulnerable WordPress component (likely allowing arbitrary PHP upload or remote code execution), established persistence, and pivoted into the operating s

Integrating AI and WordPress: From Idea to Execution, Real-World Challenges, and Practical Workflows The rise of artificial intelligence has fundamentally transformed our definition of an effective website. The era of static websites that merely served as digital placeholders is over. Today, Content Management Systems like WordPress—backed by custom AI capabilities—are evolving into intelligent, automated, and interactive assistants. Below is a detailed overview of our practical experience, architecture, completed implementations, and the technical hurdles we overcame while building custom AI tools for WordPress. 1. Why Integrate AI with WordPress? (Beyond Simple Plugins) Many people view AI in WordPress as limited to off-the-shelf content generation plugins or generic chatbots. However, real value is unlocked when custom AI tools are tailored specifically to a business's unique workflow and ecosystem. Our focus when implementing AI tools relies on three core principles: Complex Process Automation: Reducing human intervention in repetitive tasks, such as automatic categorization, SEO optimization, and metadata generation. Personalized User Experience: Delivering smart, exclusive responses to users based on real-time behavior and stored data. Direct and Secure Connectivity: Seamlessly bridging Large Language Models (LLMs) with the WordPress database and native hooks via APIs. 2. Featured Projects and Case Studies Throughout our development journey, we have brought several practical AI use cases from concept to live production environments: A) Intelligent Content Engine A custom tool integrated into the WordPress admin panel that analyzes article topics to: Generate an optimized SEO structure (Headings and target keywords). Draft initial content alongside image metadata (Alt text and Descriptions). Automatically suggest internal links based on existing posts inside the wp_posts database table. B) Context-Aware AI Support Agents Upgrading basic chatbots into smart agen

Five failure patterns from past WordPress major upgrades ended with the observation that "the same structures will recur in some form in the next major (7.0 or 8.0)." This post applies that pattern knowledge to WordPress 7.0 specifically — not as a list of things that will happen, but as a preparatory checklist for what you can verify now. This sits alongside the seven-item pre-flight checklist from W1 rather than replacing it. Think of it as the 7.0-specific supplement. Item 1 — PHP minimum requirement increase (W3 pattern 3 again) W3’s pattern 3 was "older plugins break with parse errors when the PHP minimum requirement is raised." This pattern repeats on every major upgrade cycle. WordPress 7.0 is expected to follow the same trajectory. Background: PHP 7.4 reached end-of-life from the PHP project in November 2022 (security support ended November 2023) WordPress 6.6 requires PHP 7.2 minimum WordPress 7.0 is expected to raise the minimum to PHP 8.0 or later When this happens, sites running PHP 7.x will encounter plugins and themes that "worked fine before" but break with syntax or fatal errors after the upgrade. The mechanism is the same as past cycles — the plugin hasn’t updated its code to handle PHP 8.x stricter type handling, and the errors surface only at runtime. What you can check now: # Confirm the server&#8217;s PHP version php -v # List all plugins with their current version and update status wp plugin list --fields = name,version,update,update_version --format = table # Run a JSON output check — noisy output here means PHP warnings already leaking wp plugin list --format = json The pattern to watch for: plugins with an old "Tested up to" value and no updates in the past year. These are the highest risk candidates for PHP compatibility issues when the minimum requirement moves. The post on PHP 8.2 Deprecated warnings leaking into WP-CLI JSON output covers a related symptom — even when PHP compatibility doesn’t cause a hard break, it can silently corrupt o

Everyone's telling you the same thing right now: update WordPress. Which is, fine, yes, obviously but that's not enough. Patching closes the hole. What is someone is already In your system? So let's actually walk through this properly what to do right now, what to do if you can't patch immediately, and what to do if you think you were already hit. Need more context? I wrote a summarising one here. wp2shell: The Bug That Turned an Empty WordPress Install Into a Shell Aditya Pidurkar Aditya Pidurkar Aditya Pidurkar Follow Jul 22 wp2shell: The Bug That Turned an Empty WordPress Install Into a Shell # wordpress # wp2shell # cybersecurity # cve Add Comment 4 min read S1: Stop assuming you're patched. Go check. WordPress flipped on forced automatic background updates for this one because of how serious it is. That's great, except "forced" doesn't mean "guaranteed", VERIFY IT. Go look at your actual running version right now: In the dashboard: wp-admin > Updates Via WP-CLI, if you have shell access: wp core version You want to see 7.0.2 if you're on the 7.0 line, or 6.9.5 if you're on 6.9. If you see anything else — 6.9.0 through 6.9.4, or 7.0.0/7.0.1 — you're still exposed. Update it now!! Come back when done. A few situations where the forced update quietly doesn't happen, in what I read on internet: Managed hosting environments where the host controls the update pipeline and hasn't pushed it yet Sites with a "disable auto-updates" plugin installed months ago for stability reasons and never revisited wp-config.php with WP_AUTO_UPDATE_CORE explicitly set to false Staging or dev environments nobody thinks of as "production" but that are still internet-facing If any of that describes you, don't wait on the automation. Update manually. S2: If you genuinely can't update right now, here's your stopgap aybe you're facing a compatibility issue, a change freeze, or a custom plugin that isn't ready yet. It happens. If you need a little more time before applying the real fix, here'

Most “WordPress to Next.js” tutorials show you how to fetch posts from the WP REST API and render them in the App Router. That’s the easy 20%. The 80% that actually decides whether your organic traffic survives is everything around the content: your URLs, your redirects, your metadata, your sitemap, and your images. Get those wrong and you’ll watch impressions fall off a cliff two weeks after launch, right when everyone assumes the migration “went fine.” This guide is the checklist I wish every team ran before flipping DNS. It’s framework-accurate for the Next.js App Router, and it works whether your new backend is headless WordPress, a headless CMS, or flat files. The one rule that saves rankings Every decision in a migration comes back to a single principle: Nothing about how Google already sees your pages should change, except the parts you deliberately improve. Google ranks specific URLs based on their content, their metadata, and the links pointing to them. A migration is dangerous precisely because it’s tempting to change all three at once: new URLs, a “cleaner” content structure, redesigned templates. Do that and you’ve thrown away the signals every ranking is built on. The safe path is boring: same URLs, same content, same meta, just a faster, modern frontend underneath. Step 1: Inventory everything before you touch anything You cannot preserve what you haven’t captured. Before writing a line of Next.js, you need a complete, structured snapshot of the live site: every published URL, its rendered content, its SEO metadata, its images, and its internal links. This inventory becomes the source of truth for your redirect map, your generateMetadata , and your sitemap. This is the step most guides wave away with “export your content from WordPress.” In reality it’s where migrations break, because the default WordPress export (WXR) gives you raw post content, not the rendered HTML your page builder actually outputs, and it drops most of the SEO fields you need. If

Most "SSG vs SSR vs ISR" content out there is written from documentation. Someone reads the framework, restates it, and you're left inferring the actual difference in performance and behavior. So I built a lab where you can just run the commands and see it yourself, no table to trust blindly. astro-wp-seo-lab builds the same WordPress content four different ways with Astro 7.1.1, then serves all four side by side so you can compare them directly. git clone https://github.com/nimajafari/astro-wp-seo-lab npm install npm run compare That builds each arm into its own directory and serves them all at once. arm url what it is ssg-full http://localhost:4301 everything prerendered at build time ssr http://localhost:4302 rendered per request, no caching ssr-cdn http://localhost:4303 per request plus CDN cache headers route-cache http://localhost:4304 per request plus Astro 7 route caching islands http://localhost:4305 static shell with deferred fragments Every page has a black bar at the top showing which arm rendered it and when. That timestamp is the instrument for most of what follows. First build takes a few minutes since each arm fetches from WordPress, later builds are faster because the Content Layer loader caches between them. It ships pointed at a live WordPress install (oxyplug.com), but it works against any public WordPress site with the REST API exposed. npm run probe -- https://your-site.com --save mysite SOURCE = mysite npm run compare probe checks what your own install actually exposes, REST API reachability, Yoast presence, permalink structure, then saves it under a name. Use the URLs npm run compare prints for your own site instead of the ones below, since those are generated from your own content. Build time vs request time This is the distinction most of the SSG vs SSR debate hinges on, and it takes about 30 seconds to see for yourself. Open these two side by side and reload each a few times. http://localhost:4301/optimization/crl-ocsp-certificate-revocati

Your Contact Form 7 form can work perfectly from a user's perspective and still fail to deliver a lead to your CRM. The visitor fills out the form. The browser shows a success message. The WordPress form appears to have submitted correctly. But when you open Systeme CRM, the contact is nowhere to be found. This is one of the most confusing problems in form-to-CRM integrations because a successful form submission does not necessarily mean a successful API request. The complete workflow has multiple stages: Visitor ↓ Contact Form 7 ↓ WordPress ↓ API Request ↓ Systeme CRM ↓ Contact Record ↓ CRM Automation A failure at any stage can break the workflow. The key to debugging the integration is to stop treating the form submission as a single event and start checking each stage separately. First, separate the two different types of success There are two different questions: Did Contact Form 7 submit the form? This is a WordPress-side question. Did Systeme CRM accept and process the API request? This is an API and CRM-side question. These are not the same thing. A form can successfully collect: Name: John Doe Email: john@example.com Company: Example Inc. while the API request fails because: the endpoint is incorrect authentication is missing the request method is wrong the JSON payload is invalid the CRM expects different field names a required field is missing The first debugging step is therefore to identify exactly where the data flow stops. Step 1: Confirm that Contact Form 7 is collecting the expected data Start at the beginning. Look at the form fields: [text* your-name] [email* your-email] [tel your-phone] [text company] [textarea your-message] The important values are the actual field names: your-name your-email your-phone company your-message A common mistake is to assume that the visible label is the field name. For example: Visible label: Full Name Field name: your-name The integration needs the submitted field value associated with the actual field name. Before

Cross-posted from the Loopress docs Loopress is a toolset to make WordPress reproducible and reviewable via Git . Versioned snippets, Composer without SSH, and more coming... Check Loopress WordPress doesn't have a package manager. If you want a PHP library in your project, be it Guzzle for HTTP calls or a PDF generation library in a snippet, you're either vendoring the code by hand or running Composer somewhere the WordPress admin can't see. We built a feature to fix that: a Composer UI inside the WordPress admin. Search Packagist, install a package, audit it for known vulnerabilities, all without SSH access ( full walkthrough here ). Before shipping it, we asked the wordpress.org plugin review team whether it would be acceptable in the official directory. The answer was no. The rule Here's the relevant line from Guideline 8 of the wordpress.org plugin directory: "Plugins may not send executable code via third-party systems." Installing a PHP package from Packagist is, by definition, downloading executable code from a third party and writing it to disk. It doesn't matter that our plugin never calls the installed code's autoloader itself, that the user has to load it deliberately from their own snippet. The review team was clear: the indirection changes nothing. The mere presence of that capability is enough to trigger the rule, whether or not it's ever used. There's no folder you can hide it in that makes it acceptable, they weren't shy about saying that outright. If you want PHP dependencies in a plugin distributed on wordpress.org, the only accepted path is to vendor them at submission time: ship the code, with a compatible license and readable source, not fetch it dynamically. For us, that meant Composer package management could never live in the same plugin that ships on wordpress.org. Full stop, no clever workaround changes that. What we tried first, and undid Our first move was the obvious one: split into two plugins. A "Core" plugin with snippet sync, distri

Artificial intelligence is changing the way websites are planned, built, managed, and improved. WordPress developers now have access to tools that can help with coding, content creation, customer support, automation, analytics, and search engine optimization. However, using an AI plugin does not automatically make someone an AI-ready developer. A genuinely AI-ready WordPress developer understands how to combine technical experience, business thinking, automation, and human judgment. The goal is not to add AI everywhere. The goal is to use it where it solves a real problem. AI Should Solve a Clear Business Problem Many businesses make the mistake of choosing an AI tool before deciding what they actually need. A better approach starts with a practical challenge. For example, a company may want to: Respond to customer questions more quickly Organize website enquiries Improve WooCommerce product recommendations Automate repetitive administrative work Connect website forms with a CRM Generate content drafts Analyze customer behaviour Improve internal support processes An experienced developer will first study the workflow, the expected result, the available data, and the possible risks. Only after that should a suitable plugin, API, automation platform, or custom solution be selected. This approach prevents businesses from spending money on features that look impressive but provide little value. AI-Generated Code Still Needs Human Review AI coding tools can produce functions, snippets, plugin ideas, and debugging suggestions within seconds. That speed is useful, especially when a developer is working with repetitive tasks or unfamiliar code. The danger is that AI-generated code may look correct while containing hidden problems. It can include: Outdated WordPress functions Weak security practices Plugin compatibility issues Poor database queries Unnecessary scripts Incorrect assumptions Performance problems That is why generated code should never be added directly to a li

When I started working on a WooCommerce slider plugin, I noticed that many existing solutions were packed with features that a lot of websites simply don’t need. More features often mean more CSS, more JavaScript, and a bigger impact on performance. So I asked myself a simple question: What would a WooCommerce slider look like if performance came first? My goals Instead of creating another all-in-one slider plugin, I focused on a few principles: Lightweight codebase Fast loading times Responsive by default Easy integration with Gutenberg Elementor support Shortcode support Clean and maintainable architecture Performance matters Every additional request and every unnecessary asset affects page speed. Some optimizations I implemented include: Assets are loaded only when required. Local libraries instead of unnecessary external requests. Server-side rendering where appropriate. Clean HTML output. Developer experience I also wanted the plugin to be simple for users. Instead of a complicated interface, the goal was: Install Create a slider Insert it into a page Done Lessons learned Building a public WordPress plugin taught me a lot: Documentation is almost as important as the code. User feedback quickly reveals edge cases you never considered. Keeping the codebase simple often leads to better long-term maintainability. What’s next? I’m continuing to improve the plugin by adding new features while keeping performance as the top priority. I’d also love to hear how other developers approach WordPress plugin development and performance optimization. Thanks for reading! ⸻ If you’re interested, you can check out my project here: WordPress.org: https://wordpress.org/plugins/amitry-product-category-slider/ GitHub: https://github.com/amitry-de/amitry-product-category-slider Live Demo: https://slider.amitry.de/