Secure Custom Fields by WordPress.org

OK so:

1) WordPress clearly lacks functionality like ACF that belongs in core

2) Many developers clearly like ACF

3) Many do not (it's messy in the DB, if you ask me)

4) Core functionality that was if not API-compatible, at least API-familiar with ACF would be welcomed by many

5) Creating a new plugin that did this, that was transitioned into core (like other functionality has been), would be a good plan

6) Commandeering the slug for a decade-old commercial plugin like this, to replace it with a fork, is so obviously fucking bad form that it's still hard to believe it is happening even given all the other whatthefuckery that has been happening.

ETA: 7) "Secure Custom Fields"? Really? The difference is what?

What the fuck, Matt?

ETA: personally I understand many of the frustrations with WP Engine's positioning. I have experienced exactly the trademark confusion issues that the lawsuit has been about, where clients have assumed WP Engine is WordPress itself. I don't use them after some iffy customer service and technical issues early on. But this is absurd behaviour.

The fucked thing is that per the article, they're not even dedicating any resources to maintain it going forward, they've just made this one fix and are throwing it to other people to maintain if they want:

> Going forward, Secure Custom Fields is now a non-commercial plugin, and if any developers want to get involved in maintaining and improving it, please get in touch.

We have taken on stewardship of this code going forward, and will dedicate engineers to it. Probably more than Silver Lake does.

So, the ACF plugin is a useful contribution to the WordPress ecosystem? Significant enough to warrant bringing it in-house now? Is work on it included in your assessment of what WPE contributes?

Why don't you mention this in the post at all?

Your shift of signifier here from WP Engine to Silver Lake is interesting. Clever tactic, private equity money is BAD! Unless it’s… I dunno? Black Rock p/e money?