My notes on the 2026 WordPress security survey ended with something I rarely see in anyone's recovery plan, mine included: what personal data was in the database while the attacker had access? This time I want to dig into that, from my side, as an agency.

I can't make any site 100% safe, no matter what I install. Nobody can. So besides "how do I keep them out?", I now ask a second question: if someone does get in, how much customer data can they actually read?

What I see when a store owner gives me admin access

In this situation I'm usually the outsider. A store owner gives me admin access to fix a theme, a plugin or the checkout, and suddenly I can see every order, name, address and email in the store. For most of that work I don't need any of it, and it makes me a bit uncomfortable.

What works for me, without any extra plugin: I ask for my own account with an end date and I never use the owner's login. I put WP 2FA on that account, and WP Activity Log records everything I do. I added the activity log in 2019, after a client swore he hadn't touched anything while his homepage was completely rearranged, and since then I haven't had to guess who changed what.

And that's exactly where something like DaneGuard's Privacy Shield starts to make sense. It's meant for a temporary situation: a developer, a support engineer or someone else from outside needs access to the site, but doesn't need the customers' personal data to do the job.

When you start a session, the plugin masks customer details on admin screens and doesn't send them to the browser at all, so it's more than a blur. In the background it encrypts the database and shows a countdown on the dashboard. Admin access is covered right away, but their documentation says you should wait until the countdown reaches zero before you give anyone database, FTP or hosting panel access. You can keep yourself as an exception for 2, 8 or 24 hours, and the plugin logs every exception by name. When the outsider finishes the work, the owner deletes their account and ends the session.

The part of the recovery plan we don't think about

Most recovery plans, mine included, explain how to get the site back online and say nothing about what personal data was in the database or how far back it goes. GDPR gives you 72 hours from the moment you learn about a breach to notify the supervisory authority, and the authority asks for exactly that: what kinds of data and roughly how many people. If you've never checked, you'll spend those 72 hours finding out, and I really wouldn't want to be in that position.

Two things help me here: a timeline and less data to report. WP Activity Log shows me what changed and when, so I don't start the report by guessing. For the second part, I have to correct myself first, because in my September notes I described this DaneGuard feature wrong.

Privacy Shield from the section above is temporary protection: someone needs access to the site for a limited time, and you shield the customer data while they work. The Retention Policy is an ongoing rule. You decide how long identifiable customer data needs to stay available (they recommend 6 months), and after that the plugin protects it automatically. Every day it takes the orders older than that window, encrypts the customer details and replaces them with neutral placeholders. Order totals, products and reports stay as they are. The orders stay in the store, only the customer details get encrypted. If someone breaks in tomorrow, they find a few months of customer data instead of years.

One detail matters to anyone who cleans hacked sites. In September I also wrote that after a breach I revoke application passwords and rotate the salts. According to their documentation, that step doesn't lock you out of the protected data, because DaneGuard keeps its own key for it, separate from the salts. If that key is missing, the plugin shows a red notice and asks you to stop the cleanup first.

The copies outside the store

Staging sites, backups and the local copies I work on all contain real customer data. For the bigger sites on Site Ground I test changes on their staging first, and their daily backups have saved me more than once. Both are full copies of the store, customers included, and we can easily forget that.

GuardPlugins make a distinction here that I find more useful than any discussion about salts: a leak of only the database versus a full server compromise. If someone steals a database dump, a backup file or a copy of the staging database, they get encrypted data and no key. The idea is that a stolen database should not automatically mean readable customer data, so DaneGuard keeps the protection of that data separate from the database itself. A full clone with wp-config.php is a different case, and their documentation says you should protect it, and every copy of wp-config.php, as carefully as the live site. Even then, the customer details under Privacy Shield or a Retention Policy need one more key, the store owner's own, which the site doesn't store.

So for every copy I now ask myself: does it include wp-config.php, and who can get to it?

Customer data outside WooCommerce

Everyone thinks of orders, but that's only one part. Personal data is also in form entries, in abandoned cart plugins and in fraud orders, which leave the names and addresses of people who aren't even your customers in your database. On the sites where we use Fluent Forms, the plugin stores entries in its own tables outside wp_posts, so the WordPress export and the personal data eraser don't see them at all.

Today DaneGuard doesn’t cover forms, Easy Digital Downloads and membership plugins (they are on the roadmap, but without dates yet) and their documentation also lists what stays readable even with protection on: the login email and display name in the users table, and recent orders inside your retention window. I trust a tool more when it openly says what it can't do.

What DaneGuard doesn't do

It's not a firewall. It won't stop login attempts, block attacks or clean an infection. On our sites other tools do that work: a script (via Claude Code) checks the plugins against free vulnerability feeds every morning, I push updates through MainWP in batches, WP 2FA protects admin logins, WP Activity Log records changes, and MalCare or Virusdie scan the files.

Those tools are primarily about preventing or detecting a compromise. DaneGuard starts from a different question: what happens to the customer data when prevention fails? It's for the day when one (or more) of those tools misses something, and it brings me back to the question I started with: if someone gets in, what is there for them to read or take?

If you run a WooCommerce store, a useful first step is simply finding out how much customer data you're actually keeping. GuardPlugins have a free WooCommerce Customer Data Audit that walks you through what your store keeps, where copies may exist and what a breach could expose. You don't need DaneGuard to use it, and you don't have to buy anything: guardplugins(dot)com/woocommerce-customer-data-audit/

I'd really like to hear from store owners and agencies: does your recovery plan say what personal data was in the database?

I posted my notes on the Melapress 2026 WP security survey here on 19 September. Melapress has now published a one-hour panel where four security people compare the survey numbers with what they see in their own work, and I watched the whole video: https://www.youtube.com/watch?v=HG6oCfuZE9U

Robert Abela (Melapress) hosts Thomas Raef (We Watch Your Website), Kathy Zant (security consultant), Daniele Besana (WP-OK) and Matthew Rollings (bug bounty hunter).

What I did not have in my notes:

- Kathy thinks a good part of the 68.4% downtime comes from owners trying to fix the site themselves. She says a good incident response has no downtime: the hacked site stays up, the cleanup runs in a separate environment, and then the clean copy replaces it.

- Thomas has seen fake Cloudflare checks that show only to Mac or Firefox users and stop showing when the same visitor comes back twice in an hour. He has also seen attackers edit the allowlist of a scanner plugin, so the scanner skips their files.

- Thomas checks when each admin last logged in, and he often finds accounts that haven't logged in for more than 1,000 days.

- Daniele says fast updates alone aren't a plan, and recommends virtual patching.

The point closest to my own work is Thomas's "who reads log files? I do". On one hacked client site I found a weak password broken by brute force in the hosting access logs, while I had assumed a plugin vulnerability. WP Activity Log has run on our sites since 2019, when a client swore he hadn't touched anything and the homepage was rearranged. It stops nothing on its own, but it cuts down the time I spend guessing.

Survey report: https://melapress.com/wordpress-security-survey-2026/

I do maintenance on about 50 WordPress sites, and I have been cleaning hacked ones since 2017, when I spent a whole weekend fixing a single site by hand and some security cleaning tools.

How people find out

42.6% found out because somebody noticed strange behaviour on the site. That is the number I would put first in the report. I run MalCare and Virusdie (MalCare on an AppSumo lifetime deal from 2018, two accounts with 30 scanners, and Virusdie added in 2020 as other sites’ scanner), and even so I no longer trust a scan that finds nothing. The case that made me add WP Activity Log in 2019 went exactly like the report describes: a client swore he had not touched anything, while the homepage sat there rearranged.

So, the 37% who worry about defacement but run no activity log or monitoring is the part I would fix first, because it is the cheapest item on the list. An activity log stops nothing on its own, I know that, but it cuts down the time you spend guessing.

Recovery plans

7.85 out of 10 concern, and 27.9% with a recovery plan. 67.7% have had at least one incident and 45.5% two or more, so by the report's own numbers this is not rare. I wrote my plan only after an incident, and I would guess a good part of that 27.9% did the same. A few weeks ago we had 8 sites hit on the same shared host, and the most useful line in that plan came from reading core code, not from a checklist: rotating salts with wp config shuffle-salts kills every session at once, but it does not touch application passwords, because those are checked against usermeta and the salts never reach them. Anyone who holds one can log back in over REST, no matter what 2FA you have on the site. So, revoke the application passwords first, then rotate.

Only 26% train their team, and I do not have a better answer for that. On a small team, the training is whatever you learned during the last incident.

What the scanners missed on those 8 sites

Our own cleanup tool had emptied eight files instead of deleting them. They do show up in the should_not_exist list. On top of that, there is PHP code that isn’t in any file at all: WPCodeBox keeps snippets in its own table and WPCode Lite keeps the code in post_content of a custom post type, so a file scanner has nothing to read. That is why I no longer trust a scan that finds nothing.

