Lately I keep seeing more and more “I moved off WordPress to Astro in a weekend with Claude” posts. I think they’re making a mistake: they take what AI gives them, but lose what WordPress gives them.

When static is enough: a five-page site you maintain yourself, content that rarely changes, an owner who’s happy working through Git or an agent pipeline. Cheap hosting, nothing to patch. I wouldn’t argue with that. It’s great while it’s yours. It’s a different story when a business relies on it and someone else has to keep it running.

I won’t defend the standard WordPress stack either. A pre-made theme, a page builder and 25 plugins is painful to maintain. We’ve built custom WordPress since 2014 and avoided that stack on purpose. It existed because custom WordPress was expensive: a ThemeForest theme plus a few days of setup was what most budgets allowed.

But AI doesn’t only lower the cost of leaving WordPress. It lowers the cost of building WordPress right. A custom theme on native Gutenberg blocks, with real fields and one design system, is now overnight work for an agent connected over MCP. After that, the same agent manages the site from a chat: a new block from a screenshot, a new post type, rearranging a page.

What a static AI site quietly gives up once it has to grow:
- Changing CRM: someone already maintains the add-on for the form you have.
- A second language: multilingual setups that have run in production for years.
- SEO tooling: same story.
- An editor a non-technical person can use, without touching the repo.

On a static site, each of those becomes custom code you own. Each site also needs its own set of agent rules to stay consistent, and someone has to maintain them. That’s fine while it’s your evening project. It’s a burden the day it has to scale or be handed to someone else.

And on speed: built right, with a custom theme, a page cache and each page loading only the CSS and JavaScript of its own blocks, WordPress serves pages about as fast as a static site.

So my line: small and maintained by the owner, static is enough. Anything bigger, I build on WordPress, right up until it stops being a website and turns into Facebook. Then it’s an app, and we build it as one. Either way, an AI agent now does most of the build.

I'm about to sign a client after doing a partial audit of their website. It has 90+ plugins, many of them needing updates, and several that seem to do the same thing.

The job is a website restoration, and I'm starting to think my original quote of around $300–400 isn't enough for a restoration with this many outdated plugins.

My tech lead says he wouldn't normally take a project like this. As the one bringing in clients, I see it as good, sustainable income for a startup, especially with monthly maintenance after. But I also don't want to put us in a pickle, since this feels like the kind of site where if you touch too much, the whole thing goes down.

I'd love advice from other WordPress pros: would you take this on, how would you approach it, and how would you price it?

Note: Given mod permission to post about this.

We've been working on an open-source (MIT) tool that was initially built for ourselves, but since it's been such a pain point for us, we figured in might be helpful to the Wordpress developer community in general.

