Hello,
Thanks for the feedback!
As you mentioned, this is an old topic in the ACF community. First, I would like to tell you that I totally understand your point here. I worked as a lead developer in a WordPress agency where we heavily relied on ACF for our clients websites, before going full-time on ACF Extended. So yeah, I experienced the examples you mentioned.
TL:DR
This feature will come in the next ACF Extended release, which introduce a new module called “Scripts UI”. This new module allows developers to run any kind of script on dozens/hundreds/thousands posts without server/DB restriction.
The module is packed with 2 useful builtin scripts, which include a “Orphan Meta Cleaner”, as mentioned on the Trello Board.
Additionally, note that it will be possible to clean orphan meta from each posts/terms/users/options pages individually, with the upcoming enhancement of the Developer Mode.
Long story
I also thought the same while developing websites with ACF, and while it looks insane that there is no native feature to do such operations, the more I worked on ACF Extended (and by extension the more I learnt from the ACF source code), the more I understood why it is not in the core, even after 7 years. I will try to explain the reasons, in my opinion, and I will try to not be too technical because this topic is related to many aspects of both ACF & WordPress logic. Before starting, some few notes:
- Other plugins have similar logic and never clean post meta left behind
- WordPress doesn’t provide any solution to make this operation easier
- Deleting data is always a sensitive topic, as it can lead to unwanted data loss
The first major issue here is that there is no way to deal with mass deletion in WordPress, as such operations depend on server limitation (allowed execution time, resources needed etc…). While it can be pretty easy to cleanup data on dozen of posts, it’s a completely different topic to do it on hundreds or thousands of posts. As explained earlier, the server will probably throw an error as the execution time will be reached pretty easily. You can try it by yourself, simply delete hundreds of posts at once from your admin UI, you’ll see that you’ll receive an error.
In the case of ACF, a solution would be that if a user delete a field from a Field Group UI, and save the Field Group, ACF would go thru all Posts, Terms, Users, Options Pages, and look for the said field to delete it. This could lead to very heavy DB requests on large websites. To get around that problem, ACF could delegate that task into splitted background processes, so the deletion are made without the user even noticing it. But that solution is far more complex to implement, and WordPress doesn’t provide any native framework for such case.
Assuming ACF goes that way, it would not be compatible with the Local Field Groups declaration which are widely used by advanced developers on large websites. If a developer delete a Local Field Group in PHP, ACF would not be aware of it, so it couldn’t launch the deletion process. To get around that problem, ACF could return the logic upside down, and start from the Posts, Terms, Users, Options Pages instead from the Field Group UI. But even there, it is facing a new issue, as metadata saved on each posts are tied to field groups, but not to the Field Group Location logic.
For example, let’s say you create a Field Group on the Post Type “Post”. You create few blog posts with those new meta, and then decide to change the location of the Field Group and move it on the Post Type “Page”. The deletion would not work in that case since the field still exists in the Field Group, but isn’t valid on that specific “Post Type: Post” location. That means we have to add an another level complexity in the deletion process, and check if the field is supposed to be displayed on the blog post or not. Here there is a major issue, since ACF doesn’t have any way get the location validity of a field individually (this is due to internal logic of field group display, saving process etc…). On top of that we have to deal additional edge cases, like the Clone Field which allow to clone a Field Group that is independant of that “Location” validity logic, since any field that can clone anything (a field group with an another location rule, or an another field).
Anyways, I won’t go deeper in the rabit hole, I think you understood it’s a really complex topic, and that’s probably why it’s not part of the core.
I hope the answer will be informative for you, and any other ACF developer who come by 🙂
Have a nice day!
Regards.