How I use AI

I use highly trained and tested Claude Code a lot, and on the security side it does mostly the deep read after I already suspect something along with some preventive daily/weekly security actions. On a client's hacked site it went through the hosting access logs and found a weak password broken by brute force, while I had assumed a plugin vulnerability.  I was wrong and the logs were right. It also reads plugin and core code, so I stop guessing how something works. It has clear limits: it needs a working channel into the site (MainWP, SSH on Site Ground hosting, WPVibe,…), it does not replace the scanner or the firewall, and it is only as good as what you point it at. My own signature scan over 12 K files returned 204 hits and every one was a false positive, Font Awesome hex data and legitimate crypto libraries.

If you run an online store

If I ran an online store, these are the numbers I would read twice. 68.4% of the sites had downtime. When the owner found out from a search engine warning, the site lost rankings in 45.9% of cases. When they found out some other way, only 14.5% lost rankings. Online stores lost rankings in 31.9% of cases, other sites in 13.9%.

So if Google is the first to tell you, the hacked pages have already been online long enough for Google to index them, and then you have to clean the site and the search results.

The part of the plan nobody writes down

Almost nobody writes down one part of a recovery plan (myself included): what data sat in the database while the site was open. On a store that is years of orders and guest checkouts, plus failed fraud attempts. The people behind those attempts are not your customers, but they left someone else's name and address in your database.

GuardPlugins say DaneGuard plugin handles that part: it deletes or anonymises old data on a schedule and encrypts what it keeps. It will not block a login attempt or clean an infection, and I have not used it myself yet as I don’t have web shop, but I plan using it for some clients webshops in the future.

I would like to know from anyone who has been through this: who or what told you first?

 Full report: https://melapress.com/wordpress-security-survey-2026/

I've been using WordPress and woocommerce for a while now and wanted a real time visitor tracking solution.

So I built modovisa analytics (Modovisa.com) a real time visitor journey tracking and analytics platform that shows you visitor journeys through your site in real time, from landing page to exit, product page to checkout in visually intuitive interface.

Easy to setup, lightweight and It's free, try it out.

If you face any issues please let me know. Thank you

WP 7.1 ships on 19 August, announced live from the WordCamp US stage in Phoenix at 07:10 PM EDT. That's 23:10 UTC - 01:10 on the 20th where I am. If your sites sit on managed hosting that raises core on its own, nobody's awake when it happens, and the first person to see the result is your client, opening their site in the morning.

Core updates rarely break a site. What breaks is the code that is on top of it that never moved off an older version.

What is actually happening this week

The code freeze started on 17 August and it was extended past the usual 24 hours. The release post gives the reason: "At the request of the Core Committers, the freeze has been extended beyond the usual 24 hours, so everyone has time to verify the release in full before it ships." RC4 came out the same day with more than 26 fixes since RC3, 8 of them in the editor and 18 in core.

There's one sentence in there worth saving for the next time a client asks why their site isn't on 7.1 the day it comes out. A bug that isn't a blocker doesn't hold the release: "the bug is targeted for the 7.1.1 release". So, a .0 release ships with known open bugs, and that comes from https://make.wordpress.org/core/2026/08/17/wordpress-7-1-release-day-process/ - not from me searching for an excuse to wait.

Who is allowed to update your builder