Strauss-RS is a Rust port of the Strauss project (itself a fork of Mozart) which prefixes classnames and symbols in Composer-based plugins and themes. Since plugins and themes are increasingly including their own dependencies, the chance of clashes has been increasing (we know, one client's site had a total meltdown when they installed Atum Pro because it used Eloquent).

With Strauss-RS, a class like `Illuminate\Support\String` would potentially become `Acme\PluginA\Vendor\Illuminate\Support\String` avoiding those clashes in your own code.

The main advantage of the Rust version is speed. We've also added a few more nice-to-have features. With Strauss PHP in our pipeline, prefixing could take several minutes every update or install, with the Rust version, it's down to a few seconds.

DM me if you'd like to give it a test run (direct links not allowed due to subreddit rules).

• Wall time for prefix, median of 5 runs after 1 warm-up, from a clean output directory each time. Both tools were given the worker count explicitly (1 against 1, 12 against 12). Memory is peak total across all processes, sampled on Linux. Strauss PHP 0.31.1 on PHP 8.4.23 (static CLI build, no OPcache, no memory limit). Strauss-RS release build. Intel i5-10600 (12 threads), 32 GB RAM. Projects: monolog (small), guzzle + flysystem + finder (medium), laravel/framework (large) and aws-sdk-php (xlarge), all with locked dependencies.

Be safe out there kids!

I (and my pal Claude) found malware hiding out in a very well-used spot. I can verify that some copies of Rank Math Pro 3.0.123 have injected malware. It beacons to rank1cdn.com every 6 hours and drops a credential-stealing webshell whose filename differs on every site.

Where to look: open wp-content/plugins/seo-by-rank-math-pro/rank-math-pro.php and check right after the plugin header, before the real class starts. On an infected copy there’s a block of about 145 lines in there, tagged with a // @wp-perf-init comment and wrapped in if (!defined('_VOWGBDFHIN')). A clean file goes straight from the header into the code. You can also just check the size: clean is about 15KB, infected is about 62KB.

Heads up: version number alone won’t tell you. One of our sites fetched 3.0.123 on Oct 12 and got a clean copy; two others fetched it on Oct 15 and got infected copies. Same release, different copies. So something changed on the distribution side between those dates.

Rank Math has released 3.0.124, which fixes the issue for now. But I got my eyes peeled, ya hear me?

WordPress 7.2 (planned for December 9, 2026) adds a Secrets API. It was committed to trunk on October 13 (r64337, Trac #66187), so you can try it now on a nightly install.

I develop plugins. Most of my plugins check for a wp-config.php constant first for sensitive information like SMTP credentials, payment provider keys and Google API keys, then fall back to the saved option. But most admins never add the constant, since they can't edit wp-config.php from wp-admin, so these keys end up in wp_options as plain text.

The Secrets API fixes that nicely. The admin pastes the key in the settings screen as usual, wp_set_secret() stores it encrypted, and the key that unlocks it lives in wp-config.php. wp_get_secret() returns an object that prints as [secret:name] if you echo or log it by mistake, and it keeps the previous value for easy key rotation.

I tested it on trunk and it works well. One catch: if you add WP_SECRETS_KEY to wp-config.php after secrets are already stored, they can no longer be read, and even saving new ones fails. So add it first.

I feel very positive about it, since database backups will no longer expose API keys.

Hi everyone,

I'm looking for a genuine Elementor Pro license for my WordPress website. I don't want a cracked or nulled version.

If anyone has a spare license or knows a legitimate, affordable way to get Elementor Pro, please let me know.

I'd really appreciate your help. Thanks!

Hey everyone,

We just released the first beta of the WordPress Contributor Toolkit 2.0, and I'd love some help testing it before the stable release. I work on this one (I'm a developer advocate at Automattic), so feel free to throw questions at me in the comments.

If you haven't seen it before, the toolkit is a desktop app for macOS, Windows, and Linux that helps you contribute to WordPress core. It sets up a local copy of core so you can apply a patch from Trac or check out a GitHub pull request and actually test it, without building that whole environment by hand.

What's new in 2.0

- A redesigned interface built with the WordPress Design System

- A new settings dialog for things like your default site location, PHP version, and WP_DEBUG flags

- Light and dark themes, or follow your system, or pick your own colors

- Every string in the app is now translatable

It already ships in Czech, Dutch, English (Canada), English (UK), Galician, Hungarian, and Polish. A language gets bundled into the app once it's at least 80% translated on translate.wordpress.org, so if yours isn't on that list, you can help get it there.

How you can help

1. Download the beta and try to break it. Bugs go in GitHub issues. https://github.com/WordPress/contributor-toolkit/releases/tag/v2.0.0-beta.1

2. Translate it into your language. https://translate.wordpress.org/projects/meta/contributor-toolkit/

It's a pre-release, so v1.2.1 is still the stable version if you'd rather wait for 2.0 to land.

Hey everyone, how has your experience been with Railway.com for hosting?

Basically, it looks like I can get a great stack with vertical scaling, paying mainly for CPU/RAM usage. How does that compare to Cloudways or SiteGround in practice?

Any insights would be appreciated! :)

