[removed]

I’m a React Native developer with about seven years of experience in software development. 2 years of those were focused entirely on WordPress development building sites through actual code and an IDE, not primarily using page builders.

I currently work as a React Native developer, but around two years ago, before AI agents became as capable and widespread as they are now, I started building a WordPress plugin that I thought could genuinely help WordPress users.

Since then, AI has improved so quickly that I’ve found myself in a bit of limbo. I’m unsure what the future of WordPress plugin development looks like and whether it still makes sense to invest time in building a plugin as an independent developer.

I’ve been thinking a lot about where WordPress plugin development is headed. AI is making it much easier to generate code, scaffold plugins, write documentation, create marketing copy, and even troubleshoot bugs. The barrier to creating a basic plugin feels like it is dropping quickly.

At the same time, the places developers used to use to build visibility and connect with people like Facebook groups, forums, subreddits, and other public communities. It seem increasingly flooded with AI-generated content, spam, and affiliate posts. It makes sense that moderators are responding with stricter rules around self-promotion and posting, but it also makes it harder for legitimate small developers to share something useful they are building.

As noted in the title, I gave it access to STAGING, not my production server. Wanted to re-iterate that so nobody does anything stupid... like giving it access to production.

This was incredible for me. I was wondering the best ways to connect AI to my site to help do the busy-work. Since claude code uses terminal, I realized it can simply ssh in on its own and do my bidding. (actually claude suggested it and I facepalmed at how the answer was right there).

I'm on Windows and was able to safely create a terminal command 'staging-server-connect' and it would connect to the staging's ssh. This way, I didn't have to give claude any creds.

Since it has access to ssh, it can access logs, the database, files, the WP CLI, everything.

The website I was working on was very customized and complicated. Changing the site's nav menu's could be an hour of copy/pasting, etc. into WP's backend. But not anymore! I told claude what to change, and it did. easily. I was impressed. So I started asking it for more.

It gave me audits of the website and database and bottlenecks.

I was able to tell it to create new ACF fields and how to populate them. It did all this.

I had it create new products, and variations, and it did. I did have to fix some things, it didn't give all my variations the prices for some reason, but it did set everything up, including attributes and taxonomy attributes.

I hear a lot of people asking how AI is helping and how to do it. So I just wanted to share that it is possible.

Remember, Claude and AI is a tool. It's not perfect. I did check every single thing it changed before pushing staging to live, and it had a bump along the way for some reason (the variation pricing).

I didn't look into why the pricing didn't work, since it was easy for me to manually do at that point, but am confident I can get it working and get it to import entire spreadsheets of products.

It did create the ACF fields and assigned them to the correct posts as needed, and populated them correctly.

Overall, I was very impressed. I'm sure you could do this with Cursor or whatever AI. This is not a promo for Claude, it's just what I have.

Also, I wanted to point out that I did manually create a skill for this, based on my own needs. I told the skill how to connect (use the command staging-server-connect), where the WordPress install folder was (public_html for me), and some other info like that.

so the company manages the website in the wordpress already now I made a whole replica using html and stuff new and now i want to push it without changing the domain please help me guys i am scared af😭😭😭😭😭

I’m building a travel guide in WordPress and trying to settle on the URL structure before anything goes live. The site will have around 150 destination pages and potentially up to 800 activity pages, so I’m trying to choose a structure that will still be manageable as the site grows.

For activities, I’m deciding between:

example.com/activity/shotover-jet/

and:

example.com/shotover-jet/

I’m also wondering the same thing about destinations and geographic areas. For example:

example.com/queenstown/
example.com/otago/
example.com/south-island/

rather than:

example.com/destination/queenstown/
example.com/destination/otago/
example.com/destination/south-island/

The site structure would be something like:

South Island
→ Otago
→ Queenstown Lakes
→ Queenstown
→ Shotover Jet

That hierarchy would still be shown through breadcrumbs and navigation, even if the URLs themselves were flat.

I’ve been testing this locally and have a custom resolver working, so Pages, Destinations, Locations and Activities can all use root-level URLs. The obvious downside is that every slug has to be unique across all of those content types, and it requires more custom handling than standard WordPress permalinks.

For anyone who has built or maintained a site like this, would you keep the /activity/, /destination/prefixes for simplicity, or are flat URLs fine as long as slug collisions are properly prevented?

I’d also be interested to know whether flat URLs have caused any real problems with SEO plugins, redirects, caching, multilingual plugins or adding new sections later.

I’m trying to make the best long term decision rather than just choosing the shortest URLs.

Your help and feedback would be much appreciated!

It doesn't happen very often, but this time it is: WordPress has released yet another security update within just a few days.

We are currently seeing a massive wave of AI-driven attacks, and this heightened threat landscape shows no signs of slowing down anytime soon.

Security is a moving target right now, so if your website hasn't been updated yet:

