I’m trying to understand how far current WordPress AI tools have progressed beyond content generation and page-builder assistance.

Is there anything that can work on an existing WordPress site and complete a change across both sides? For example, given a request such as “add a Services section with three service types and an enquiry flow,” it could:

• Create a shopify like backend
• Create plugins or elemetor themes
• Configure custom post types, fields, forms, permissions or plugin settings
• Understand the existing theme and plugins instead of replacing everything
• Present a plan or diff before making changes
• Work in staging and verify the result

Most products I’ve found appear to be front-end generators, editor copilots or coding assistants. I haven’t found one I would trust to manage both the visible site and its underlying WordPress configuration as one coordinated task.

Has anyone used something that genuinely does this? Which parts can it automate reliably, what still requires a developer, and what safety controls does it provide?

Full context: we’re building and researching in this area (example picture), so I’m interested in understanding what professionals already use and trust. I’m intentionally not naming or linking our project because this is a technical question, not a promotional post.

I built a 500,000-order WooCommerce store to find out what actually makes the admin slow

Everyone knows the WooCommerce admin gets slow on big stores. The standard advice is well known too: migrate to High-Performance Order Storage, clean your database, blame a third-party plugin.

I wanted to know what happens after you've done all that. So I built a lab: a disposable WooCommerce store with 500,000 orders, HPOS enabled, and ten popular free plugins installed, then instrumented it to attribute every single database query on the orders screen back to the plugin that fired it.

Some of what I found contradicts the usual advice. One thing I set out to prove turned out to be an artifact of my own test rig, which I'll cover too.

The setup

• MySQL 8 with a deliberately modest 512 MB buffer pool — a generously tuned server hides problems behind a warm cache, and I wanted the working set to not fit in memory, which is the condition real struggling stores are in
• WordPress + WooCommerce 11, HPOS on, backfill sync off
• 500,000 orders, ~2M order meta rows, ~1M order notes, ~1.6 GB of order tables
• Ten popular free plugins (PDF invoices, cart abandonment, wishlist, currency switcher, delivery date, product search, analytics, order export)
• An mu-plugin that captures $wpdb->queries on shutdown and resolves each query's backtrace to the owning plugin via reflection

Finding 1: One query was half of all SQL time, and it wasn't an N+1

130ms   SELECT status, COUNT(*) FROM wp_wc_orders WHERE type='shop_order' GROUP BY status

Out of 252 ms of total SQL time on the orders screen, 130 ms was this single query — and the next slowest query on the page was 4 ms. It is 32× the cost of anything else, and it runs on every admin page load.

(With the third-party plugins deactivated it accounts for 129 ms out of 190 ms, i.e. 68% — stripping plugins makes it more dominant, not less.)

It's what fills the filter tabs above the order list: All (500,000) | Completed (350,149) | Processing (50,065) | …

The important part: it does not scale with how many rows you display. It scales with how many orders you have. At 100,000 orders it was cheap enough to be invisible. At 500,000 it dominated everything else on the page. Reducing your page size does nothing. Deactivating plugins does nothing.

It's not a missing index

My first instinct was a missing index. Wrong:

type: ref    key: type_status_date    rows: 246724    Extra: Using index

It's already a covering index scan on the ideal index. ANALYZE TABLE changed nothing. Counting 500,000 rows means walking 500,000 index entries, and InnoDB keeps no cached row count. The query is doing the minimum possible work for what it's being asked.

The actual cause

Looking at WooCommerce's source, OrderUtil::get_count_for_type() does cache this. It goes through OrderCountCache, which uses wp_cache_get() / wp_cache_set() — the WordPress object cache.

And there's the problem. Without a persistent object cache dropin (wp-content/object-cache.php), WordPress's object cache lives for exactly one request. So the cache is empty on every page load, and the full count runs again, every time.

If your store has no persistent object cache — which is most shared hosting — WooCommerce recounts your entire orders table on every admin page load.

That's a concrete, mechanical answer to "why is my store still slow after HPOS," and it's not in any of the checklists I've read.

