[foopod]

As a (unfortunately) wordpress dev this seems to solve my single biggest painpoint with WP. Which isn't plugin security, but the overall plugin architecture.

WP treats plugins as content, literally in the same top level `wp-content` directory as uploaded images. This makes CI/CD among other things, a nightmare. But EmDash plugins are just TS modules, which has got to make things easier even if plugin configuration does end up in the db somewhere.

[bombcar]

Wordpress has no concept of a "staging site" and no way to make changed and then "export" them from dev to production; you basically have to either restore it as a backup or just replay the changes by hand.

[donohoe]

Huh? That’s not how i think you should be approaching that. I always run local, staging, and production sites. It’s easy to setup and deploy across.

[bombcar]

How do you deploy menu changes from staging to production?

[donohoe]

Ah. I understand your circumstances better. Short answer - I wouldn’t deploy menu changes. That’s usually low-lift that I would do it manually.

If I was doing it in a recurring basis I would investigate creating a process to export the menu data and import directly using a custom plugin. Or create (via plugin) and endpoint to sync both environments (a bit more work).

I did this one time before for a subset of pages and admin users. There are likely plugins that do this already but you could likely roll your own just for menus in an hour imho.

[Y-bar]

I’m not the one you asked, but when I did WP work a few years ago I would solve it via a hook that was triggered on Jenkins deploy. The hook would always fire and listeners to that hook would execute migration scripts and similar callbacks. For example used it to migrate some tags to categories and vice versa.

https://developer.wordpress.org/plugins/hooks/custom-hooks/

[EvanAnderson]

I remember when I looked at Wordpress for the first time, like 15 years ago, and was baffled that a dev/test/prod workflow involved copying filesystem content, database content, and changing URLs that got saved in the database. I couldn't believe what a steaming pile of garbage architecture it was.

Fast-forward to last year and I'm asked to look at it again. Surely, I think, in the ensuing time somebody would have rectified the architectural stupidity. It's a wildly popular platform, I thought. Surely it can't still be so terrible...

Fool me twice, I guess. >sigh<

[withinboredom]

> a dev/test/prod workflow involved copying filesystem content, database content, and changing URLs that got saved in the database.

This just sounds like deploying web software. You always have static assets that need to be deployed, the code/binary itself, and database migrations.

[EvanAnderson]

The "copying filesystem content, database content" part of that is perfectly sane. I should have phrased that better.

The insane part is the search-and-replace on the database backup to find hard-coded URLs referencing the environment's hostname. That's ridiculous. It speaks to the lack of serious operational experience that went into building the software.

[julianlam]

Why would you expect it to? It probably predates these concepts. /s