3 ms·

They replaced ACF with a forked version so the functionality is still there. That doesn't excuse it but the situation is not so dire for users.

by wmf 2y ago

GenerocUsername 2y ago
Asking for a friend... What's the migration path to a different plugin look like? Seamless? Better be duckin seamless
- CodeWriter23 2y ago
  Tell your friend to get ready to jump to the next thing.
- mattrad 2y ago
  You don't need to migrate from ACF to a different plugin, you can still access ACF and received future updates indepedent of wordpress.org. See https://www.advancedcustomfields.com/blog/installing-and-upgrading-to-the-latest-version-of-acf/ https://www.advancedcustomfields.com/blog/installing-and-upg...
- wmf 2y ago
  https://dorve.com/blog/ux-news-articles-archive/wp-forks-acf-to-create-scf/#first_scf_analysis_similarities_and_differences https://dorve.com/blog/ux-news-articles-archive/wp-forks-acf...
noapologies 2y ago
There are examples of things breaking in this very comment section [1]. Given how widely used ACF is, it wouldn't be surprising to learn that a lot of weekends were ruined by the "fork". [1] https://news.ycombinator.com/item?id=41830709 https://news.ycombinator.com/item?id=41830709
- sgdfhijfgsdfgds 2y ago
  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.

They replaced ACF with a forked version so the functionality is still there. That doesn't excuse it but the situation is not so dire for users.

by wmf 2y ago

They replaced ACF with a forked version so the functionality is still there. That doesn't excuse it but the situation is not so dire for users.

GenerocUsername 2y ago

Asking for a friend... What's the migration path to a different plugin look like? Seamless? Better be duckin seamless

CodeWriter23 2y ago
Tell your friend to get ready to jump to the next thing.
mattrad 2y ago
You don't need to migrate from ACF to a different plugin, you can still access ACF and received future updates indepedent of wordpress.org. See https://www.advancedcustomfields.com/blog/installing-and-upgrading-to-the-latest-version-of-acf/ https://www.advancedcustomfields.com/blog/installing-and-upg...
wmf 2y ago
https://dorve.com/blog/ux-news-articles-archive/wp-forks-acf-to-create-scf/#first_scf_analysis_similarities_and_differences https://dorve.com/blog/ux-news-articles-archive/wp-forks-acf...

noapologies 2y ago

There are examples of things breaking in this very comment section [1]. Given how widely used ACF is, it wouldn't be surprising to learn that a lot of weekends were ruined by the "fork". [1] https://news.ycombinator.com/item?id=41830709 https://news.ycombinator.com/item?id=41830709

sgdfhijfgsdfgds 2y ago
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.