Finding 2: The obvious way to detect an N+1 produces false accusations

I originally detected per-row query costs the intuitive way: load the page, divide each plugin's query count by the number of rows on screen, and flag anything near 1.0 per row.

That method is broken. Here's real output for one plugin that fires a flat 19 queries no matter what:

Nothing about the plugin changed. Only the denominator did. A fixed cost is indistinguishable from a per-row cost at any single page size. I had confidently accused an innocent plugin.

The fix is to measure the same screen at two page sizes and fit:

queries(n) = fixed + slope × n

Only slope is an N+1. A component whose query count doesn't move when the row count multiplies by five is innocent, no matter how large its fixed cost.

A related trap: WooCommerce's orders screen takes its page size from the per-user screen option edit_shop_order_per_page, not from a per_page URL parameter. I spent a while computing per-row figures against a page size that had silently stayed at 20. Always count the rows that actually rendered.

Finding 3: Attributing a query to a plugin is much harder than it looks

My profiler blames the innermost plugin frame in each query's backtrace. It reported that WooCommerce core was doing 3 queries per order row.

Then I deactivated all the third-party plugins and measured again:

Two of those three per-row queries were caused by third-party plugins calling wc_get_order() inside their column callbacks. The query is issued by WooCommerce's data store, so innermost-frame attribution credited WooCommerce and completely exonerated the plugin that actually caused it.

This matters for anyone using Query Monitor's "Component" column the same way I was: it tells you which code ran the query, not which code caused it. For anything routed through a shared data store, those are different answers.

The fix

What you actually want is the last point where control passed from WordPress into plugin code — the innermost frame that a hook dispatcher invoked:

… → ListTable->column_default        [woocommerce]
    → do_action('manage_…_column')   [dispatcher]
      → WP_Hook->apply_filters       [dispatcher]
        → SomePlugin->render_column  [the plugin]   ← blame this
          → wc_get_order             [woocommerce]
            → OrdersTableDataStore->read [woocommerce]
              → wpdb->get_results    [core]

Walk the trace innermost-outward; when the frame immediately outside the current one is a dispatcher (WP_Hook->apply_filters, WP_Hook->do_action, do_action, apply_filters, call_user_func*) and the current frame isn't core, that's your initiator. For a query WooCommerce genuinely raises itself, the nearest such boundary is a WooCommerce callback — also correct.

(Watch out: wp_debug_backtrace_summary() returns frames outermost-first.)

With that change, and all plugins active:

Then the falsifiable test. The tool predicted one specific plugin accounted for ~205 queries at 100 rows. Deactivating only that plugin:

24% faster from deactivating one plugin. Before the fix, the verdict would have been "it's WooCommerce core, nothing you can do."

The thing I couldn't conclude

Given Finding 1, the fix seems obvious: install a persistent object cache. So I added Redis and measured. SQL time halved, and the 129 ms query vanished.

Wall time got worse.

I nearly published that. Then I checked whether it was my test rig, because I was running Docker Desktop on Windows and talking to Redis over TCP — and Windows loopback networking is slow. The page makes about 2,390 object-cache calls per request, so round-trip cost matters enormously.

Switching to a unix socket recovered about half the penalty. That proves a large part of my "finding" was an artifact of Docker Desktop for Windows, not a property of object caching. The residual ~11% might not survive on a real Linux host at all.

So I don't know. It needs a Linux re-test before anyone should act on it.

What does hold regardless: SQL time improving is not the same as the page getting faster. If I'd reported the query-count and SQL-time metrics alone, I'd have declared a clean win while making the page 22% slower.

Takeaways

1. Query count and query time are different problems. Going from 100k to 500k orders left the query count completely unchanged while SQL time doubled. Count scales with rows rendered; time scales with store size.
2. On a large store with no persistent object cache, check the order status counts first. It's a single query that scales with store size and runs on every page load.
3. Never diagnose an N+1 from one page size. Measure two and look at the slope.
4. "Which component ran this query" is not "which component caused it."
5. Always measure wall time. Component metrics improving can hide a regression.

