Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WordPlate: WordPress on Composer with sensible defaults

github.com

Post reply on HN
Print view View original

51–60 of 105 posts

Re: WordPlate: WordPress on Composer with sensible defaults

#51

Post by montroser »

johnchristopher wrote: post #46
montroser wrote: post #39

WordPress is plain crazy. 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... - 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 an…

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

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

Re: WordPlate: WordPress on Composer with sensible defaults

#52

Post by montroser »

johnchristopher wrote: post #46
montroser wrote: post #39

WordPress is plain crazy. 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... - 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 an…

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

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

Re: WordPlate: WordPress on Composer with sensible defaults

#53

Post by johnchristopher »

montroser wrote: post #51
johnchristopher wrote: post #46

Earlier quoted context omitted.

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

> 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 t…

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

Re: WordPlate: WordPress on Composer with sensible defaults

#54

Post by johnchristopher »

montroser wrote: post #52
johnchristopher wrote: post #46

Earlier quoted context omitted.

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

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

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

Re: WordPlate: WordPress on Composer with sensible defaults

#55

Post by johnchristopher »

gnz11 wrote: post #48
bottled_poe wrote: post #44

Earlier quoted context omitted.

For better or worse, part of the appeal of Wordpress is ease of use for non-developers to update their website. Most small businesses definitely don’t employ a dedicated site admin/developer - if they had to they wouldn’t bother with a website. In fact, it looks like that’s the way things are going - pushing small businesses into walled gardens like FB, Insta, Wix, etc. And I don’t blame them, that’s probably the rig…

"part of the appeal of Wordpress is ease of use for non-developers to update their website." Seems like in every HN thread regarding Wordpress this is brought up, but later the thread fills up with horror stories of sites being melted down when non-technical users are left to manage these Wordpress sites. Just my two cents, but that supposed benefit of Wordpress seems more like wishful thinking.

> Seems like in every HN thread regarding Wordpress this is brought up, but later the thread fills up with horror stories of sites being melted down when non-technical users are left to manage these Wordpress sites. Just my two cents, but that supposed benefit of Wordpress seems more like wishful thinking.

Nah, it could also mean we don't hear about all the Wordpress running without problems.

Personally I think it's a HN meme now, like the Signal thread with half the comments about Matrix.

Re: WordPlate: WordPress on Composer with sensible defaults

#56

Post by johnchristopher »

montroser wrote: post #47
noeltock wrote: post #40

Earlier quoted context omitted.

Why do you give non-devs the ability to upgrade PHP plugins and edit theme syntax, shouldn't that be the site admin handling? Why are you not using staging to test? These don't seem like WP problems :/

Why can a "theme" editor edit application code? Why do I need a developer in order to change what it looks like? Why is plug-in code not sandboxed? These are WordPress problems. At the end of the day, if you tell me that WordPress is an application framework, that themes are code and plugins are dependencies, then okay -- devs own it and there's code reviews and staging environments and deployments and migrations and…

> Why can a "theme" editor edit application code? Why do I need a developer in order to change what it looks like?

Because CSS, because HTML tags are rendered server side and that H1 should be a H2 or that tailwind div soup is funky, or the company team member pages needs ACF to keep tracks of member profiles because editing the page by hand takes too much time,etc.. webdev :/

The other option is things like Elementor or Divi which aim to give content team the ability to modify layouts (and even links to dynamic elements in db) but it's a whole another mess (but it wouldn't be your, yeah !).

Someone at WP is aware of it though, hence all the work on gutenberg and front-side editing (FSE) which ultimately should turn WP into a complete headless CMS.

> Why is plug-in code not sandboxed? These are WordPress problems.

Definitely ! Wait until you have a plugin breaking wp-cli so you can't deactivate it... rm wp-content/plugins/foobar-plugin -rf to the rescue.

> At the end of the day, if you tell me that WordPress is an application framework, that themes are code and plugins are dependencies, then okay -- devs own it and there's code reviews and staging environments and deployments and migrations and all the rest.

