I want to create a react native app for an existing WooCommerce site. What is the best way or industry standard to handle the authentication since there would be users that need to see the order history. Has anyone built before?

This should be stupidly easy but I can’t figure it out. I’d like to set up a blog where I can add items and the newest one appears at the top. Currently I have a Post called News that my site defaults to. The only way I can add to that post is opening News and adding the new item to the top and saving it. Seems like I’m missing something very basic.

Hi guys , so I was updating plugins on my clients e commerce site in production today. Unfortunately after updating Yoast SEO plugin the website crashed and it returned a white screen.

although I got back the site am asking what's the best way to avoid issues like these in the future again ?

Hello,

Which are the best plugins for the new return directive in EU?

You have to place a link in the footer that redirects to a return form, also you must implement in "My account" page.

Thank you.

I’m managing SEO for a website that currently runs on WordPress, and the website is ranking well for several important keywords.

We’re considering moving the website from WordPress to React.js mainly to improve the website’s mobile experience, performance, and overall development flexibility.

My concern is whether migrating from WordPress to React.js can negatively affect existing rankings.

For those who have handled similar migrations:

Does moving from WordPress to React.js usually affect organic rankings, even if the URLs remain the same?

What SEO factors should we be especially careful about during the migration, rendering, meta tags, canonicals, structured data, internal links, redirects, sitemap, page speed, etc.?

Would you recommend making this migration if the current WordPress website is already ranking well, or would you first try to improve the existing WordPress site?

Would really appreciate insights from people who have handled large website migrations or have 10+ years of SEO experience.

What is the #1 booking plugin

- That syncs with booking.com

- Sends an email to the manager (required) to approve/decline booking requests (optional)

- allows booking directly from the website

Decently priced... its for a chalet that gets booked as a whole

I will have a motel (multiple rooms) website to make in the future... what recommendations are there?

I re-post this again, forgot [PROMO] on earlier...

I've been working on a lightweight WordPress activity logging plugin and just released version 1.2.0.

The idea behind it was simple: I wanted something that logs important admin actions without trying to be an enterprise security suite or adding unnecessary complexity.

At the moment it logs things like:

• post publishing, updates, trashing and permanent deletion
• user creation, deletion and role changes
• media uploads and permanent media deletions

It also includes log retention (auto-purge), search/filtering, pagination and a small dashboard widget for recent activity.

What's new in 1.2.0

This release is mostly focused on making the logs more useful on larger sites.

• Added severity levels (Info / Warning / Critical)
• Promotions to Administrator are now logged as critical events
• New severity filters and date range filtering
• Role changes now show both the previous and new role
• Media Library uploads are now logged
• Faster log searches thanks to fulltext indexes and query caching
• Separate setting for dashboard widget log count

I'm trying to keep the plugin focused on being fast and lightweight rather than adding every possible audit feature.

I'd be interested in hearing what admin actions you think are worth logging that most plugins tend to miss.

https://mobbi.dev/admin-activity-logger-lite/

https://github.com/mobbi-dev/admin-activity-logger-lite

Hey r/WordPress — wanted to share a small utility plugin I built called LinkGather, now free on WordPress.org.

It started as an internal tool for auditing content on my own sites: I wanted one screen showing every published post/page/custom-post-type URL, filterable by post type, author, title keyword, and date range, sortable, paginated, with one-click copy on any URL, and CSV export (including the author column) for when I need to hand a link audit off to someone else or drop it into a spreadsheet.

Nothing fancy — no external dependencies, no premium upsell, just an admin-side content audit table. Useful if you're doing a link cleanup, migrating platforms, or just want a quick export of what's live on the site.

WordPress.org listing: https://wordpress.org/plugins/linkgather/

Happy to answer questions or take feature requests if it's useful to anyone here.

​

I need a plugin where my website's visitors can reserve a stay at this cabin/chalet but I need it to sync with booking.com so it doesn't overlap...

If a booking is made on booking.com (ex. 12-14 September) the calendar on my website shouldn't allow 12-14 September to be booked on my website

