Home›Support›English Support›[Resolved] acfml after update above v2.0.5 empty postmeta fields are added to db
[Resolved] acfml after update above v2.0.5 empty postmeta fields are added to db
This thread is resolved. Here is a description of the problem and solution.
Problem: After updating to a version of ACFML greater than 2.0.5, you might find that on a secondary language page, many ACF fields (e.g., from an ACF options page) and unfilled fields in the backend are saved in the postmeta. This results in numerous empty fields and incorrect
get_field()
calls because the field is present with the post but has an empty array as a value. In the default language, these fields are not saved in the database. Solution: We recommend editing the file
This change should resolve the issue. Additionally, ensure that each of your custom fields across different field groups has a unique Field Name to avoid translation and functionality issues. More details can be found in the WPML documentation. If this solution does not apply to your case, or if it seems outdated, please open a new support ticket. We also highly recommend checking related known issues at https://wpml.org/known-issues/, verifying the version of the permanent fix, and confirming that you have installed the latest versions of themes and plugins. For further assistance, you can always contact our support at WPML support forum.
This is the technical support forum for WPML - the multilingual WordPress plugin.
Everyone can read, but only WPML clients can post here. WPML team is replying on the forum 6 days per week, 22 hours per day.
No, not from the options page.
These are fields that are in an element in a flexible content (which can be added to the post) but are not used (the element).
And again this only happens on the translated page when saving.
I would like to offer to have a closer look at the problem and request temporary access (wp-admin and FTP) to the website to investigate this issue further.
You can find the required fields below the comment section when you log in to leave the next reply. The information you provide is private, which means only you and I can see and access it.
IMPORTANT
Please be sure to make a backup copy of the website and database before allowing us access.
If you can't see the wp-admin / FTP fields, your post and website credentials are set as PUBLIC. DO NOT publish the data unless you see the required wp-admin / FTP fields.
I may have to install a plugin called "All In One WP Migration" to make a copy of the website where I can investigate the issue further.
However, I would also be very grateful if you could provide a staging site or copy of the website from your server yourself for this purpose.
If you have any questions about creating such a staging site, you can consult your hosting provider. Just take note that WPML should be registered on this site again.
If you are unable to provide such a copy of the site for testing, please let me know on this ticket.
The private response form looks like this: hidden link
Next time you reply, click "I still need assistance."
Video: hidden link
Please note that we are obliged to request this information individually on each ticket. We may not access any access information not specifically submitted on this ticket in the private response form.
I updated our plugins on your staging site and ran further tests.
I created one post with WPML, translated this post, and created one original post without WPML active and I see the same results for all three posts on the database.
See screenshots.
Could you please test again and in case the issue persists, provide me with more detailed steps on how to replicate the issue?
I activated wpml again (you kept it switched off).
see now post 9336 (in default lang) and 9338 (the translation) after adding some fields in both languages.
that happened after adding some content (fce element text). german fields are ok, english is an issue with the empty fields like "button", "link", ... marked in the screenshot.
those are fields within the flexible content from type "link"
Thank you for the provided details, as we need to know exactly which steps to take to be able to replicate the issue.
WPML was activated on my test and I even updated our plugins to the latest available version. Only I did not enter any values into any fields, apart from the page title.
Post ID 9336:
This is the original post. I see that inside the group "News Infos" you added "Autor", "Leistung" and "Teasertext".
Post ID 9338:
This is the translation of this post and the fields were translated as expected on Frontend.
I understand right, that the unexpected issue is the appearance of additional fields on the postmeta table, when translating the custom post manually, correct?
Here "link", "url" and "button".
Is it possible that your field groups use those field names more than ones?
If various field groups use the same field name, please take note that each field name in and between each group should be unique.
The next step I would take now is to revise the ACF Field Groups on the backend and verify which translation setting the groups are using, but I do not have access to ACF. Also, I do need this information to understand where the unexpected field entries are coming from.
I need to be able to see all your field groups to investigate this issue, which is why I deactivated "Admin Columns Pro" but I still can not see ACF on the backend.
Before I proceed I have a few questions:
1) Are you registering ACF here programmatically?
2) I see you are using custom addons for ACF, like "Advanced Custom Fields: Extended PRO // MUEVO extended" and "ACF Multisite Options // MUEVO Extended". Did you already make sure to test if the issue persists if you disable those plugins?
3) Is it possible to network-wide disable plugins on this site, so that I can run further tests?
4) Is it possible to install a File Manager PLugin so that I can take a look at the files?
You described the issue correctly. After adding content (with the flexbile content element) in the secondary language this behaviour appears.
I probably have the ACF menu hidden for all users except our admin user, eventhough we are on a staging environment the client also tests some things here before using it on live (also I reactivated all the plugins that were activated before, otherwise the site will have issues on the frontend and the clients needs to be able to test on the staging).
1) acf fields are created in the backend but are saved to json and php
2) the changes to the plugin are minimal and acf extended pro is needed
3) please dont
4) sure
But I would suggest you provide an empty installation (like last time) and I will import the fields in the installation and we try it out in a naked install since we need the site to keep working.
Thank you for the sandbox - I imported the acf field group "Inhalt" which is now attached to "posts". I also created a post in english (default lang) and a translation.
You will see in the postmeta table, that there are 2 fields added that are in the flexible content "Inhalt" but are not added to the post. The post only has the "Text" FCE and nothing more, eventough in the translation you will find acf fields "url" and "link" that are saved with empty arrays.
Thank you for the provided example. I was able to recreate the issue with a new group that only includes a Flexible Content Group with a text field plus url and link fields.
We have now included a workaround on the test site.
Edit \sitepress-multilingual-cms\classes\custom-field-translation\class-wpml-copy-once-custom-field.php
on line 36 replace
If I test now with a new post the issues seem solved.
---
Could you please run another test and let me know if you can still replicate the issue?
----
Please take note, that when working with ACF, each field name should be unique. You should not use the same field name more than once, or you will run into issues if you try to call the fields by PHP or try to translate them with the WPML Translation Editor.
Thanks, that fixes the issue. Will this workaround be in the next update?
Since the fields are only added with their parent flexible content element I don't see an issue here, that they cannot have the same name. With FCE the fields are saved with the prefix of the field group and and an index so they never have the same name. I understand to not name fields the same name when working for example in the same field group (without repeater or fce).
A release for the fix is panned in the upcoming version of "Advanced Custom Fields Multilingual 2.1.4". I do not have a release date for this version.
---
We do not recommend using the same field name twice, whether it is inside one group or between all groups.
Make sure each of the custom fields across your different field groups has a unique Field Name. If you use the same Field Name with more than one custom field, you may not see all your field values available for translation in the Advanced Translation Editor.
RE Naming: I am aware of this, but we use ACF heavily in complex situations and render them with our own RendereringClass ... also we use WPML only with the classic translation and not the ATE ... but I understand the issue.
