WordPress and related ecosystem
View All Tags
WordPress 6.8 is set to introduce native support for the Speculation Rules API, a browser feature that allows sites to tell the browser which pages should be prefetched or prerendered before the user even clicks.
With WordPress 7.0 Beta 1 set for February 19, 2026, the ecosystem is bracing for one of the most significant releases in recent years. This version isn't just a number bump; it represents the convergence of Gutenberg Phase 3 (Collaboration) and the first steps into Phase 4 (Multilingual). To help developers prepare, I've updated my wp-7-release-readiness CLI scanner to detect more than just PHP versions.
I've enhanced the tool to specifically target the upcoming core changes:
Beta 1 (Feb 19) is the "feature freeze" point. For developers, this is the time to start testing themes and plugins against the new core. The final release is expected in early April, giving us a tight 6-week window to ensure compatibility. Using a scanner like this allows for automated auditing across large multisite networks or agency portfolios before manually testing each site.
The plugin detection logic uses a simple but effective directory-based heuristic. By mapping known third-party solutions for multilingual and collaboration to their core-equivalent counterparts in 7.0, the tool provides a high-level "conflict risk" score. It's not just about what breaks; it's about what becomes native.
Google just handed independent publishers a way to fight back against AI scraping with their "Preferred Sources" tool, while hackers are simultaneously punishing anyone who ignores their composer.lock with a massive new malware campaign.
If you run a WordPress site in 2026, you're fighting a two-front war: visibility and integrity.
I've been spending time this weekend auditing my sites against these two updates.
According to the latest reports, this tool allows publishers to explicitly signal "original reporting" via structured data or Search Console configuration. It's effectively a canonical tag for facts.
Here is how the flow changes for content producers:
If you are a technical writer or news breaker, ignoring this means you are voluntarily feeding the model without getting the traffic credit.
The report from Squared Tech highlights that this campaign specifically targets "outdated plugins." This isn't a zero-day exploit in core; it's an exploit of the "set it and forget it" mentality.
The most dangerous thing you can do right now is rely on auto-updates that might fail silently. You need active scanning.
# Don't just update; audit first.
# Check for known vulnerabilities in your lock file.
composer audit
# If clean, then update safely
composer update --with-dependencies
Dashboard -> Updates -> "Update All"
# Why this fails:
# 1. No audit trail.
# 2. PHP timeouts can leave sites in maintenance mode.
# 3. Doesn't check against vulnerability databases (usually).
No separate repo—this is an operational update based on industry reports.
I am currently updating my drupal-eu-sovereignty-checklist (which applies to WP as well) to include a check for these "Preferred Source" meta tags, as I suspect this will become a compliance standard for EU publishers wanting to protect their IP rights.
NewsArticle schema needs a specific property for this.composer audit in your CI/CD pipeline. If you aren't blocking deployments on high-severity CVEs, you're asking for trouble.In early 2026, the WordPress ecosystem was rocked by a widespread security breach that infected over 40,000 sites. The culprit? A critical administrative bypass vulnerability in the Modular DS Connector plugin, tracked as CVE-2026-23550.
The vulnerability is a classic example of a flawed authentication check. The plugin's isDirectRequest() method, intended to validate requests from the central Modular DS dashboard, could be tricked by simply adding origin=mo to the URL parameters.
This allowed unauthenticated attackers to target the /api/modular-connector/login/ endpoint and gain full administrative access to the site.
Because Modular DS is a multi-site management tool, the breach was particularly devastating. Attackers could potentially leverage access to a central dashboard to compromise all connected WordPress installations.
Common indicators of compromise (IoCs) include:
I have built a simple Python-based tool to check if a WordPress site is still vulnerable to this specific bypass.
View Code
# Quick check example
python checker.py https://your-wordpress-site.com
This tool performs a non-intrusive check on the specific endpoint using the known bypass parameters to identify if the vulnerability is present.
Stay safe and keep your plugins updated!
WordPress 7.0 is set to bring a significant architectural shift with the proposed merge of the WP AI Client into core. This initiative aims to provide a provider-agnostic foundation for AI capabilities within WordPress, allowing developers to build AI-powered features that work seamlessly across different models and services.
I spent some time reviewing the proposal and building a proof-of-concept (POC) to see how this architecture might look in practice.
Google News and "Preferred Sources" are critical for publishers looking to maintain visibility in search and news feeds. Today, I'm reviewing and building a demonstration of a Google Preferred Source CTA Tool for WordPress.
This tool is a lightweight plugin designed to encourage users to follow a site on Google News and set it as a preferred source, effectively boosting the site's authority and reach.
When a user "follows" your publication on Google News, they are more likely to see your content in their "For You" feed and Discover. Setting a site as a "Preferred Source" (or just Following) is a strong signal to Google's algorithms that your content is valued by that specific user.
[google_preferred_source] to place the CTA anywhere in your layouts.The plugin follows WordPress coding standards (verified with PHPCS) and includes unit tests powered by Brain Monkey to ensure reliability without requiring a full WordPress database for testing.
public function render_shortcode() {
$options = get_option( $this->option_name );
$url = isset( $options['google_news_url'] ) ? $options['google_news_url'] : '#';
if ( empty( $url ) || '#' === $url ) {
return '';
}
// Render the CTA box...
}
Future iterations could include:
View Code
The honeymoon phase of "generate everything with AI" is officially over, as major platforms like WordPress and Cloudflare are now forced to build guardrails against the resulting tide of low-quality "slop."
While I didn't push a new repo for this specific analysis, the shift in industry standards directly affects how I build my own agent workflows. The "slop" problem isn't just about bad blog posts; it's about the erosion of trust in both content and code. WordPress's new guidelines and the Cloudflare Matrix debate highlight a critical technical debt: if you can't verify or maintain what you generate, you shouldn't publish it.
The industry is moving toward a "Human-in-the-Loop" (HITL) requirement. WordPress is now explicitly targeting mass-produced, low-value content, while the Cloudflare community is debating whether AI-generated code for complex systems (like Matrix homeservers) is a feature or a liability.
The technical fix isn't to ban AI, but to implement scoring and verification pipelines.
When building content generators, we need to shift from "is this grammatically correct?" to "does this add value?".
Using AI to generate complex infrastructure code (like a Matrix homeserver) without a deep understanding of the output is a security risk. The Cloudflare debate proves that "it runs" is no longer the bar—"it is maintainable" is.
No separate repo—this is a review of external guidelines and industry shifts that are reshaping my development roadmap.
Recently, a critical authenticated SQL injection vulnerability (CVE-2025-9318) was discovered in the Quiz and Survey Master (QSM) WordPress plugin, affecting versions up to 10.3.1. This flaw allowed attackers with at least subscriber-level permissions to execute arbitrary SQL queries via the is_linking parameter.
In this post, we audit the vulnerability, demonstrate how it worked, and show the implementation of the fix.
The core of the issue was a classic SQL injection pattern: user-supplied input was directly concatenated into a SQL string without being sanitized or passed through a prepared statement.
The vulnerable code looked something like this (simplified for demonstration):
function qsm_request_handler($is_linking) {
global $wpdb;
// VULNERABLE: Direct concatenation of user input into SQL
$query = "SELECT * FROM wp_qsm_sections WHERE is_linking = " . $is_linking;
return $wpdb->get_results($query);
}
By providing a payload like 1 OR 1=1, an attacker could change the logic of the query to return all sections or extract data using UNION SELECT statements.
The vulnerability was resolved in version 10.3.2 by properly utilizing WordPress's $wpdb->prepare() method. This ensures that parameters are correctly typed and escaped before being merged into the query.
function qsm_request_handler($is_linking) {
global $wpdb;
// FIXED: Using wpdb::prepare to safely handle the parameter
$query = $wpdb->prepare(
"SELECT * FROM wp_qsm_sections WHERE is_linking = %d",
$is_linking
);
return $wpdb->get_results($query);
}
In the fixed version, the %d placeholder tells WordPress to treat the input as an integer. Any non-numeric payload (like 1 OR 1=1) will be cast to an integer (resulting in 1 in this case), neutralizing the injection attempt.
We have created a standalone audit project that simulates this environment and provides automated tests to verify both the vulnerability and the fix.
View Code View the Audit Repository on GitHub
(int) provides an extra layer of defense.Stay secure!
The Hook Kinsta’s reliability playbook reads like an agency runbook: isolation, caching at the edge, continuous monitoring, and recoverability drills are table stakes when a single outage can wipe out a campaign or revenue window.
Why I Built It The article makes the case that reliability is as much about operational discipline as it is about infrastructure. I wanted a lightweight way to capture those signals in WordPress, store them, and export a structured report teams can drop into their runbooks.
The Solution The review highlights a few recurring themes: containerized isolation to avoid noisy neighbors, Cloudflare-powered edge caching to reduce origin load, APM tooling to find bottlenecks, and backup depth for recovery objectives. I translated those themes into a checklist and scoring model that teams can keep updated as projects evolve.
The Code View Code
What I Learned
The Hook Gutenberg 22.4 (January 20, 2026) quietly unlocked the feature I have been waiting on: pattern overrides for custom blocks. Synced patterns are finally useful beyond a handful of core blocks.
Why I Built It I use synced patterns to keep layouts consistent, but the lack of overrides on custom blocks meant I still had to fork or detach patterns for small copy changes. Gutenberg 22.4 fixes that gap, so I built a minimal plugin to prove the workflow end-to-end.
The Solution The release highlight list is solid: Font Library now works in classic and hybrid themes, the Image block gained focal point controls, and there is an experimental visibility toggle for responsive layouts. But the part that changes how I build sites is the pattern overrides expansion.
The trick is simple: any block attribute that supports Block Bindings can be overridden in synced patterns. So the job is to opt your custom block into bindings via the server-side filter, then ship a pattern that binds those fields to core/pattern-overrides.
add_filter(
'block_bindings_supported_attributes_g224/spotlight-card',
function ( $supported ) {
$supported[] = 'title';
$supported[] = 'summary';
return $supported;
}
);
Then the pattern sets metadata bindings to core/pattern-overrides so each synced instance can change text without breaking the sync.
<!-- wp:g224/spotlight-card {"title":"Launch faster","summary":"Swap this copy per instance using pattern overrides.","metadata":{"name":"spotlight-card","bindings":{"title":{"source":"core/pattern-overrides"},"summary":{"source":"core/pattern-overrides"}}}} /-->
The Code I shipped a small plugin with one custom block and a pattern ready for overrides. Clone it, activate it, and insert the Spotlight Card (Overrides Ready) pattern. Convert it to a synced pattern, then override the title and summary per instance.
What I Learned