sgdfhijfgsdfgds

Yeah.

I don't know off-hand what the rule is for plugin updates, actually; I'd have to look it up.

As far as WordPress itself is concerned, the updater definitely does not auto-push updates to major WP versions by default [0], and they continue to patch older versions for a long time.

But at any rate, whether the plugin updates respect SEMVER or not, Matt/WP.org pushed this bullshit out as the most minor of minor version number changes over the previous ACF version: 6.3.6.2.

https://wordpress.org/plugins/advanced-custom-fields/advance... (scroll down to the bottom and you can download the previous version to diff it)

So as far as the poor benighted plugin updater is concerned, it's just a change to the display name, which is inconsequential.

[0] WP Engine do, ironically, on a pretty short timescale!

Looking at the code, it's not clear to me how much has broken because of the fork, and how much has broken because of the "secure context" security patch that ACF have apparently also applied in their own version.

That is, I think some of these things might have broken even with the real ACF.

The main change appears to be that if a developer has used a built-in wordpress function as a filter hook (rather than a user-defined one), that has been blocked. (This has never been a good idea, anyway; developers should not do it.) Also a filtered version of the POST variables has been passed to the callback. These are both seemingly to stop CSRF attacks.

This patch was necessary; it prevents CSRF and potentially other nasties.

I don't mean to excuse any of the other bullshit; I'm just saying that if there are "breakages" here, they are likely to do with the necessary patch that is hidden inside the gaslighting.

Wordpress has a (highly effective) auto-updates mechanism for security patches.

It was extended a couple of years ago to automatically apply plugin updates for you if you opted in, and I think automatic plugin updates may now be the default.

(This is on balance a good thing; almost all WP vulnerabilities are outdated plugins, and until this mechanism was prevalent, WordPress occasionally had to live-patch existing installations of third party plugins in the case of severe vulnerabilities.)

The reason this nasty little takeover worked is that they (Matt, whoever helped) have stolen ACF's slug (advanced-custom-fields). So as far as the updater is concerned, it's just another plugin update to the same code base.

And in fact, very little has changed.

> This is particularly bananas as ACF is basically table stakes for doing anything beyond blogging.

Not sure about this.

I'd assume most Wordpress sites that make actual money are dependent on WooCommerce and Easy Digital Downloads, and maybe Gravity Forms/WP Forms for member subscriptions.

None of these are reliant on ACF, and there's any number of WP plugins like this that do the whole job of some website niche or other.

(I've been doing bespoke WP builds for at least a decade -- first one probably more like 14 years ago actually -- and I've not used ACF a single time. There has always been an alternative, and for a developer it's a bad choice.)

Either way: I don't think ACF's popularity is the major factor here. It's that it's an outright abuse.

The word "gaslighting" gets overused but it applies quite well to what ACF free plugin users are experiencing here.

As to "blew up": I am not sure how many money-making ACF users this has affected, because they tend to use ACF Pro, which is a separate download.

What appears to have been removed from ACF to make this shady SCF nonsense is the upsell marketing. Not sure what other breakage there would/could have been. I have seen people say things have broken but I suspect they are relatively minor issues caused by the actual ACF security patch which is also shipped here... because they haven't changed much.

Though if Secure Custom Fields is getting the blame for the breakage, that's kismet, karma, whatever you want to call it.

> The standard "LAMP" stack, for example, has Apache in it for the actual server, talking to PHP using a CGI interface. So if your PHP script crashes or hangs, the server itself is still up, and capable of serving other clients.

Not exactly... the standard, typical LAMP stack makes use of mod_php, so the PHP engine is in-process with one of the Apache process.

The fact that Apache has multiprocess/hybrid workers is actually why the server stays up and can serve more requests.

Some contemporary LAMP stacks use FPM, I guess; most of those in shared hosting ISPs for example because of the possibility of running the script as a user process.

Yeah. I'm a long-time WP site developer. I actually really like Gutenberg (which a lot of critics seem to be suggesting is the first thing that should go in a fork). I'm broadly supportive of e.g. bringing WP-GraphQL and its developer in-house, of adding ACF-type functionality to the core, and even of working to persuade WP Engine to be slightly better citizens.

But I can't shake the feeling that to a lot of observers, this latest thing is going to look rather like a kidnapping. It's not right.

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.

First off, no, it did absolutely not do the same thing. It was a polemic question, sure, but it was a specific criticism of a technology and its proponents.

I did not make any claims about myself at all, until I was separately accused of being something or other by someone projecting onto me whatever it was they needed to feel better about themselves.

Second, you have rate-limited me with the "posting too fast" thing so I couldn't reply to your comment or other ad hominem, even though I was posting at a rate no faster than the discussions about OpenSCAD and FreeCAD I had been involved with earlier (considerably less, I would say).

It's IMO really classless to use your administrative privileges to silence people after you accuse them of something but before they can respond, but I am not surprised to see that.

I will repeat again: I think it is really clear to me, and really to everyone I have me outside this bubble, that there is no fine distinction to be drawn between content generating AI projects that are "good" and those that are contributing to "slop". It's all slop-generation; e.g. NotebookLM is no better or cleverer than Midjourney.

Every tool HNers are excited about is going to be used to make the world's culture, and the web, worse.

I'd encourage you and those reading to consider this.

Sure, you can't make much of a change by yourself. But you don't have to be part of what amounts to inflicting automated cultural vandalism on an unprecedented scale.

Goodbye.