Preferably free plugin, but if its really not possible then ig I'm open to purchasing a plugin, but I can't stress this enough... it kinda has to be free

Thanks in advance

Anyone who wants to insert a link in the Gutenberg editor often gets hundreds of attachments in the search suggestions, which I find very annoying.

This plugin only needs to be installed; no configuration is required, and the attachments are no longer displayed. It also works for me with Metabox CPT. Maybe it will help someone else.

I posted this under WordPress Plugins, but it was immediately deleted, hmm...

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.

I honestly never thought I’d try making my own WordPress theme.

I’ve always wanted to get away from page builders and just have something simpler that works the way I want. But building a theme myself always felt like one of those things that was way above my level.

Then AI happened.

So I started messing around with it locally, asking AI to help me write parts of the theme, changing things, breaking things, fixing them, and somehow… it’s actually starting to look pretty good.

I know AI-generated code can be messy, insecure, or just plain wrong sometimes, so I’m definitely not pretending this is production-ready. I probably wouldn’t use it for real client work without someone who actually knows what they’re doing reviewing it first.

But still, seeing something I had in my head actually show up and work inside WordPress was such a cool feeling.

That was probably the part I enjoyed the most.

Even if I never end up using this theme for anything serious, I’m kind of amazed that AI made me try something I probably never would’ve touched before.

Anyone else here doing the same thing?

Alright let's settle this once and for all 👀

Team WordPress: flexible, huge plugin ecosystem, been around forever

Team Webflow: clean visual builder, faster to design, no plugin hell

If you had to pick ONE for a client project today, which are you going with and why?

Bonus points for horror stories 😅

I spent a while stacking caching plugins and wondering why things weren't as fast as they should be. The thing that fixed it wasn't a plugin, it was understanding that the three caching layers do completely different jobs and you build them from the bottom up.

OPcache is the foundation. It caches compiled PHP bytecode so the interpreter isn't recompiling your code on every request. It helps every single PHP app, it operates independently of everything else, and you basically never turn it off. In production I set validate_timestamps=0 and just flush it on deploy.

Object caching (Redis or Memcached) sits above that. It stores the results of expensive database queries so WordPress isn't making dozens of DB round trips per page. This is the layer that matters most for logged-in users and anything dynamic, because those requests skip page caching entirely.

Page caching (Nginx FastCGI cache for me) is the big hitter for anonymous traffic. A cached page never touches PHP or MySQL, it just serves HTML. Massive for traffic spikes, but useless for logged-in users, so you set proper bypass rules for wp-admin, carts, checkout and logged-in cookies.