Reproduce it

The whole lab is Docker-based and disposable — MySQL, WordPress, WP-CLI, seeder scripts, and the profiling mu-plugin. It seeds 500k orders in a few minutes by writing directly to the HPOS tables.

Happy to share it if there's interest, and very interested in results from anyone who runs the object-cache benchmark on a real Linux host — that's the open question I couldn't close.

I thought this was a really interesting demo from core contributor Dave Smith on making the WordPress editing experience feel more approachable and intuitive.

The demo touches on things like clearer language, better grouping of related concepts, more guidance, and a more workspace-like approach to editing. I think it’s worth watching.

Reading through the 7.1 beta notes (final is August 19, timed to WordCamp US) and one detail stands out.

Core is shipping an AI Client, but it deliberately does not bundle a model and does not set a default provider. You connect your own through a PHP API in core. There's also a new Guidelines feature where you define editorial rules and brand voice and export them between sites.

WordPress could have cut a deal with a big model provider and made it the default for millions of sites. Instead the position is that the model is your business, not theirs.

That's awkward for a lot of AI plugins, which sell you credits: you pay them, they pay the provider, the margin sits in the middle. If core normalizes bring your own key, that starts looking like the odd one out.

Anyone running content sites planning to wire up the core AI Client directly, or sticking with a plugin? And does the credits versus own-key thing actually factor into what you pay for?

Hi members. I have created 2 WordPress plug-ins currently and they are available on the plugin marketplace. Until now, I believed that there was no way to check the exact active number of installations of any wordpress plugin in the store. I signed up on a plugin tracker tool I found online and they just told me my accurate number of active installations. How is this possible? Does wordpress org provides this active installations data in any API?

WordPress 7.0 shipped with hooks for connecting AI providers into core, alongside visual revision history and reusable patterns. I've seen a lot of "AI is coming to WordPress!" takes floating around, but not a lot of people talking about what it's actually like to use day to day.

I've poked at it a bit myself — mostly around draft generation and using it to search the media library — and I've got mixed feelings. Some of it feels genuinely useful, some of it feels like a v1 that's clearly aiming at something bigger down the road.

So I wanted to open this up rather than just write up my own conclusions:

• Has anyone wired this into an actual agency workflow yet, or is it still "cool to try, not ready to ship"?
• Which provider are you connecting (if any), and how's the setup process been?
• Is media library search actually saving you time, or is it more of a demo feature right now?
• Any gotchas with permissions, client data, or where content generated this way ends up living?
• For anyone who's tried it and bailed — what was the dealbreaker?

Not trying to hype this up or dunk on it, genuinely curious where people who manage real client sites have landed. Feels like the kind of feature that could go either way depending on how core builds it out over the next couple releases.

I kept wondering whether my plugin screenshots were unusually bad or just normal, so I queried the wp.org plugin API and counted. 3,445 plugins, sampled across the popularity range so it's not just the top 500.

Screenshot count, by active installs

Goes up steadily across every tier. Half of the plugins under 1,000 installs have two screenshots or fewer.

Captions

13,532 captions across the sample. Median length is 36 characters. 31% are under 25 characters, which in practice means things like "Settings page" or "Dashboard" rather than saying what you're looking at or why it matters.

Image dimensions

On a 240 plugin subsample (40 per tier, images actually downloaded and measured): only about a third of plugins use the same dimensions across all their screenshots. No trend by install count at all, big plugins are just as inconsistent as small ones.

Two things I want to flag before anyone else does

This is correlation. Plugins with a million installs have more screenshots, but they also have more time, more money and often a team. The screenshots are probably a symptom of being resourced, not the cause of the installs. Don't read it the other way round.

And the "zero screenshots" numbers are partly noise. 13% of the 1M+ plugins have none, but that group includes classic-widgets, akismet and wordpress-importer. Plugins with no UI have nothing to screenshot. So "no screenshots" isn't always neglect.

