feat: add migration tool for ACF hidden layouts

[arnespremberg]

This is an attempt to migrate from this plugin to ACF's native "Deactivate layout" feature.

• Adds an admin page for the migration process, including options for a dry run and displaying results.
• Updates the ACF_Hide_Layout class to include the file for the migration tool in the admin context.

The UI could be improved somewhat. I also did not test this on more than a single instance, especially not on a multisite. Will keep testing and keep updating. Happy to receive feedback!

[arnespremberg]

A few more thoughts here:

• I prefer to register a tool page for this so it can be triggered deliberately by users, after running a dry run. Obviously clutters the backend for a fairly minor feature, but I'd expect users to disable the plugin after having run the migration. Please excuse the layout tool page itself for not being stellar, it was mostly prompted together.
• I am 90% sure this solution will not work with nested flexible content layouts, and I am not sure if we want to support it. Could make sense to add a note on that

[steffenbew]

@arnespremberg Thank you very much 🙏 We'll review and test it!

[arnespremberg]

Hi all, I just tested this on a multisite. Needs to be run on every site separately but works fine.

[mjot]

@arnespremberg Thanks for showing your migration code.

I have three things that should be known when using the migration code:

1. Only regular posts are scanned
   get_posts() over public post types won’t catch layouts stored via ACF in options, term meta, user meta, or non-standard post statuses. Those hidden layouts will remain unmigrated.

2. Nested flexible layouts aren’t migrated
   The code inspects only top-level flexible_content fields from get_field_objects(). Flexible fields nested inside a repeater, group, or even another flex are never visited, so their hidden flags won’t move into _layout_meta.

3. minor - "updatedPosts" is incremented per field, not per post
   $summary['updatedPosts']++ sits inside the field loop, so a post with two flex fields is counted twice. The success message (“%d post(s) were updated”) is misleading.

I am currently testing a DB-first approach: search all legacy keys *_acf_hide_layout directly in postmeta, termmeta, usermeta and options, aggregate the indices per context + field name and then write the native structure once via acf_update_metadata_by_field(...).

Before that I tried to go via the registered field groups, determine all flexible_content fields (incl. nested) there and then search/migrate for *_acf_hide_layout only for these field names. The advantages would be to migrate only active fields, with the disadvantage to keep possibly orphaned meta entries (fields deleted).

[arnespremberg]

Hi @mjot thanks for the thorough review and feedback. I believe that especially the Options might be an issue. Since we don't use Flexible Content outside of regular post types I successfully migrated our client's websites using this tool. Given your concerns, I'd leave it to @steffenbew if he wants to implement this solution or a similar approach, or one of the others you described.