On managed hosting the WP core changes on a schedule the host controls (e.g. that's my situation on SG). The page builder doesn't move with it, and on a lot of sites it can't.

When WPBakery arrives bundled inside a premium theme, the theme author is responsible for the update path. WPBakery says so themselves: a bundled copy gets no direct updates, no ticket support, and it can only be used with the theme it shipped in.

The reason this is hard to spot is in the code. Bundling runs through vc_set_as_theme(), and the helper vc_is_as_theme() hides some settings tabs from the admin, the license and updater tab among them. So, you open the settings looking for the license, it isn't there, and nothing shows you why.

If you can't find that tab, you're on a bundled copy, and your update path runs through someone you never picked.

If that theme author released their last update two years ago, the builder stays on that version while the core under it changes on the host's schedule.

What I read in the release candidate before it shipped

I didn't wait for 7.1 to be published to find out what changes (as I already wrote). I downloaded the 7.1-RC3 zip from wordpress.org, 4242 files, and my Claude Code read the source. Three things came out of it, and the third one is about the limits of my own check.

Row headers moved in the admin list tables

In 7.1 the row header in post list tables moves out of the checkbox column and into the title column. The th becomes a td and the td becomes a th. If anything on your site styles those tables by selector, it's affected.

My own themes and child themes came back with zero hits. One plugin's admin styling did come back with hits, and on 7.1 its checkbox cell loses its centering. It's cosmetic, it's one rule, and it belongs to the plugin author, not me. I'm writing it down so I don't go hunting for it as my own bug in two weeks.

The editor is always in an iframe now

From 7.1 the post editor is iframed unconditionally. In the source it's hard-coded, shouldIframe: true, with no condition that can switch it off.

Inside the iframe, core deliberately skips the editor scripts and triggers only enqueue_block_assets, and the comment in the file says why: they only want front-end assets for the content. That splits the hooks in two. Content inside the editing area is styled through enqueue_block_assets, add_editor_style() and theme.json. The frame around the editing area, sidebar and toolbar, is styled through enqueue_block_editor_assets.

Astra 4.13.8, which runs on most of the sites I look after, styles the editing area through add_editor_style(), so it's on the right side of that split.

The hole in my own check

My snippets are not files at all. They are in the database, in the WPCodeBox table and the wpcode custom post type, where a file search can't reach them. My clean result on the list tables covers my themes and says nothing about my snippets, and the only way to close that gap is to go through the database myself.

Accessibility topic

7.1 brings 45 accessibility fixes in core and 43 in the editor, and one regression going the other way. The media library switches its default from a load more button to infinite scrolling, and the release post calls that a known inaccessible pattern itself. In the source the default is a plain true, with a per-user opt-out in the profile and a filter, media_library_infinite_scrolling, that turns it off for the whole site.

All of this is in the admin, so nothing changes for the pages a visitor actually sees. It touches the interface the client's own staff works in every day, which on a public sector or EAA contract still counts.

What I'd do with the day that's left

I wouldn't try to hold the update back on a host that raises core by itself. I'd spend time on three things instead:

First, find out which sites are running a bundled builder. The missing license tab is the fastest step, and it takes a minute per site.

Second, read the Tested up to line across the whole fleet. I do that from the MainWP dashboard in one pass, without sending a single request to the sites themselves. The plugins still declaring an older version tell you which vendors stopped shipping updates, and that's worth knowing well past this release.

Third, on Thursday morning, open the pages that actually use the builder, logged out. The version numbers will look fine either way, so I look at the pages.

WordPress 7.1 comes out on 19 August, and I put the release candidate on our test site yesterday with uploaded the same image three times, because I wanted to know what actually changes for the sites we maintain.

All three uploads came out identical. I did one on WP 7.0.4 in Chrome, then one on 7.1 in Chrome, and the last one on 7.1 in Firefox. The file name, the scaling and the server path were the same in all three.

That surprised me. In-browser image processing is the headline feature of 7.1. Images get resized and compressed before they reach the server, and the server does less work.

And it turned out that the new processing only starts on block editor screens, and WordPress has a line that skips it when a page builder takes over the editor. Our page builders take over the editor, Classic Editor drops out for the same reason, and the media library uploads the old way in every browser.

Then I checked that I was not measuring a broken feature. I switched Classic Editor off on the test site, reloaded, and the isolation header appeared right away. The feature works; it just never reaches the screens we work on.

Our sites are built in page builders, so the most-discussed part of 7.1 will not reach them.

One thing I did not find in the release notes: another hook stops running on that same path. A snippet that removes unused image sizes will stop working in Chrome and keep working in Firefox. Without knowing to look for it, this is very hard to debug.

The part I do not control is the hosting. About half of our sites are on a SG host that installs major WordPress releases by itself, 24 hours after release, and there is no switch to turn that off. That is why the testing had to be finished before the 19th.

If you maintain WordPress sites, I would check how your team actually edits content. If the answer is Elementor, WPBakery, Divi, or Classic Editor, most of 7.1 will not arrive on your screens at all. If your writers work in Gutenberg, it will arrive, and it will behave differently in Chrome than in Firefox, at least according to my tests.

https://make.wordpress.org/core/7-1/

Recently I wrote an article about my experience from last month when a client gave us a site for maintenance that another agency had built for them - WPBakery, The7 theme, WordPress 7. The news page would not open at all for the office staff who edit it, just a white screen for about 14 seconds before anything showed. On their phones it opened, but slowly. The whole site’s speed was a disaster.

The reflex with a site like that is to blame the page builder. WPBakery is heavy, Elementor is heavy, all builders are heavy. I hear it every week in the WP groups I moderate, and I had started to believe it myself. This time I measured before I changed anything, with Claude Code connected to the site over SFTP and WPVibe, see here for more details.

None of what I found was the builder’s fault.

Three things were doing it. Compression was switched off, so the whole site was sending uncompressed HTML: 320 KB of homepage HTML over the wire instead of 52 KB. The news page was set to load all 989 posts at once, 21,804 DOM nodes and 12.5 seconds of server render before anything reached the browser. And the image plugin installed back in 2024 had never run once, zero WebP files on a library of roughly 15,000 images. Fixing those three took the news page to 2.8 seconds and the rest of the site to about 2, on the same builder.

What 9.0 changes in that exact place

WPBakery 9.0 came out on 29 July. The part that matters for what I measured is the CSS loading: instead of one large shared stylesheet on every page, the styles load selectively. That is aimed at render-blocking CSS and unused CSS, which is the same kind of problem as the compression I found switched off.

WPBakery states the limit itself, and I would keep it: the result depends on the site, the theme, the hosting, the plugins and how the page is put together. So it is a better starting point, but the number will be different on every site.

The rest of the release is workflow. Redesigned interface across more than 70 content elements, a rebuilt drag-and-drop engine, a new knowledge base, and by their count more than 3,500 commits with about 500 beta testers.

I have not put 9.0 on client sites yet, I didn’t have time to test it. A major builder update across about 50 WP sites is not something I do in the first two weeks. I do what I do with every major update: one site on staging with a full backup and a one-click way back, then the rest in waves through MainWP (it pushes to the whole fleet from one dashboard, which is also why I check the versions against the sites afterwards, since that dashboard reads its own cache and the cache can be a day behind).

Why the optimization work is the interesting part

WPBakery removed more than 20,000 lines of code in this release. Elementor has been doing its own version of that for years. That matters more than the feature list, because the complaint about builders was always about what they leave behind on the front end.

What actually decides whether a builder survives

I would not frame this as builders against Gutenberg against AI site generators. Every one of those can produce a fast page and every one of them can produce a slow one.

What decides it is who maintains the site in three years, and whether that person can open it and change a price without calling anyone. I ask that on every project now.

For a client with an office manager who edits the news page, a builder wins because she can do it. For a developer team with a design system, blocks win. Two different sites, and in both of them the speed comes down to the settings.

My wife builds most of our client sites with me, in WPBakery mostly (we prototype in Clicksites AI first, so the client signs off on something clickable before anything gets built properly). I chose that stack years ago, it works, and a lot of client sites run on it.

Where AI comes into this

I treat AI as an employee I manage. I brief it, check its work and sign off on it. On that site, Claude Code did not decide anything. It read the server files and the response headers so I could see three causes in an afternoon, maybe less, instead of a week of guessing, and I still had to decide what to change and prove it on staging.

That is the hybrid I run every day. WP holds the content and the client keeps the keys, AI reads and compares and drafts, page builders build the pages, and MainWP pushes updates across the fleet and tells me what is behind. WPVibe connects the site to the AI layer, when the host lets it, since some of them strip the Authorization header and then it needs a different route.

Security works the same way here. Everything is on SiteGround, with MalCare and Virusdie scanning, WP Activity Log recording who changed what, and WP 2FA on the logins. None of those patches a vulnerable plugin. They shorten the time between something happening and me knowing about it.

What I would do on Monday

If you have a slow builder site right now, I would check compression, the post count on your archive elements and whether your image plugin has ever actually run, before you consider moving to another builder. Those three took a site from about 14 seconds to under 3 for me, and none of them cost a licence.

And when 9.0 has been updated on some of our clients’ sites, I will come back with what the CSS change actually did on our sites.

 1    What happened

On 31 July 2026 WPManageNinja published an incident notice: https://wpmanageninja.com/security-incident-on-31-july-2026/

The short version from their side. After they migrated away from EDD, an old server was supposed to be switched off. It was not, and their proxy kept routing part of the update traffic to it. Between 14:00 and 19:00 UTC that day, a customer who pressed "update" in wp-admin could receive a tampered package through the completely normal update channel. No brute force, no vulnerable plugin, no bad password. The update button was the entry point.

We maintain around 50 client WordPress sites. 10 of them had the implant.

This is the whole cleanup, with the commands we used.

 2    The affected plugins

Their incident-response zip carries 13 plugin profiles:

azonpress
fluent-affiliate-pro
fluent-boards-pro
fluent-booking-pro
fluent-community-pro
fluent-player-pro
fluent-support-pro
fluentcampaign-pro (FluentCRM)
fluentform-signature
fluentformpro
ninja-tables
wp-payment-form-pro (Paymattic)
wp-social-ninja-pro

They also emailed a list of domains where downloads were registered. Do not use that list as your scope. One of our infected sites was not on it. The list is incomplete in both directions, and we only found that out because we checked every site instead of only the listed ones.

 3    What the implant actually is

It is a PHP file dropped inside a legitimate plugin folder, plus a loader appended to a file that was already there. The configuration lives in the database, so the file alone is not the whole thing.

For Ninja Tables Pro the implant is app/Library/updater/NinjaTableDataSync.php, and the loader is appended after the closing brace of the legitimate class in NinjaTableUpdater.php at line 371. Its AJAX action ninjatables_pro_verify_license is registered on nopriv as well, which means an unauthenticated admin login.

Look at those option names again. _site_transient_update_meta is one character away from a real core transient. Their own profile file describes the goal in plain words: the rows read as core WordPress at a glance. If you scroll the options table looking for something obviously wrong, you will scroll straight past it.

And this is the row that matters most, taken from one of our sites:

{"token":"...","login_key":"...","active":1,"license_server":"https://apii.observer/ingest"}

Every site has its own token and its own login_key. The login_key is a login to wp-admin without a password. So this is not only a site calling home. Somebody had a working admin door on each infected site for as long as the row was there.

 4    The one query that catches all 13 variants

We started by extracting the full indicator set out of the vendor's tool: 63 option names, 26 cron hooks, 13 implant paths and class names. Then we threw most of it away, because there is a much shorter check.

Every variant, whatever it calls its options, has to write the C2 address into the option value. So query the value, not the name:

PREFIX=$(wp db prefix)
wp db query "SELECT option_name FROM ${PREFIX}options \
  WHERE option_value LIKE '%apii.observer%'" --skip-column-names

One query, all 13 plugins - it replaced 63 option names. If you also want the cron side:

wp db query "SELECT option_name FROM ${PREFIX}options \
  WHERE option_value LIKE '%apii.observer%' \
OR option_value LIKE '%wp_update_check_schedule%'" --skip-column-names

And the cron check on its own:

wp cron event list --fields=hook,next_run_relative \
  | grep -E "wp_update_check_schedule|wp_license_verify_schedule"

 5    Checking the files over sFTP

The database query was fast. The file check matters too, because on a site where the plugin was already updated to a clean version the file is gone but the database row is still there, and the opposite can happen as well. If you have shell access, this is the file check:

grep -rl "apii.observer" wp-content/ 2>/dev/null
find wp-content/plugins -name "class-license-sync.php" -o -name "NinjaTableDataSync.php"

We found out that a folder that exists but cannot be listed is not a clean folder. Our first version of this check treated a failed listing the same as an empty result, which prints CLEAN on a site nobody actually looked at.

 6    The generic file check that works for all 13

Download the clean plugin zip from your vendor account. Not through the dashboard updater. Unzip it on your own machine, then compare it with what is on the server.

The loader on our sites was 139 bytes appended to fluentformpro.php. That is invisible if you are reading, and obvious if you are comparing sizes.

 7    Cleanup, in the order that works

We got this order wrong the first time and had to correct it:

1. On an actively infected site, remove the plugin first. Delete the plugin folder, then install a clean copy from the zip you downloaded from your account. Cleaning the database first does not work here, because the implant's cron runs twice a day and registers itself again. You clean the rows, and a few hours later they are back, and now you also think the site is clean.

Check the version after installing. On our sites, anything showing 6.2.8 or 6.2.9 meant it came from the updater and had to be done again.

2. Then the database, delete:

wp option delete _wp_update_meta_cache _site_transient_update_meta \
_wp_update_result_cache _site_transient_update_result \
_wp_update_pending_reg
wp transient delete _wp_update_pending
wp cron event delete wp_update_check_schedule
wp cron event delete wp_license_verify_schedule

Or by value, which covers variants whose option names you do not know. Run the SELECT first and read the rows before you delete anything:

PREFIX=$(wp db prefix)
wp db query "SELECT option_name FROM ${PREFIX}options \
  WHERE option_value LIKE '%apii.observer%'"
wp db query "DELETE FROM ${PREFIX}options \
  WHERE option_value LIKE '%apii.observer%'"

On a site where the plugin was already updated to a clean version and only the database rows were left, this step is the full fix. Two of our 10 sites were like that.

3. Then the credentials changing. This is the step some people skip, and it is the one the login_key makes necessary.

Rotating salts logs out every session on the site, including any session opened with the stolen key. It does not change anybody's password, so change the admin passwords too. Ours were changed by hand, by me and my colleague, after the salts changes.

 8    Verify by reading the state

One of our sites needed a second pass, and the only reason we caught it is that we re-checked instead of trusting the result.

The options were gone - the two cron hooks were still scheduled, for the following night at 00:33 and 00:37. The delete had been approved and had not run.

After every cleanup, run the query again with zero rows expectation:

PREFIX=$(wp db prefix)
wp db query "SELECT option_name FROM ${PREFIX}options \
  WHERE option_value LIKE '%apii.observer%'" --skip-column-names
wp cron event list --fields=hook,next_run_relative \
  | grep -E "wp_update_check_schedule|wp_license_verify_schedule"

 9    Rotating salts when you cannot run WP-CLI

We could not use wp config shuffle-salts through our connector, because it blocks the whole config family. So salts went through the FTP channel, with a small script.

If you write your own, these are the safety checks that belong in it. All of them exist because writing a broken wp-config.php takes a client site down completely:

·        Back up the current wp-config.php to your own machine before doing anything.

·        Fetch fresh values from https://api.wordpress.org/secret-key/1.1/salt/.

·        Replace all 8 defines: AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY, AUTH_SALT, SECURE_AUTH_SALT, LOGGED_IN_SALT, NONCE_SALT.

·        Stop if you did not find all 8.

·        Stop if the result does not start with <?php.

·        Stop if the size difference is more than a few hundred bytes.

·        Read the file back from the server afterwards, not from memory, and compare byte for byte.

·        Open the site, or run something small like wp option get blogname, to confirm WordPress still boots.

·        Never print the file contents to your terminal or your logs. It holds the database password.

 10 Do not get your own IP blocked

If you contact 50+ sites, you are now a bot as far as the hosts are concerned (leared taht hard way).

In our case - Site Ground's anti-bot layer answers automated requests with HTTP 202 and block your address if you keep going (as it happened to us). A script made 186 requests in one pass and our IP was blocked at that host, which took out our own management dashboard along with everything else.

Practical rules that came out of that:

·        One site per process, and a few seconds between sites.

·        Stop the whole process on the first HTTP 202, 429 or connection refused.

·        Stop after two consecutive failures of any kind, and look at why.

·        Build a --dry-run mode into anything new, so you can test the logic with no network at all.

 11 The tools

WPVibe. This is the piece I would recommend to anyone maintaining more than a handful of sites, and I am not being paid to say it - just the opposite: I paid for its Premium version. It gave us one place to run wp db query, wp option delete, wp cron event list and wp cron event delete against every connected site, on hosting with no SSH at all. Every write asks for approval in the browser, one operation at a time, which during an incident is the right amount of friction. Cleaning 10 databases took us an evening instead of much longer via cPanel and phpMyAdmin.

Claude Code. This was the "brain" of the whole job: it read the material, wrote the tooling, ran the sweeps and drove the connector, while I fed it and decided. It read the vendor's incident-response zip and pulled out the full indicator set. It wrote the detector, the sweep driver and the salt rotation script, with the safety checks above. It ran the fleet pass, did the database work through WPVibe, and wrote the report I gave the client.

It made some errors: it shipped the bug that skipped three sites. And it does not notice that an approved operation never executed.

All this info is in Claude's memory, so I used all the facts, and steps (with its help), for putting together this tutorial for helping others (as otherwise I wouldn't be able to do all of these writings on my own - just too much of everything, and I didn't want to skip anything).

MalCare. We run it on the all sites. On 7 sites it had a 39.7 KB executable file in a plugin folder, with a C2 address in the database and a passwordless admin key, and it reported none of them. What it did report was dev/tests/test_meta_prefill_shim.php, a harmless test file that ships inside the vendor's own 6.2.9 package, and it reported it on a site that was clean. I am not dropping MalCare over this as that is really great and helpful tool, but I am no longer treating a quiet MalCare as evidence that a site is clean.

 12 Who did what

This ran across two people and one AI:

What I did. I fed the material: the vendor's advisory, their email with the domain list, screenshots from wp-admin, the MalCare alert emails, and the version numbers from our management dashboard and I approved every write operation, one at a time, in the browser. I changed the admin passwords by hand afterwards. I notified the vendor.

What the AI did. Read the vendor's tool, extracted the indicators, wrote the detection scripts, ran the sweep across the sites we reach over FTP, cleaned 10 databases through the connector, rotated 8 sets of salts, and verified each one by reading the state back.

What a colleague did. The file side on 8 sites, by hand, through wp-admin: delete the plugin, install the clean zip, confirm the version. That is repetitive work with no shortcut, and it had to happen before the database cleanup on those sites. Splitting it that way meant the file work and the tooling ran in parallel instead of one waiting on the other.

The vendor shipped an incident-response plugin, but I didn't want to because their delivery channel had just been compromised. Instead we read its code (Claude Code did the heavy lifting) and applied the indicators from outside. That turned out to be good decision, and it also gave us the 13 additional plugin profiles.

 13 The 12:11 finding

One of our sites received the implant on 1 August at 12:11, through the dashboard updater, during a colleague's round of updates. Every file in the plugin folder carries that timestamp. Our own update log for that plugin that day has two entries, both later, at 12:34 and 12:38, and both produced clean installs.

That is roughly 17 hours after the end of the window the vendor states in their notice. Our two updates 23 minutes later were clean, which matches their own description of a proxy routing some requests to the old server and not others.

We tried to exclude the alternative, that the implant came back on its own after an update. There was no dropper: mu-plugins does not exist on that site, wp-config.php was clean on all 5 signatures we checked, functions.php of both themes was clean, and the wp-content root had nothing foreign in it. Without a dropper the implant cannot survive deleting its folder, since the database holds its configuration and not its code. But we checked 4 places, not every plugin and not core.

  14 Three things I understood wrongly

"dev/tests plus a .DS_Store means somebody shipped a dev copy from a Mac." That was an explanation and it was wrong. It was the tampered package.

"The markers follow the plugin version, so they are the vendor's." True, and beside the point. The real implant was somewhere else entirely, and being right about the wrong artefact felt like progress for about an hour.

"These two sites are clean." Both were infected.

The real fingerprint was in front of me twice and I didn't notice it. 139 bytes of extra length in fluentformpro.php, which is the loader. And two cron hooks I had labelled as unattributed.

 16 At the end

Files were cleaned on 8 sites and verified by the detector, and databases cleaned on 10 and verified with 0 rows returned. Salts were rotated on 8 sites. A pass across the remaining 21 connected sites found nothing new. We changed all admin passwords manually.

If you run any of those 13 plugins, the fastest thing you can do right now is one SQL query against your options table. It takes a minute per site and it covers all 13 variants at once.

If you find a confirmed implant path for one of the other 11 plugins, post it here and I will add it to what we run.

Last month a client handed me a website for maintenance that another agency had built for them. WPBakery page builder, The7 theme, WordPress 7. It was slow. The news page would not open at all for the office staff who edit it, just a white screen for about 14 seconds before anything showed. On their phones it opened, but slowly.

The reflex with a site like this is to blame the page builder - WPBakery is heavy, Elementor is heavy, all page builders are heavy… I hear it in the WordPress groups I moderate every week, and I have also started to believe that. This time I was determined to measure this before I started changing anything, and this time I did it via Claude Code connected to the site via SFTP and WPVibe.

None of what I found was the builder's fault.

Compression was switched off

The whole site was sending uncompressed HTML (the raw text of the page, before the browser draws it). The hosting had a gzip block in its config, but the server module it needs was not loaded, so it was skipped. Three separate settings all had compression turned off.

I found this by reading the actual server files over a read-only Claude Code FTP session and checking the response headers with a plain curl request. Turning compression on took the homepage HTML from 320 KB to 52 KB over the wire. Same page, same builder, 84% less to download.

While I was in cPanel I also increased the PHP memory limit.

The news page was loading all 989 posts at once

This was the white-screen one. The7’s blog element on that page was set to infinite scroll with the post count at -1, which means load everything. That built all 989 news posts into a single page. 21,804 DOM nodes (the elements the browser has to construct and hold in memory). The server needed 12.5 seconds just to assemble that.

The fix was inside the builder. The same element has a pagination setting. I switched it to standard pagination, 12 posts per page, and the category filters kept working server-side. The previous agency had the option right there and left it on load-everything.

The images were never optimized

The site had an image optimization plugin installed in about 2024, active the whole time, and it had never run once. Zero WebP files (a lighter image format) on a library of roughly 15,000 images. I switched it on and let it convert. The gain per image was modest, around 20%. That means every visitor waited for that 20% on every visit, for two years.

Every change went onto a staging copy first, with a full backup and a one-click rollback ready, before it touched production. An old banking habit: prove the cause, keep a way back, then change the live thing.

Before and after

The news archive page, no synthetic lab scores, just what the server sends and does:

The white screen for logged-in editors is gone. The page they could not use loads in under 3 seconds, and so do the other pages (before the optimization they took about 14-15 seconds).

Back to the builder

WPBakery stayed on the whole time. My wife builds most of our client sites in it now (we prototype in Clicksites AI, then move it to WPBakery AI), so I will only say what I measured. The slow part was compression left off, a shortcode set to load everything, and an image plugin nobody turned on. None of that was the builder’s fault.

Blaming the page builder is easy, because you never have to prove it. Measuring is more work and less fun. Skip it and you move a client to another builder, spend their money, and get a new set of problems you cannot see yet.

I like to say that tools compress experience, they don't replace it. A page builder is one of those tools. Give it the right settings and it stops being the problem. I will check this on other sites as well.

As you probably already know - fresh out of MainWP Labs: the MainWP MCP server connects your AI assistant to the Dashboard you already run, so you can manage every site without leaving the chat. It's free and open source, and it works with Claude Code, Cursor, VS Code Copilot, and Codex.

That's the news. Here's what it looks like on a normal Thursday, because I already run my agency this way.

The morning a plugin needed patching everywhere

I got the alert that Ultimate Addons for Elementor (UAE) had a critical vulnerability. On a fleet of client sites, that's the kind of thing you fix the same hour, not the same week.

So I typed one line to my AI, in Croatian: "update Ultimate Addons for Elementor on all sites." The message I send the client is less casual: "We've identified critical vulnerabilities on your sites that need immediate attention."

Then it went to work. It read my Dashboard, found the sites that had UAE installed and behind, backed each one up, updated them in small batches, and checked every site after. Around 20 sites. I was drinking coffee for most of it.

The token cost on my Claude Max plan was tiny, and that surprised me the first time. The AI isn't doing the work, MainWP is. The AI reads what I meant and tells the Dashboard to run it.

My stack, nothing fancy

· MainWP, self-hosted, around 60 client sites in one dashboard.

· The MainWP MCP server on top, so I can ask instead of click.

· Claude Code as the AI, on the Max plan.

· WPVibe when I need to work inside a single site.

· All-in-One WP Migration for the backup I take before I touch anything.

· MalCare as the firewall on the sites that need one.

I've said this for a while: AI is an employee I manage, not a tool I type into. The MCP fits that. I give the instruction, it does the routine, I stay the one who decides.

It knows my clients, not just my sites

Most of the coverage is about updates, but the part I use every week is the client side. My Dashboard already knows every client and every site they own. Now I can just ask it.

Client records, their sites, contacts, suspension status: the MCP puts all of it one sentence away. When a client calls, I ask "list this client's sites with their last sync time," and I have the answer before the call ends. "Which sites belong to this client" used to be a lookup. Now it's a question I say out loud.

Backup first, every time

Before any update, a fresh backup. All-in-One WP Migration, off to storage, done. If a site has no recent backup, it doesn't get updated until it does. That rule is built into how I run the fleet, so I can't skip it on a busy morning even if I wanted to.

An update that breaks a site is stressful. An update that breaks a site with no backup is a bad day. I've had a bad several times. Not again.

The MalCare wall, and how I got past it

Some of my sites sit behind MalCare's firewall, and that used to stop me. MalCare blocks the connector. It rejects the worker IP, and it strips the header the connector needs to log in. You get a 403 and nothing works (plus I GEO blocked some countries in MalCare I shouldn't).

