> This update is as minimal as possible to fix the security issue.
> This is a rare and unusual situation brought on by WP Engine’s legal attacks, we do not anticipate this happening for other plugins.
So.. is this fixing a security issue.. or is this because of WP Engine?
> and are forking Advanced Custom Fields (ACF) into a new plugin
And stealing their place in the plugin store. A fork generally implies that you are going to set off on your own, and not inhabit the dead flesh of the project you just killed.
Matt Mullenweg is the biggest child I have ever seen in operation.
> So.. is this fixing a security issue.. or is this because of WP Engine?
AFAIK, here's the timeline.
1. Automattic announced that there was a security issue in ACF.
2. WP Engine fixes it immediately.
3. Automattic bans the WP Engine developers from Wordpress.org, so they can't deploy the fix. This places millions of users at risk, but that's how they roll.
4. Automattic forks ACF, removes the commercial upgrade, and renames it.
So WordPress-the-org — which is effectively Matt, as far as I can tell — just Sherlocked a developer's plug-in using the developer's own code, ostensibly as retribution for a security issue that the developer had already fixed. https://www.advancedcustomfields.com/blog/acf-6-3-8-security...
That ACF security update was not made available on WordPress.org due to ACF maintainers being blocked from accessing WordPress.org, according to WordPress.org's blog https://wordpress.org/news/2024/09/wp-engine-banned/
Forking isn't the issue. Here they just took the whole ID/address from which existing installations will continue to be updated from. This is theft. I have no doubt it will be added to the lawsuit.
While technically they own the platform and can do whatever they want, there is clearly ill intent here and it'll be used against them.
They kept the permalink afaik, which is probably still likely to cause confusion in the marketplace and may still be a trademark issue.
Without knowing this drama, if I found and clicked an ACF link on a 2 year old Reddit post and ended up at Secure Custom Fields, I’m not sure I’d know it wasn’t by the ACF folks. Just their branding for the v2 or whatever. I think customers have a reasonable expectation that permalinks won’t take them to unrelated products.
Yep. And the string 'acf' is used throughout the plugin and the plugin download page (in reviews, etc). And 'acf' is indeed a pending trademark registration.
Or, more blatant and accurate, Sherlocking is when Apple literally named their search product "Sherlock" when a popular third party shareware app named "Watson" already existed.
Unfortunately you have no proof of that, because the only relevant changes are actually neither introducing fixes, nor ever changing the plugin core code in a way that fixes security issues.
The only thing done is removing a LOT of references, links, and instructions that would remind of WP Engine, as well as all compatibility with the POR features.
However, these are no fixes. You just introduce a new variable, that you never use, and re-assign the same contents of that new variable back to the $_REQUEST
Unless you show proof of a security fix - which you could have pushed to users WITHOUT renaming the plugin, WITHOUT removing original, non-security related code, and WITHOUT breaking compatibility with the PRO features - you have LIED and STOLEN code in the name of WP.ORG
This will hopefully be recognized by WP Engine and if god wills, remove you from the equation once and for all legally speaking.
> However, these are no fixes. You just introduce a new variable, that you never use, and re-assign the same contents of that new variable back to the $_REQUEST
While this whole takeover thing is completely ridiculous, it's you who displays an "inexperienced eye" here. What do you think the $original_post variable (which was already there) is doing, huh?
The same. Nothing. The “security” issue here would be that the user callback can access post and request data. Tell me one place in the entire wp code base where that is NOT possible?
Security issues can be fixed WITHOUT renaming the plugin or removing links and text even if the original author has no access anymore
And that “fix” is ridiculous. If anything it breaks code of users who were actually adding callbacks using that data. It’s the nature of php that you can access those details - it’s up to the caller to know what to do with it.
If anything, the usage of user callback is an issue here.
And in any thinkable case this ain’t a security fix that was done.
A security fix would include that and only that change.
For some context how you MIGHT actually “fix” the true security concern in this code:
$allowed_callbacks = ['some_function', 'another_function']; // Example of allowed functions
if ( in_array($original_cb, $allowed_callbacks, true) && is_callable($original_cb) ) {
$return = call_user_func($original_cb, $post);
} else {
// Log or handle invalid callbacks safely
$return = false;
}
Tampering with global variables or else is NOT a fix, and this one in particular is like pointing out a crumb on the child’s mouth and grounding it for not brushing its teeth.
You could apply a filter to allow filtering the allowed callbacks, if you really want to allow more than the hardcoded whitelist.
In the end it still boils down to “do not use user callbacks” as the better security fix, which again shows how “they” didn’t fix a thing here. This is a blatant excuse for legal CYA.
If the codebase was built on the assumption that user callbacks will execute in a context where POST data is sanitized (which is evidenced by the code that was already there), then failing to sanitize $_REQUEST in addition to $_POST is certainly a security issue.
Of course, relying on such simplistic measures is still brittle and inelegant, but that's another matter. Reworking it would likely be quite invasive to that codebase and far beyond the scope of a security patch.
(also, frankly, the entire WordPress ecosystem isn't particularly known for its high quality codebase... this kind of "fix" is exactly what you'd expect there even without all that drama around)
> Security issues can be fixed WITHOUT renaming the plugin or removing links and text even if the original author has no access anymore
Not sure who you're arguing with there, but certainly not with me.
You have plenty of shitty behavior to call out there, so not sure why you decided to announce that there's no security issue being handled at all instead. It only makes your point weaker for no good reason.
If anything, the problem here is call_user_func, which when an attacker HAS ACCESS TO THE CODE, can be dangerous.
How on earth does emptying POST or REQUEST solve anything at all in regards?
How on earth does, no matter what crap ACF added BEFORE the takeover, this "Fix" justify a hostile takeover? If or not there is a security issue with this code (which there IS, but not with POST or REQUEST data) is not even the matter anymore - it was and is posed and defended as a "urgent action to fix a security issue in a plugin the author has no access to"
And I repeat - there has not been any security fix!!
Read my root comment:
> because the only relevant changes are actually neither introducing fixes, nor ever changing the plugin core code in a way that fixes security issues.
And I stand by that. Anyone reading this code can see it.
Why do you not actually provide some researched facts?
I mean, I am all ears to stand corrected. Yet it appears all you (and other automatticians, and/or else employees) can do is deflect and talk down pretending you know better. Do you? Then teach your fellow humans where they are wrong. So far, I still have not been proven wrong about this pretended fix, which fixed nothing at all.
I don't intend to defend Automattic's shitty behavior at all, it's indisputably shitty and I take offense at your suggestions that I may think otherwise, as I never gave you any reason to believe that.
That said, you clearly seem to be confused about the nature of the issue being fixed there. It's clear from the existing code that the contract between this function and the callback getting executed is that the callback is expected to execute in a kind of a sanitized environment with restricted execution abilities.
You can argue that it's a really weak sandbox and that the whole design is smelly, and I'll agree with you. However, that's how this code was designed and that's what users are running on their servers, and that's how they expect it to behave. It prevents the callback from calling functions with `wp_` prefix and it disallows it from reading or making changes to user's POST data.
Now, if you find a way to circumvent those restrictions, it's an obvious security issue. Someone may have deployed some code that relied on that contract, and now that contract is known to be invalid (it always had been, but it wasn't known before). Therefore, stopping that from happening is a security fix.
It may be a poor fix - and in fact, this one is, as it's incomplete. But it's a fix. The upstream project recognized that and applied a similar, but a bit more thorough approach in its repo:
It does exactly what the change we're discussing does, plus a bit more.
You still wouldn't convince me that it's a bulletproof sandbox and I already have some other ideas in my head on how it could potentially be circumvented after reading that code (though my PHP is so rusty I may very well be wrong), but the change in question is clearly a security fix, recognized and applied by both Automattic and WP Engine and I really can't understand why you're so keen on implying otherwise. As I already said, it only made your other (good) points seem weaker.
Thanks for the reply.
Actually that code (I mean the one where they started clearing POSTed data) was the "fix" WPE rushed into during the "grace period".
The contract existing before, was that you throw in a user callback in a backend input and it executes that. It still did that after the rush fix (which was committed by Otto, but supposedly delivered to him by WPE), but with some more clearing:
- POST is cleared
- registered functions with wp_ are cleared
call_user_func was still called. Clearly, the idea behind is is not "some kind of sanitized env" since the start.
The idea was "the user can throw in a callback and it will be executed".
Then someone said "but that is unsafe" (And it is!)
But the unsafely thing here is not "You have access to POST data or wp_ functions".
That is the default in ANY code attached to WP anyway, and while being part of the danger here, the real danger is that an arbitrary POST EDITOR can throw in a callback and it executes that.
Which is why, yes, somehow, clearing posted data and excluding already existing methods like wp_ stuff is sort of a "fix" for that, since before the Post Editor did not even need to write the callbacks code: he could just have called a eventually bad (in context) registered method in core. So the "fix" does somehow mitigate, but not fix the issue.
I can see upstream builds on that idea even more. However the code still uses user callbacks, and those user callbacks can still be unsafe. You just need to throw in a callback that does something malicious, which does not even be an obvious malicious code. It could be a callback registered elsewhere, where the else context makes sense and is not flagged, but in conjunction with this ACF feature, would be malicious.
It should be clear that the security issue here is not what you can access during that callback - the security issue is that the callbacks are not whitelisted, and/or allowed at all (which can be considered a problem too, but would break potency of the features of course if removed)
Not putting my hands in fire for this, but I believe there is reason I Could not find a CVE yet for this alleged security issue, only a reserved one. I suspect that is, because the issue is still there, and publishing it, would immediately render it more dangerous.
I again would love to learn that I am wrong here.
I do stand by my original post that said:
> because the only relevant changes are actually neither introducing fixes, nor ever changing the plugin core code in a way that fixes security issues.
This stands true: the security issue was not fixed. If we start to call incomplete fixes a fix, then we can as well call anything anywhere a fix. Heck, I moved around some lines and cleared some of the data. It's fixed! That would never hold true. In all and every case, plugin review team would immediately review the FIX before you can even say "but", and they would immediately throw it back at you, asking for an _actual_ fix. Especially with call_user_func.
This has not happened here at all, which just adds to the fun of the day.
I feel the discussion should evolve around this, and The Guys who yelled "Security" should come forward and explain to the public what they actually fixed, if they truly believe this fixes the issue, if they truly believe that ACF (sorry, SCF) is now _safe_, or not.
My point stands that it (the core issue) has not been fixed.
You also said "you added a few irrelevant changes that to the inexperienced eye look like security fixes", and that was the part I objected to. "You just introduce a new variable, that you never use, and re-assign the same contents of that new variable back" causes more confusion to an inexperienced eye than that code could ever do.
The real danger is that an arbitrary post editor can throw in a callback and it gets executed unsanitized. Having a proper sandbox would be a perfectly valid solution - in the end, that's the whole modus operandi of the web browser you're using to write these comments. And yes, I also have doubts whether the implemented measures are nearly enough to actually sanitize the input; I'm also not sure whether you can sandbox that feature properly without making it effectively useless - and while neither of those justify Automattic's behavior, it's a different accusation.
I think we might agree - and my original wording was tainted by emotions.
- indeed, there was changes in code that can be sold as “attempted security fix”
- indeed, as I think we both agree, the main security issue still needs attention to this very day
So far as I can tell, when Matt talks about "the WordPress Community", he means:
- Matt
- the people who didn't quit Automattic last week
- _maybe_ the WP core developers who don't work at Automattic, so long as they keep their criticisms to themselves
And the community of people who _use_ WordPress to run their websites, and the people who help them to do that, and the 3rd party plugin and theme developers who make WP work for so many different kinds of websites - can all go and get fucked.
The maintainers [1] and the Wordpress project’s core security team lead [2] said that the fix was already published, despite your blocking them from publishing it directly and irresponsibly disclosing the issue out of spite [3].
ACF isn’t a premium plugin (linked post only concerns those).
The linked post also might not reflect the current policies. This update was a security update and was done due to the unique circumstances around the original publisher.
The correct information is that your employer created the security problem as part of their shakedown attempt. They then banned the WP Engine developers from Wordpress so that they couldn't update the plugin. Now they've forked the plugin, removed the commercial upgrade, and renamed it.
I'm not sure where values come into it. I'd be ashamed to work there.
"It is difficult to get a man to understand something, when his salary depends upon his not understanding it." -- Upton Sinclair (probably, may be apocryphal)
For sure dude, the guy who came here to defend the values of his own and his megalomaniac employer on a weekend evening is probably much too busy to name one. That tracks.
It still uses trademarks from ACF, those are obviously not "open source", which also has been Matt's & wordpress.org's stance since forever: the _code_ is GPL, but the assets are not.
If you "fork" the assets, you're not covered by GPL.
Obviously it's nonsense to discriminate between the free version of a freemium plugin and a commercial plugin and this is simply a stupid way to lash out.
If anyone from Automattic is reading this and would like to confidentially leak any internal information about this behaviour from Matt, please email admin@bullenweg.com and I will publish it on bullenweg.com.
Matt you propably don't remember me but we met briefly on WordCamp Vienna 8 years ago. I was hugely inspired by you for many years and still was until few weeks ago.
I have been unable to convince Jason Bahl to share the ~threats~ ~coercion~ terms you used to convince him to join Automattic. Your contribution via GitHub of the terms that you used to ~coerce~ persuade him into defecting would be appreciated.
Hey Matt, you're behaving like a normal abuser who's successfully managed to mask up to this point. None of your behavior is clever. If you continue down this path, it's not going to be good for you.
This is one of the sleaziest things I've ever seen. I fear a hard fork of WordPress is now inevitable and unfortunately, it's possibly going to kill the platform, all over one man's ego. How can I now sell my clients on using WordPress for mission critical things if on a whim the owner of WordPress can break my site or lock out my security updates, just because I chose the "wrong" host or plugin? I don't see how the Board can sit by and let this all unfold like this, it's practically business suicide.
TBF WordPress was also created by two men and one of them was Matt. Of course it only achieved it's success through efforts of countless others, but it's not just some person. Shame, it came to this.
We had hard forks of very popular systems before, e.g. xfree86 turned into x.org, LibreOffice vs OpenOffice.org, Hudson to Jenkins and others and basically everyone switched (nearly) overnight.
Fork will likely have a much better direction structure to avoid precisely this problem, at least it seems to be the pattern.
Wow, I hadn't heard about the nosebleed incident. Absurd, even if he ain't snorting coke, it's deeply weird to continue an interview while profusely bleeding as if nothing is happening.
I have no stake in any of this but some people have nosebleeds without anything nefarious or bad going on. This guy doesn’t need any help looking bad, suggesting that his nosebleed is important is stupid.
It's not the nosebleed in itself, it's the ignoration of the blood streaming down the face during a video interview that is the most curious. And it wouldn't be as relevant if the subject hadn't acted increasingly erratic and self-destructive at the same time period.
It's not "important", it's just deeply weird, because it tracks.
I sometimes get nosebleeds. There's no pain involved - it just feels like a slightly runny nose until either you wipe it or blood starts dripping into your frame of view. I get them a lot in low humidity.
I haven't watched the video, but if it's a small amount of blood it's perfectly possible he just didn't notice.
Him being in the middle of a mad coke bender would explain so much. I'm accepting this as canon until we find out WP Engine slept with his wife or something
> There is separate, but not directly related news that Jason Bahl has left WP Engine to work for Automattic and will be making WPGraphQL a canonical community plugin. We expect others will follow as well.
Anything to prop up their position and throw the company they are attacking under the bus. What a jerk.
The support notice got deleted[1]. The plugin developer got banned. Blocking access from certain ip. Shady or problematic hosting term[2]. I think hosting your code on wordpress.org is considered dangerous.
The diff contains two (identical) changes that aren't just ripping out upgrade notices for the pro version: Two functions that stop callbacks from accessing $_POST now also stop them from accessing $_REQUEST, which also contains everything in $_POST. Also confirmed by WP Engine's update notice[1].
I honestly don't see why anyone would treat this as a security issue. Everything involved is PHP code that can do whatever it wants, not in any kind of sandbox.
Edit: And even if it were this update doesn't fix the problem. POST variables can still be accessed:
Though, Automattic posted publicly that there was a vulnerability shortly after filing the CVE, while simultaneously blocking WPEngine from being able to push a fix to it because they'd cut off access to wp.org
I can’t find the actual number because Automattic’s tweet[1] announcing it has been deleted, but it’s the one mentioned in the ACF 6.3.8 release notes[2]. The authors of ACF can’t upload that version to wordpress.org themselves because Matt banned them from there before making the announcement.
ETA: Matt says[3] it’s a different vulnerability. Anybody willing to break out the almighty diff?
> The use of trademarks or other projects as the sole or initial term of a plugin slug is prohibited unless proof of legal ownership/representation can be confirmed
> What happens to a plugin if the plugin owner gets blocked?
however the page says "Last Updated: 12 October 2024" and https://github.com/WordPress/developer-plugins-handbook/blob... (permalink at the time of writing this) doesn't have this section. So it really looks someone manually edited the page on wordpress.org without editing the source. Now, who has such permissions and has the motive to do this?
I feel so bad for all the Wordpress devs and shops right now. This is not the kind of community turmoil I'd want to deal with leading up to holidays/new years!
It makes Drupal 8/Backdrop seem like a pleasant and wonderful experience, in comparison.
I don't think there was any bad blood between Drupal 8 and Backdrop, was there? It was forked in 2013 and look https://www.drupal.org/u/jenlampton Jen was still doing BADCamps and went to DrupalCons and all that. My memory is fuzzy a little but I do remember we were making huge progress on migrate at BADCamp 2014 and I do not remember a single tense moment with Jen or Nate. Or was that 2013? But even if it was, that was after the fork. Nate also went to DrupalCons look https://www.drupal.org/u/quicksketch
In short, I know I considered Backdrop futile but I don't think there was any significant controversy or is my memory failing me? http://www.drupal4hu.com/node/380 here's my post from the time.
Truth to be told there was significantly more controversy between me and the rest of the Drupal community than Backdrop and Drupal. You can not imagine how much I regret that.
True; I'm just thinking back to the absolute worst drama I can think of in Drupal land, it all pales in comparison. Most of it was misunderstandings that were subsequently sorted, or like Backdrop just a friendly fork with community connections still intact.
Well instances were both painful but in my mind mostly affected a few core groups of devs, and a lot of the community was oblivious to anything going on. The Drupal 8 migration and subsequent forking of D7 into Backdrop caused a lot more consternation with smaller agencies especially.
I mostly did Drupal stuff with local and regional camps at the time, I was hired at Acquia slightly after, so I remember a lot of pain back then, especially as Wordpress and Drupal were often considered in the same meetings when building small local sites for nonprofits, small businesses, etc.
Nowadays it seems Drupal isn't part of the conversation unless there's a C-suite at the place building the website, it's moved upmarket quite a bit.
It sure did. Dries cashed out thanks said upwards movement and then he realized this move destroyed the contributor pipeline (make a personal/charity/etc small website-tinker Drupal-contribute to Drupal) and also market share so he now tries to move it back down with Starshot. I wish him the best.
Pathetic. Matt banned one of the most popular WordPress plugins. Then, he forked the code and hosted it on WP.org, which is against the Terms of Service. He also hosted it in the plugin directory on the same path as ACF, stealing its SEO traffic. Wow!
Matt's state of mind is clearly not good. If I were an investor in WordPress, I would start thinking about cutting my losses. WordPress will not recover from this self-inflicted destruction
*Update*
Oh, it's worse than that. He just renamed the ACF to SCF and claimed all the installations and reviews from ACF. I still can't believe this happened. This can't be legal!
Eventually you are going to have to confront that the distance between 'technical correctness' and 'moral correctness' is vaster than you apparently think it is.
Have you read them? Both are in pending status and not registered. "Advanced Custom Fields" most recent update before a last minute extension to respond to final notice was for: "Merely Descriptive Refusal - Registration is refused because the applied-for mark merely describes the function of applicant’s goods
and/or services."
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.
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?
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?
I can't even follow what's going on here, and I used to be an expert in software licensing drama. All I see is a bunch of unilateral actions driven by Matt Mullenweg that breaks so many implicit promises of how a free software steward should behave.
Wordpress sites quite often seen to be a hodge-podge of plugins, each with their own UI and conventions, and (as a host) I'm never an expert in anye one of them. Has one of the site designers used a plugin that has offended Matt? Or that might offend him in the near future? How do I even audit for that?
I don't need much of a push to move my position on this. Before: "eh, use Wordpress if it's cheaper" Now: "please don't, that decision will probably cost me".
Theoretically WPE might be a bad actor-- perhaps even more than any commercial competitor naturally is-- but they're smart enough to not smear it around with absurd moves like this that radiate a lack of professionalism or ability to predict reactions.
A lot of the comments seem to call out Matt (right or wrong). But that’s the easy thing to do.
No one dares address the systemic issue of for profit corporations exploitatively (ab)using open source software.
There is a social contract that people should contribute back, and while it’s largely unenforceable, as it should be, when it’s happening on a systemic level something has to be done. And we are all complicit if we don’t at least say that much and spare some good will towards the guy actively in that fight at least superficially
*Following is a response to some replies on the other thread, that clarifies my points
*
Matt being a poor steward of gpl is by definition not a systemic issue … unless ur claim is that many people in positions like him do what he does which is in turn caused by invariant factors?
The systemic issue is companies the world over not giving their fair share back in terms of contributing to foss.
I might agree with most of your points, I’m just trying to get people to realize there’s the local issue of Matt/wp and then there’s this global issue of companies building businesses off foss and not giving back.
> A lot of the comments seem to call out Matt (right or wrong). But that’s the easy thing to do.
It's also productive. If there's enough of an uproar, then the board will remove him. They're pretty much the only people who can stop him.
> There is a social contract that people should contribute back, and while it’s largely unenforceable, as it should be, when it’s happening on a systemic level something has to be done. And we are all complicit if we don’t at least say that much and spare some good will towards the guy actively in that fight at least superficially
You don't speak for me. Contributions to my OSS projects are appreciated, but all I ask is that users comply with the license terms.
If you feel that contributions are an unwritten obligation, he's made them much harder to ask for. Everyone else who asks for them in the future will be tarred with the same brush.
Matt is burning down the WordPress ecosystem because his shakedown attempt failed. He's prevented at least 2.5 million users from receiving security updates. He's earned my contempt, not my goodwill.
> I might agree with most of your points, I’m just trying to get people to realize there’s the local issue of Matt/wp and then there’s this global issue of companies building businesses off foss and not giving back.
I don't know how much goodwill we owe somebody currently being sued for extortion and who lied to a community about ownership of a trademark for over a decade in an attempt to take a whole community hostage when he feels like it's time to cash in. The writing was on the wall when he sold user intellectual property from WordPress.com and Tumblr to OpenAi. Was that fighting for open source?
I think we're pretty far removed from the original issue of WP Engine and WordPress and people are just trying to deal with the fallout from Matt's nuke-the-entire-ecosystem approach he's elected to take.
That was a great article from drupal. It’s a great idea and really goes along way to help, but we still need more.
This only addresses foss projects that are hosted as an offering. It wouldn’t address how for example the pgp guy basically went broke or just the general amount of pressure maintainers of “critical” foss packages are under and are spread so thin, that it’s always a triage fire and there’s never any room to “level up” with rewrites or full code base audits. And a lot of it comes at a huge personal cost but it just so happens the people often times in those shoes end up being super noble.
Maybe this is a cynical take but year after year it really does seem the software we rely on for modern life is just a house of cards where most cards are solo devs or a handful each doing the task of atlas cus the worlds corporations just don’t give back!
My words will ring true in 10-20 years when most of these people kick the bucket or retire and all we have left will be google’s next android| fuchsia and windows server.
Just stealing plugins right now? Or is this some kind of "eye for an eye" situation?
I'm really turned down from the whole ecosystem by this total shitshow. Seems like everything could be pulled from under running sites if some clown decides he doesn't like it anymore.
At this point I just hope that WP Engine wins whatever lawsuit happens and Matt Mullenweg (and everybody who was involved besides him) has to pack his things and leave everything WP-related forever.
We no longer do custom WordPress work --- it turned out to never be worth the hassle --- but when we did, our company used ACF extensively. High quality plugin with responsive support and very fair licensing terms.
It's certainly "high quality" in the sense of "it solves a huge number of requirements that WP core doesn't, in a way that's better that alternative plugins". It's a high quality WP Admin user experience. Just don't try looking too deeply into the database mess it creates.
For WordPress _users_, as in the people who log into the WordPress dashboard to run their website, 'stuck in the past' is often an advantage and not a bad thing. You'll be able to find blog posts and tutorials and youtube showing you how to use in, unlike the "new shiny" where there's no easily found example or support for.
I'm not arguing against its usefulness, not at all. The sites I work on use it as well (and abuse, you really shouldn't do complex things with it), though we're looking into replacing it with something custom because the dev experience is bad and the performance isn't great. But for the average small to medium site, it's great, especially because of what you mention: the standard use cases are super well documented by a million people having gone through them before you.
I wouldn't call it high quality though. 200k LOC even for the free version (I use pro), no OOP, global variables, bugs get no attention unless they're major. It was amazing when it first came out, but it has fallen behind even compared to core + other plugins (and the WP average is a very low bar).
It clearly belongs in core, just like 90% of Yoast's (or AIOSEO's, Rank Math') functionality, Redirection and permalinks, and they should have focused on getting that done instead of gutenberg. But also clearly this isn't the way to bring it into core.
4 years ago it was still great. I had one contact with WPE support since they bought the plugin last year or so and it was the most frustrating support interaction I ever had. It felt like I was writing with an AI that was prompted to drive me crazy so that I would leave them alone.
This whole saga is surreal because I thought myself to be constitutionally incapable of rooting for a private equity firm to win a fight, but this is like watching a guy violently strain to shit his pants while yelling “Look what they made me do!”
Also the guy is in a hot tub with all of his friends and employees
If you were an insider deliberately trying to tank WordPress, it is hard for me to imagine anything you could do that would be more effective than this.
If you look at the reviews, they took over the advanced-custom-fields plugin and modified the owner to be Wordpress.org and renamed it to Secure Custom Fields.
What a terrible look
They also modified it by ripping out the pro features, so if people update their ACF Plugin and they had pro features enabled, it'll just break their install
I'd normally never say something like this, but: seek therapy, man. Seriously. This is not normal. It will end badly for so many people, including yourself. It may not be too late.
I've vouched this comment. I don't think we should be flagging this comment; it's not particularly out of line, and there's a significant interest in the community seeing Mullenweg's comments.
Business is war, I get it. But you chose to make innocent bystanders (your users) life difficult and you crossed a line by stealing code with an excuse that everyone sees through. This looks now more and more of a personal vendetta.
There must be a timeline in which this is de-escalated, compromises are being made and everyone's happy.
In your perspective - what does it look like? What could be done to go the opposite way and keep going?
Also, I'm surprised to see people only siding with WP Engine here. Usually the discussions here are much more balanced.. What do you think could be the reason for it?
I don't think punishing people for suing you typically plays well in court. Especially not if you, you know, publicly announce that's what you're doing.
This was my reaction as well. This sounded like tortious interference before, but to blatantly announce that he’s trying to kill someone else’s business, for exercising their legal rights no less, sounds like a summary judgement waiting to happen.
There is no dispute over the facts here if Matt is just going to announce his intents.
I cannot imagine his rage when not only does WPE not have to pay him, but now he’s paying them.
Most of the world's 8+ billion people managed to go through the last months without shaking down a competitor, preventing users for receiving security updates, conducting a harassment campaign, or destroying an ecosystem because they feel like it. That's not just a mistake. He deserves contempt, firing, and a substantial fine at the very least.
I don’t think anyone wants to lynch him in the sense of harming him for the sake of it, or even retributive justice.
People want him removed from Wordpress leadership to protect Wordpress. The harm to him is really orthogonal to the greater goal of not destroying the software that runs 40% of the internet or whatever, triggering man-centuries of pointless labor to replace it across all those installs.
Given the options of letting Matt tear the ecosystem apart or letting the ecosystem tear Matt apart (figuratively, not literally), the ecosystem should win. It sucks for Matt, but wasting cumulative lifetimes of human effort to migrate all these installs is stupid and not worth saving one man’s ego over.
> This is a rare and unusual situation brought on by WP Engine’s legal attacks, we do not anticipate this happening for other plugins.
So.. is this fixing a security issue.. or is this because of WP Engine?
> and are forking Advanced Custom Fields (ACF) into a new plugin
And stealing their place in the plugin store. A fork generally implies that you are going to set off on your own, and not inhabit the dead flesh of the project you just killed.
Matt Mullenweg is the biggest child I have ever seen in operation.