When a client asked to see the latest version, the answer sometimes depended on whether the developer who built it was online. If they were available, the demo took a minute. If they weren’t, somebody had to find the correct branch and rebuild the environment. It wasn’t a disaster, just an embarrassing amount of work for something the client had already seen. We’ve started putting client demos and small internal tools on a shared staging VM. I’m testing serverspace as a cloud server provider for that setup. The rule is simple, like if a client can review it, the rest of the team must be able to open it without asking somebody to turn on their laptop. It has also exposed undocumented setup much earlier. If another person can’t deploy the project to staging, the handoff isn’t finished. The next decision is whether to keep one shared staging server or isolate every client project. One is cheaper and easier to manage, the other limits the damage when somebody breaks something.

I’ve been spending quite a bit of time thinking about security-deposit flows in WooCommerce, especially for rentals and bookings.

A lot of implementations seem to treat the deposit as a normal payment: charge it with the order, hold the money, then refund it later if everything is fine.

Technically that works, but it creates a pretty different lifecycle from the actual order payment.

The alternative is to keep the two separate: charge the order normally, then create a separate card authorization for the security amount that can later be captured or released.

That sounds cleaner, but it introduces its own set of edge cases:

- authorization windows expire
- capture and release need to be safe to retry
- webhooks may arrive late or out of order
- the external payment state can change before WordPress records it
- partial capture makes the local state more complex
- long rental periods may outlive the original authorization window

I’m curious how other WooCommerce/payment developers model this.

Do you treat a security deposit as part of the order payment lifecycle, or as a completely separate financial object with its own state machine?

I maintain a booking plugin and recently ran adversarial concurrency tests against it: MariaDB 10.11 with 8 PHP workers, plus an SQLite copy (like WordPress Playground). A few findings that might be useful to anyone doing slot-based writes in WP, and a question at the end.

1. GET_LOCK has three outcomes, not two

Check-then-insert ran under a per-staff named lock, and 20 simultaneous requests for one slot gave 1 booking and 19 refusals. Fine. But the code treated "didn't get the lock" as "carry on anyway". GET_LOCK returns 1 (got it), 0 (timeout) or NULL (error). On the SQLite translator you get neither. So now:

$got = $wpdb->get_var( $wpdb->prepare( 'SELECT GET_LOCK(%s, %d)', $name, 5 ) );

// '1' => locked, '0' => busy (refuse with 409), anything else => no lock support

Also worth noting: lock names are server-wide, not per database. Two sites on the same MySQL server with the same lock name block each other. I now prefix the name with a hash of DB_NAME and $wpdb->prefix.

1. Without named locks, re-check after the insert

SQLite has no named locks, and the same 20-request test booked one slot up to 4 times. Since wp_insert has no unique constraint across time ranges, I re-check right after the insert: if an active row for the same staff member overlaps mine and has a lower id, mine deletes itself and the request gets a 409. Zero double bookings in repeated runs since.

1. Claim before you send

Overlapping cron runs sent each reminder 6 times. The fix is a conditional UPDATE and only sending when exactly one row changed:

$claimed = $wpdb->query( $wpdb->prepare(

"UPDATE {$table} SET reminder_sent = 1 WHERE id = %d AND reminder_sent = 0 AND start_utc = %s",

$id, $start_utc

) );

if ( 1 === $claimed ) { /* send */ }

Including start_utc means a booking moved mid-run is not reminded for its old time. Same pattern for status changes (UPDATE ... WHERE status IN (expected states)), which also stopped an outdated admin view or app from reactivating a cancelled appointment after its slot was rebooked.

1. DST: wall-clock vs real minutes

Everything is stored in UTC, but two bugs still showed up:

- On the PHP version I tested (8.4), $dt->modify('+90 minutes') across the spring-forward change in Europe/Berlin gave 30 or 150 real minutes instead of 90. Using setTimestamp( $dt->getTimestamp() + 90 * MINUTE_IN_SECONDS ) gives real minutes.

