[johnchristopher]

> - WordPress consultant hired by marketing people while "editing the theme" introduced an infinite loop which caused OOM killer. That's when we learned you can point-click your way to editing actual php code in the admin web interface! Complete and total chaos and anarchy.

Fear not, you can also introduce infinite loops with a good old code editor and ship through FTP or git or whatever. Also work with different CMS and languages.

Who was responsible for setting user roles on that site ? Who gave admin access to a consultant without having a conversation with ops ? If there's an op team, why isn't there a staging environment for that site ?

> - Content manager "upgraded the SEO plugin" which downloaded from the Internet some hot-new code which used some language features beyond the version of php we were running, and bam, the whole thing was 500s, and everyone freaked out!

Content manager shouldn't be given admin rights to a Wordpress installation. Why did op team allow content managers to upgrade software ?

> - Content people messed up the syntax editing the theme trying to change contact info in the footer, site wouldn't load anymore, they panicked and reverted the whole theme back to the stock default, and then ops people had to help them resurrect from the daily git check-in of the 1gb docroot they set up after the last time this happened.

Isn't that also one of op team's job ? Manage backup and restore ?

Seriously, you can replace WordPress with Joomla, Drupla, Ghost here and the story is the same.

[montroser]

> Fear not, you can also introduce infinite loops with a good old code editor

Well, when a developer writes code in an editor, they probably are working in a development environment with tests and version control, etc.

Why is there a web editor that changes the application's own running code? And why in the world would I expect that that would exist, and be on by default, for me to have to go and figure out how to turn off?

[johnchristopher]

> > Fear not, you can also introduce infinite loops with a good old code editor

> Well, when a developer writes code in an editor, they probably are working in a development environment with tests and version control, etc.

This can be done with WP, but you are totally right and I should also have pointed out that the consultant should have asked for a staging environment or at least set up his modifications on his local copy of the site. He/she worked on prod and that's a big no-no.

> Why is there a web editor that changes the application's own running code? And why in the world would I expect that that would exist, and be on by default, for me to have to go and figure out how to turn off?

Ah, I think I now see where you are coming from. but:

> Marketing people insisted on WordPress so we reluctantly put it off in its own isolated network and expected bad things to happen. And, they did...

Well, if op team was aware of WordPress's reputation (and rightly so) it's a little bit on them to preemptively mitigate some of the risks especially if marketing team isn't aware of it. I suppose there wasn't enough hands on deck to do so deep enough at the time it happened or maybe office politics got in the way, etc.

Anyway, some security practices for WordPress suggest to change some file ownership (so only sysadmin can do maintenance work for core, plugins and themes via wp-cli), see https://wordpress.org/documentation/article/hardening-wordpr... which lead me to suggest that git may not be the best option for backup (since it doesn't preserve user ownership). Something like Borg, Restic or a file system based backup/veam/etc. is a better option.

> Why is there a web editor that changes the application's own running code?

Well, in the before time, it would give anyone running the site the ability to modify theme/plugins if they didn't have access to FTP.

Totally agree, I don't see any reasons to keep this around. But any plugins or themes can add a section in the dashboard with a web editor able to modify anything the webserver can modify, so... it's mitigation more than prevention if themes and plugins upload aren't locked.

I hope I am not coming off too strong ? I would likely do the same kind of mistakes if I was asked to host a django something.

[montroser]

> Isn't that also one of op team's job ? Manage backup and restore ?

Yes, and that's what they did. But it seems a broken design when it takes all that to change some copy in the footer.

[johnchristopher]

Yeah. Big workflow failures here. The person who changed the code doesn't have a revision system in place or the skills/knowledge to put the site back up after such a minor edit :/.

[Nextgrid]

How do you even reliably version-control something that relies on editing its own code?

[johnchristopher]

There's some confusion here. WordPress themes and plug-ins don't rely on the built-in web editor. That's why it can be safely disabled.

What that guy did is no different from sshing into the prod server, live editing a Django plug-in and refreshing the browser.

Version control of the plug-in won't protect from that. But it's a handy tool to manage regressions.

Rolling back changes and editing a live plug-in are different problems.