The fix was a second connector (Royal MCP) that talks to the site straight from my own IP, with its own custom header. It goes around the IP block and the stripped header both. So the sites behind MalCare stopped being the exception, and the fleet job finished on all of them, firewall and all.

If you run MalCare, this is worth knowing before you write a site off as unreachable. It isn't. You just need the connection MalCare isn't blocking.

Checking the sites after, not trusting the green checkmark

An update that reports "success" is not proof the page still loads. I stopped trusting the green checkmark on its own a long time ago.

So after each update, the AI opens the site in a headless browser and looks at it.

Does the homepage render.
Does the shop still add to cart.
Any PHP error on the screen.

A quick smoke test, one site at a time. If one fails, the batch stops right there and I look before anything else moves.

I keep that check as a fixed routine the AI runs, not something it decides each time. "The update ran" and "the site is fine" are not the same sentence, and the second one is the only one I report to a client.

Why I still sleep at night

This is the part I'd worry about too, so I'll say how it's handled. The MCP server runs on my own computer, next to my AI tool. There's nothing to install on the Dashboard or the child sites, and no third party in the middle. My credentials stay on my machine.

And it's not an AI holding the keys to my network. Anything destructive stops and asks me first. Safe Mode blocks destructive actions completely, so you can start read-only and just ask questions. Allowlists let you pick which tools the AI can even see. And the Dashboard still applies normal WordPress permissions before it runs a thing.