- Slots between 02:00 and 02:59 on spring-forward night don't exist, but PHP silently moves them to 03:00-03:59, so they were offered twice. I now check whether a wall time survives a round trip (create it, format it back, compare) and skip it if not. Zones that change at midnight (America/Havana) need the same check for 00:00.

The question: for slot claims in WordPress without custom unique constraints, would you rather go with named locks plus a re-check like this, or a separate "slot claims" table with a unique key on (staff_id, slot_start)? The table seems cleaner but gets awkward with variable durations and buffers. Curious how others solved it.

I’m designing a WooCommerce workflow for stores that sell custom products such as apparel, signage, packaging and personalized merchandise.

The main design decision is modelling the workflow per order item rather than per order, because one order can contain multiple products at different proof and production stages.

The proposed model is:

• Capture normalized product specifications at checkout

• Store an immutable specification snapshot against the order item

• Create one production Job per eligible order item

• Store artwork and proof revisions as separate records

• Keep revision number, author, timestamp and file identity

• Treat approval and change requests as append-only workflow events

• Make customer actions idempotent

• Maintain production state separately from commercial order state

• Synchronize the aggregate state back to the WooCommerce order where appropriate

• Use WooCommerce CRUD APIs for HPOS compatibility

• Keep transitions behind named actions and filters

• Build the activity timeline from state transitions

I’m interested in feedback from developers who have implemented similar workflows:

1. Would you keep production state in custom tables or order-item metadata?

2. How do you derive the overall order state when items are at different stages?

3. Which transition rules should be hard-coded versus extensible?

4. How do you handle secure customer approval links?

5. Which events should be scheduled through Action Scheduler?

6. Which integrations are most valuable for print and personalized-product stores?

I’m implementing this as a free WordPress plugin, but I’m keeping this post focused on the architecture rather than promotion.

Thanks

Iamgsbala

Honest question, not a rant.

I've been freelancing since 2016 - WordPress/WooCommerce bug fixing and development. The last couple of years, work has fallen off a cliff. I used to get messages every day; now it's close to nothing.

I don't blame one thing, but AI feels like the biggest reason: for a lot of" fix this bug / build me this small thing" work, clients just ask an AI now.

What I actually want to know is what's happening for other people:
- Has your volume dropped, or just changed shape?
- Which kinds of work are still selling, and which are gone?
- If you pivoted, what did you move to?

Not selling anything - just trying to understand the ground under my feet. Genuinely curious what's working for people right now.

I'm a plugin author, and have some users who want to use Git Updater rather than the w.org repo to update my stuff.

I'm looking for some "here's what you do, plugin author" documentation on this, and I'm coming up short.

Reading between the lines of the Git Updater documentation, it looks to me like installing a plugin with Git Updater copies the entire contents of the Primary branch: whatever header it finds in the main plugin file (or theme style.css).

And updating it compares the Version: 1.2.3 headers in the presently installed plugin and the Github (or Gitlab &c) repo.

It looks like Git Updater, unlike the w.org repo svn setup, doesn't use the Version 1.2.3 header to decide which tagged version to install. And unlike 10up's CI workflows, it looks like Git Updater doesn't honor .distignore, so it pulls unit tests and other build-time assets as well as runtime.

Is there a commonly accepted way of setting up for Git Update? Does anybody have any guidelines for that? Ideally, it would do more-or-less what the w.org repo does with tags. But I'll be happy with any convention that lots of people follow.

Thanks.

I’ve been thinking about production logging in WordPress plugins lately.

During development it’s tempting to log everything because more context makes debugging easier. In production though, that gets uncomfortable pretty quickly.

Things like request payloads, webhook bodies, order IDs, user IDs, API responses and stack traces can be extremely useful when something fails, but they can also create privacy, storage and retention problems if you keep too much.

I’m curious where other plugin developers draw the line.

For example, do you:

