For those who are interested;
I made an ACF cleaner plug-in, which cleans out those thousands of empty / orphaned database entries, created by ACF.
I created the plug-in for my own workflow (I want a clean database, not filled with useless, empty, orphaned revisions) so it may not suite everyone (see README.md on GitHub for the details).
I was looking for it as well;
ACF is great, but it really meshes up your database.
It even creates empty records (two for every entry) of empty values and it’s revisions… when you save an empty value and do some revisions on the same page, your database will explode with useless entries.
The project started as a stand-alone script (outside the WP environment), than I decided to run it by cronjobs, after that I realized it was more easy to wrap it into a plug-in.
So that’s why the code is a mix of plain-vanilla PHP and some WP-API’s 🙂
The only restriction is that your field-ID’s are prefixed with “ACF__” or “acf__” because I use this as an identifier for the queries.
Feel free to port; it’s completely open source.
Personally, I don’t really worry about the database and the empty entries unless it’s causing some type of a bug or issue with proper operation. The WP database is properly optimized and empty values will not usually cause any performance problems. But I have seen people as how to get rid of the empty values and it will help me to give them a place to go rather than tell them how difficult it is to add.
Well, I don’t care about “some” useless entries 🙂 but your database can really become huge, when not cleaning up some stuff.
I am now adding a new feature to this plug-in (so you can use it without a fixed prefix) and (as a test) deleted one ACF field… I ended up with over 60 orphaned entries…
So I am happy with the option to delete those records – when I delete a field, I also want to delete the values (I realize this is not for everyone, but I want to have the choise).
Well, technically that’s an error 🙂
The page / URL should be something like this;
And the page requested should be on your server (check it by (s)FTP) like this;
Of course the last part (/wp-content/…) is the most important for now.
That’s kinda weird…
Is the plugin menu-entry nested inside the tools-sections, like this;
Or not at all?
Maybe it’s a conflict with another plugin?
The issue you describe looks a bit like this (solved) one;
I will update the README.md file with this manual 🙂
Please, keep in mind that the plug-in works best when there is a solid “prefix” for your ACF-entries in the database.
Something like ACF__logotype / ACF__reviews / ACF__4901-31A, etc…
When you do not have a consequent prefix, the plug-in is unable to find all ACF-fields available.
Yes I noticed that, with my luck I used very unique names for the two fields and it’s discardable fields after the post is submitted we don’t actually need to store the information AND the new fields are new, they literally have a new naming convention/group so I could clean up like 100k of them no problem.
Thank you again!
I don’t think the plugin works (properly?) for flexible content.
We make heavy use of flexible content, they are called “flexible_content_”. Under those we have ‘content blocks’ that make up the content, but many of those content block fields can be/are empty.
So querying all “flexible_content” resulted in 250.000+ results, however they are almost all classified as Orphans, when they’re not and still being used on many active pages. Barely any resulted in ‘Empty’.
Testing and deleting the orphans resulted in many of the content being deleted (test environment, no problem).
It’s also a multisite but I doubt that is the issue, the plugin successfully identifies the table and prefixes.
You must be logged in to reply to this topic.
Welcome to the Advanced Custom Fields community forum.
Browse through ideas, snippets of code, questions and answers between fellow ACF users
Helping others is a great way to earn karma, gain badges and help ACF development!