4 ms·
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. W
by foopod 6mo ago
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 6mo agoWordpress 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 6mo agoHuh? 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 6mo agoHow do you deploy menu changes from staging to production?
- Y-bar 6mo agoI’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/ https://developer.wordpress.org/plugins/hooks/custom-hooks/
- donohoe 6mo agoAh. 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.
- EvanAnderson 6mo agoI 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 6mo ago> 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 6mo agoThe "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.
- withinboredom 6mo agoAh. That’s like a 15-line rite-of-passage plugin you write once and never have to worry about it again. Filter content going into the database and use relative uri for the same site. Configure everything else via environment variables. I moved away from Wordpress altogether earlier this year because I got tired of babysitting MySQL.
- julianlam 6mo agoWhy would you expect it to? It probably predates these concepts. /s