Password Compat VS bedrock

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

There are ready-made boilerplates like Bedrock and Sword but, at an architectural level, I'm not a fan of any I've seen.

Node (within the docker container) to build theme assets, composer to manage WordPress core + plugins and other dependencies. I built something similar to Roots for project boilerplate, custom starter theme and in-house mu-plugin within it.

Is this any good? https://roots.io/bedrock/ for a plugin?

As I only really use it for keeping stuff up to date, I'm looking at using Roots Bedrock for my next project. I'll then be keeping everything up to date via composer.

What advantages does WordPlate have over Bedrock[1], some of whose packages WordPlate also uses?

[1] https://roots.io/bedrock/

Probably looking for a https://roots.io/bedrock/

WordPress on containers is a very different beast if you actually want to use any of the advantages of containers. You probably need to figure out how to run upgrades by building a new image and not with the WP installer (which you need to disable to not have sudden version rollbacks). You probably want your plugins managed by compose and not a user. You probably want an S3 plugin for media. In fact, you probably want Bedrock. This is not a "single day task", just taking in the requirements and design phase is easily a day or two.

I'd strongly advice using Bedrock ( https://roots.io/bedrock/ ) and possibly even Sage

No, as far as I know it’s not that easy to accomplish with WordPress. You can use Bedrock (https://roots.io/bedrock/ ) as a Boilerplate for your development process. The Database can not be cloned to each environment that easily. Because every instance is working on it’s own. So if others want to work on their local machine they need a database dump which they have to setup manually on their machine. The only way that comes in my mind is to set up a development site that is accessible for every developer. You could then connect your local WordPress environment with the database from that development site. Everyone would than be working in the same database and everybody could see the changes someone else is making. But I think that wouldn’t be best practice but could be an option.