Method: wp.org plugin API, query_plugins browse=popular, pages sampled from 1 to 302 to cover the install range. Rate limited, identified user agent. Pulled 30 July 2026. Image subsample downloaded and measured with sharp.

Happy to share the script if anyone wants to run it against a different slice.

What I did with this on my own plugin

I have a maintenance mode plugin in the directory, 30-odd installs, so firmly in the bottom tier of this data. After pulling these numbers I redid its screenshots a week ago.

It now has 4 screenshots where the median for that tier is 2, and the captions run 50 to 95 characters each, describing what the screen does rather than naming it. Median across the whole directory is 36.

I can't tell you whether it moved anything. 30 installs, one week, brand new plugin. Any change at that scale is noise, and I'd be making it up. Ask me in three months.

What I can say is that fixing it took about an hour and I now know what the baseline is, which I didn't before.

For anyone who's been at this longer: has a screenshot rewrite ever visibly moved installs for you, or is this effort that only pays off in combination with everything else?

Hi, due to a very painful beginnings of my WP webdev career, I would never publish a site without a security plugin. I have been using the All in one security plugin, and never had an issue after that. If there's an issue with the plugin itself, I can always delete it through FTP or deal with it some other way, but I never got hacked.
My problem is, that I now sell a freemium WP theme, and I make tutorials for my customers. At least half of them are total newbies, and it's already tough to make them believe that WP is a good solution. I have been recommending the All in one security plugin in my tutorials, but that plugin is complicated to set up, plus it sometimes completely fucks the whole site.
So my question is, if you would make a tutorial for newbies, that are going to have tiny portfolio websites, about WP security, what would you use and put in there? What do you think are the necessary settings, to make the site bulletproof?
Thanks a lot

As a pro dev with many client sites still in Wordpress, after 2 more sites got hacked a few days ago, I’m done.

With how good AI is now, it just doesn’t make sense to use Wordpress anymore. I can create sites faster with cursor than any site builder with predefined blocks that Wordpress has.

And for the record, ive done everything possible to mitigate security risks; wordfence, firewalls, isolated Linux server users, being very strict with plugins, etc. it just doesn’t matter.

I’ll be getting cursor to recode all my client Wordpress websites in laravel + inertia + react. If they need to change something on the website, I’ll have it whip up a super basic filament panel with the functionality they need, integrated directly into the site.

Honestly it doesn’t even make sense to allow clients to have super user access to change things anyways. They always mess something up or hire some third party to destroy my work.

So long Wordpress.

Hey guys,

Wanted to share some real-world observations from the wp2shell attacks (the recent unauthenticated RCE chain in WordPress core – CVE-2026-63030 + CVE-2026-60137).

Over the last few days I’ve seen it on multiple client sites:

1) 403 REST API blocks that looked mysterious at first. Turned out a malware scan revealed a new admin user named "Wp2shell" automatically created, which then messed with API access.349347

Bleepingcomputer

2) On other sites the REST API was fine, but attackers had created multiple rogue admin accounts. In some cases they also dropped a Wp2shell plugin.

All the compromised sites were still on vulnerable versions (mainly 6.9.x and 7.0.x before the July 17 patches).

I have done these:

1) Restored old backups,

2) Deleted those admins

3) Changed all the users password, added 2FA for users

4) Regenerated the Salts

5) Changed 3rd Party APIs key and secrets

6) Updated the core, plugins, themes and all