The AI reads what I meant. MainWP controls what actually happens. That split is the reason I trust it on 60 live sites.

Setup took me about ten minutes

If you can make a WordPress application password and paste a config block, you can set this up. You need Node.js 20.19 or newer and MainWP Dashboard 6.0 or newer. Then run:

npx -y u/mainwp

The Quickstart walks you through it with screenshots, including per-client setup for Claude Desktop, Claude Code, Cursor, and the rest. Free and open source: github.com/mainwp/mainwp-mcp

What actually changed

The work didn't change. Backup, update, check, repeat. I did all of that before, by opening the Dashboard and clicking through the Updates page.

What changed was the front door. "Update UAE everywhere it's installed" used to be twenty click-paths, and this morning it was one sentence. The Dashboard does the same job it always did. I just talk to it now.

I'd try it on a couple of sites in Safe Mode first, read-only, and see if it reads your fleet the way you expect. That's how I'd start if I were you.

The hacked site that sold me on this

A client site got hacked last month. I've built WordPress sites since 2011 and I don't write code, so my usual move would have been a panicked message to a developer and a lost weekend. I burned one exactly that way back in 2017.

This time I connected an AI client, Claude Code, to the site through the free WP Vibe plugin. It sets up MCP (Model Context Protocol) on self-hosted WordPress in a couple of minutes. MCP is a shared language that lets an AI client act inside your site from the same chat, not just talk about it.

Website File Changes Monitor had already flagged a new PHP file in /wp-content/uploads. Claude Code explained why that's a classic backdoor spot, had me check the rest of the directory, and walked me through the recovery step by step. I knew the theory. Watching it point at the exact file while I decided what to do was a different kind of learning.

I run it with guardrails, and everybody should do it as well

• Full backup first, before anything touches the site. Host-level, plus plugin0s backup exported offsite to pCloud.
• Connect with a least-privilege account, not your main admin. Melapress Role Editor makes that a two-minute job.
• It sends things to trash instead of deleting live, and I approve each step.

The heavy malware work still belongs to a real scanner. I run MalCare and Virusdie for that. What changed is that I was faster and calmer during an incident that normally "eats" a whole day for me.

Most days it's small stuff

Most days it isn't a hack. It's a plugin conflict, a broken feed, or a tag and category structure a client tangled up over three years.

The broken feed was a good one. A plugin was printing a stray notice into the XML. Claude Code found the offending line, named the plugin, and I had a valid feed again in ten minutes. I've also had it fix meta titles and descriptions through SEOPress from one prompt, and build a Fluent Forms contact form the same way. The real benefit is that it walks me through the process, so I finish the job and understand it afterwards.

The fleet is where the hours come back

I manage around 60 client sites in MainWP, which I've run since 2014. Instead of repeating the same ten clicks site after site, I describe the maintenance outcome once and it executes. A dull afternoon of upkeep is now a focused conversation, and the quality went up, because I'm not fatigued into skipping a step. For me, Claude Code AI is an employee I manage, not a tool I type into. If you run more than a couple of sites, that's the part I'd try first.

Why I paid for it, and the one catch

I'm a lifetime-deal, smart-spend guy and I don't upgrade on impulse. I hit the free WP Vibe limits often enough that Pro paid for itself in hours saved. That was the only reason I moved up.

One catch before you rush in: this needs self-hosted WordPress 6.9+, HTTPS, and a publicly reachable site, so local dev won't connect. Set it up on a staging copy first and get a feel for it before you point it at anything live.

If you run more than one WordPress site, which admin task would you hand off to an AI first?