- log full external API responses or only selected fields?
- keep business identifiers like order IDs in logs?
- redact emails, names and payment-related data by default?
- use different retention periods for debug logs vs audit/history data?
- let merchants enable verbose logging temporarily?
- automatically delete old logs?

I’m especially interested in plugins where failures may only become visible hours or days later, so having enough context to reconstruct what happened actually matters.

What has worked well for you in production without turning the log table into a second database?

I’ve been thinking about plugin upgrade paths lately, especially the less clean real-world case where users don’t update every release.

The simple path is easy:

1.1 → 1.2 → 1.3 → 1.4
But in production, someone might stay on 1.1 for months and then jump straight to 1.6.

That gets more interesting once the plugin has custom tables, scheduled jobs or business data.

A few things I’m curious about:

- do you run every historical migration in sequence?
- do you migrate directly from the detected schema version to the latest one?
- do you make each migration idempotent in case it partially ran before a timeout?
- how do you recover from a migration that updated some rows but not others?
- how long do you keep compatibility code for old schemas?
- do you ever refuse an upgrade because the installed version is simply too old?

I’m especially interested in cases where a failed migration can affect real orders, subscriptions, bookings or other business data rather than just plugin settings.

What approach has held up best for you on real production sites?

I'm curious how people handle content changes made on a development or staging site when production is still active.

For example: you build or update a few pages on staging, then need to move just those pages to production, including their images and custom fields, while keeping everything else on the live site intact.

Have you actually had to deal with this?

If so, how did you handle it: manual copying, WordPress export/import, a plugin, a custom script, or something else? What worked, and what caused problems?

Have you also needed those changes to go live at a specific date and time? For example, a Black Friday promotion, a Cyber Monday landing page, or an event launch. Did you schedule the transfer itself, move the content ahead of time and schedule its activation, or handle everything manually at launch?

I'm especially interested in whether this was a one-off task or something you regularly deal with, and who handled it: a developer or someone managing the content.

If your workflow avoids this entirely, I'd also like to hear how.

I’ve been thinking about backward compatibility in WordPress plugins, and the line gets blurry pretty quickly.

Obviously documented hooks, filters and REST endpoints are part of the contract.

But what about things that were never officially documented, but other developers may still start relying on?

For example:

- custom post meta keys
- option names
- database table structure
- CSS classes or DOM structure
- action/filter names that were originally added for internal use
- cron hooks
- order or product metadata
- internal REST endpoints

At some point, changing one of those can break another plugin or a client integration even if you never intended it to be “public”.

How do you decide what becomes part of your compatibility contract once a plugin is in production?

Do you treat undocumented integrations as unsupported, or do you preserve them once you know people are using them?

Hey everyone!

I'm curious about your experience with WordPress e-commerce websites and SEO.

In your experience, which type of page usually drives the most organic traffic from Google?

Product Pages – Individual product pages targeting specific product-related keywords.

Collection (Category) Pages – Pages that group similar products and target broader commercial keywords.

Brand Pages – Pages targeting specific brand names and branded product searches.

Which of these page types brings the most organic traffic to your e-commerce website, and why?

Does it depend on the niche, search intent, or website authority?

I'd love to hear your real-world experiences, insights, and examples.

Thanks in advance!

[FREE] I found myself rewriting the same GraphQL queries for pages, posts, menus, and categories in every project, so I created GraphQL Headless Toolkit to provide reusable query snippets and speed up development.

1. Works alongside WPGraphQL
2. Free to use Built for headless WordPress projects

I'd love to get feedback from the community. What features would you like to see in a plugin like this?

I’m researching better ways to manage WooCommerce stores that sell custom or print-based products.

After checkout, these orders often need more than payment and fulfilment:

• Product specifications

• Customer artwork uploads

• Artwork review

• Proof revisions

• Customer approval

• Production status changes

• Internal notes and activity history

For developers building this type of workflow, how do you usually structure:

1. Custom order-item data and immutable specification snapshots?

2. Artwork and proof file storage?

