In this issue of Delicious Brain Bytes, we look at the recent WordPress® market share decline, dive into Brian Gardner’s perspective on WordPress 7.0 as a design-focused operating system for the intelligent web, check the pulse of the ecosystem with the WP Community Collective’s State of the Community survey, and much more!
The WordPress community has been abuzz with recent data showing a contraction in its once-untouchable market dominance. According to the latest data from W3Techs, WordPress currently powers 59.4% of all websites with a known content management system, which translates to roughly 41.9% of all websites on the internet. While those numbers still represent a massive amount of sites, the trajectory has raised eyebrows across the industry.
As reported in a detailed analysis by Search Engine Journal, WordPress is facing its first sustained, multi-quarter decline in recent history. While a minor drop in 2025 was easily dismissed, the pace of the decline seems to have picked up.
“WordPress market share stood at 43.20% in December 2025 and declined to 41.90% by May 27, 2026. That’s a drop of 1.3 percentage points in six months, double what it was for the entire year of 2025,” writes Roger Monti on Search Engine Journal. “That’s a drop of 1.3 percentage points in six months, double what it was for the entire year of 2025.”
Where are these users going? While WordPress has dipped, closed-ecosystem competitors and modern developer frameworks are steadily scooping up the crumbs. Over the same timeline, platforms like Wix (+0.6), Shopify (+0.4), and Squarespace (+0.2) have seen modest gains.
The WordPress core team has issued a call for testing client-side media processing, a progressive enhancement targeting WordPress 7.1 as a core capability. Rather than depending solely on server-side image processing pipelines, this feature offloads the decoding, resizing, and encoding of images directly to the user’s browser using WebAssembly. It provides a uniform, high-quality experience across different hosting environments while supporting advanced formats like AVIF, WebP, HEIC, UltraHDR, and JPEG XL without bloating initial bundle sizes. Testing across diverse devices is highly encouraged to smoke out bugs and stress-test upload resilience paths before the 7.1 cycle accelerates.
There’s also an open call for WordPress 7.0.x release managers to steer minor maintenance versions. This lean squad will be responsible for triaging bugs, drafting announcements, and running release operations, beginning with the tentative rollout of WordPress 7.0.1 later in June.
The WP Community Collective has launched its State of the Community survey, an anonymous initiative inviting anyone who works with, contributes to, or cares about the WordPress open source project to share their perspectives.
Open from May 27 through June 28, 2026, the survey takes 10 to 20 minutes to complete and aims to capture a comprehensive snapshot of ecosystem health and participant trajectories.
Rather than just collecting basic demographics and professional background, the 10-to-20 minute questionnaire gathers broad feedback on project sentiment, community and event participation, core open-source values, and the shifting impacts of artificial intelligence.
All responses are completely anonymous and will be used to better understand the collective state of the project. To make your voice heard, head over to the WPCC and share your feedback before the June 28 deadline.
Brian Gardner of WP Engine recently shared a deep-dive perspective on the release of WordPress 7.0. Gardner notes that for twenty years, building great digital experiences often felt like a series of compromises between creative vision and software limitations. With the arrival of version 7.0, however, he believes the core software has officially matured into a sophisticated, future-ready operating system.
In the article, he explores in depth how the release transitions the CMS into an AI-ready, design-focused operating system by introducing a native AI framework, utilizing the Connectors API and WP AI Client SDK, alongside core enhancements like customizable navigation overlays, “content-only” pattern editing, and responsive block visibility.
Read the [full breakdown] (https://wpengine.com/blog/wordpress-7-0-release/) and see how these guardrails, performance updates, and media optimizations are helping to prepare your sites for the next era of web development.
“Find the right post quickly” sounds simple, but becomes more challenging as your content library grows. In an ideal world, you’d be able to search your indexed content with natural language, return results in real time, and handle follow-up requests like “show more” and “summarize the first result.”
In this tutorial, Fran Agulto shows us how to build a WordPress admin copilot that does just that, using a Next.js API backend as the coordinator, OpenAI for reasoning and tool orchestration, and WP Engine Smart Search AI MCP for deterministic search and retrieval.
No WordPress site is an island. Sites routinely integrate with external CRMs, enterprise ERP systems, inventory managers, payment gateways, and fulfillment APIs. These integrations add value, but they also introduce architectural vulnerability.
Any given third-party service might go down and cause a specific feature to stop working, but the bigger risk is a cascade failure. If an external API experiences latency or drops offline entirely, a poorly isolated WordPress site will go down with it.
Your server won’t crash because your database failed or because you ran out of memory. It will crash because your server’s PHP-FPM workers are stuck waiting in a synchronous queue for a response that isn’t coming.
In this article, we discuss defensive code isolation, and how to decouple your site’s frontend uptime from the reliability of your third-party dependencies.
What’s the most interesting news you’ve come across recently? Pop by the site formerly known as Twitter and let us know.
The post Delicious Brain Bytes: WordPress Market Share Declines, State of the Community Survey, and Building an Admin Copilot appeared first on Delicious Brains.
With the launch of WordPress 7.0, the platform has undergone one of its most significant architectural evolutions in years. Instead of treating artificial intelligence as a collection of disjointed features to bolt on, Core now includes a standardized, native infrastructure layer.
At the center of this is the Connectors API, a centralized, native registry in WordPress 7.0 that allows you to manage your external service credentials in one place instead of forcing you to configure them across multiple separate plugins. As Greg Ziółkowski writes in the Make WordPress post linked above, “The initial focus is on AI providers, giving WordPress a standardized way to handle API key management, provider discovery, and admin UI for configuring AI services.”
While this solves a massive headache, it also introduces new questions about where and how you should stash your secrets.
Saving your keys via the dashboard is convenient, but storing scalable, high-cost AI credentials as plain text in a centralized database table has its downsides. An AI API key can essentially serve as a blank check tied to an open-ended billing account. If an attacker extracts it via the database, the financial liability could be massive. In this article, we explore why shifting your credentials to environment variables is a more secure choice.
Before WordPress 7.0, a site using three different AI-powered plugins required pasting API keys into three entirely different settings screens. This method resulted in fragmented credential storage, messy rate-limiting, and unpredictable security risks.
WordPress 7.0 fixes this by decoupling the core infrastructure from the specific service providers.
The result is a centralized hub located at Settings → Connectors. While this unification provides seamless configuration, it means that a single point of entry now holds the keys to your entire external application ecosystem.
Securing this architecture requires looking at how WordPress evaluates credentials. The Connectors API uses a strict, three-step waterfall logic to check for API keys:
Logindefine( 'OPENAI_API_KEY', 'sk-...' ); inside wp-config.php)[System Request]
│
▼
1. Environment Variables ───► Key Found? ───► [Authenticate]
│ (Bypasses DB)
▼ Key Empty
2. PHP Constants ───► Key Found? ───► [Authenticate]
│
▼ Key Empty
3. Database Storage ───► Pulls Plain Text from wp_options
Defining your secrets at the server level with environment variables automatically short-circuit this evaluation chain. WordPress never triggers the database lookup for the key, reducing query load and keeping your raw credentials completely decoupled from the database layer.
If you input an API key into the WordPress admin interface, the screen will gracefully mask the characters with bullet points or asterisks. However, masked does not mean encrypted.
Under the hood, WordPress stores these credentials as raw, plain-text strings inside the wp_options table. Because of this storage model, your site’s external accounts are exposed to several common vectors:
wp_options table and extract your production API keys.NOTE: The WordPress community recognizes this plain-text limitation. Core ticket #64789 is actively tracking proposals to introduce native database encryption for sensitive stored options in future releases.
When transitioning from database storage to server-level environment variables, you must ensure that your deployment tools don’t accidentally leak production keys downward to local environments.
The Connectors API uses a standardized naming schema for options stored in the database:
connectors_{$provider_type}_{$provider_id}_api_key
Because these options use a predictable prefix, configuring your synchronization tools is straightforward.
When pushing or pulling databases with WP Migrate, you must prevent sensitive credentials from migrating between environments. Use the wpmdb_preserved_options filter to ensure that local or staging variables are never overwritten by a production database pull:
add_filter( 'wpmdb_preserved_options', function( $options ) {
// The provider type group in WP 7.0 is 'ai'
$options[] = 'connectors_ai_openai_api_key';
$options[] = 'connectors_ai_anthropic_api_key';
return $options;
});
Once you have successfully declared your keys as environment variables at the system level, your site immediately switches to them, rendering the database values obsolete. At this point, you can use WP Migrate’s find-and-replace feature to search your wp_options table for the connectors_ string prefix and safely delete those obsolete records.
The Connectors API in WordPress 7.0 is a phenomenal structural step forward for the ecosystem, turning the CMS into a highly capable platform for integrated AI capabilities. However, a framework is only as secure as its implementation.
Relying on default database storage exposes your critical external integration credentials to unnecessary vulnerabilities. By embracing the authentication hierarchy and prioritizing server-level environment variables, you harden your infrastructure and protect your operational budgets.
The post Environment Variables vs. Database: Securing the Connectors API appeared first on Delicious Brains.
No WordPress® site is an island. Sites routinely integrate with external CRMs, enterprise ERP systems, inventory managers, payment gateways, and fulfillment APIs. These integrations add value, but they also introduce architectural vulnerability.
The danger isn’t just that a third-party service might go down and cause a specific feature to stop working. The real risk is a cascade failure. If an external API experiences latency or drops offline entirely, a poorly isolated WordPress site will go down with it.
Your server won’t crash because your database failed or because you ran out of memory. It will crash because your server’s PHP-FPM workers are stuck waiting in a synchronous queue for a response that isn’t coming.
A truly resilient site uses defensive code isolation. Here is how to decouple your site’s frontend uptime from the reliability of your third-party dependencies.
When an external service drops or slows down to a crawl under heavy load, many developers assume the impact is isolated to that specific function. They believe that if the shipping calculator API is slow, only the checkout page will lag.
To understand why this is a dangerous misconception, we have to look under the hood at how PHP and your server handle incoming traffic.
By default, HTTP requests executed via WordPress core functions like wp_remote_get() or wp_remote_request() are synchronous and blocking. PHP is inherently single-threaded. When a worker process executes a blocking HTTP request, it halts execution entirely and sits idle, waiting for the external server to reply.
[Incoming Request] ➔ [PHP-FPM Worker Assigned] ➔ [Executes wp_remote_get()] ➔ [Worker Halted / Waiting for API]
Most production servers run a process manager like PHP-FPM with a finite pool of workers (for example, 20 to 50 concurrent workers depending on your server configuration). If your site experiences a sudden surge in traffic and 20 concurrent users hit a page that triggers a slow third-party API call, your entire worker pool can be exhausted instantly.
At this point, your server is maxed out. The 21st visitor will be placed in a queue, even if they are just trying to load a completely static, text-only homepage that doesn’t use the API. When the queue fills up, Nginx or Apache will throw a 502 Bad Gateway or 504 Gateway Timeout error. A slow API endpoint on a single deep page has successfully brought down your entire network.
A common first-line defense against API bottlenecks is caching the external response using the WordPress Transients API. By wrapping your request in get_transient() and set_transient(), you ensure your server only hits the external API once every hour or day, rather than on every page load.
While caching is mandatory, relying solely on standard transients under high traffic creates a severe vulnerability known as a “cache stampede.”
Consider a high-traffic eCommerce store where an API transient expires. At that exact millisecond, 50 concurrent users land on the site. Because get_transient() returns false for all 50 workers simultaneously, every single one of those workers will independently execute wp_remote_get() to refresh the cache.
Instead of protecting the external API and your local server, you have just generated a massive, synchronized spike in outbound requests! If the third-party API responds slowly during this stampede, your worker pool instantly locks up, and the site crashes.
To solve the cache stampede, we need to introduce a transient lock.
When the main cache expires, the very first PHP worker that notices the missing data will immediately set a temporary ‘lock’ transient (e.g., for 30 seconds). When the other 49 concurrent workers check the cache and see that it is empty, they will also see the lock. This tells them, “Someone else is already fetching the data!” Instead of piling onto the external API, those 49 workers will instantly return your fallback data, completely neutralizing the stampede.
function fetch_api_data_with_lock() {
$cache_key = 'external_api_data';
$lock_key = 'external_api_data_lock';
// 1. Try to get the cached data
$cached_data = get_transient( $cache_key );
if ( false !== $cached_data ) {
return $cached_data; // Cache hit! Return immediately.
}
// 2. Cache is empty. Check if another worker is already fetching it.
if ( get_transient( $lock_key ) ) {
// The lock exists. Another process is currently hitting the API.
// Return fallback data to prevent a stampede.
return get_fallback_api_data();
}
// 3. No lock exists. Set the lock immediately for 30 seconds!
set_transient( $lock_key, true, 30 );
// 4. Safely fetch the data
$response = wp_remote_get( 'https://api.external-service.com/v1/data', [
'timeout' => 1.5,
] );
// Handle failure
if ( is_wp_error( $response ) ) {
delete_transient( $lock_key ); // Clear lock so we can try again sooner
return get_fallback_api_data();
}
$body = wp_remote_retrieve_body( $response );
$data = json_decode( $body, true );
// 5. Success! Save the actual data for 1 hour and remove the lock.
if ( $data ) {
set_transient( $cache_key, $data, HOUR_IN_SECONDS );
}
delete_transient( $lock_key );
return $data;
}
The first rule of defensive engineering is to never accept default configuration values blindly. By default, WordPress sets a 5-second timeout on HTTP requests made via wp_remote_get(). Five seconds is an eternity. If a worker hangs for 5 seconds on a high-traffic site, resource exhaustion is virtually guaranteed.
When communicating with external APIs on the frontend, you must lower your timeouts aggressively and handle the resulting errors gracefully using is_wp_error().
Here is how you can set up a defensive wrapper for an API call:
function fetch_defensive_api_data() {
$url = 'https://api.external-service.com/v1/data';
// Step 1: Lower timeouts aggressively
$response = wp_remote_get( $url, [
'timeout' => 1.5, // 1.5 seconds max before failing fast
'sslverify' => true,
] );
// Step 2: Catch timeouts or network failures gracefully
if ( is_wp_error( $response ) ) {
// Log the error for internal auditing
error_log( 'API Failure: ' . $response->get_error_message() );
// Return fallback data instead of breaking the execution
return get_fallback_api_data();
}
$body = wp_remote_retrieve_body( $response );
return json_decode( $body, true );
}
function get_fallback_api_data() {
// Provide safe, stale, or static default data to keep the UI intact
return [
'status' => 'offline',
'items' => [],
];
}
By reducing the timeout to 1.5 seconds, you guarantee that a failing API can only hold a PHP worker hostage for a brief moment, giving your server a fighting chance to recycle that worker and serve the next request.
Lowering timeouts protects your worker pool from long hangs, but it doesn’t stop your server from continuously hammering a broken or offline API. If an external service goes down for an hour, your server will still spend 1.5 seconds on every single page load trying to reach it.
To solve this, we can borrow a classic microservice architecture strategy: The Circuit Breaker Pattern.
The concept is straightforward:
We can implement a lightweight, highly effective circuit breaker natively in WordPress using the Object Cache or Transients API:
function fetch_api_with_circuit_breaker() {
$circuit_status_key = 'api_circuit_breaker_tripped';
$failure_counter_key = 'api_failure_counter';
// 1. Closed or Open? Check if the circuit is currently "Open" (Tripped)
if ( get_transient( $circuit_status_key ) ) {
// Circuit is open; fail fast immediately and return fallback data
return get_fallback_api_data();
}
// 2. The circuit is Closed (or Half-Open). Attempt the remote request.
$response = wp_remote_get( 'https://api.external-service.com/v1/data', [
'timeout' => 1.5,
] );
// 3. Handle a network failure or timeout
if ( is_wp_error( $response ) ) {
$failures = (int) get_transient( $failure_counter_key );
$failures++;
if ( $failures >= 3 ) {
// Trip the circuit for 5 minutes.
// CRITICAL: We do NOT delete the failure counter here!
// We keep it so we can test a "Half-Open" state later.
set_transient( $circuit_status_key, true, 5 * MINUTE_IN_SECONDS );
}
// Always update the failure count, letting it live longer than the circuit trip time
set_transient( $failure_counter_key, $failures, 1 * HOUR_IN_SECONDS );
return get_fallback_api_data();
}
// 4. Success! If we get here, the API is healthy.
// Clear the failure counter to fully reset to a "Closed" state.
delete_transient( $failure_counter_key );
$body = wp_remote_retrieve_body( $response );
return json_decode( $body, true );
// 5. Validate the payload to ensure it isn't malicious or malformed
if ( ! is_array( $data ) || empty( $data ) ) {
return get_fallback_api_data();
}
return $data;
}
With this architecture in place, if a third-party partner suffers an outage, your site will only try to talk to them 3 times. On the 3rd failure, the circuit trips. For the next five minutes, your site doesn’t spend a single millisecond waiting on that API, keeping your frontend lightning fast and completely insulated from the outage.
After those five minutes is where the Half-Open state comes in. Notice in the code that we don’t delete the failure counter when the circuit trips; we only delete it on a successful response. After the $circuit_status_key expires, the circuit becomes “Half-Open” and lets one single request through to test the API. If that request fails, the failure counter increments from 3 to 4, immediately tripping the 5-minute circuit again without forcing the server to wait for 3 new failures. If it succeeds, the counter is deleted, and the circuit fully closes.
The circuit breaker code above relies on get_transient() and set_transient() to count failures. While fine for standard setups, this introduces a race condition on extremely high-traffic sites.
Because transients are not atomic, if 10 users trigger an API timeout at the exact same millisecond, all 10 PHP workers might query the database simultaneously, read the failure count as 0, and all overwrite the count to 1. It might take longer than 3 actual failures to trip the circuit.
If your server runs a persistent object cache like Redis or Memcached, bypass the Transients API for the counter. Instead, use WordPress’s native wp_cache_incr() function. This performs a strictly atomic increment directly in the server’s RAM, guaranteeing perfectly accurate failure counting regardless of concurrent traffic.
Relying on external services is a necessity, but allowing those services to dictate your site’s availability is an architectural choice.
Wrapping HTTP requests in defensive patterns, such as reducing blocking timeouts, planning for transient cache stampedes, and implementing fail-fast circuit breakers. you ensure that a third-party disaster remains an isolated glitch on a specific feature, rather than a catastrophic site-wide crash.
The post Managing Third-Party API Bottlenecks in WordPress appeared first on Delicious Brains.
A lot of WordPress® plugins follow the path of least resistance. They enqueue their CSS and JavaScript globally to ensure their features “just work” on every page. While this approach is safe for the developer, it’s less than ideal for site performance. Every unused byte of JavaScript adds to the browser’s execution time. This negatively impacts Total Blocking Time (TBT) and Largest Contentful Paint (LCP).
In this guide, we discuss how to move past basic script registration. We will look at how to interrogate the internal WordPress script queue and surgically remove the assets your visitors don’t actually need.
The first line of defense is ensuring your own code only loads when necessary. Don’t forget that the wp_enqueue_scripts hook is simply an action. You can wrap your enqueues in logic to restrict them to specific contexts.
Using Conditional Tags prevents scripts from loading where they aren’t needed. For example, if you have a heavy script that only runs on a specific “Contact” page, there’s no point in loading it everywhere else.
add_action( 'wp_enqueue_scripts', function() {
// Only load the heavy Map script on the Contact page
if ( is_page( 'contact' ) ) {
wp_enqueue_script( 'google-maps-api', 'https://maps.googleapis.com/...', array(), null, true );
}
});
Using is_page(), is_single(), or even has_block() allows you to implement “Just-in-Time” loading. This keeps your initial page weight low.
$wp_scripts GlobalThe real performance bottleneck often comes from third-party plugins. To stop them, you first have to identify their handles. You can spend a big chuck of time hunting through plugin source files if that’s what floats your boat, but it’s probably faster to just look at the internal state of the WordPress script manager.
WordPress uses the WP_Scripts class to manage the queue. During the page lifecycle, a global variable called $wp_scripts holds every registered and enqueued script.
You can interrogate this global object to see exactly which handles are enqueued for the current request. To use the following snippet, you can add it to a custom plugin used on a staging site or in a local development environment.
It is important to use the wp_print_scripts hook. This hook fires right before WordPress begins printing scripts into the header. This timing ensures that every plugin has finished its enqueuing logic, giving you a complete picture of the final queue.
You should only run this code in a non-production environment, such as a local install or a staging site.
Local vs. Staging: While a local site is “safe,” a staging site is often superior for this audit because it perfectly mirrors your production plugin configuration and database state.
Why Not Production? This snippet outputs data directly into your site’s HTML source code. On a live site, this looks unprofessional to visitors and can reveal your specific plugin stack to malicious actors. Additionally, running debug logic on every page load adds unnecessary overhead to your server’s performance.
add_action( 'wp_print_scripts', function() {
// Only run this if we are logged in as an admin to add an extra layer of privacy
if ( ! current_user_can( 'manage_options' ) ) {
return;
}
global $wp_scripts;
// Check if the WP_Scripts class has enqueued handles [cite: 6]
if ( ! empty( $wp_scripts->queue ) ) {
// Output the enqueued handles to the browser's JavaScript console
echo '<script>console.log("Delicious Brains Audit - Enqueued handles: ' . implode( ', ', $wp_scripts->queue ) . '");</script>';
}
});
By inspecting the queue property of the $wp_scripts object, you can find the exact strings needed to target specific plugin assets.
Once you have identified your target handles, you can use wp_dequeue_script() to remove them. However, success depends a lot on priority.
In WordPress, hook priorities act like a waiting list where a higher number executes later. Since most plugins enqueue assets at the default priority of 10, you should hook into wp_enqueue_scripts with a much higher number (like 100) to ensure your removal logic runs after the plugin’s loading logic.
Suppose a “Reviews” plugin is loading a 150KB JavaScript file on your homepage. If reviews only exist on your product pages, you can strip that script everywhere else.
add_action( 'wp_enqueue_scripts', function() {
// If we are on the Home page, remove the Reviews asset
if ( is_front_page() ) {
wp_dequeue_script( 'plugin-reviews-js' );
wp_dequeue_style( 'plugin-reviews-css' );
}
}, 100 ); // High number = runs later
For aggressive plugins that still manage to load, you can swap to wp_deregister_script(). This is a more permanent “nuclear” option that completely unbinds the handle from its source file for that specific request.
Before you start pulling the plug on every script you see, you must check for dependencies. The wp_enqueue_script() function allows you to define a list of other scripts that must load first.
You’ll break the site’s functionality if you dequeue a script that other enqueued scripts depend on. The browser will throw “not defined” errors in the console. Always check the registered property within the $wp_scripts global to see the dependency array for a specific handle before removing it.
Advanced asset management is a game of subtraction. By auditing the WP_Scripts global and implementing high-priority conditional dequeuing, you can significantly reduce the weight of your frontend. This surgical approach ensures your site stays fast and lean without sacrificing the plugin functionality you need.
The post Beyond `wp_enqueue`: Surgical Asset Management for High-Performance Sites appeared first on Delicious Brains.
In the lifecycle of a membership site, there is a predictable point where the “My Account” page begins to lag and administrative user searches start to time out. Developers can spend hours optimizing wp_postmeta or the wp_posts table, but it’s the wp_usermeta table that is frequently the culprit behind these performance regressions.
As a site scales into tens of thousands of members, the architectural limitations of the WordPress user metadata system become apparent. Understanding how this table handles data—and how it fails—is critical for building a scalable membership platform.
wp_usermetaLike the post meta and term meta tables, wp_usermeta follows the Entity-Attribute-Value (EAV) model. It is a vertical table designed to store an unlimited variety of data points for any given user.
| umeta_id | user_id | meta_key | meta_value |
|---|---|---|---|
| 1 | 50 | first_name | Jane |
| 2 | 50 | last_name | Doe |
| 3 | 50 | membership_level | Gold |
This flexibility is what makes WordPress powerful. However, this structure becomes expensive at scale. In a membership site with 50,000 users and 20 custom meta fields per user, the wp_usermeta table quickly grows to over a million rows. Every time you query for a user based on a specific attribute, MySQL must navigate this massive dataset.
One of the most common architectural mistakes in membership site development is storing complex arrays in a single meta value. It is tempting to store all of a user’s “Subscription Preferences” or “Learning Progress” as a serialized array to keep the database row count low.
// The Performance Trap: Storing as an array
$preferences = array( 'email' => true, 'sms' => false, 'tier' => 'premium' );
update_user_meta( $user_id, 'member_preferences', $preferences );
While this works for simple data retrieval, it makes that data functionally invisible to the database for filtering. Because the meta_value column is a longtext field, it is not indexed. If you need to find every user where 'sms' => true inside that serialized array, MySQL cannot use an index. It must perform a “full table scan,” reading every single row in the metadata table and using a LIKE comparison.
On a large site, this pattern is a primary cause of timeout errors. If you need to query or filter by a specific piece of data, it must be stored as its own individual meta key rather than a value inside an array.
get_users()When you use get_users() with a meta_query, WordPress performs a JOIN between the wp_users and wp_usermeta tables. This is a standard operation, but the performance cost increases exponentially as the tables grow.
The bottleneck usually occurs because the meta_value column is not indexed. While the meta_key is indexed, any query that checks the content of that key requires the database to scan the values manually.
If your membership site relies on complex filtering, such as finding users who joined after a certain date and have a specific custom role, you are likely triggering expensive queries that bypass the database’s most efficient paths.
The most effective way to prevent wp_usermeta from becoming a bottleneck is to stop hitting the database entirely. This is where persistent object caching (via Redis or Memcached) becomes essential.
In a standard WordPress installation, user data is cached only for the duration of a single page load. A persistent object cache allows WordPress to store the results of user and meta lookups in the server’s RAM across multiple requests.
Persistent object caching ensures that once a user’s metadata is fetched once, it stays in the cache until it is explicitly updated. This is particularly impactful for:
By serving this data from RAM rather than the disk, you reduce the Time to First Byte (TTFB) and free up your PHP workers to handle actual visitor traffic instead of redundant database lookups.
If your membership site is approaching 100,000 users, you may need to look beyond the default meta system.
wp_options table with the autoload property set to ‘yes’. WordPress fetches every autoloaded option on every page request to populate the object cache. If this collective dataset becomes too large, it can significantly increase memory usage and slow down the initial database handshake. Maintaining a lean options table is a best practice for keeping your object cache healthy and responsive.A scalable membership site is built on the realization that user data is the most frequently accessed resource on your server. By prioritizing clean data structures and utilizing a persistent caching layer, you can ensure your platform remains performant as your community grows.
The post The Developer’s Guide to wp_usermeta: Scaling Membership Sites appeared first on Delicious Brains.
The WordPress® REST API is the primary bridge to modern frontend frameworks. However, default endpoints are generic by design. Custom endpoints require precise logic to avoid over-fetching data and exhausting server resources. A poorly architected custom endpoint can become a major performance bottleneck.
Building lean endpoints is essential for respecting the server’s PHP worker pool and memory limits. This ensures your API remains a performance asset rather than a liability. In this article, we examine how to architect high-performance custom endpoints by implementing selective data retrieval, efficient object caching, and network-level security.
One of the most effective ways to optimize an endpoint is to support the native _fields parameter. This allows the client to request only the specific data points it needs. This reduces the size of the JSON payload and the memory required to generate the response.
You should also avoid using standard WP_Query when it is not strictly necessary. WP_Query is a heavy operation that often triggers unnecessary metadata and taxonomy lookups. For surgical data retrieval, using $wpdb directly can significantly reduce memory overhead.
_fields SupportWhen registering a custom route, you can implement a filter to prune the response based on the client’s request.
add_action( 'rest_api_init', function () {
register_rest_route( 'my-plugin/v1', '/data/', array(
'methods' => 'GET',
'callback' => 'get_custom_data',
'permission_callback' => '__return_true',
) );
} );
function get_custom_data( $request ) {
$data = array(
'id' => 101,
'name' => 'Performance Plugin',
'version' => '2.1.0',
'author' => 'Delicious Brains',
);
// Check if the _fields parameter is present
if ( isset( $request['_fields'] ) ) {
$fields = wp_parse_list( $request['_fields'] );
$data = array_intersect_key( $data, array_flip( $fields ) );
}
return rest_ensure_response( $data );
}
You should almost never generate a complex API response on every single request. Using the Transients API allows you to store expensive results in an object cache. This prevents repeated hits to the database and significantly speeds up Time to First Byte (TTFB).
In a standard WordPress setup, transients are stored in the wp_options table. This means every time you fetch a transient, WordPress still has to perform a database query. An object cache layer changes this by storing that data in the server’s RAM instead of on the disk.
Keeping frequently accessed data in memory reduces the time it takes to access the database and keeps your server healthier by saving it from searching for the same information repeatedly.
If your hosting provider does not offer a managed solution, you can implement one yourself. The process generally involves two main components:
object-cache.php) placed in your wp-content folder that tells WordPress to route set_transient and get_transient calls to your new data store instead of the database.Your host may already include solutions for this that require no manual configuration. If you are hosting with WP Engine, the object cache layer is enabled by default on all new environments. It can also be toggled manually within the WP Engine User Portal.
When using this managed layer, you must be mindful of the 1MB buffer size limit. Because the object cache stores data as a single long row, an oversized API response can cause the cache to reject the request. This can lead to a loop of failed requests and 502 Bad Gateway errors. To maintain a healthy environment, aim to keep your cached payloads under 800,000 bytes.
A custom endpoint is a gateway into your database. It must be built with both a lock and a filter. Every route should include a permission_callback to ensure the requester is authorized to access the data.
You must also use validate_callback and sanitize_callback for every input argument. These functions protect your site against SQL injection and malformed data. For state-changing requests like POST or DELETE, ensure you are properly handling nonces or authentication headers to prevent unauthorized access.
Even a secure endpoint is vulnerable to API hammering. This is a scenario where an external script, bot, or malicious actor targets your custom endpoint with a high volume of requests. Because custom REST API requests are often uncacheable and resource-intensive, they can quickly exhaust your site’s PHP worker pool. This saturation prevents legitimate visitors from accessing the site, effectively resulting in a denial-of-service state.
To protect your server resources, you should look for security solutions that operate at the network edge rather than within WordPress itself.
Traditional WordPress security plugins run as part of the application. This means every malicious request still has to be processed by your server before the plugin can block it. In contrast, edge security sits in front of your hosting environment. It acts as a high-performance barrier that filters traffic before it ever touches your WordPress install.
A robust edge strategy includes several key components:
If you are managing your own infrastructure, you can implement these protections using services like Cloudflare or specialized Nginx configurations. These tools allow you to set strict limits on how often a specific user or bot can hit your /wp-json/ endpoints.
Your host may include these protections as part of their service. For example, WP Engine offers Global Edge Security (GES). This managed solution leverages a global network to provide WAF protection and DDoS mitigation. Server resources are preserved for your actual users while malicious traffic is discarded at the edge.
Responsible API requests consider the health of the entire ecosystem, from the client’s data needs to the server’s available memory. Throughout this guide, we have explored how to move beyond basic endpoint registration toward a more defensive and performant architecture.
By implementing the _fields parameter and avoiding the overhead of standard WP_Query wrappers, you can ensure that your payloads remain lean and fast. We have also seen how the addition of an object cache layer is critical for preventing redundant database queries. Moving frequent lookups into memory reduces the strain on your database and improves response times across the board.
Finally, we discussed why securing the gateway to your database requires more than just code-level sanitization. True infrastructure defense involves shifting the burden of malicious traffic away from your PHP workers and toward the network edge. Combining these code-level optimizations with network-level rate limiting and WAF protection creates a robust system capable of handling high-traffic demands. This comprehensive approach ensures that your WordPress site remains stable, secure, and ready to scale.
The post Scaling the REST API: Defensive Architecture for Custom Endpoints appeared first on Delicious Brains.
In this issue of Delicious Brain Bytes, we explore the human side of innovation in the Crafted with Code showcase, test-drive a nostalgic Clippy-style assistant in the WordPress® dashboard, and dive into WordPress.org’s new native Markdown support for AI agents. Plus, we check the pulse of the industry with the Admin Bar’s 2026 WordPress Professionals Survey, navigate changes in the FAIR project, and much more!
The latest installment of the Crafted with Code series, Code Redefined: The Edge of Innovation, explores the intersection of purposeful technology and human judgment. In its sixth year, this showcase by WP Engine and the Webby Awards highlights that 30% of all Webby-recognized sites were built on WordPress®. This year’s “Code Redefined” theme explores how intelligence is embedded with intention across three standout projects:
Innovation in the AI era isn’t just about the tech you use, but the human choices that solve real-world challenges.
You can watch the full Crafted with Code playlist to see the behind-the-scenes stories of these award-winning builds.
For the fifth year in a row, the Admin Bar is benchmarking the “business side” of web development with its 2026 WordPress Professionals Survey.
Last year’s results from 1,200 pros revealed that Bricks was the only page builder gaining significant ground, and that agencies with a defined niche were 46% more likely to break six figures in revenue.
This year’s five-minute, anonymous survey dives deeper into AI integration and the evolving hosting landscape.
WordPress.org has begun serving content in Markdown format, a major step toward becoming part of the agentic web. First announced on Make WordPress Meta, this update allows developers and AI agents to append .md to many WordPress.org URLs—including plugin directories and handbooks—to receive clean, structured data.
As noted in The Repository, this lowers token costs for LLMs and reduces AI hallucinations by providing “ground truth” documentation in a machine-readable format.
The Federated and Independent Repositories (FAIR) project is entering an uncertain chapter as co-founders Joost and Marieke de Valk officially step back to encourage broader community ownership. Since we noted the arrival of FAIR 1.0 and the security MVP with Patchstack, the project has sought to reduce reliance on a single central authority.
As reported in The Repository, the community is now weighing whether hosting companies and developers will maintain this decentralized infrastructure or if momentum will stall without its original advocates.
Following a community-led push, the WordPress.org Featured Plugins tab is now rotating “Hidden Gems” every two weeks. This shift mirrors the “quality over popularity” logic we explored in our coverage of the Hidden Gems plugin. By showcasing high-rated, low-install tools, the repository is providing independent developers a legitimate path to visibility based on merit rather than marketing budget.
Nick Hamze has fulfilled a childhood dream by releasing “Dewey,” a Clippy-style assistant for the WordPress dashboard. Built to bring late-90s quirky energy to the modern CMS, Dewey offers “help” directly within the Block Editor. You can experience this nostalgic experimental design yourself by spinning up a live WordPress Playground instance using the project’s official blueprint.
In a thought-provoking new post, Jamie Marsland suggests the WordPress community is asking the wrong question about AI. Rather than wondering how to add AI buttons to existing tools, Marsland argues we should consider that users likely want AI instead of a complex software interface. He posits a paradigm shift where users simply talk to their website to make it “just work,” moving from traditional editing to natural, conversational creation.
In the publisher workflow, checklists are important to ensure that you don’t miss anything. Imagine how messy or unorganized things can get without checklists in your everyday life, let alone content you are writing for work.
In WordPress, WP Engine’s Newsroom features the Publication Checklist. It is a customizable quality-control tool that ensures all editorial standards are met before a story goes live.
The publication checklist helps you move away from time-consuming administrative content checks. Completely configurable to your requirements, the checklist flags missing items in real-time to editors before publishing, and gives customized suggestions to make sure your content meets everything you need it to.
In this article, Fran Agulto walks us through how to customize and use these features as well as integrate them with work management software.
Every time your code reaches out to an external API, you are introducing a point of failure that you do not control. Whether you are fetching a social feed, a weather widget, or processing a payment, your site’s performance is now tied to a third party.
A common mistake is treating a remote request like a local database query. If the external server is slow, your site becomes slow. If the external server is down, your site might crash or hang indefinitely. Professional WordPress development requires a defensive architecture that anticipates these failures. By using the WordPress HTTP API correctly, you can protect your site from external volatility.
In this article, we explore how to move beyond basic requests by architecting a defensive fail-safe strategy using the WordPress HTTP API to shield your site from external server volatility. By prioritizing rigorous error handling and strategic caching through the Transients API, you can ensure your site remains fast and stable even when third-party services stumble.
What’s the most interesting news you’ve come across recently? Pop by Twitter and let us know.
The post Delicious Brain Bytes: Code Redefined, “Clippy” for WordPress, and Customizing Publication Checklists appeared first on Delicious Brains.
WordPress® is built to be a flexible application framework, but that flexibility comes with a trade-off in the form of a “one size fits all” database schema. For most sites, the default indexes provided by WordPress core are sufficient. However, as your site grows and your wp_postmeta and wp_options tables climb into the millions of rows, those standard indexes eventually hit a ceiling.
A site might feel fast on the frontend due to page caching, but a crawling dashboard or a ballooning slow query log indicates a database that is struggling to find data. Moving beyond standard tables requires an understanding of how MySQL indexing works and when to implement custom indexes to prevent full table scans.
In a database without an index, MySQL must perform a full table scan. This means it looks at every single row on the disk to find a match for your query. If you have 2.5 million rows of post meta, this process is incredibly slow and resource-intensive.
An index acts as a table of contents for your data. Instead of reading every page, MySQL uses a B-Tree structure to jump directly to the relevant information in logarithmic time.
This sounds great, but remember that there’s no such thing as a free lunch. While indexes dramatically speed up reads, they slightly slow down writes. Every time you insert or update a row, MySQL also updates the index file. On small tables, the performance gains are minimal and might even add unnecessary overhead. However, on large-scale sites, a missing index is often the primary cause of server bottlenecks.
wp_options Bottleneck and the 1MB BufferThe wp_options table is arguably the most common source of administrative slowness. WordPress is designed to query every row where autoload = 'yes' on every single page load to populate the object cache.
Depending on your hosting platform, these autoloaded values may be stored as a single row in the persistent object cache. This is where the 1MB buffer limit becomes a critical architectural guardrail. If the total size of your autoloaded data exceeds this 1MB limit, the cache layer may reject the request. This forces WordPress to repeatedly query the database for the same massive dataset, often resulting in a loop of failed requests and 502 Bad Gateway errors.
Even if you stay under the 1MB limit, a bloated options table makes primary index lookups less efficient. Keeping your wp_options table lean, ideally under 800,000 bytes, is essential for maintaining a healthy object cache and ensuring fast Time to First Byte (TTFB) for all requests.
wp_postmeta NightmareThe wp_postmeta table is a “vertical” table that uses key/value pairs. By default, the meta_value column is not indexed because it uses a longtext data type.
If you run a meta_query that filters by meta_value, such as searching for all products within a specific price range, MySQL is forced to scan every single row of metadata. When your table reaches the millions, these queries can take seconds to execute.
The solution is often a partial (or prefix) index. Because you cannot index an entire longtext field, you can tell MySQL to index only the first $N$ characters of the column. This allows for significantly faster filtering while keeping the index size manageable.
Before adding custom indexes, you must identify exactly which queries are causing the bottleneck.
Query Monitor is highly regarded for identifying slow queries directly within the WordPress UI. It highlights duplicates and expensive queries, allowing you to see exactly which plugin or theme component is responsible.
EXPLAIN: If you have a specific slow query, prefixing the SQL statement with EXPLAIN in a tool like phpMyAdmin or MySQL Workbench will reveal how MySQL intends to execute it. If the type column shows ALL, you have confirmed a full table scan is occurring.
For production environments where you want minimal overhead, the MySQL Slow Query Log records every statement that exceeds a defined time limit.
Database indexing is not a “set it and forget it” task. As a site evolves, so do its data patterns. A query that was fast with 10,000 rows can become a site-killer at 1,000,000 rows.
Proper stewardship of the WordPress schema involves regular audits of your autoloaded data and the strategic application of custom indexes. By keeping your wp_options under the 1MB buffer and ensuring your meta queries are supported by indexes, you protect your site’s scalability and ensure a smooth experience for both visitors and administrators.
The post Database Indexing: The Missing Manual for WordPress appeared first on Delicious Brains.
When it comes to WordPress® performance, we often focus on the big metrics: page load speed, database query optimization, and asset minification. However, there is a silent pulse running in the background of every WordPress installation that can, under the right conditions, bring even a robust server to its knees.
This pulse is the WordPress Heartbeat API.
Introduced in WordPress 3.6, the Heartbeat API provides a way for the browser to communicate with the server in real-time while a user is logged into the dashboard. It manages essential features like session concurrency, auto-saving posts, and post locking, ensuring that two editors don’t accidentally overwrite each other’s work.
While these features are vital for a collaborative environment, the Heartbeat API’s default behavior isn’t always optimized for high-concurrency sites. If left unmanaged, it can lead to exhausted server resources and impacts on site stability.
The Heartbeat API functions by sending a POST request to admin-ajax.php at regular intervals (usually every 15 to 60 seconds). The journey of a single “pulse” looks like this:
admin-ajax.php.The critical issue here is that Heartbeat requests are uncacheable. Because they are POST requests sent to the administrative backend, they bypass standard page caching. Every single pulse requires a dedicated PHP worker to process.
On a site with a single editor, this is negligible. The math changes rapidly when it’s a site with 50 concurrent users, whether they are editors in a newsroom or students in a learning management system. Fifty users with the dashboard open can generate hundreds of uncacheable requests per minute, saturating the server’s capacity.
Identifying a “Heartbeat Storm” starts with the server logs. If your access logs are filled with repetitive POST requests to /wp-admin/admin-ajax.php with the action heartbeat, the API is likely the culprit.
Beyond logs, this overhead manifests as a drain on PHP workers. PHP workers are the engines that process the PHP code on your site. Since a worker is “occupied” for the duration of every Heartbeat pulse, a high volume of these background tasks leaves fewer workers available to serve actual frontend traffic to your visitors.
heartbeat_settings FilterYou do not necessarily need to disable the Heartbeat API entirely.Doing so would break useful features like auto-save. Instead, another approach is to throttle the interval.
By default, the “pulse” happens every 15 seconds when you are editing a post. You can use the heartbeat_settings filter to change this interval to the maximum allowed (60 seconds), significantly reducing the load.
/**
* Throttle the Heartbeat API to 60 seconds.
*/
add_filter( 'heartbeat_settings', function( $settings ) {
$settings['interval'] = 60; // Set to the maximum allowed 60 seconds
return $settings;
});
In some cases, you may want to disable the Heartbeat API on specific parts of the site where it serves no purpose. For instance, there is rarely a need for the heartbeat to run on the frontend of the site for non-administrative users.
You can selectively deregister the script based on the screen or the user’s capabilities:
/**
* Disable Heartbeat on the frontend unless a user is editing a post.
*/
add_action( 'init', function() {
if ( ! is_admin() ) {
wp_deregister_script( 'heartbeat' );
}
});
Managing the Heartbeat API is a key component of site reliability engineering for WordPress. By slowing down the background pulse, you ensure that your server’s resources—specifically its PHP workers—are prioritized for the most important task: serving your content to your audience.
Standardizing these throttles in your theme or a core functionality plugin allows for a more predictable server load, preventing administrative activity from ever becoming a bottleneck for site performance.
The post Taming the Heartbeat API: Preventing `admin-ajax.php` Overload appeared first on Delicious Brains.
In the hierarchy of WordPress® data storage, transients often occupy a misunderstood middle ground. They aren’t quite as permanent as options, yet they aren’t as ephemeral as a standard PHP variable.
The Transients API is designed to store cached data with an expiration time. It is the go-to tool for developers looking to cache expensive operations like remote API calls and complex database queries. It ensures that a single slow request doesn’t degrade the experience for every subsequent visitor.
However, beneath the simple set_transient() wrapper lies a complex relationship with the WordPress database that, if left unmanaged, can lead to significant performance bottlenecks.
wp_options ForensicsTo understand how transients affect a site, we must look at how they are physically represented in the database. When a transient is created using the standard WordPress configuration, it doesn’t just create one row in the wp_options table; it creates two.
Consider the following command:
`set_transient( 'github_api_data', $value, HOUR_IN_SECONDS );`
In the wp_options table, WordPress will generate:
_transient_github_api_data: This row contains the actual serialized value of the data._transient_timeout_github_api_data: This row contains a Unix timestamp representing the moment the data should expire.The logic follows a simple mathematical check every time get_transient is called to determine if the data is still valid:
$$\text{is\_expired} = (\text{current\_time} > \text{timeout\_timestamp})$$
If this calculation evaluates to true (meaning the clock has passed the expiration point), WordPress deletes the expired rows and returns false to the application. This false response serves as the signal to the developer that it is time to refresh the data and set the transient once again.
However, there’s a hidden danger here. It lies in how WordPress handles the autoload flag for these rows. While transients with an expiration, like our example above, are not autoloaded, any transient set without an expiration is automatically set to autoload: yes. This means every time a page is requested, those rows are pulled into memory, even if the current page doesn’t need them. If a developer inadvertently creates numerous non-expiring transients, this global overhead can quickly exceed the 1MB buffer limit of the object cache.
This means every time a page is requested, these rows are loaded into memory by the WordPress core, regardless of whether that specific page actually needs the GitHub API data. On a site with hundreds of transients, this global overhead begins to chip away at PHP memory limits.
A common misconception is that WordPress has a background process, a sort of garbage collector, that automatically deletes expired transients.
In reality, an expired transient is only deleted when it is specifically requested via get_transient(). If a plugin is deactivated, or if a developer changes the name of a transient key, the old “expired” rows may sit in the wp_options table indefinitely.
On high-traffic sites or those using dynamic naming conventions, this can result in thousands of orphaned rows. This bloat increases the size of the database index and slows down every single query targeting the wp_options table.
For sites with significant transient bloat, you can use the following SQL query to safely remove all expired transients from the wp_options table. This is particularly useful for cleaning up “orphaned” rows left behind by deactivated plugins or old dynamic keys.
DELETE a, b FROM wp_options a
JOIN wp_options b ON a.option_name = REPLACE(b.option_name, '_transient_timeout_', '_transient_')
WHERE b.option_name LIKE '_transient_timeout_%'
AND b.option_value < UNIX_TIMESTAMP();
This works by identifying the “timeout” row (_transient_timeout_) and checks if the stored Unix timestamp is older than the current time. It then joins the corresponding data row (_transient_). Finally, it deletes both rows simultaneously, ensuring your database stays lean and indexed properly.
One way to address the issue of transient bloat is to leverage the object cache layer provided by your hosting environment. On the WP Engine platform, object caching is a primary tool used to improve site stability, speed, and scalability.
Unlike standard WordPress installations where you might need to configure this manually, object caching is enabled by default on all new WP Engine environments. This layer acts as a specialized storage area that sits between your site and the database. When an operation like a transient request is made, the server first checks this caching layer for a result. If the data is found, it is served immediately, completely bypassing the need for a database query.
This greatly reduces the load on your server, but it’s not a bottomless storage solution. It requires a clear understanding of how your site uses transients and options, particularly those stored as autoloaded data.
Implementing an object cache layer offers several technical advantages for high-traffic sites:
Reduced Database Latency: By storing the results of repeated queries, the server significantly reduces the time spent accessing the database.
Improved Server Health: The server stays “healthier” because it spends less energy and fewer resources searching the database for the same information repeatedly.
Intelligent Memory Management: The object cache does not clear on a fixed schedule. Instead, it uses a “Least Recently Used” (LRU) algorithm to automatically identify and remove older query results only once its allocated storage space is full.
Despite these benefits, developers must be mindful of the 1MB buffer size limit. Object caching stores autoloaded values as a single long row. If your transients and other autoloaded data combined surpass what the cache can handle, the system will reject the request.
This rejection can trigger a dangerous loop. WordPress requires the data to load the page and will immediately send the request again, eventually resulting in a 502 error on the site. To maintain a healthy environment, it is recommended that all autoloaded data stays below 800,000 bytes. If you encounter persistent 502 errors after adding new transients, temporarily disabling object caching may be necessary while you identify and reduce the volume of autoloaded data.
To maintain a healthy balance between performance and persistence, consider these updated standards for your development workflow:
Strict Namespacing: Use a consistent, unique prefix for all transient keys to make them easily identifiable during a database audit or when debugging.
The “Get/Check/Set” Pattern: Always handle the “false” return of a missing transient gracefully using the strict identity operator (=== false). Because a transient might store a “falsy” value like an empty string or the number 0, a loose check could trigger an unnecessary and expensive data refresh. Remember that a transient is a “best-effort” cache. Your code should never be written with the assumption that the data will be there when requested.
Key Length Management: Keep your transient keys under 172 characters. WordPress appends prefixes like _transient_timeout_ to your key before saving it to the database; if the total string exceeds the character limit of the option_name column, the transient may fail to save or retrieve correctly.
Mind the Expiration: Avoid setting excessively long expirations for data that changes frequently. Shorter, more aggressive caching windows (e.g., 5 to 15 minutes) are often safer for maintaining site consistency and reducing the risk of serving stale content.
Transients are one of the most powerful tools in the WordPress developer’s arsenal, but they are not a “set it and forget it” solution. By understanding the database forensics behind the API and leveraging persistent object caching, you can ensure that your cache stays warm and your database stays lean.
The post The Art of the WordPress Transient: Performance, Persistence, and Database Bloat appeared first on Delicious Brains.
It’s the time of year when we roll out delicious savings! We’re offering new customers big savings on the essential plugins trusted by top developers and agencies worldwide. Whether you’re trying to move a complex website, offload a massive media library, or structure cutting-edge content, this is the best time to invest in the power and efficiency you need.
This sale covers our entire suite of plugins, with savings of up to 50% on your first year’s license for new customers. Plus, we’ve got deals on other WP Engine products like ACF PRO and NitroPack, so you can build your perfect tech stack at the lowest price of the year. Please note that all discounts listed below are for new customers only.
Here’s a breakdown of the incredible deals available on WP Engine’s developer-focused plugins:
The time to invest in efficiency, performance, and structure is now, with savings on every tool you need to build faster, more stable, and more profitable client sites.
The sale runs from November 17th through December 5th, 2025. Make sure to get these deals now and upgrade your entire WordPress workflow!
The post The Ultimate Savings Event for WordPress Professionals appeared first on Delicious Brains.
In this issue of Delicious Brain Bytes, we track the final progress of WordPress 6.9 RC1 and the new Abilities API, explore the security advancements of the FAIR/Patchstack collaboration, preview the future of ACF Blocks, and much more!
The final major WordPress release of 2025 is right around the corner. WordPress 6.9 Release Candidate 1 is now available, putting the release on track for its scheduled launch on December 2, 2025. The core team encourages all developers and users to test the RC1 build to ensure stability, particularly since new features like the improved Site Editor experience and the universal Command Palette are included.
The 6.9 release includes several key developer updates, such as enhancements to the DataViews components and the Interactivity API. However, the most foundational change is the introduction of the Abilities API.
The Abilities API is a new foundational system designed to transform how plugins, themes, and WordPress core expose their functionality. It allows developers to register self-contained units of functionality—an “ability”—with standardized inputs, outputs (using JSON Schema), and permissions.
This system is a key part of the broader AI Building Blocks initiative. By registering abilities using the new PHP functions, developers make their plugin features discoverable and executable by AI agents, automation tools, and other systems. Registered abilities are automatically exposed through a new REST API endpoint (wp-abilities/v1), creating a unified, machine-readable registry of functions. This eliminates the need for isolated functions or custom AJAX handlers, simplifying integration and offering developers a predictable method for building the next generation of AI-powered WordPress solutions.
Developers are urged to begin testing the RC1 and exploring the detailed documentation for the Abilities API now. You can download and test RC1 via the WordPress Beta Tester plugin or view the Abilities API documentation here.
The Advanced Custom Fields (ACF) team is hosting a webinar to showcase the latest advancements in ACF Blocks and how modern developers are leveraging them for efficient, creative WordPress solutions.
The session will cover the full spectrum of ACF’s power, from fine-tuning the client editing experience to establishing structured data for the emerging “agentic web.” Speakers Rob Stinson and Iain Poulson will provide a quick “ACF 101” refresher before diving into a live demo of features from recent releases, highlighting how custom block creation has taken a significant leap forward. The team will also address how pairing ACF PRO with managed hosting platforms like WP Engine can unlock new workflow opportunities.
This session is designed to empower developers to build more efficient and creative solutions. The live webinar takes place on Wednesday, November 19, 2025, at 10am CT / 4pm GMT. Secure your spot now and discover the new capabilities transforming the custom block creation experience.
A new plugin called Hidden Gems aims to fundamentally change how developers and users find quality software in the WordPress ecosystem. The plugin addresses a core issue: the default plugin directory prioritizes popular tools with millions of installs, leaving thousands of excellent, lesser-known plugins flying under the radar.
The Hidden Gems plugin solves this by adding a dedicated tab to the “Add New Plugin” screen, using a smart discovery logic built on “quality over popularity.” It defines a “hidden gem” as a plugin that maintains excellent ratings (3+ stars) but has low installation counts (often filtered to under 10K). This logic ensures that users bypass poor-quality, unknown plugins and well-known, established ones to find truly innovative solutions before they become mainstream.
For plugin developers, this tool creates a pathway for quality to be recognized without requiring a massive marketing budget. For users, it offers a competitive advantage by surfacing niche solutions and high-quality alternatives. The plugin includes advanced filtering options based on installation limits, quality thresholds, and more.
You can read the full story behind the plugin’s creation here and find the plugin itself on GitHub.
It’s the best time of year to pick up new developer tools! We’re offering new customers big savings on the essential plugins trusted by top developers and agencies worldwide. Whether you’re trying to move a complex website, offload a massive media library, or structure cutting-edge content, this is the best time to invest in the power and efficiency you need.
This sale covers WP Migrate Pro, WP Offload Media, WP Offload SES, ACF PRO, and NitroPack, giving you the chance to build your perfect tech stack at the lowest price of the year. Please note that all discounts listed below are for new customers only.
Here’s a breakdown of the incredible deals available on WP Engine’s developer-focused plugins:
The time to invest in efficiency, performance, and structure is now, with savings on every tool you need to build faster, more stable, and more profitable client sites.
The sale runs from November 17th through December 5th, 2025. Make sure to get these deals now and upgrade your entire WordPress workflow!
As reported in The Repository, the decentralized architecture of the FAIR Package Manager recently took a major step toward robust security integration at the inaugural CloudFest USA Hackathon. A collaborative team from FAIR and Patchstack built a Minimum Viable Product (MVP) for the FAIR Software Security Assistant.
The project’s goal was to surface vulnerability warnings directly in the WordPress admin by translating Patchstack’s vulnerability data into FAIR’s trust labeling model. This model allows independent organizations to attach verified trust signals to plugins. FAIR technical steering committee co-chair Carrie Dils noted the process was crucial for figuring out “how we talk to the API, how we turn that into labels, and how we build rules around those labels.”
The resulting policy engine will allow hosts or site owners to define automated rules—such as automatically hiding critically vulnerable plugins from the search screen—addressing supply-chain security directly during plugin discovery. This MVP demonstrates a model where decentralization and security are designed to work together.
The Smart Search AI MCP Server is a powerful new feature in WP Engine’s AI Toolkit that transforms your WordPress site into a dynamic, real-time knowledge base for any external Large Language Model (LLM) you connect to it. When enabled, this server responds to requests from AI tools formatted using the Model Context Protocol (MCP) standard.
In this article, Fran Agulto discusses what MCP is, how to work with the Smart Search AI MCP Server, and how it enhances the Smart Search AI product.
The WordPress media library serves us well for public content, but what about premium assets, private documents, or confidential client data? The default setup makes every uploaded file publicly accessible via a direct URL. This is a critical limitation for membership sites, digital product stores, and businesses sharing sensitive information.
Relying on direct links in your wp-content/uploads folder means anyone who finds the URL can access your content. This is a significant security risk and, for some sites, a potential loss of revenue.
In this article, we address that challenge. We’ll explore a solution to move beyond basic file storage and achieve granular control over your WordPress media, ensuring your valuable or confidential files are securely delivered only to those with proper authorization.
What’s the most interesting news you’ve come across recently? Pop by Twitter and let us know.
The post Delicious Brain Bytes: WordPress 6.9 RC1, FAIR’s Security MVP, and Finding Hidden Gems appeared first on Delicious Brains.
In this issue of Delicious Brain Bytes, we look into WordPress 6.9, round up the latest industry surveys, figure out how to make Postgres much slower, and much more!
WordPress is set for a second major release in 2025. After an increase in contributor capacity, project leadership has moved forward with a full release. As detailed by Anne McCarthy in a recent roadmap post, WordPress 6.9 is scheduled to be released on December 2nd, 2025. This release turns its attention to evolving the Site Editor, enabling new collaborative workflows, and enhancing the platform’s foundation for developers and AI.
Of note, there will not be a new default theme in this release.
WordPress 6.9 will introduce a simplified site editing mode that separates content editing from advanced design tools, offering a less overwhelming experience for users who only need to update text or imagery. Template management is also being overhauled to allow for multiple templates per slug, with the ability to draft new templates and preserve them when switching themes. Additionally, the new release will introduce block-level commenting, enabling asynchronous collaboration workflows directly within the editor.
This release brings significant updates for developers, laying the groundwork for a more robust and extensible platform. The new Abilities API will provide a unified registry of callable functions, making core WordPress functionality accessible to AI systems. Meanwhile, updates to the Interactivity API will enable a new client-side navigation algorithm that supports full-page transitions, and enhancements to the Block Bindings API will extend its support for more core blocks and data sources.
A key focus of WordPress 6.9 is on performance. Planned improvements include faster page transitions, smarter resource handling, and stylesheet enhancements. Looking beyond the official release, several major projects are scheduled to launch as canonical plugins alongside 6.9, including a new WordPress Admin experience, the Model Context Protocol (MCP) Adapter to standardize how applications provide context to large language models, and a PHP AI Client SDK to simplify AI integration for developers.
Advanced Custom Fields (ACF) PRO 6.5 is now available, bringing a host of user experience improvements to its Flexible Content field. The update is specifically designed to give content editors more clarity and control when managing complex pages.
Key improvements for the Flexible Content field include the ability to rename layouts in the editor to provide custom labels (e.g., “Pricing CTA”), disable layouts without deleting them to allow for a non-destructive way to stage or archive content, highlight the active layout to give editors a clear sense of their position on a page, and collapse and expand layouts in bulk, which makes navigating long pages much faster.
The release also removes dynamic class properties across the codebase to ensure compatibility with modern PHP versions and adds an option to default date fields to the current date.
For more information, please see the ACF PRO 6.5 release post.
Two prominent figures in the WordPress community have recently raised fundamental questions about the platform’s long-term viability. Kevin Geary and Jamie Marsland have each published pieces that, while coming from different angles, point to a single conclusion: WordPress is at a critical juncture, and its current architecture and strategic direction may be holding it back.
In The WordPress Architecture Crisis, Kevin Geary argues that the platform suffers from a foundational flaw by confusing design and architecture. He points out that themes, which should only control a site’s look and feel, are instead treated as all-in-one packages that include a site’s core functionality. This confusion, Geary says, violates the principle of “separation of concerns” and has created a fragmented ecosystem where themes are incompatible, and work can be lost when users try to change designs. He suggests that Gutenberg’s introduction was a missed opportunity to create a unified, component-based system that could have fixed these long-standing issues.
Taking a broader view, Jamie Marsland’s article, I’m Not Sure WordPress Can Be WordPress Anymore, contends that the platform is at risk of falling behind because it is still largely seen as “just a website builder.” Marsland notes that the web is moving toward “app-ification,” with AI-native tools allowing users to build and deploy full applications in minutes. While these new platforms are often proprietary “black boxes,” Marsland argues that WordPress, with its brand, distribution, and open-source community, is perfectly positioned to be the open-source alternative. He poses a strategic question: should WordPress’s mission to “democratize publishing” evolve to “democratize building for the web”?
Both authors highlight a central tension within WordPress. Geary points to a technical and architectural trap, while Marsland focuses on a strategic and market-driven one. However, both believe that if WordPress can shed its legacy constraints and embrace a more flexible, forward-looking identity, it can unlock its full potential and compete in the next era of web development.
Always optimizing for speed? One developer took the opposite approach. In a hilarious and surprisingly technical blog post, Jacob Jackson chronicled his quest to build a Postgres configuration that operates as slowly as possible.
Instead of focusing on performance, Jackson intentionally misconfigured a number of key parameters in postgresql.conf. He shrunk the buffer cache to force every query to hit the disk, cranked up the database’s background work to constantly get in the way, and reconfigured I/O to be as inefficient as possible.
The result? A “successful” performance degradation of more than 42,000 times, bringing Postgres down to a sluggish 0.1 transactions per second. It’s a masterful (if entirely useless) demonstration of how a database’s configuration can be its own worst enemy.
Get all the details in Making Postgres 42,000x slower because I am unemployed.
A new report from WPCampus and enterprise agency Human Made, The State of WordPress in Higher Education, reveals a complex picture of WordPress adoption and sentiment across universities. The report, based on a survey of 115 higher education professionals, shows that while WordPress is thriving in the sector, many teams are also grappling with significant challenges and a cautious outlook on the platform’s future.
The report’s findings highlight strong points, with 70% of respondents saying WordPress meets or exceeds their expectations due to its extensibility, multisite support, and cost-effectiveness. However, a significant 62% of respondents also reported having internal discussions about whether to continue with the platform. Key frustrations include uneven adoption of the Block Editor (used on all sites by only 40% of respondents), a lack of resources, plugin compatibility issues, and governance concerns.
Ultimately, the study points to a growing gap between WordPress’s core strengths and the evolving needs of a demanding sector. Higher education professionals are satisfied with the platform’s foundational capabilities but are asking for improvements in areas like accessibility, training, and governance to ensure its long-term viability.
This is your chance to help shape the future of the web. Two key industry surveys are now open, inviting developers to share their insights and influence the direction of both web standards and the WordPress ecosystem.
In addition, the ACF Annual User Survey is still collecting responses. You can provide your feedback and help guide the direction of the plugin at advancedcustomfields.com/annual-survey/.
The State of HTML survey is back, offering developers a direct way to provide input on the direction of web browsers. The survey, curated by Lea Verou, goes far beyond HTML markup to include topics like accessibility, browser APIs, web components, and static site generation.
The 2025 survey aims to measure awareness and usage of new web platform features. The results are used by browser vendors to inform their roadmaps and prioritize key projects, making this an impactful way for you to make your voice heard.
Now in its third year, the State of Enterprise WordPress survey is inviting enterprise users of WordPress to share their insights. The survey gathers valuable data on how WordPress is being used at scale.
For developers and agencies working with large organizations, the survey is a crucial tool for identifying key trends, challenges, and priorities in the enterprise space. The findings will be published in a free, in-depth report that provides a unique view into the needs of high-stakes, complex WordPress implementations.
Marcus Burnette has turned the much-loved WordPress mascot into a strategy card game for the community. Titled Unleash the Wapuu, the game is a fast-paced mix of engine-building and sabotage. Players build their dashboards with Team Wapuus, upgrade them with plugins, and use malware and function cards to derail the competition. It’s a game filled with WordPress in-jokes and playful, chaotic fun.
Burnette, a longtime Wapuu enthusiast, created the game in a few weeks with the help of generative AI and the open-source GPL license. He used ChatGPT to brainstorm card names, generate game text, and create artwork based on the original Wapuu mascot. This creative, community-focused project is available to preorder and will be brought to WordCamp US for attendees to play in person.
Have you ever tried to buy something on a website only to have its poor search feature send you somewhere else? The search feature is an essential tool on any eCommerce site for converting visitors into customers. It helps users find and purchase products quickly and efficiently.
This is where WP Engine’s Smart Search AI steps in. It’s a product for WP Engine customers that replaces WordPress’s built-in search with an intelligent, AI-driven engine for both traditional and headless WordPress applications. Smart Search AI guides visitors to the most relevant content using semantic understanding to surface better results, even for custom post types.
In this article, Francis Agulto shows you how to create a full headless WordPress eCommerce search experience with WooCommerce, WPGraphQL, and WP Engine Smart Search AI.
Many successful WordPress sites eventually hit an architectural bottleneck. As traffic scales, the web server struggles to handle the dual responsibilities of running the PHP application and serving a library of heavy media assets. This strain on bandwidth is a primary cause of slowdowns and instability under load.
One solution is to decouple these roles. In this article, we discuss a key strategy for building a truly scalable site: offloading the entire WordPress media library to a dedicated cloud storage provider.
What’s the most interesting news you’ve come across recently? Pop by Twitter and let us know.
The post Delicious Brain Bytes: WordPress 6.9, ACF PRO 6.5, and Unleash the Wapuu appeared first on Delicious Brains.
User-generated content is the proverbial double-edged sword. While it’s a powerful engine for engagement, it’s also a significant technical liability. User uploads are often unpredictable, unoptimized, and can consume server disk space and bandwidth at an alarming rate. This unchecked growth directly impacts site performance, inflates hosting costs, and complicates essential maintenance tasks like backups and migrations.
To manage this, you need an architecture designed for scale. This article will guide you through the strategies for offloading user-generated media to dedicated cloud storage. We’ll cover the foundational techniques for handling simple uploads, advanced methods for integrating with complex community plugins, and the critical best practices for managing file optimization and privacy in a UGC-driven environment.
Handling user-generated media isn’t simply a matter of scaling your existing /wp-content/uploads directory. It presents a distinct set of architectural challenges that standard media management workflows are ill-equipped to handle. Before implementing a solution, it’s critical to understand the specific problems you need to solve.
An administrator typically curates and optimizes media before uploading. Users do not. They will upload 8 MB photos directly from their phone for a profile avatar that will be displayed at 150×150 pixels. This creates an environment of unpredictable and explosive growth. A successful forum thread or community event can result in gigabytes of new, unoptimized media being added in a single day, placing an immediate and heavy strain on your server’s disk space and bandwidth.
User-generated content may not be intended for the public. Consider a student’s assignment submission on an LMS site, attachments in a private message on a BuddyBoss community, or a member’s “friends-only” photo gallery. These files require sophisticated access control. Simply placing them in a publicly accessible cloud storage bucket is not a secure option, as the files could be accessed by anyone with the direct link.
By default, WordPress places all uploads into date-based folders (e.g., /wp-content/uploads/2025/08/). When user content is added to this mix, your server’s filesystem becomes a chaotic blend of blog post images, user avatars, forum attachments, and form uploads. This lack of separation makes programmatic management, manual auditing, or bulk operations on a specific type of user content nearly impossible.
Routine server operations become increasingly burdensome as the /wp-content/uploads directory swells with gigabytes of user content. Full-site backups that once took minutes can take hours, consuming significant server resources and storage space. Migrating the site to a new host becomes a monumental project, involving massive, time-consuming file transfers that are frequently prone to failure. Separating this volatile user data from your core application files is essential for long-term maintainability.
The foundational strategy for managing user-generated content is to intercept file uploads and redirect them to a dedicated cloud provider like Amazon S3, DigitalOcean Spaces, or Google Cloud Storage. This immediately separates the storage and delivery of these heavy assets from your web server’s primary responsibilities.
For some cases of UGC, this can be accomplished using the free WP Offload Media Lite plugin. Some plugins that allow frontend submissions—such as forms for guest posts, contests, or simple “upload your photo” features—are coded to use the standard WordPress Media Library uploader.
When a user submits a file through one of these forms, WP Offload Media Lite hooks into the process just as it would for an admin upload. The file is automatically copied to your configured cloud bucket, and its URL is rewritten to serve it directly from the cloud. This provides an immediate, effective solution for offloading user content generated through these standard channels.
However, this foundational approach has a critical limitation: it only works if the content-generating plugin funnels uploads through the core WordPress Media Library. This is often not the case for plugins that need more control over files.
For example, BuddyBoss uses custom handlers for avatars and cover images, and the eCommerce plugin Easy Digital Downloads intentionally stores digital products outside of the public Media Library for security. These uploads bypass the standard WordPress hooks and therefore aren’t detected or offloaded by WP Offload Media Lite. Addressing this requires a deeper level of integration.
Overcoming these limitations and properly managing content from complex plugins requires a tool that integrates more deeply with your site’s ecosystem. The licensed version of WP Offload Media provides specific features designed to solve the core challenges of privacy, organization, and compatibility inherent to user-generated content.
One advantage of the licensed version when dealing with user-generated content is its library of purpose-built integrations.
For platforms that bypass the WordPress Media Library, the plugin doesn’t just watch the /uploads folder, it hooks directly into their specific functions. WP Offload Media intercepts the file at its source to ensure it’s offloaded correctly. In addition, it can process all historical content from these integrations, ensuring your entire existing community’s media is migrated to the cloud.
Solving the privacy challenge is critical. You can’t store a customer’s purchased file or a student’s submitted paper in a publicly accessible bucket. WP Offload Media Pro handles this by allowing you to restrict access to offloaded media.
When a legitimate user needs to access the file, the plugin generates a signed, expiring URL on the fly. This unique URL grants temporary access to that specific user, after which it becomes invalid. This is the industry-standard method for serving private content securely from cloud storage, ensuring sensitive files are protected.
Some integrations sort uploaded files into logical paths within your cloud bucket. The level of organization is tailored to the third-party plugin, with some integrations offering highly dynamic structures.
The BuddyBoss integration is the most powerful example of this. It automatically sorts the different types of community media into a structured path system based on context, such as:
uploads/avatars/{USER ID}/uploads/buddypress/groups/{GROUP ID}/cover-image/uploads/bb_medias/{YYYY}/{MM}/This deep, automatic organization is a key benefit of specific integrations designed to handle complex, user-driven content. However, for many other plugins, the integration’s primary focus is on different challenges, such as security and compatibility.
For many plugins, the most critical function of an integration is to handle security for private files or to ensure that URLs work correctly within complex environments like page builders.
For eCommerce plugins like Easy Digital Downloads and WooCommerce, the integration’s primary role is security. When you upload a digital product, the integration automatically offloads the file, sets its permissions to private in your cloud bucket, and ensures that when a customer makes a purchase, the file is delivered using a secure, expiring URL. This protects your digital assets from unauthorized access.
For page builders like Elementor or plugins like Advanced Custom Fields, the integration focuses on compatibility. These tools often store URLs in their own cached data. The integrations ensure that when media is offloaded or settings are changed, these URLs are correctly found and rewritten, preventing broken images and “mixed content” errors that would otherwise be very difficult to troubleshoot.
A robust storage architecture is the foundation, but a truly resilient UGC platform also requires proactive measures to manage the content itself. Implementing a tool like WP Offload Media solves the “where,” but the following best practices address the “what” and “how” of user content, ensuring your platform is secure and efficient from end to end.
The most effective time to stop a problematic upload is before it ever consumes server resources. Your frontend forms are your first line of defense, and it’s critical to implement strict validation to control what users can submit.
This begins with enforcing a strict file type whitelist, where you explicitly define the exact extensions you will accept—such as jpg, png, or pdf—rather than attempting to block specific malicious types. In addition to controlling the file type, you must also set a sensible maximum file size, like 5MB or 10MB, to prevent users from bogging down your server with enormous video files or uncompressed high-resolution images.
You cannot expect your users to upload optimized images. Therefore, you must automate the process on the server. By integrating a plugin like EWWW Image Optimizer, you can process every user-submitted image before it gets offloaded. Such a tool can automatically resize images to appropriate maximum dimensions, apply powerful, lossless compression, and even convert them to efficient formats like WebP. This ensures that only lean, optimized files are sent to your cloud storage, saving on both storage costs and your visitors’ bandwidth.
The fact that content was uploaded by a user doesn’t absolve you of the responsibility for what that content is. You must have a clear and consistent moderation workflow in place. Consider whether user-submitted content should be held in a “pending review” state before it goes live, and who on your team is responsible for that review. This should be supported by a public-facing Terms of Service or Acceptable Use Policy that clearly outlines what is and isn’t permitted on your platform, giving you a firm basis for any moderation decisions.
User-generated content transforms a website into a living community, but it introduces architectural stresses that can easily undermine the platform’s stability and performance. Treating UGC as just another part of the Media Library is a short-term approach that creates long-term technical debt, resulting in a site that is slow, expensive to maintain, and difficult to migrate.
A professional-grade storage architecture is the solution. By offloading media to a dedicated cloud provider, you immediately solve the core problems of storage and server load. When this foundation is enhanced with deep plugin integrations, secure handling for private files, and disciplined best practices for validation and optimization, you transform UGC from a technical liability into a truly scalable asset.
Ultimately, this is about more than just managing files. It’s about building a technical foundation that allows your community to flourish without limits. By implementing these strategies, you are free to encourage user engagement and foster growth, confident that your platform is engineered to handle the success that follows.
The post Using Cloud Storage for WordPress User-Generated Content appeared first on Delicious Brains.