> But if you tell me it's a CMS so marketing people can have a blog, I just ... thought it would be simpler.

Yeah, if marketing just wanted a blog and no forms to collect resumes, polls etc. I'd have given them a ghost or a very reduced/amputated WP and signed binding agreements that no plugins or themes would ever be installed on it.

Re: WordPlate: WordPress on Composer with sensible defaults

#57

Post by unity1001 »

9dev wrote: post #6

Just reading this again gives me a backflash of the horrors of working with WordPress. If you haven’t seen the source, you don’t know just how god-awful the code is - and it just won’t die, because of all the ecosystem traction it has. Even the PHP developers have chosen to ignore WordPress in language evolution considerations, as the WordPress community refuses to do accept kind of progress for their project - they…

> If you haven’t seen the source, you don’t know just how god-awful the code is

And yet, it runs 50% of all websites and 30% of all ecommerce websites.

...

Apparently it is not god awful. If running 50% of the web is godawful, anybody would want their software to be that much 'godawful'...

Empty elitism contrasting the actual reality of life and business...

Re: WordPlate: WordPress on Composer with sensible defaults

#58

Post by e12e »

montroser wrote: post #39

WordPress is plain crazy. 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... - 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 an…

Fwiw at a previous job we found that using blog vault backup gave us reasonable backups - a way to migrate setups (restore to new host) and workable (if a little clunky) staging environments:

https://blogvault.net/

In addition:

https://elementor.com/

Helped by providing a more reasonable editing experience (for a website - not "just" a blog).

Both of these are paid. I think I would have preferred a managed host that provided backup and staging - but that would probably cost a little more (cash, fewer hours) - than basic php+mysql web host.

Other than those two - I think we got rid of all third party plug-ins, except for a theme or two (different theme for different sites).

Made wp just about manageable.

Personally I still can't stand the wysiwyg "works 90% 80% of the time) editor - but then the marketing people were responsible for updates - and with wp they could do it themselves.

Re: WordPlate: WordPress on Composer with sensible defaults

#59

Post by dazc »

bottled_poe wrote: post #44
noeltock wrote: post #40

Earlier quoted context omitted.

Why do you give non-devs the ability to upgrade PHP plugins and edit theme syntax, shouldn't that be the site admin handling? Why are you not using staging to test? These don't seem like WP problems :/

For better or worse, part of the appeal of Wordpress is ease of use for non-developers to update their website. Most small businesses definitely don’t employ a dedicated site admin/developer - if they had to they wouldn’t bother with a website. In fact, it looks like that’s the way things are going - pushing small businesses into walled gardens like FB, Insta, Wix, etc. And I don’t blame them, that’s probably the rig…

Until some random violation gets the page suspended or removed. Had this happen a couple of times, latest was a result of changing over from Facebook Ad manager to Meta Ad manager (or whatever they call it) which triggered the suspicious activity, give us your Govt ID busllshit.

Sorry Facebook, you can go and... you know what!

Re: WordPlate: WordPress on Composer with sensible defaults

#60

Post by berkle4455 »

tyingq wrote: post #28
mpol wrote: post #8

Earlier quoted context omitted.

WordPress uses the PHP-mysqli extension. The PHP-mysql extension is unused since WordPress 3.9, quite some years ago. You might mean PHP-pdo is advised. Can you explain why it is better in this regard? Also $wpdb->prepare() uses parametrised values. Not everywhere in WordPress core is it being used. Most plugins use it for direct queries (not that common), but I don't know if the plugin team refuses plugins when they…

>Also $wpdb->prepare() uses parametrised values. They appear to be a hand-rolled PHP version of imitation client-side parameterized values, not the actual database library ones. https://github.com/WordPress/WordPress/blob/master/wp-includ...

Wow. That is so much code just to avoid calling mysqli_prepare(). And they insist on using a weird printf inspired syntax instead of ? or :field.
Post reply on HN