3. Customer approval and change requests?

4. Production statuses?

5. Synchronization with WooCommerce order statuses?

6. Hooks and extension points for agencies?

I’m particularly interested in approaches that work reliably with custom themes, checkout extensions and multiple order items.

I've been using Astro for a few years, and I've worked with WordPress enough to understand why it's still everywhere.

WordPress is mature. The ecosystem is huge, developers know it, agencies know it, clients know it, and there's a plugin for almost everything. For many websites, that's more than enough, except custom-built sites could do better where custom code can solve more complex problems.

EmDash is coming from a different direction.

It's not really trying to be "the next WordPress". It's a full CMS built around Astro.

You still get the things you'd expect from a CMS: an admin panel, content types, rich text you can add block-like to your contents, media management, drafts, revisions, scheduled publishing, search, taxonomies and menus.

But the website itself remains an Astro project.

One part I find particularly interesting is the content model. Content types (Like ACF plugin) can be created and modified through the admin rather than requiring every collection to be defined in code. Each collection becomes a real SQL table with typed columns, and developers can generate TypeScript types from the live schema.

So your content is managed in EmDash, while the website is built with Astro.

For developers, EmDash also provides an API, CLI and MCP server. AI agents can work with the CMS, but isn't required to use it.

The deployment model is another difference. Self-host with Node.js uses SQLite database by default, while Cloudflare deployments can use D1, R2 and Workers. There is also support for other database and storage backends.

And there is a plugin system. On Cloudflare, plugins can run in isolated Worker sandboxes with declared capabilities. Node deployments currently use in-process plugins instead.

It's still early, and obviously it doesn't have anything close to WordPress's decades of plugins, themes, integrations and community knowledge. Yet, plugin developers are already making plans to support both CMSs, which is an encouraging sign that an ecosystem is starting to form around EmDash.

Worth reading:
https://blog.cloudflare.com/cloudflare-blog-uses-emdash/

Joost de Valk, founder of Yoast, also wrote about it:
https://joost.blog/emdash-cms/

Have you tried it? How's it?

I creates a API that can generate social cover images on the fly up to date and customizable.

The ideas was to generate all the users public links for when some players of a game i made share their profile on social media the image the preview would be personalized with names, levels, branding of the game and so on.

But now i'm thinking of bringing this to the eCommerce space as there is nothing like it, every product link can have a preview with product, price, discounts, rating, review count and more. Always up to date, automatic and you can customize the look and what you want to show.

Would you guys like something like this? I can share some examples and even show how your links can look like if you share a product.

Appreciate all the feedback

I’ve been thinking more about plugin lifecycle lately, especially what should happen when a user removes a plugin completely.

Deactivation is easy enough, but uninstall is where things get less obvious.

For example:

- plugin options

- custom database tables

- scheduled cron jobs

- logs

- generated files

- cached data

- user-generated or business data created through the plugin

Some of that clearly feels disposable.

Some of it really doesn’t.

I’m curious how other plugin developers draw the line.

Do you delete everything by default, preserve business data, or give the user an explicit cleanup option?

And have you ever seen an uninstall mistake that caused real problems later?

Hey everyone!

I'm looking for recommendations on how to make the WordPress and WooCommerce themes and plugins I develop even more secure.

A bit of background: I've been developing custom WordPress and WooCommerce themes and plugins for over 5 years now.

I'd like to think I follow good security practices, but I'm always looking for ways to improve.

At my current job, we've been using WordPress since long before I joined. Unfortunately, some of our older websites have recently been getting hacked.

Most of these sites are quite outdated and overdue for an upgrade, so it's not entirely surprising.

With the rapid development of AI, I feel like attackers are becoming even faster at finding and exploiting vulnerabilities, especially in WordPress, WooCommerce, and Elementor websites.

It has made me want to step up my security game and take an better approach to securing everything I build.

So, I'm curious: what tools, techniques, or best practices do you use to test and improve the security of your custom themes and plugins?