The lightbulb moment was realizing they don't compete, they cover for each other. Page cache handles anonymous hits, object cache carries the cache misses and logged-in users, OPcache speeds up all the PHP underneath both. The mistakes I'd been making were running two page cache solutions at once and expecting object cache to help on pages that were already fully page-cached (it doesn't, page cache bypasses WordPress completely).

The other thing that clicked: the right strategy depends on your site. Marketing sites lean hard on page caching. Membership and ecommerce lean on object caching because everyone's logged in. Frequently updated content sites need shorter TTLs and smart invalidation.

I wrote the full guide up with the actual php.ini, wp-config and Nginx config snippets in this article Understanding WordPress Caching Layers: A Developer's Configuration Guide. Curious how you guys handle cache invalidation on fast-moving sites, that's the part I still tweak most.

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

Hi,

I need to change the attached header to include two seperate images in the middle.

The website uses Avada and I understand I need to create a new Layout section to replace this.

The problem is that it's proving difficult to apply the style of the red contacts/ social row at the top and the Nav section at the bottom to the new header.

Is there an easier way of doing this in Avada?

The client understandably assumes this is a simple change!

Thanks

Hello!

Here's what I'm not understanding about Docker:

You have to essentially write out the environment for each project, so you will have a docker-compose file that will potentially change from one project to the next.

Say over time you have 10 projects, your oldest project is maybe running an outdated version of php described in the docker file. Or maybe some setting has changed... and this happens on each project.

How do you keep each docker configuration, of which there are now 10, up to date and in sync?

Maybe keep a repo with your up to date WordPress-Docker config and pull it down to each project?

Thanks!

Hi, has anyone had a similar issue with WordPress 7.0.3?

I have a custom plugin that works fine on my demo site (also WP 7.0.3), but on the live site its settings page keeps loading forever.

No PHP/debug errors. Other wp-admin pages work normally.

The weird thing is that if I open the same settings page with &noheader=1, it loads immediately. Without it, the request just hangs and doesn't even return headers.

So I'm guessing something is getting stuck during the admin header/hooks, possibly a conflict with another plugin or security/cache layer.

Just what the title says. I can't get at the photo but I can see a tiny preview of it. How do I change it?

I work in higher ed, mostly instructional design and Canvas LMS support type stuff. WordPress has been a growing chunk of work for me, and is now solely on my plate following the retirement of my coworker.

I’ve been in my current role for seven years and have gradually picked up some work from a long time colleague who has now retired on short notice. This work is now completely on my shoulders and I worry I’m in over my head. I did get a pay bump to pick up this work, which is great, but I fear I didn’t realize what I was getting into when agreeing to this.

I feel confident with “visual” Wordpress editing but do not have a development background. I’m working through the “Beginner WordPress Developer” course now and it has me freaking out a bit that I have so much to learn in a few weeks. I follow the course content just fine when it’s presented linearly, but I worry that in a troubleshooting scenario I wouldn’t even know where to begin.

Background… Over the years I’ve picked up some WordPress support work from a long time colleague. Essentially, several classes use a WordPress site to publish their work in the class. It’s a learning experience for students and a way to get their work published for awards, portfolios, etc.

In the past my colleague did the setup part (creating site files) and archiving (converting to static sites, migrating sites to new domains). He did this all manually because for him it was easier that way. We use DreamHost shared hosting. I have no problem creating the sites with DreamHost’s installer, but archiving/converting to static/migrating seems much more complex. He was using a tool called Simply Static to convert to static HTML and then manually moving the files around via FTP.

I did everything else, the “soft” stuff — training the students, adding users, first line for troubleshooting issues, customizing design, reviewing plugin/theme requests when students wanted something specific. Rarely if something completely stumped me I’d ask for his help, maybe 1-2 times per year. Frankly I think some of my anxiety around this is because former colleague was a classic old school IT grump (in the same position 35 years) who tended to make mountains out of molehills. I’ve found that several things he would complain and doomsday about didn’t actually take the hours and hours they pretended they did, he just insisted on doing it the manual way he liked rather than using the host tools.

These are pretty simple sites in terms of content, but often have many plugins, sometimes ancient ones (Knight Labs pls update your shit) and I know that’s a security issue but these aren’t exactly high traffic or sensitive sites -- just text, images, and links.

With all the fuss I see about WordPress security problems I’ve never seen any of our sites hacked… but maybe colleague was just doing more than I realized? Or maybe our sites aren't great targets?

There is also just a large quantity of sites and users to manage, so I think the big challenge is scale rather than depth, if that makes sense. I’m looking into setting up a custom role for the students and faculty that lock them out of most functionalities to prevent issues in the first place.

Before this next school year starts, can someone either walk me back from this ledge or tell me if I need to just abandon ship and tell my department we can’t sustain this and classes need to transition to using Google Sites? Obviously that's much less flexible and doesn't give students CMS experience.

Or... if I keep everything basic, set expectations low, can I build this plane as I fly it? (i.e. tell everyone we’re sticking with Twenty Twenty Five, standard theme, restricted roles, no outdated plugins, while I upskill?)

For this fall semester I only need to worry about four new sites for one course. I can keep hand updating themes and plugins from last semester while I figure out how archiving works I guess. I did one archive test successfully but the second failed and I just had to throw in the towel to get back to the rest of my “main” job after wasting half a day. Bleh.

This work really does interest me but I don't want to let the students or faculty down with my ignorance.