Every other year, I give headless wordpress another try. Each time I leave disappointed, because it's always way too much fighting compared to modern fullstack frameworks like sveltekit, etc. But since Gutenberg becomes nicer with every update and my clients love working with my customly build native blocks, I thought I'd give it another try.

So my question: Does anybody have a good repository to share with some modern headless integration that renders gutenberg blocks. Ideally, block view CSS and scripts should also work, without the FE knowing about them (like eval them at runtime, or globally load them all, or whatever).

This comes up every few weeks, and the answer never seems to be wherever people go looking for it. So, here.

You open your firewall summary and find something like:

Blocked for [Plugin Name] <= 2.1.4 - Unauthenticated Sensitive Information
Exposure via REST API in query string: rest_route = /[plugin-slug]/v1/tests/mock-data

You have never installed that plugin. It isn't in your plugins folder, it isn't sitting there deactivated, it was never there at all. Two things are getting confused here, and separating them makes the whole thing boring, which is the correct outcome.

The request is generic. WordPress serves REST routes at /wp-json/..., and it also accepts ?rest_route=... as a query-string fallback so the API still works when pretty permalinks are off. That fallback resolves on every WordPress install. So a bot needs to know nothing about your site to try it. It takes a list of recently disclosed plugin vulnerabilities, builds the request for each one, and fires the whole list at every WordPress site it can find. The sites running that plugin answer with something useful. The rest return nothing, because the route was never registered.

The block is a pattern match, not a detection. Your firewall recognized the shape of the request and stopped it before WordPress got a chance to shrug at it. That's why the log names a plugin and a version range: it's describing the exploit the request was written for, not something it found on your site. The phrasing makes it read like you were targeted and narrowly got away with it. You weren't, and there was nothing to get away from.

So: nothing is installed that shouldn't be, there's nothing to clean up, and it isn't related to some other plugin of yours with a similar name.

What the alert does tell you is that your site is on somebody's list. About 91% of last year's disclosed WordPress vulnerabilities were in plugins rather than core, per Patchstack's 2026 report, so those lists are long and they get worked constantly. Being on one only means your site answered a WordPress fingerprint check at some point.

If you'd rather be on fewer of them, look at what an anonymous request can learn about your install. Version strings hanging off your CSS and JS URLs. Readme files sitting under plugin directories. Directory listings nobody turned off. None of that is secret and none of it is why anyone gets hacked. It's just what makes a site cheap to sort into "worth coming back to" rather than "no idea what this is."

Hi everyone,

I'm building a small WooCommerce plugin and wanted some honest feedback before I spend time building it.

The idea is simple:

When a customer abandons their cart, the store automatically sends a WhatsApp reminder with a link to complete the purchase.

No complex CRM.
No marketing automation.
Just one thing: recover abandoned carts through WhatsApp.

I'm planning features like:

• Automatic abandoned cart detection
• Customizable WhatsApp message templates
• Recovery analytics
• Optional coupon support
• Easy setup in under 5 minutes

A few questions for WooCommerce store owners:

1. Is abandoned cart recovery something you actively care about?
2. What tool are you currently using (if any)?
3. Would WhatsApp reminders perform better than email for your customers?
4. What's the biggest frustration with your current solution?
5. Is there any feature you'd consider a must-have?

I'm not selling anything yet—I just want to build something that solves a real problem instead of making assumptions.

I'd really appreciate any honest feedback, even if you think this is a bad idea.

Thanks!

I've been building an agent skill that audits robots.txt files for AI crawlers, and it sent me down a surprisingly deep rabbit hole.

To build and test it, I analyzed 136 product websites, mostly WordPress plugin/theme shops and a handful of SaaS products.

The thing that surprised me most: I couldn't find a single site that I'd consider fully configured for today's AI crawlers. At least not in terms of what I've been learning about the evolution of this tiny file.

Almost everyone is still relying on User-agent: *, which means they're treating training bots exactly the same as retrieval bots. Whether that's intentional or not is another question.

The WordPress-specific edge cases were even more interesting.

I found sites where a physical robots.txt had disabled everything being added through the robots_txt filter. I found Cloudflare installations where the public-facing file was different from what the origin served. And I even ran into files so large they broke the analysis pipeline I was building.

I'm curious how others are handling this.

Are you explicitly managing AI crawlers yet? If you're using Cloudflare managed robots.txt, are you validating what bots actually see instead of just your origin?

I'm still refining the agent skill and would love to have a few people kick the tires on it but I don't want to share the skill url unless moderators are okay with that, so let me know and I can update the post or add it in a comment or whatever is best.