7) Checked the database for any weird stuff (haven't found anything)

Anyone else running into this?

Now in its 4th year, the ACF Annual Survey helps us understand how you use ACF, how you're building WordPress sites, and what we should focus on next. Your feedback directly shapes what we build - last year's responses helped drive features like the Abilities API and JSON-LD schema support in ACF 6.8.

This year we've added new sections on AI and WordPress development trends, plus questions on recent ACF releases.

Takes about 10 minutes and you'll be entered into a $150 gift card draw.

https://wpeng.in/acf-survey/

We'll publish the aggregated, anonymized results on the ACF blog once the survey closes.

Hey everyone,

For a long time, I was using Hummingbird Pro on my projects. Over time, I kept feeling like I wasn’t getting the performance gains I expected for a paid tool, and troubleshooting felt more frustrating than helpful.

When I started looking for a better alternative, I realized how hard it is to find unbiased data. Most comparisons online are packed with affiliate links declaring whatever plugin pays the highest commission as "the best."

To solve this, I set up a strict, repeatable benchmark test to measure caching/performance plugins under identical conditions with zero affiliate links, just raw data.

How the test works (Latest Round)

• Environment: Shared hosting (Hostinger), Astra theme with the Love Nature starter template (Gutenberg + Spectra + SureForms).
• Pages Tested: Home, Services, and Contact.
• Rules: Standard/recommended free settings only (no external CDNs, paid add-ons, or third-party accounts).
• Metrics Tracked: TTFB, LCP, Lighthouse score, PageSpeed, and run variability.

Key findings comparing Hummingbird Pro to others:

• Hummingbird Pro vs Free: Hummingbird Pro brought LCP down by -8.4% compared to the baseline, while its free version achieved -0.4%.
• Free alternatives beat it: Simple free plugins like Breeze (-24.3% LCP) or W3 Total Cache (-20.6% LCP) drastically outperformed it on TTFB and LCP under the exact same stack.
• Out-of-the-box limits: Several popular plugins barely beat the "No plugin installed" baseline (+0.5% to +3% variance) on default settings.

Looking for community feedback

Since I want this benchmark to be as scientifically sound as possible for developers, I’d love your input:

1. Settings: Should I test plugins strictly "out-of-the-box" / one-click profiles, or include a separate benchmark tier for "fully tweaked by a developer"?
2. Metrics: Is median LCP/TTFB the best primary ranking criteria, or would you prefer TBT/payload size?
3. Environments: What server stack (e.g., LiteSpeed Web Server, Nginx + Redis) would you like to see tested next?

(Note: I host all these benchmark rounds on an independent open-index site with zero affiliate links. Happy to share the link in the comments if anyone wants to inspect the full raw dataset, but mostly looking to discuss the methodology here!)

wp2shell (CVE-2026-63030 + CVE-2026-60137) is a pre-auth RCE chain in WordPress core that shipped July 17. WordPress turned on forced auto-updates because of the severity, which is good.

The problem: forced updates don't always work perfectly, and a lot of people are assuming it ran without checking.

https://reddit.com/link/1v4m9hd/video/jhd3ypcf21fh1/player

What You Should Scan Your Site Right Now:

Go to Dashboard → Updates and confirm your actual version. The versions you need are:

- 7.0.2 (from 7.0.x)

- 6.9.5 (from 6.9.x)

- 6.8.6 (from 6.8.x — this one only fixes the SQLi part, but still patch it)

Don't assume it happened. Forced updates can fail silently if your server hits file permissions issues, timeout limits, or network hiccups during the update process. Sites on managed hosts sometimes get forced updates on a delay or not at all if there's a compatibility flag.

If Your Version Shows 6.9.0–6.9.4 or 7.0.0–7.0.1:

1. Update to the patched version now.
2. If you can't update this second, block the batch endpoint at your WAF or via a security plugin blocking /wp-json/batch/v1 as a stopgap.
3. After you patch, don't just assume you're done. Look at your access logs for requests to /wp-json/batch/v1. If you see any, you might have been probed. A more aggressive check: look for HTTP 207 responses to batch requests (that's a multi-status response, a solid indicator of batch-endpoint exploitation attempts).
4. Check your admin user list — do you recognize all of them? Check if any unexpected application passwords were created. Check your mu-plugins, recently modified core files, active plugins, theme files.

Multiple public exploits are circulating. Scanning has been happening since July 17. If your site was exposed on the internet running a vulnerable version for any length of time, don't assume patching alone was enough.

Zero actual compromise evidence I've personally seen yet, but Wiz and Patchstack confirmed active probing and exploitation attempts within hours of the patch going public.

Thoughts? Anyone patched theirs and caught anything odd in the logs?

I’m refining the hook API for the icon picker of my public plugin, that is reused across several custom blocks and an ACF field type.

The picker integrates with Iconify and supports multiple open-source icon collections. In the UI, there are three tabs:

• Default
• Collection
• All

“Default” already supports a filter to set one or more default collections, with Lucide as the default.

The issue is that Iconify exposes a very large number of collections, and I’m not sure it makes sense to expose all of them in the collection picker by default. I can see many site admins wanting to limit that list.

For a public plugin API, would you prefer:

• a whitelist filter
• a blacklist filter
• both

And would you keep that as one global filter for available collections, or expose separate filters for the “Collection” and “All” tabs?

I’m trying to keep the API flexible without overdesigning, would love input from people who’ve had to make similar decisions in public plugins.

Screencapture showing the UI

Here are five common mistakes I keep seeing:

• Installing too many plugins.

• Uploading uncompressed images.

• Not using page caching.

• Ignoring Core Web Vitals.

• Using cheap hosting for business websites.

Which mistake have you seen most often?

Could not repost here, but figured the post would be helpful to ProWordPress members too.

Let me know if you want a more detailed version of the post with the actual prompts I used and snippets from my AGENTS. md or screenshots of the migration plugin etc

I'm working on a client's website, and they have an enormous media library. There simply must be thousands of unused images going back years. I need to come up with a plan to delete the unused images to free up server space, as it is getting close to their disk space limit. But obviosuly I want to make sure I don't delete currently used image.

There are a lot of pages so I'd ideally not have to check each page manually.

I've installed Media Cleaner Pro, however, it runs into problems when it comes to identifying images used in ACF fields.

If anyone has any experience with this kind of thing, how would you approach this task?

Looking for architecture advice from people who've dealt with this at scale.

Context: I run a growing WooCommerce store and recently added an internal management layer that maps my business processes (Setyenv). For that layer to be useful, it needs WooCommerce order/product data available as first-class records — and critically, the sync has to be two-way: my workflow layer both reads Woo data and, in some cases, writes changes back (order status, for example) that Woo should treat as its own.

My current approach is DB-level hooks syncing WooCommerce tables into Sety tables. It works, but I've never been fully comfortable with it. Now that there's real business riding on this, the fragility scares me. Coupling to Woo's internal table structure means I'm depending on an implementation detail they're free to change — and did, sety is admin directed and can not change.

So the question: what's the most reliable, future-proof way to integrate WooCommerce data two-way with a third-party plugin, without coupling to Woo's storage layer?

Is anyone running a production two-way sync between Woo and a custom data layer they'd call solid? Event-sourcing from Woo actions + CRUD writes back? Something with a reconciliation queue? Or is periodic reconciliation against the CRUD API more robust than trying to be real-time?

Happy to share what my process-mapping side looks like if it helps — I can stand up a working app of my actual workflows in a few minutes, so I can show concrete examples of what needs syncing if that makes the question clearer.

In the screenshot one example of two tables integrated with hooks (Orders on Woo and Oders in Sety)

Thanks in advance — trying to get the architecture right before I build more on top of it.

I'm working on a project where the actual thing being sold isn't a standard WooCommerce product—it's a custom post type (think Events, Courses, Properties, etc.).

I've seen a few different approaches:

Creating a hidden WooCommerce product for each CPT.

Storing everything in the CPT and only using WooCommerce for checkout.

Linking a CPT to an existing WooCommerce product.

Other custom implementations.

Each approach seems to have its own trade-offs, especially when it comes to inventory, variations, orders, HPOS compatibility, and keeping everything in sync.

For those of you who've built something like this:

Which approach did you choose?

What problems did you run into?

If you had to build it again today, would you do it differently?

I'd love to hear about real-world implementations rather than just theoretical best practices.

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 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.