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 still use the unsafe, outdated mysql-API without parametrised queries, for example.
Whatever you do in 2023—if you can avoid it, don’t use WordPress as a CMS.
WordPress is the FLOSS alternative to Wix et al. It is the only practical software that enables people to create and self-host an online presence without having to type a single line of code, and without being beholden to a large centralized platform.
No, a static site generator that requires knowledge of Markdown and a few lines of bash doesn't count. A CMS that requires you to hire a professional to even get started doesn't count, either. It might seem strange to developers like us, but there are lots of people out there who are simply allergic to code. They can use PowerPoint and maybe even Photoshop, but show them a blank terminal and they'll just freeze. WordPress, on the other hand, can be navigated with a bunch of point-and-click, drag-and-drop, buy this and add that and change the options a bit. Just like PowerPoint, it barely works, but it works.
Very few people in our startup bubble seem to care about these "I want a website, but no code please" people, and when we do we often treat them with contempt. How hard can it be to copy and execute a few commands, after all? But apparently that market is large enough to attract a sustainable ecosystem of plugin and theme sellers. WordPress has this market completely cornered. It won't magically disappear just because it's built in crappy code. Understand the users, on the other hand, build a good alternative, and that billion-dollar market might become yours. :)
it wouldn't be hard to put together the base of wordpress in python on top of django. but hosting companies for decades cared only about mod_php and had no one click uwsgi/fastcgi solutions.
although this still doesnt answer why wordpress became king of the hill in the php ecosystem. was textpattern/drupal/joomla/etc that much worse/harder to use?
in the end wp just looked a tiny bit more professional and an easier name to remember for the masses. this technical dept will be paid for many years to come.
1-point-click installations failing, to failing standard templates, tutorials that are only for version 2 and not 3, because that's a video right now.
Talk is cheap, but execution is where it is.
Isn't that the entire point of Ghost?
Can it? I can write code but I'll be damned if I can figure out how to make something that doesn't look like a fourth grader in an Intro to the Internet, 1995 Edition class made it.
If you own a wordpress site for your business and you want to change your dev or agency then you will have no problems finding people who understand WP and can work on/fix your site. It might cost you but you'll have no issues finding people to work on it.
Use anything else and you'll be hunting down people who can and want to work on it.
The other major issue is, the paid plugin ecosystem is vast in wordpress and because of that many problems can be solved with a plugin. The conversation typically goes "If this were on wordpress we'd buy this plugin for $xx and we'd be done in a few days, but it's not so we can build it for $xxxx and it'll take at least 2 weeks."
Client hears that and ends up on wordpress next redesign.
Code quality ultimately doesn't matter to site owners so long as the site works.
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...
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 are not using it.
And the fact that it’s 2023 and we’re somehow ok with the biggest web application there is not using parametrised queries in its core completely stumps me. Time and time again, SQL injection attacks in Wordpress or it’s plugins pop up. PDO with parametrised queries simply eliminates this issue.
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...
To the contrary, with each PHP iteration, "bad code" is executed faster with fewer energy utilized.
This leads to PHP itself having to make bad compromises for the future to keep the Wordpress code of millions of websites running; this leads to developers wasting time trying to accommodate Wordpress in plugins and themes; this leads to new developers growing up with bad standards and outdated practices.
I’m not complaining Wordpress doesn’t follow the latest trends or won’t add arrow functions everywhere. I’m complaining they actively block the way to the future, like a senile senator with lots of unmerited influence and decade-old opinions.
Instead it's just wild wild west, code review is a pain because every plugin and every developer working with WP has radically different structure and coding practices approach.
In regard to WordPlate project - I can guarantee that huge amount of plugins and themes won't work correctly with this modified, non-default project structure.
Thank you, I'll happily keep working with WordPress.
If you’re happy with Wordpress, by all means, keep on going. My critique isn’t targeting you.
I have the luxury to be able to refuse Wordpress projects. In fact whenever I can I replace Wordpress with Django.
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 and total chaos and anarchy.
- 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 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.
It's a rough ride all around...
You should probably think about giving certain users like 'content people' the 'Editor' role if you don't want them doing administrator stuff like editing the theme file directly.
I'd imagine most CMSs where you give your client full administrator access can cause issues with them doing things they shouldn't, like blindly upgrading plugins.
Which SEO plugin gave you that 500 error? Most WordPress plugins have a 'Requires PHP' header that specifies the minimum PHP version required and refuses to install otherwise.
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.
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?
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.
In addition:
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.
It's not a great assumption anymore (since many WordPress installs are now set up by agencies and dev teams for non technical clients), but it's likely a holdover from the days when most people installing it were also the main designer, developer, content writer, etc (read, bloggers).
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.
But would you also agree it's a totally insane capability, let alone default, for a CMS to offer a web interface to edit its own running application code? With no VCS integrated or rollback mechanism...
I was too naive to know I should look for a thing like that to disallow.
https://github.com/roots/wp-password-bcrypt#readme https://core.trac.wordpress.org/ticket/21022
With an admin password you can probably upload some executable code, but if you can find a database dump online I doubt you'll have too much effort exploiting a WordPress plugin anyway.
Just because Wordpress plugins are notoriously bad quality, you absolutely shouldn’t be lax with password security.
I have never seen such a badly coded mess.
I ask every downvoter to prove me wrong. I'm sure none of them have ever seen any piece of WordPress code (or documentation, or anything else).
* features People say that “you can just add a plug-in” for whatever, and that’s true. But so many things that should be core are not (advanced custom fields, forms) and other features have no place in modern WordPress (comments). Gutenberg is an incomplete answer to page builders. While the page builders are impressive, they still have a pretty substantial learning curve.
* cost I’ve been using WordPress for over a decade and it’s fallen woefully behind other CMS’s. Recently I spun up a site for a client and the plug-ins cost over $1000 just to get them going. That isn’t _WordPress’s_ fault, but it doesn’t help.
* speed WordPress inexplicably gets slow after about a year unless it’s managed by someone with masters-degree level skill. It’s like the system gets tired. The caching plug-ins help, but why doesn’t WordPress offer better caching itself?
* deploying Recently, I decided I’d had enough. I was doing a one-day build for a small marketing site and it took two hours to deploy because the “yoast” plug-in broke the WP CLI’s ability to search and replace the database for URL’s. Not to mention that source control is a nightmare because people can install their own plug-ins from the dashboard.
I’m writing an open source visual page builder for Laravel. It fixes the problems I see with WordPress for building marketing sites. Think of it as a blend between the visual ease of Webflow and the programmatic power of Laravel. By default, it’ll run off of SQLite (but any sql db will work), so they’re awe only two things living outside source control - the SQLite database and the uploads folder. That makes managing transitions from dev to production an absolute breeze.
I’m very excited about it! It should be ready for beta testing in a few weeks…if anyone wants to give it a shot, let me know.
> Recently I spun up a site for a client and the plug-ins cost over $1000 just to get them going.
I think that's the wrong way around - you/your client could buy stuff costing a thousand dollars because of the huge wp ecosystem (however dysfunctional it may be - I once looked briefly at how to write and sell a wp theme - and quickly moved on to different pursuits). Now, how much value did you get from that? That's one of the big draws of wp.
Im sure your new system will cover 80% of that - but what about the themes and plug-ins someone else needs?
As far as costs go…
Beaver builder - 250 Custom fields - 100 Faceting - 100 forms - 150 Import/export - 100
It doesn’t take long to get to $1000!
The new system I’m working on will be extensible for various needs using new composer packages. So if someone wanted to write an obscure form handler, they could trivially add it to Prodigy as well.
Stephen@bate-man.com
and I’ll add you to the list!
I’m glad I’ve been able to develop on https://wagtail.org/ for the past few years though. Usually such a pleasure to work with.
This isn't a critique, I use WP intensively, and we heavily modify and extend it as well, but the familiarity of the team (in dev, seo and content) is pretty much the only selling point, because we shut down most extra features (feeds, rpc, json-rpc, emojis, gutenberg, comments etc etc etc), use a complex varnish-setup, do image optimization etc outside of it and most plugins aren't really good, so we roll out something custom instead. Getting rid of it it isn't an option for us because we're so committed and have built so much custom stuff around it, but with a green field, I'm not sure.
Gutenberg isn't a thing for the folks I work with, nobody there likes freedom (freedom only leads to errors!), everything is form-based (ACF is slow but it works, and here, too, it's not users setting up the fields, it's developers) with a few shortcodes to pull in special elements.
I'm not complaining, I like building tools and solving problems and using WP allows for plenty of both, but in hindsight WP is slowing us down, I believe. Of course, it's hard to predict the scale of things when you start, so having something you can quickly iterate with is useful.
Craft CMS. Statamic. Expression Engine.