• Head over to your site dashboard immediately.
• Update WordPress to the latest version: 7.0.4.

Stay secure!

Gravity Forms newest update changes the submit button from an input field to a button. If you were targeting the input[type="submit"] in your styling in any way, you will want to update to button[type="submit"]. I am partway through updating this on a whole bunch of sites at the moment.

For example I needed PHP concurrency not blocking requests and found in includes/requests/src/requests.php there is an existing function called requestMultiple() where I can pass the fetch request and the options and it works just similar async/await in JS. This saved me having to import a whole library.

Another was wp_enqueue_media(); where it attached all the required logic and functions in the window object which can use JS functions (in my case TSX within react) to use media uploads straight to the media library via ajax. I can just call window. wp. media and it has all the dependencies to upload.

I'd love to hear any githubs you have saved or templates you use that you'd like to share please let me know how they helped you.

Been doing wp work and my setup feels stuck in 2018. laragon for local, vscode, wp-cli, and a terminal open just to watch debug.log lol.

Is everyone on localwp / ddev now or does that not matter much? and the php version thing across older sites drives me nuts, curious if you just keep separate stacks or something smarter

whatever you're using, even if it's ugly, I want to hear it...

For those building or maintaining larger WordPress/WooCommerce installations, how are you approaching subscriptions these days?

I'm less interested in the basic "create a subscription product" part and more interested in the architecture around it.

Things like: recurring billing and renewal failures, subscription status and lifecycle management, membership access, content restriction, plan upgrades/downgrades, customer self-service, reducing plugin conflicts

At some point, stitching together a subscription plugin, membership plugin and separate access-control system can become harder to maintain than the original problem.

I've been looking at both traditional setups and newer all-in-one approaches. ArraySubs is one of the options I've come across because it combines subscriptions with membership access and content restriction than treating them as completely separate systems.

what's your preferred architecture? One comprehensive plugin, or several smaller plugins that each do one thing well?

I am so excited, its not just decoupled, it is edgeless.

Wordpress functions with SQLite, Next.ja with both decoupled front and backend. Its a project I have been working on doing. I do independent journalism and not so much anymore but when I used wordpress I made so many customizations I had a decoupled frontend but always annoyed at the backend. Now after so much testing and development no core functionality is lost, the code is rebuilt entirely for the future. Wordpress is finally edgeless.

The version I built has features for newsrooms like local ffmpeg, telemetry, positioning news articles with interest based engines for newsrooms, newsletter management, fully integrated analytics, edgeless sso, mcp server, digital watermarking in videos and photos that is hidden with cryptographic transparent pixels, unlimited horizontal scaling which doesnt increase price since everything is base level and then usage based. A complete integration with with tools like Clickhouse through Apache lighthouse and even a vector database for internal LLM and frontend ai use. Every article on the default template is transcribed by their choice of AI voice and when they upload a video it converts it to HLS and builds chapters and captions automatically. Their photos are optimized for modern browsers and also auto transform.

Built into the product is hardening mechanism driven by real time machine learning of the edge network of all the instances.

The custom build fully generates a react based pwa and native ios and android app for the customer based on their site design and also fully integrates with apple news, google news and video rss. If they upload a video on their news site they can also auto upload to youtube as well.

They can do automatic A/B testing of articles and create their own programatic ad network allowing them to take control of their monetization.

I feel like a fucking nerd, i searched for months for this solution. Not even WP VIP has this. For newsrooms like CNN who is a customer of Wordpress VIP this could be a huge gamechanger.

For everyday users this changes everything.

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:

page size	its queries	"per row"
20	19	0.95 — looks like a textbook N+1
100	19	0.19 — looks completely innocent

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:

all plugins active	WooCommerce only
per-row queries blamed on woocommerce	3.0

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:

before	after	deactivation control
blamed on woocommerce	3.0/row	1.0/row
blamed on the real culprit	0	2.0/row

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

with	without
total queries @100 rows	495
queries blamed on woocommerce	206
wall time	0.62 s

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.

config	SQL time	wall time	vs baseline
no object cache	255 ms	0.62 s	baseline
Redis over TCP	118 ms	0.757 s	+22.1%
Redis over unix socket	116 ms	0.687 s	+10.8%

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.

Hey guys,

Been dealing with a couple of big Multisite networks this week and I'm curious how you're all handling this.

Full network backups are easy enough. But whenever a client wants to back up or isolate just one specific subsite—or worse, move a subsite out to its own standalone WP install—it turns into a headache. Between serialized data, custom table prefixes, and sorting out the media uploads folder, it always takes way more time than it should.

How are you guys actually dealing with this day-to-day? Custom WP-CLI bash scripts? paid plugins? Or are we all still doing manual DB dumps and search-and-replace praying nothing breaks?

Would love to know if there's a cleaner way people are doing this lately.