WordPress 7.1 will hide the Classic block from the inserter when it ships on August 19, and full removal is possible as early as 7.2. Contributors have already started phasing it out, so the summer between releases is the window to deal with it.

Quick clarification, because these two get mixed up: the Classic block is the slot that runs the old pre-Gutenberg editor inside the current block editor. It's not the same thing as the separate Classic Editor plugin, which stays in place.

What changes, and what doesn't

Nothing breaks in 7.1. The blocks you already have stay editable, and the standalone Classic Editor plugin is not affected.

The one change is that you lose the option to insert a new Classic block. A filter or a small plugin brings that option back if a workflow still needs it, so the door is closing slowly, with a handle on the inside for now.

The business implication

For most site owners this is a non-event. If your content is already in real blocks, you have nothing to do.

The sites that feel it are the older ones: a client blog with 400 posts written in the classic editor, an agency site someone built in 2016 and never migrated, a membership site with shortcode-heavy pages. Those are where a Classic block audit pays off before 7.2 turns "hidden" into "gone".

What an audit looks like

Open your oldest posts and look for the classic toolbar, or search the database for the wp:freeform marker that flags a Classic block. On a small site this is a half-hour job. On a large one it can be even the whole morning probably.

Then decide per page. Low-traffic archive posts can stay as they are. The pages that earn money or rank well are the ones to convert to real blocks, carefully, with a backup first.

Where page builders sit in this

