Our great sponsors
-
wordplate
WordPlate is a boilerplate for WordPress, built with Composer and designed with sensible defaults.
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
WordPress
WordPress, Git-ified. This repository is just a mirror of the WordPress subversion repository. Please do not send pull requests. Submit pull requests to https://github.com/WordPress/wordpress-develop and patches to https://core.trac.wordpress.org/ instead.
-
elementor
The most advanced frontend drag & drop page builder. Create high-end, pixel perfect websites at record speeds. Any theme, any page, any design.
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
Found some discussion here, but tbh it's a little light for me not to think that NIH syndrome doesn't come into it?
https://github.com/vinkla/wordplate/issues/234
What advantages does WordPlate have over Bedrock[1], some of whose packages WordPlate also uses?
[1] https://roots.io/bedrock/
Wow, Wordpress still use MD5 hashes for passwords? That's really taking backward compatibility with old PHP versions too far!
https://github.com/roots/wp-password-bcrypt#readme
>Also $wpdb->prepare() uses parametrised values.
They appear to be a hand-rolled PHP version of imitation parameterized values, not the actual database library ones.
https://github.com/WordPress/WordPress/blob/master/wp-includ...
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.
Best of luck on your cms - I must admit I think the future lies with something like deno/fresh (https://fresh.deno.dev) or astro (https://astro.build) along with cdn/edge computing.
> 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?
Best of luck on your cms - I must admit I think the future lies with something like deno/fresh (https://fresh.deno.dev) or astro (https://astro.build) along with cdn/edge computing.
> 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?
> Same for WordPress.
Not as much - WP favours backwards compatibility (or is it laziness?) even when doing so impacts security.
Another problem is that the environments Wordpress targets are inherently vulnerable - while it's not WP's fault directly, they do nothing to warn people against using them nor outright stop supporting broken, insecure configurations.
> There are multitudes of comments that specifically single out WP in the post's comment thread. Including this very thread that you are on.
I was talking about publicized data breaches in general. But if we specifically talk about CMSes, I'm not sure anything else beats Wordpress and similar PHP-based CMSes of that era when it comes to not just the amount of vulnerabilities, but especially the nature of them - the same, dumb, basic problems resolved in every other language (including modern PHP with a framework such as Laravel) repeated over and over again.
> WHERE is that objective study that compares WordPress with other software in regard to vulnerabilities
Someone posted the following excerpt of the Wordpress codebase, which appears to be some custom attempt at simulating SQL query parameterization instead of using the actual, database-driver-provided function. If this is indeed the purpose of that function and it is indeed used, then I'm not sure there is any valid excuse for this in today's day and age.
Someone else mentioned password hashing still relying on MD5 - if that is actually true, I'm not sure that is excusable either? I haven't done PHP for many years now, but surely even if the native functions aren't available, couldn't they use a "polyfill" such as https://github.com/ircmaxell/password_compat ?
I'm sure there are many other issues but frankly the first one should be enough for any competent developer to run away.
> No it doesnt. Dont make up falsities. PHP executes files how you configure it to.
I was with you until this, but now I think you're arguing in bad faith.
Yes, if you want to be pedantic, PHP and your web server execute files like how you configure them to. In practice, the environment where the vast majority of Wordpress sites are deployed (your typical shared hosting environment) will execute anything that ends with .php and is in the web root.
This is inherently a legacy PHP problem (which WP encourages by supporting it) - no other language that I know of does this by default. If I accidentally store a malicious file in Python, Ruby, Node.js, etc applications, the worst that will happen is that I serve it back. At no point what so ever the server itself will execute that file.
Yet in the PHP environments Wordpress targets, this is a massive issue which means every single feature handling file uploads (both in WP core and any plugins) should anticipate your server's misconfiguration (maybe it's not limited to .php files, but .html files too?) and try to protect against it, eventually failing and then you get yet another Wordpress vulnerability.