Since you need to support versions of PHP that don't support the extensions that have parameterized queries.

I was replying to

> show me if security is improved! > (which for Wordpress can't be that hard)

that is, to say that the concept of 'WordPress Security' isn't a single simple thing to 'improve'. Unfortunately. If you wrote a set of 10 jillion tests and proved that wordpress core has no possible security vulnerabilities (humour me), that still would not fix 'WordPress Security'.

From a theoretical point of view, you're absolutely right, and I agree with you.

From a practical point of view, WordPress is often 'good enough', and 'works well enough', and has 'few enough security issues', for many people.

Improving security is great, but it's a complex, perhaps impossible problem.

I disabled the default toolbar with shortcodes and replaced it with my own with Kramdown versions. I hooked the Add Media button to output Kramdown instead of HTML as well. Also we're having our editors write Kramdown.

Lastly, when pulling all the data, I determine if the post is HTML or Kramdown and use the Kramdown library to parse the HTML.

Everything migrated from the old site was automatically converted to Kramdown this same way and had to have some minor cleanup work done on each post. Not a small task on our main WordPress site with 7000+ posts/pages.

The interesting part was that wp_autop() happens at render time, so to get Kramdown to parse the HTML correctly, you actually have to RegExp replace '\n\n' with '<br /><br />' first to preserve paragraphs.

Some of them are just bizarre. We have like 14 different WordPress sites with varying degrees of customization. Oddly, some of our most basic WordPress sites (basically zero plugins) would return _no results_ when querying for Posts. Especially in our Multisite instances. Especially in our sites that hook parse_request. Some others would return inconsistent results for the same queries. Custom post types would most-consistently not return sensible results. Entries in the wp_postmeta table stored via ACF Pro seemed essentially inaccessible.

Most annoying though is that the API returns paginated posts but without returning data about how many posts there are or what page you're on. IIRC, there was a hard limit on returning max 100 posts per query. Might have been higher but significantly less than the number of posts we have. It was a total nonstarter unless we could guarantee that we could make and return enough queries to return all the posts before anything changed. With a 40+ content team that's impossible.

Sorry that I can't be more accurate than that right now.

Side note: I don't know if this has been said before, but ACF Pro is like the single most essential WordPress plugin for dev teams who know what they're doing. That plugin combined with some dev time replaces the need for like 99% of anything else that we would need to install. Please consider doing whatever it takes to make that plugin part of WP Core. Installing it on any site is a really sensible thing to do. That said, their field labels ("field_<somedigits>") really should be replaced with a GUID.

What you're missing is that these security exploits are discovered, patched and disclosed. The same can't be said about most tech services / products. Security through obscurity is not a viable strategy.