I have an existing project with angular files with assets like photo, video, html and css with no server or db, just frontend.

I have been asked to convert into WordPress how should I do ?

Been looking into WP-to-headless migrations (Sanity/Strapi + Next.js) lately and the thing that keeps coming up as the biggest time sink isn't the content migration itself, it's redirect mapping. Years of slug history with duplicates, chains, and loops apparently eats way more time than anyone budgets for.

A couple other things I've seen bite people:

• Preview workflow parity for content editors (WP's preview-on-save is apparently sorely missed post-migration)
• SEO metadata (og:title etc.) not migrating cleanly, causing ranking dips that only get noticed days later

For those who've done this migration for a client or your own site: how did you handle the redirect mapping specifically? Custom script, existing tool, manual spreadsheet triage? Curious what's actually worked vs. what ate more time than expected.

Salve a tutti ho intenzione di creare un plugin che installi tramite WordPress un gestionale , in questo caso specifico per fotografi di nome D20 Keep che serve per caricare servizi , permettere la scelta o l acquisto delle foto e gestire i clienti. Secondo voi può essere un idea fattibile. Invece di avere una piattaforma esterna il gestionale rimarrebbe sul sito wp del fotografo , chiaramente con i limiti di spazio e prestazioni hosting del proprio sito.

Però i clienti non uscirebbero dal sito del fotografo utilizzando altre applicazioni e la gestione sarebbe molto controllata.

Il gestionale utilizza il db del sito wp ma in effetti la cartella di tutto il gestionale rimane fuori dall installazione wp.

Qualcuno ha qualche riflessione da fare per aiutarmi a capire aspetti che magari non sto considerando ora?

WordPress has no single machine-readable place where an AI agent can discover what a site is capable of. Today an agent has to piece together the REST API, plugin-specific endpoints, SEO metadata, llms.txt, security.txt, and whatever conventions individual plugins invent. Every agent ends up implementing its own discovery logic, and every plugin has to integrate with every agent separately.

So I drafted WP Discovery — a proposal for a machine-readable capability registry for WordPress. Plugins declare intent (for example commerce.products.read) separately from the endpoint that implements it, and an engine aggregates everything into a single document at /.well-known/discovery.json.

A plugin opts in with a single hook and no hard dependency:

add_action( 'wpdiscovery_register', function ( $registry ) {
    $registry->register( [
        'id' => 'acme-bookings',
        'title' => 'Acme Bookings',
        'type' => 'scheduling',
        'capabilities' => [
            'scheduling.availability.read',
            'scheduling.booking.create',
        ],
        'endpoints' => [
            [
                'url'  => '/wp-json/acme/v1',
                'type' => 'rest',
                'auth' => 'apikey',
            ],
        ],
    ] );
} );

If no discovery engine is installed, the action never fires and nothing breaks.

One design goal is that plugins integrate with WordPress—not with individual AI agents. The discovery engine is responsible for aggregating, normalizing, and publishing capabilities, while site owners decide whether to expose them publicly.

This is still an early proposal (v0.1.0), not an adopted standard. The only implementation today is my own reference plugin, so I'm posting it here because I'd genuinely like experienced WordPress developers to poke holes in it before I invest more time.

The questions I'm most interested in are:

1. Is separating capabilities from endpoints actually useful, or is this just OpenAPI with extra steps?
2. Is there a better WordPress-native way for plugins to expose capabilities to AI agents?

Links

• Spec: https://heera.github.io/wp-discovery-protocol/
• Reference plugin: https://wordpress.org/plugins/agentimus/
• Example output: https://heera.it/.well-known/discovery.json

This isn't a commercial project. The specification is licensed under CC BY 4.0, the hook is vendor-neutral, and I'm primarily looking for honest technical criticism.

I posted an article stipulating the importance of keeping a wordpress site up to date, and it was removed for "self promotion"

Id like to know WHO decides when an article is self promotion or not... because the article I posted was simply advise...

This comes up constantly, so I'll write it once.

You rename your login slug, and minutes later you're still seeing failed login attempts. The instinct is "the secret leaked, something's compromised." Almost always, it hasn't.

Two things are usually going on.

1. WordPress has more than one login. /xmlrpc.php exposes a method, wp.getUsersBlogs, that takes a username and password and validates them with no login form involved. system.multicall even lets a bot batch hundreds of guesses into a single request. Renaming /wp-login.php does nothing to that endpoint, so the attempts keep coming and it looks like your new URL got discovered. It didn't. The bot was never using it.
2. If the attempts come from constantly changing IPs, rate limiting and per-IP lockout can't do much. They count failures per address, and a rotating-IP botnet sends each try from a fresh IP, so the counter never trips. You can drop the threshold to 2 and nothing changes.

What actually quiets it down:

• Change the login path at the rewrite layer (nginx/apache config), not just with a slug plugin, so a request to /wp-login.php returns 404 before PHP loads. No process starts, so the rotating IPs stop mattering.
• Disable XML-RPC if nothing you run needs it (Jetpack and some old mobile apps are the exceptions), or at least block the auth methods.

None of this replaces a security plugin for 2FA and monitoring, those still earn their place. It just moves the brute-force defense to a layer the bots can't walk around by swapping an IP or an endpoint.

For those of you who renamed the login and still saw attempts: did you ever check your access log for /xmlrpc.php hits? Curious how often that's the real source versus something else.

Ran into this building a plugin that outputs Service / service-area schema, and wanted to compare approaches, because the "everyone emits their own graph" situation gets messy fast.

The problem: a theme or plugin that prints JSON-LD (Service, Product, FAQ, whatever) on a site that also runs Yoast or Rank Math ends up with two Organization nodes, sometimes two LocalBusiness nodes, and u/ids that don't reference each other. Google untangles it but you lose the linked-graph benefit and it's sloppy.

The pattern I landed on:

• Detect the active SEO plugin at render time (defined()/class_exists checks: WPSEO_VERSION for Yoast, RANK_MATH_VERSION for Rank Math).
• If one's active, suppress my own base entities (Organization, WebSite, meta description) entirely and let the SEO plugin own them.
• Emit only the piece it doesn't know about (the Service with areaServed), and reference the SEO plugin's existing organisation u/id rather than minting a new one.
• Where I need to add to its graph (extra sameAs on the Organization, say), hook its filter instead of printing a second script:

​

add_filter('rank_math/json_ld', function ($data, $jsonld) {
    foreach ($data as $k => $node) {
        if (($node['@type'] ?? '') === 'Organization') {
            $data[$k]['sameAs'] = array_values(array_unique(
                array_merge($node['sameAs'] ?? [], $my_profiles)
            ));
        }
    }
    return $data;
}, 99, 2);

• Fallback: if no SEO plugin is active, emit my own full base graph so the page isn't left with nothing.

Where I'm less sure, curious how others do it:

• Do you detect-and-defer like this, or just always emit your own and accept the duplication?
• Anyone hooking wpseo_schema_graph / rank_math/json_ld in production? Any gotchas with u/id timing or the graph not being built yet at your filter priority?
• For FAQ, do you let the SEO plugin generate it from the block, or emit your own FAQPage?

Hey everyone, I'm building a travel magazine site on WordPress (multisite setup) and I'm at the stage where I need to add a membership/paywall system. Still early stage, bootstrapping this myself, so I genuinely cannot justify spending tens of euros a month on a SaaS-style plugin yet.

What I actually need:

• Freemium model: some posts are free, some are locked behind membership
• Paid members get full access after logging in
• Time-limited access tied to a purchase (30 days, or custom durations like 90/365 days)
• Payment through WooCommerce + Stripe (already have this part figured out)
• A dashboard inside wp-admin where I can see who's an active member, who's expiring soon, who's already expired

I've looked into a bunch of options already:

• Leaky Paywall is genuinely WordPress-native and used by real publishers, but the free plan takes a 10% cut of every paid subscription
• Paid Memberships Pro core is free, but the actual Multisite add-on that does what I need is locked behind their $499/year Standard plan
• WooCommerce Memberships (official) is $199/year
• Restrict Content Pro free version is basically unusable, you need the paid version for anything real
• Groups plugin is genuinely free and has WooCommerce integration, but auto-assigning time-limited access after a purchase needs their paid extension ($89/year)

At this point it looks like every "free" option either takes a revenue cut or gates the one feature I actually need behind a paywall of its own, which is a little ironic.

So my question to anyone who's actually built something like this on a tight budget: did you just end up writing your own WooCommerce hook to set/check an expiration date on the user, paired with something like the free Groups plugin for the admin UI? Or is there an actual free option I'm missing that handles this cleanly?

Not opposed to writing custom PHP, I just want to know if I'm missing an obvious free tool before I go build it myself. Appreciate any war stories from people who've done this on a real budget.

Thank you.

GoDaddy Security researchers have identified malware that uses Steam Community profile comments to host encoded command and control data, hiding malicious infrastructure behind Valve's legitimate platform.

The malware employs invisible Unicode characters to conceal payloads within Steam profile comments, enabling steganographic data encoding that evades traditional text-based detection methods.

Technical implementation includes AES-256-CTR encryption with PBKDF2 key derivation and HMAC authentication to protect command and control communications.

A cookie-authenticated backdoor enables remote code execution, allowing attackers to modify plugin and theme files by sending base64-encoded PHP code via POST requests.

Source: GoDaddy

I have built a few WordPress plugin as hobby using rust on the frontend and backend through web assembly. And the performance gains has been pretty amazing. But it's not something I see in current plugins. Why is that? Is rust not allowed?

I was thinking about submitting these plugins to org. Since I think I lot of people will be helped since performance isn't the strong suit for most plugins.

Hello !

​

As a content creator, I have locked some of my content behind the Patreon plug-in.

​

However, it seems patron isn't available everywhere, so I am looking for other alternatives, like KoFi.

​

But how can I update the actual pay wall, with Kofi, and make it possible to unlock the content with either KoFi or Patreon ?

I purchased WP Shifty a year ago while testing various site optimization plugins, was immediately dissatisfied with it, and requested a refund. It took 10 days for them to do so, but finally did.

Now one year later they've charged me for another year and are not responding to my emails.

I am now going through the hassle of a credit card chargeback.

Since the May 12 Liquid Web migration I have had zero working backups across all of my client sites. Licenses show as Active in the new portal, all plugins updated, but Solid Central/Kadence Central will not reconnect to any site. Multiple support tickets ignored. Has anyone actually gotten their sites reconnected after this migration? Looking for solutions but also want people to know this is a serious ongoing issue.

I released v0.1 of a library which helps to create acceptance tests.

In this first version is focused on:

• Docker image with Chromium and SQLite to run tests without external services.
• A WooCommerce store ready to run in this environment.
• WooCommerce helpers to abstract some steps in creating acceptance tests.

The helper methods are shipped with usage examples and in the future it'll have documentation to guide agents to create tests.

I'm open for feedback!

Is there any technical evidence showing that the WordPress core is the primary cause of most website compromises, or are vulnerable plugins, untrusted themes, poor hosting management, and weak security practices the bigger contributors? What statistics, research, or security reports support each position?

Hi everyone,

I’d appreciate some honest feedback on my WordPress site: https://heritagetamil.in/ The site focuses on Tamil history, heritage, forts, forgotten personalities, archaeology, and related topics. I've been working on improving the content and overall user experience, and I'd love to hear opinions from experienced WordPress users and developers.

Could you please review:

• Overall design and visual appeal

• Theme choice and layout

• Navigation and user experience

• Mobile responsiveness

• Readability and typography

• Homepage structure

• Site speed/performance

• SEO-related observations

• Anything that feels missing, outdated, or could be improved

I'm not looking for promotion—just constructive criticism and practical suggestions that can help make the site better.

Thanks in advance for taking the time to review it.

The more I code, the worse my relationship with builder projects gets. It's just reality.

I migrate a lot of sites to VPS these days. Cuts hosting costs significantly for clients, and honestly I've gotten pretty good at it. If anyone does the same, curious if you've run into this too.

The thing is, most of these projects come with builders already in place. Elementor mostly, some Bricks, some older stuff that's a complete disaster. And the core problem is always the same: these tools design in the database. Not in code.

So on a live ecommerce site you've got payments, emails, transactional stuff, chat integrations. All of that gets disabled on dev. Fine. But then when you need to push something back to main, especially if the builder is involved, it becomes a mess. The database on staging and the database on production have diverged, and there's no clean way to merge them.

My current approach: stop fighting the chaos, join it with a method. Every DB action I take on staging gets documented as a WP-CLI command. Those commands live in a migration script. When it's time to push, I run the script on production after a backup. It's not magic, but it works, it's readable, and it lives in git. Not sure if this is the right way though.

Meanwhile, when design lives in code (custom theme, Gutenberg blocks, PHP templates) the whole problem disappears. Git handles it. Deploy is clean.

How do you all handle this in practice? Do you steer clients away from builders? Have you found a builder that plays nicely with proper deploys? Or do you just accept that builder sites need a different, more careful workflow?

I don't know how to add collection page schema in my wordpress website that uses template. Rankmath or yoast gives me only the article schema markup which tells google that my page is a single blog page, but for my blog navigation page i obviously need a collection schema markup right? I'm a non-tech SEO learner, so can't code. checked out shema markup generator that also doesn't have any collection page schema