When updating the ACFML plugin to 2.0 several concerning things happened. I have updated the plugins on two different local instances and the both have the similar issues
- After enabling the ACFML 2.0 plugin a lot (not all) ACF field groups are duplicated.
- Duplicated ACF field groups seem empty
- All sorts of ACF field synchronisation are created.
- The New synchronisations do not seem to respect the clone field?
I am very anxious for updating the plugin, seeing al these bugs. Is there a migration guide or process, for using an existing setup?
Thank you for contacting WPML support, and sorry to hear about the issues after updating ACFML plugin to the latest version.
I have checked the website's debug information, and I can see that all plugins are updated. Could you please confirm which ACFML version you updated from?
Furthermore, would it be possible for you to provide us with a copy of the website before the plugin update? We would like to test the update and see what happened.
We usually recommend the free Plugin “Duplicator” (http://wordpress.org/plugins/duplicator/) for this purpose. I have enabled the private reply for you to provide us with the package and the login details.
Hello there, and thank you for providing this staging site.
This is Jamal from the compatibility team. I have been involved in the development of this new version of ACFML. Let me try to take a copy of your website using duplicator or another plugin, that would help us very much to debug the issue of the update and I'll get back to you as soon as possible.
I am getting back to you to share a patched version of the plugin that should update your website without duplicating the field groups. Please find it here hidden link
Follow these steps to install it.
1. Update WPML Multilingual CMS to 4.6.0, and WPML String Translation to 3.2.4. These version are required for ACFML 2.0 to work. Do not update ACFML at this point.
2. Download the zip file.
3. Go to Plugins->Add New.
4. Upload the file.
5. Click on "Replace current with uploaded" button.
Based on my debugging on a copy of the shared staging site, this issue happens because there is a difference between the ACF fields groups from the theme's acf-json folder, and the database.
As you can see on this screenshot hidden link there are field groups that are fully synchronized("Saved" status), some that needs to be synchronized from the JSON files("Sync available" status), and others that needs to be synchronized from the database to the JSON folder("Awaiting save" status).
There are also some field groups that need to be "imported". Check this screenshot hidden link
To be honest, this is the first time I get to see the "Awating save" status. And it seems to happen if ACF encounters issues writing into the theme's acf-json folder. Maybe this ACF support thread could explain it better hidden link
You may also want to approach the ACF support to get more details about it.
In this ACFML update, we run some code to set the new Translation Option(Expert) for the existing field groups. Read more about this new option here https://wpml.org/documentation/related-projects/translate-sites-built-with-acf/#selecting-a-translation-option
Because of the differences between JSON folder and the database, ACF returns some field groups without IDs. ACFML, then, adds the new translation option to them, and calls ACF to update them. Because these field groups do not have and ID, they get created again which duplicates them.
This patched version will skip any field groups that do not have a valid ID.
I run a test on the staging site you provided, and it did not duplicate any field group. However, it did inactivate a field group, and it did synchronize other field groups.
Before the update: Field groups were: All (51) | Active (23) | Inactive (28) | Sync available (29). Check this screenshot hidden link
After the update: They become: All (51) | Active (22) | Inactive (29) | Sync available (19). Check this screenshot hidden link
So, you may need to reactivate the inactivated field group, or probably synchronize the field groups before updating ACFML. I believe you should check this with your website developer(s).
This being said, I'll ask you to try again on a new staging. And let us know your results. We'll be happy to assist you further if you encounter any issues.
Thanks so much for looking into this.
To be sure on the procedure I have a couple of questions:
- I should not update to the available version of ACFML, instead I should run the updates for WPML Multilingual CMS and WPML String and after that manually update ACFML using the zip you've provided?
- Regarding the "Awaiting save" status. What would your advise be on how to proceed in order to avoid issues in the future? Ask ACF support and maybe check whether the acf-json folder is writable? I personally do not think it has to do with the writabillity of the acf-json folder, as all saves will end up in the acf-json folder, and the naming "acf-json" of the folder is the default naming.
- Is my conclusion correct that you suggest that if all statusses of the ACF field groups are "Saved", that you expect no issues to arise? What we could do is first save al fields again locally (which will update the database acf-field group and will set the status to "Saved"), before updating to ACFML 2.0.
- The patched version will skip any field groups that not have a valid ID (and thus are not synced to the database?). Will this mean that some features will not work - regarding the new Translation Option (expert)? Will this cause any issues in the future?
- What do you exactly mean by "field groups that do not have a valid ID"? When I look in the database I do find all ACF field groups in the database, also the ones that have the status "Awaiting for save".
I will block some time in the upcoming days to dive into the matter, so we can together look for what is actually happening.
Hello again! I'll try to reply to your question in a slightly different order.
- I should not update to the available version of ACFML, instead I should run the updates for WPML Multilingual CMS and WPML String and after that manually update ACFML using the zip you've provided?
Yes, exactly.
- Is my conclusion correct that you suggest that if all statusses of the ACF field groups are "Saved", that you expect no issues to arise? What we could do is first save al fields again locally (which will update the database acf-field group and will set the status to "Saved"), before updating to ACFML 2.0.
Yes, for sure. On the tests we have done during our developement of ACFML 2.0, we always had the field groups set to "Saved", and we never got duplication issues.
I believe that if all the field groups are in the "Saved" status, and none of the groups are on the "Sync available" list, the update will run smouthly without any issues.
- The patched version will skip any field groups that not have a valid ID (and thus are not synced to the database?). Will this mean that some features will not work - regarding the new Translation Option (expert)? Will this cause any issues in the future?
Based on the issues you encountered, we realized that we should handle the case when ACF API returns a Field group that has no ID. In this case, we should not update it. Our features are based on ACF, so we'd prefer to let ACF first save these kind of field groups, and once it return valid groups to us, we'll add our translation option to them.
So, I would say taht ACF field groups and their fields should work as expected in a backward compatible way. And no issues will be generated. But as you may know, zero bug is still a myth.
- What do you exactly mean by "field groups that do not have a valid ID"? When I look in the database I do find all ACF field groups in the database, also the ones that have the status "Awaiting for save".
We used ACF API to interact with field groups, functions such as acf_get_field_groups and acf_update_field_group. And the first one did return some field groups without IDs. This may happen if the field group exists on a JSON file but not yet saved on the database, or if it was registered with PHP code. To be honest, I did not dig into it deeper as it seems to be very ACF specific rather than ACFML related. I believe that the ACF team is the best placed to answer that.
- Regarding the "Awaiting save" status. What would your advise be on how to proceed in order to avoid issues in the future? Ask ACF support and maybe check whether the acf-json folder is writable? I personally do not think it has to do with the writabillity of the acf-json folder, as all saves will end up in the acf-json folder, and the naming "acf-json" of the folder is the default naming.
To be honest, it was the first time I see this status in my ACF experience. I believe the ACF support team will be the best to explain it. If you do so, please share your finding with us on this thread.
I hope this answers your question, and I'll remain at your disposal for anything further.
I saw that you published a ACFML 2.0.1 update, which addresses the issue we discussed. When we locally update the plugins (acfml to 2.0.1, sitepress-multilingual-cms to 4.6.0 and wpml-string-translation to 3.2.4) we do not see the creation of new ACF fields as before, so that seems to work!
I do have some questions about the updates in the local ACF JSON files.
1. Reference to local file.
In ACF field groups that are assigned to the "Expert" mode, we see a reference to
in the json file. We use the ACF JSON files to synchronise changes of ACF fields across several environments (local dev machines, staging, production). Therefore a reference to any local file, stating my personal machine name "aron" seems quite odd as it would only work for my machine? What is the concept behind this implementation?
2. Cloned fields are displayed inline
Also, we see that references to cloned fields are now replaced by setting these fields inline in the ACF JSON files, which seems to a very different approach than before (where only the reference was stated). Will updating the original clone field now also update all inline references in the potential multiple ACF JSON files?
Hello again! I am glad we could fix this this fast. Thank you for your report.
Regarding the first question, I believe this is something done on the ACF side. I know that ACFML does not read or write the ACF local JSON files. We only add an attribute to the array(PHP array) and we let ACF handles everything else.
To be sure, I run a test on a clean install without WPML and I was not able to reproduce the issue. Which let me think that WPML/ACFML has something to do with it. hidden link
However, IMHO, this is probably a bug on ACF where it saves the field group without removing this new attribute (locale_file).
Regarding the second issue, it may also be the same.
This being said, and because we need to handle one issue per forum thread, I'll invite you to:
- Report this to the ACF support team too. They may provide more insights.
- Test this scenario(moving from dev/qua/prod) and if you encounter any issues, create another ticket in our support forum, add a link to this thread on it, and we'll do our best to help.