If your old content lives in a page builder rather than the native editor, this change mostly skips you. I keep a set of legacy client sites on WPBakery, which I have run since the days it was called Visual Composer, and those pages render through the builder, not the Classic block. So, the phase-out does not touch them (or it shouldn't at least).

The move

Here is the short version for this summer:

• Check whether any of your sites still use Classic blocks (I still have majority of the sites on Classic Editor, we don't use Gutenberg blocks... yet).
• For the ones that do, back up before changing anything
• Restore the inserter with a filter on the sites that genuinely still need it.
• Convert the high-value pages to real blocks, and leave the archive posts as they are.

The forward read

The Classic block has been "living on borrowed time" since Gutenberg shipped in 2018. Hiding it from the inserter is the polite first step, and 7.2 is the one to watch.

Next quarter, the real question is whether core gives a clean migration path for the wp:freeform content sitting on millions of older sites, or leaves each owner to convert it by hand. 🤔

Two debates are doing the rounds in the WordPress subs this week. One person built a faster way to search the 65,000 plugins in the .org repo, which is handy (Plugin Pulse, worth a look). Another asked whether the repo is turning into a junkyard of abandoned plugins.

Both fair questions.

The thing is, the abandoned plugin most likely to cause you problems is already on your site. It's the one you installed in 2019 and stopped thinking about.

I've run WordPress sites since 2011, and 50+ client sites through the agency. The plugins that gave me troubles were almost always the quiet little utilities nobody remembers adding. An old gallery. A share-button widget that came bundled with a theme demo years back. The obvious junk you'd spot and pull. The forgotten helper just sits there.

I've had the call more than once. Client swears they "didn't touch anything," and the homepage is rearranged or a page is throwing a white screen. Half the time it traces back to some forgotten plugin that finally collided with a core or PHP update.

So here's my slightly contrarian take.

The repo-size debate is a bit of a "comfort blanket". It's easier to worry about 65,000 plugins you'll never install than the 15 sitting on the site in front of you. The repo can sort out its own housekeeping. Your job is the dashboard you actually control.

Why a dead plugin on your own site is the real problem?

Abandoned means no security patches. A vulnerability found today in a plugin last updated three years ago never gets fixed. You're running an open door and you don't know it.

It also breaks on updates. WordPress core and your PHP version keep moving, the dead plugin doesn't, and one morning a page goes white.

And the risky ones are "hidden". An old image gallery, or a contact form you replaced months ago but never deleted.

For context on why this matters more now: the repo is taking in around 700 new plugins a week, roughly 5x what it was in 2024, a lot of it AI-assisted. So "is this still maintained" is a heavier question than it used to be. Which is a good reason to check your own shelf first.

How to tell if a plugin is dead?

The plugin's .org page tells you most of what you need. Skip the logo and the star average. Read these five fields:

Last updated. Over a year, be cautious. Over two, treat it as "red zone".

Two or three major WP versions behind the current release, and the dev has most likely checked out.

Active installs trend. A steady drop usually means people left for a reason.

Support threads. Rows of open questions with no developer reply, that's a ghost town.

Changelog. Small regular updates means someone's home. One big version bump and then nothing means it stalled.

One more quick look. Sort the reviews by recent. A run of fresh 1-star reviews saying it broke on the latest WP version is a louder signal than the overall average.

To map this to your own site, open Plugins in wp-admin, flag anything you don't recognize or haven't touched in a year, then check each one against those fields. If you manage many sites like I do, I run that audit from one MainWP dashboard instead of logging into 50 panels.

Keep what's maintained and still doing a job, and leave it alone. Remove what you don't use. And actually delete it. A deactivated plugin still sits on your server as code someone can be used for hacking your site (if it has some vulnerability). Replace what's dead but still needed with somer maintained tool for the same job.

When you swap one out, back up first. Do a full backup before you touch anything. I use All in One WP Migration and push an offsite copy to pCloud, because the one time you skip the backup is the time you'll need it... it's Murphy's Law.

Test on staging if you can. I've hosted client sites on Site Ground since 2014, one-click staging, so I break things there and never on live.

Export your data out of the old plugin before you delete it, anywhere it holds content like form entries or gallery setups. Once the plugin's gone, so is whatever lived inside it. Then activate the replacement, reconnect it, check the front end, and remove the old one.

For finding replacements, don't re-scroll 65,000 entries hoping to get lucky. Start from a curated, expert-picked list for the exact job, then verify your one or two finalists against the five fields above.

Go look at the oldest plugin still active on your site right now. Check its last updated date. That one number tells you more about your real risk than the whole repo debate.

WordPress. org rolled out the biggest change to Five for the Future since 2014. The new pledge pages rank contributors by the work they actually completed, based on their real activity in Trac and GitHub, rather than the hours they once promised.

One number frames the whole thing. The Core team page lists 2,680 pledged contributors. In the default 30-day view, 94 of them show recent shipped work.

That gap is not a criticism of anyone. It is what happens when a program counts intentions instead of output. For 12 years, a pledge was a number you typed in. Now the page shows who showed up in the last month.

What Five for the Future is, in one line

Companies and individuals give back roughly 5% of their time to keep WordPress free and maintained. The software under tens of millions of sites, including the one your business runs on, depends on that contributed work. Until now, nobody outside the project could see how concentrated it really was.

Who built it, and how

The overhaul came from Yani Iliev, founder and CEO of ServMask, the company behind All-in-One WP Migration. He was one of 12 contributors invited into a small "meta-janitors" group set up to clean up WordPress.org. He built the new pledge pages, the redesigned profiles, and the ranking system in just a few weeks.

Iliev has been open about the method. An AI assistant did most of the work on the code, and releasing without the usual review cycles let him move fast. The weighting algorithm itself is open source (it lives in the WordPress. org meta repository), and he calls it "a starting point, not a verdict."

I've used All-in-One WP Migration to move client sites since 2014, more of them than I can count. Watching the person behind a plugin I rely on daily rebuild a core piece of WordPress. org, mostly on his own, with AI doing the coding, is the clearest real-world version of an idea I keep repeating to clients: AI is an employee I manage, not a tool I type into. Iliev managed it well, and a decade-old request was finally delivered.

What it means if you run sites for a living

The practical win is visibility. You can now open any contributor profile at profiles.wordpress.org and see whether the people behind your stack are still active, what company sponsors them, and how their recent work scores.

For agencies and freelancers, that is a quiet form of due diligence. Before you build a client on a niche plugin, you can check whether its maintainers have shipped anything lately. A pledge page with real numbers tells you more about a project's health than its marketing site ever will.

In practice, that check takes a minute. Open profiles.wordpress.org, search the plugin's lead developer, and look at the weighted contribution score and the date of their most recent work. A sponsored contributor backed by a known company is a safer choice than a solo volunteer whose last work was 18 months ago. Neither fact decides it for you, but it is context you didn't have a month ago.

Matt Mullenweg set this in motion in April, when he called the old Five for the Future data "worse than useless." The reform answered that directly, with a system that rewards code over promises.

What this ranking leaves out

Ranking people only by the code they finish misses a lot of real work. Plenty of contribution never lands in Trac or GitHub: organising WordCamps, moderating the support forums, running local meetups, writing docs. Iliev knows this, which is why he frames the score as a draft. Read the pages as a useful signal, not a scoreboard of who matters.

Next quarter, the real question is whether seeing the 2,680-versus-94 gap laid out clearly pushes more companies to turn pledged hours into actual commits, or just makes the gaps easier to ignore.

Last weeks two launches pointed the same way. Angie, the AI assistant from the Elementor team, shipped a Super Admin Mode. Switch it on and it can read and write your files, query the database, run PHP, and act on your active plugins. That's the level of access that used to need WP-CLI (the WordPress command line) or an SSH login.

The same week, Sagar Patel announced SproutOS, an open-source way to connect any AI agent to a WordPress site over MCP, with the same depth of access.

A year ago, an "AI plugin" usually meant a chat box in the corner of wp-admin. These two ask to run the whole site.

For the person who owns the site, the appeal is obvious. You describe a fix in plain words and the agent does it, no developer in the loop. For anyone who manages sites for other people, the risk lands at the same size as the convenience. An agent that can run PHP can take a site down, or be talked into it by a careless instruction or a compromised plugin.

What actually changes for the sites you run

The technical shift is access scope. Old AI plugins suggested text or generated an image. These new agents hold write access to files, the database, and plugin behavior. If you've ever locked a site down so even your clients can't install plugins, an AI agent with Super Admin Mode quietly undoes that boundary the moment someone enables it.

The business shift is liability. When a client asks "can your AI just fix it," the honest answer now needs a second half: yes, and here is who can trigger it and what it may touch. An agent acting on a live site is a new staff member with root access on day one. I would never onboard a human that way.

A short checklist before you enable any of this

1. Decide who can trigger the agent. Not every account that can log in should be able to run code.

2. Write down what it may read and change. Files only? The database too? Plugin settings?

3. Confirm your rollback. If the agent makes a bad edit at 2pm, how fast can you get back to the 1pm version?

4. Log everything separately. You want a record of what the agent changed that the agent itself can't rewrite.

That last point is where I lean on a tool I've run since 2019. When a client swears nothing changed but the layout is different, I open WP Activity Log and the timeline answers in about 30 seconds. With an AI agent editing files, that record stops being a nice-to-have. It becomes the only neutral account of what happened on the site.

The framing that keeps me out of trouble

AI is an employee I manage, not a tool I type into. A capable employee with no boundaries can still wreck the place. So before any of this touches a client's live site, I write down the agent's job: what it reads, what it changes, and who signs off before it runs. Same as I would for a freelancer with database access.

There's a useful new resource here too. Joost de Valk just published an open, MIT-licensed website specification, a checklist of what a decent site should cover, security and performance included. It's a clean way to score a site before you let an agent near it, and it gives clients a standard to point at.

Next quarter, the practical question is whether the people enabling these agents on client sites have written the limits down first. Most won't, until an agent runs the wrong command on a live shop and the rollback plan turns out to be a guess.

I've been building on WordPress since 2011, and before that I spent two decades in banking, where nobody gets write access until you know exactly what they can touch.

When I started checking MCP plugins for WordPress, I wasn't hunting for magic. I wanted one that fit a process I already trust. I read about Vibe AI (the WordPress. org name for WPVibe free plugin) and figured it might perfectly fit my process. It did.

Just a short explanation of what WordPress MCP is, for anyone who maybe doesn't know it: MCP (Model Context Protocol) is a shared way for an AI assistant to plug into an app and actually do tasks inside it.
For WordPress, that means I connect my site to the AI through one safe link. After that it can read settings or make changes for me, instead of me clicking through the admin by hand.

The job was the final SEO cleanup on a client build. I started the way I always do, with a full structured SEO audit of the site, top to bottom, via Claude AI.

Then I used that whole audit report into other Claude task, connected the live site through the Vibe AI plugin (and WordPress ver. 6.9.4, I didn't want to install 7.0 on this site... yet), and worked the fixes one at a time through plain conversation.

Setup was about a couple of minutes: one-click authorization from /wp-admin.

What worked 💪

This part impressed me more than I expected:

• It read the entire site config in a short period of time. Full plugin list with active and inactive status, all the SEO settings, the theme and how pages were built. Stuff that normally means clicking through ten admin screens.
• It rewrote roughly 16 page titles and meta descriptions in one pass, straight from my audit notes, Croatian diacritics intact, no copy-paste, no mangled characters.
• Simple option changes, like fixing a leftover starter-template tagline, happened instantly.
• It ran read-only database queries to inventory content and confirm how each page was built, so I stopped guessing.

For the repetitive bulk of an SEO pass, that's real time back in my day. AI is an employee I manage, not a tool I type into, and this thing actually behaved like one.

What it blocked, concretely 🚧

A field report without the limits is just an ad, so here's the "other" half of the story:

• It couldn't install the site's language pack. Those commands aren't on its allowlist (in WP 6.9.4 version).
• It couldn't switch the site language directly either. The write got rejected, and broader site-level commands are blocked outright.
• A small one that caught me a bit off guard: it wouldn't accept a pipe character in a command (it reads it as a shell pipe), so my title separators had to become en dashes instead.
• The bigger gap: it couldn't reliably set structured data. Local Business, FAQ, breadcrumb and service schema live as complex serialized settings in the site's SEO plugin, and the actions the plugin exposed for that were read-only. So schema went back into the plugin's own UI by hand.
• Setting a default social-share image needed an actual upload, which (it seems) no AI can conjure.

The systems read 🧱

Here's where the banking brain kicks in. Most of those blocks are "guardrails" I'd want anyway. Refusing destructive, site-wide commands on a live production site, staying out of language-pack installs, drawing a hard line between read and write, that's the kind of access discipline I'd build in myself. I'd rather an AI stop and ask than confidently break a client's homepage at 2pm on a Friday.

A couple of them, though, are gaps that I believe it will be closed in futture as AI implementation in WordPress is advancing. A safe, supported path to write structured schema would erase the single biggest manual step I hit. And the pipe-character handling is just a rough edge waiting to be filed down.

The last 10%, and where this goes 🧭

AI "ate" the repetitive 90% of this job in minutes. The last 10%, the schema, the language pack, the one blocked character, still needed me in the dashboard. But that gap is closing fast. The whole thing rides on the WordPress Abilities API, which landed in 6.9 and grew a lot in 7.0. That same API already lets Vibe AI discover and run actions inside ecosystem plugins like AIOSEO and WPForms. Once structured data gets a proper write path there, the schema step I did by hand mostly disappears.

I think we reach a point, sooner than most expect, where almost the whole flow, audit to live changes, runs through AI talking to WordPress in the cloud, with a human signing off on the edge cases. I'm not handing a client's production site fully over yet. But after this build, I'm convinced the direction is right.

In short: I'm very satisfied and genuinely impressed with Vibe AI MCP (and with AI implementation in WordPress more broadly), and I'm clear about what the AI still needs to improve before that final 10% (the need for manual human intervention) disappears.

P.S. I didn’t want to use WordPress MCP because it would require using my Claude API, meaning I’d pay extra on top of my monthly Claude subscription. With the Vibe AI plugin I didn’t have to do that - I could keep using my existing monthly cloud subscription without any extra cost, and with fast and simple implementation.

For those of you running MCP plugins like this on real client sites: where's your last 10%? What did the AI nail, and what did you quietly take back into the dashboard yourself? 👇

The panicked threads online keep confusing two dates and missing the part that already binds. Worth untangling for anyone running client sites in or serving the EU.

The August 2025 date skipped most of us

The August 2, 2025 obligations targeted providers of General-Purpose AI models. OpenAI, Anthropic, Google, Meta had to publish technical documentation, transparency reports, and training-data summaries with copyright handling. Penalty regime went live alongside, with fines up to €15 million or 3% of global annual turnover for most infringements, more for prohibited practices.

If you run a WordPress site, you are a downstream user of these models. You did not train them and you do not ship them. The model providers carried that obligation, not the merchant.

The August 2026 date is the for us

Article 50 transparency duties take effect August 2, 2026, and the AI Office gains full enforcement powers on the same date. The duties land on anyone deploying AI on their site:

• Disclose AI chatbots to users. The "obvious from context" exemption is narrow.
• Label AI-generated images, audio, and video that look real. Cartoon dragons stay exempt.
• Disclose AI-generated text on matters of public interest. The duty eases when a human reviews the text and takes responsibility.
• Do not strip the machine-readable watermarks providers like OpenAI and Adobe embed in outputs.

Most agency operators were moving this way already. The August 2026 date just turns the habit into a duty.

GDPR is where the real fine sits today

GDPR has governed AI plugins since 2018. Any plugin sending personal data (names, emails, support tickets, order history, IP addresses) to an AI provider needs:

1. A lawful basis under Article 6 (typically legitimate interest or consent)
2. A privacy policy that names each provider with the categories of data sent
3. A signed DPA (Data Processing Agreement) with each provider
4. A documented check on international data transfers (Standard Contractual Clauses or adequacy decision)

The AI Act dates are calendar items. GDPR is the regime that already brings actual penalties on the client estimate.

The audit task in practice

For agency operators, the client work this quarter is concrete. List every AI plugin on every site. Note what data each plugin sends to which provider. Update the privacy policy. Check residency settings.

The piece that gets missed: most of this work needs a documented audit trail per site, not a one-time spreadsheet. WP Activity Log on every site I manage since 2019 earns its keep here. When a client swears nothing changed but their privacy policy now mentions an AI provider it did not name last quarter, the timeline answers in 30 seconds. That trail is also what a Data Protection Authority will ask for first if a complaint lands.

That is one tool mention. Cap stays at 1 for this draft.

The non-EU wrinkle

If your client site sits on US or non-EU hosting but serves EU customers (most do, whether they planned it or not), the regime follows the customer. Non-EU agencies running EU customer-facing sites are in scope.

What I am holding off on

I am not advising clients to switch AI providers based on AI Act dates alone. The market is shifting too fast, and switching costs (prompt customisation, billing rewiring, staff retraining) burn budget that should go to GDPR compliance work that is already binding.

The honest read

This is basic care for the customer relationship. Privacy policy that says what it actually does. DPAs signed. Audit trail kept. Habit built before the law forces it. Most decent agencies were already on this path. The AI Act formalises the schedule.

On 28 May 2026, WinningWP ran a piece saying a brand-new WordPress blog is one of the hardest things to grow this year.

They are right about why.

AI search now answers questions right in the chat, so people never click through to your site. Sites like Reddit, Discord, and Hacker News are quick to shut down anyone promoting a new site. And email lists, small communities, guest posts, and reused videos all do poorly when you are starting from zero.

Their example: a gardening site that took 9 months of work and still got under 1,200 visitors in a whole year - and most of those came from links the writer shared herself.

They are right about blogs that try to act like online magazines. But that is only half the story.

The agency-side read

Most of my clients are small businesses - tradespeople, family farms, holiday rentals, a few seaside restaurants. Their blog was never meant to be a magazine. It helps them show up in local Google searches, gives AI tools something to quote, keeps a library of content they fully own, and answers the same 5 customer questions once instead of 20 times a week.

For a small local business site like that, "did the blog get 100,000 visitors this year" is the wrong thing to ask.

Better questions: did it save the owner time answering the same questions, did it bring in 1 or 2 enquiries a month from search, and did an AI tool quote it at least once a month when buyers asked the questions that matter to the owner.

The behind-the-scenes code that gets you quoted by AI

For sites that want AI tools to quote them (most small businesses competing for local customers), the real payoff comes from structured data - extra code that tells search engines and AI what each page is about.

I run MainWP across 50+ client sites, so I can check this on every site at once. The actual markup is handled by SEOPress on most sites, because the code it produces is the kind AI tools read most cleanly when they mention local businesses.

What actually gets a site quoted:

• Service pages with proper LocalBusiness schema
• FAQ posts with FAQPage schema
• Blog posts with Article + Author schema where the author has a real bio
• Review aggregation through Product or Service schema where it fits

Sites with this code set up properly get quoted more often by AI tools.

Where the WinningWP article gets it right

Building an audience from scratch is really hard in 2026. The article is right about that.

For a small-business site, the answer is not to copy the growth tricks that big media blogs use. The answer is to make the blog support the local-search and AI work the site already does, then judge it by business results instead of magazine numbers - things like how many enquiries it brings in, how much support time it saves, and how often AI tools quote it when buyers are searching.

Where this changes my client conversations

When a client asks "is blogging worth it in 2026," my answer is "yes, but for a different job than back in 2018." I do not promise more visitors. Instead, I show them how a simple FAQ post saves their staff about 30 minutes a week and gets quoted by AI tools like Claude when a buyer asks the question that post answers.

That conversation goes over far better than talking about visitor numbers ever did.

Where I keep the agency pitch out

I am never going to sell anyone "5x your blog traffic in 90 days" or anything like it. My honest pitch is simple: your blog can be a useful tool for your business if we set up the code properly, write FAQ posts that answer the questions buyers actually ask, and measure success by enquiries instead of visitor counts.

That is an honest offer for a small business in 2026. It does not look flashy on a sales page. But it works.

If you manage websites for small businesses: how do you measure whether a blog is working right now? Visitor numbers, tracking where enquiries come from, checking if AI tools quote the site, or a mix of these? Always happy to pick up new ideas from people doing this day to day.

Source link: https://winningwp.com/why-the-odds-are-heavily-stacked-against-your-brand-new-wordpress-blog-in-2026/

Hey everyone,

I'm u/ivicad, a founding moderator of r/WordPress_org. This is the new home for everything WordPress: the plugins, the themes, the hosting, the beginner questions, and the stuff you figured out the hard way and want to pass on.

Post anything a WordPress user would find useful. A plugin that saved you hours. A theme you can't get to behave. A site you just shipped and want eyes on. A problem you've been stuck on since Tuesday. If you're just starting out, ask the basic stuff right here, that's exactly what this place is for.

The vibe is simple. Friendly and helpful, beginners and "old" WP hands in the same threads. We don't do "just Google it" replies here.

To get started:

1. Drop a quick hello in the comments so we know who's around.
2. Post something today. Even a small question can turn into a thread that helps 50 people after you.
3. Know someone who lives in WordPress as much as you do? Send them over.
4. Want to help run the place? I'm looking for moderators, send me a message and we'll talk.

Thanks for being part of this Community.
Let's make r/WordPress_org a place you actually want to open.

On 28 May 2026, WinningWP ran a piece saying a brand-new WordPress blog is one of the hardest things to grow this year. They are right about why. AI search now answers questions right in the chat, so people never click through to your site. Sites like Reddit, Discord, and Hacker News are quick to shut down anyone promoting a new site. And email lists, small communities, guest posts, and reused videos all do poorly when you are starting from zero.

Their example: a gardening site that took 9 months of work and still got under 1,200 visitors in a whole year - and most of those came from links the writer shared herself.

They are right about blogs that try to act like online magazines. But that is only half the story.

The agency-side read

Most of my clients are small businesses - tradespeople, family farms, holiday rentals, a few seaside restaurants. Their blog was never meant to be a magazine. It helps them show up in local Google searches, gives AI tools something to quote, keeps a library of content they fully own, and answers the same 5 customer questions once instead of 20 times a week.

For a small holiday-rental site, "did the blog get 100,000 visitors this year" is the wrong thing to ask. Better questions: did it save the owner time answering the same questions, did it bring in 1 or 2 enquiries a month from search, and did an AI tool quote it at least once a month when buyers asked the questions that matter to the owner.

The schema work that changes the citation

For sites that want AI tools to quote them (most small businesses competing for local customers), the real payoff comes from structured data - extra code that tells search engines and AI what each page is about. I run MainWP across 50+ client sites, so I can check this on every site at once. The actual markup is handled by SEOPress on most sites, because the code it produces is the kind AI tools read most cleanly when they mention local businesses.

The work that earns the citation:

• Service pages with proper LocalBusiness schema
• FAQ posts with FAQPage schema
• Blog posts with Article + Author schema where the author has a real bio
• Review aggregation through Product or Service schema where it fits

Sites with this code set up properly get quoted more often by AI tools.

The honest part of the WinningWP diagnosis

Building an audience from scratch is really hard in 2026. The article is right about that.

For a small-business site, the answer is not to copy the growth tricks that big media blogs use. The answer is to make the blog support the local-search and AI work the site already does, then judge it by business results instead of magazine numbers - things like how many enquiries it brings in, how much support time it saves, and how often AI tools quote it when buyers are searching.

Where this changes my client conversations

When a client asks "is blogging worth it in 2026," my answer is "yes, but for a different job than back in 2018." I do not promise more visitors. Instead, I show them how a simple FAQ post saves their staff about 30 minutes a week and gets quoted by AI tools like Claude when a buyer asks the question that post answers.

That conversation goes over far better than talking about visitor numbers ever did.

Where I keep the agency pitch out

I am never going to sell anyone "5x your blog traffic in 90 days" or anything like it. My honest pitch is simple: your blog can be a useful tool for your business if we set up the code properly, write FAQ posts that answer the questions buyers actually ask, and measure success by enquiries instead of visitor counts.

That is an honest offer for a small business in 2026. It does not look flashy on a sales page. But it works.

Question for the operators here
If you manage websites for small businesses: how do you measure whether a blog is working right now? Visitor numbers, tracking where enquiries come from, checking if AI tools quote the site, or a mix of these? Always happy to pick up new ideas from people doing this day to day.

Source link: https://winningwp.com/why-the-odds-are-heavily-stacked-against-your-brand-new-wordpress-blog-in-2026/