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.
I am trying to: save a post in the secondary language
Link to a page where the issue can be seen: hidden link
after updating to a greater version of acfml than 2.0.5 I have the issue that on a secondary language page a lot of acf fields (from an acf options page for example [fields page_*, button, client, clients,..] and not filled out fields in the backend like "kunden" are saved in the postmeta which results in a lot of empty fields and then wrong get_field() calls because all of a sudden the field is there with the post but has an empty array as value. in the default language those fields are not saved in the database (default lang is german screenshot with -de-), you will see the difference in the results (63 entries in DE and 82 in EN). Something with saving a post in secondary language is not working correctly.
Languages: English (English )Spanish (Español )German (Deutsch )
Timezone: America/Lima (GMT-05:00)
Hello,
ACF Options pages can only get translated while switching the language inside the top admin bar, which means to translate them, the fields need to have a value in each language.
Usually, by default, the fields should get copied but it might be that you are using a different setting for the field group-
Which settings does the field group use? If it is Expert mode, also add the setting information for the fields.
Also, please verify that the post type ACF Field Groups should be set to "Not translatable" at WPML > Settings > Post Type Translation.
you are not understanding correctly: I am saving a custom post type (or page) that has acf fields. But on saving the post in the secondary language, I get in the database also fields saved to this post (the custom post type) that are fields from the options page and also empty entries from fields that are attached to this post which should not be saved there.
all field groups (trough the page) use expert settings.
something in the behaviour of saving in the seconday language changed with the acfml update.
Thank you.
Also I can report this happening on a different site (also multisite, with acf + wpml + acfml) in which an acf field (that is on an options page) is saved to a custom post type in the translation (2nd language) to the custom post in the postmeta table.
I copied the fields to the site. I could reproduce the issue.
I added an options page (with acf, called "theme settings"), did not fill out much there, and attached some acf fields to the "page" post type.
after creating a post on "page one" in english the database saves the fields that are filled out and is ok ('select * from wp_postmeta where post_id = 139') after that i "duplicated" to german, then "translate indipendent", edited some fields and updated the german version - in there you see, that are a lot of acf fields that are either empty (or not filled out) in the post itself and fields from the options page, that are there as well ('select * from wp_postmeta where post_id = 172').
eta: for post_id 172 (de translation) what worries me here are the fields with meta id from 240-249) - these should not be there at all
Languages: English (English )Spanish (Español )German (Deutsch )
Timezone: America/Lima (GMT-05:00)
If you save a page, then all the fields will be saved to the database, no matter if they have a value to not. This is not a WPML issue, I can confirm the same behavior if I test the site without WPML.
To avoid issues with empty fields, check if the field is empty before calling it.
<?php if (get_field('field_name')) : ?>
<p>My field value: <?php the_field('field_name'); ?></p>
<?php endif; ?>
After that, usually, the same registered fields should be used, if you update a field value on the original content.
Anyhow, I can still confirm an issue here, testing without WPML.
My original page has the ID 190 but anytime I edit a field and save the page again it creates a new ID entry on the mostmeta table, like 191, 192, etc.
This does occur when WPML is disabled, which means that the reported issue is not WPML-related.
---
If you translate the page then WPML will need to create some reference entries for the fields and it will then save the actual translations on our string tables.
we are still not talking about the same thing here. Your example is fine with wpml disabled, that is quite ok how it turns out, because the fields (that are not filled out) are really empty in the database, this would be fine by me. see screenshot pid190-nowpml
No issues in this case, check.
I have again enabled wpml and created a new page (old ones weren't there anymore), with page id 193 ("test en"). After saving this page it looks good in the database (screenshot pid193-wpml-en). Eventhough not all fields are saved (filled out ones are there, but empty ones are not all there, which is fine, since they are empty I do not care, if they are there or if they are there and empty. Though you might want to consider that something is not really working anyways. Field with the name details_mail for example is not in the postmeta table (it is not filled out, but in your post id 190 it is there and empty, in my page (default lang) 193 it is not there at all, other fields like "details_place" are also not filled out, but in the database.
Now coming to the translated page with id 195: you will see that fields until id 915 are ok (screenshot pid195-wpml-de), after that there the following fields, that are acf fields from the acf options page ("theme settings"): url, page_service, page_clients, page_contact, page_news, page_team, page_jobs => they have nothing to do with the post type page, and are set to appear on the options page (see screenshot acf-options). Now the fields "leistungen", "kunden", "end_personen" => those 3 are fields that are in the field group for the post type "page" - all those 3 are empty in the backend, and not filled out, but they are not saved empty in the dabase, they havea an emtpy array in there "a:1:{i:0;s:0:"";}" which is wrong. Because either they are empty and have no value in there or have a value, but not am empty array. Also you see those fields are not in the originl post (195).
With that I hope you know understand the issue, because if in the template I now check for get_field('leistungen') which is empty, I get a true for the translated page (which should not be) and false for the original language (which is ok).
If I downgrade to acfml 2.0.5 this issue does not appear when saving translated pages.
Languages: English (English )Spanish (Español )German (Deutsch )
Timezone: America/Lima (GMT-05:00)
Thank you, I can see the issue now. This needs some further testing, as I need to try to recreate the issue from scratch on new groups and verify in which use cases the issue occurs.
Hi Andreas,
it works partly. So fields on the post-type itself are now saved without any value (empty in the database) - so this is fine.
But I still get acf fields saved to the post (in the database) that have an empty array as value but are not added as acf fields.
It seems this is happening within flexible content with the acf type: "link"
See meta_key: button, link, url in the screenshot
Manage Cookie Consent
We use cookies to optimize our website and services. Your consent allows us to process data such as browsing behavior. Not consenting may affect some features.
Functional
Always active
Required for our website to operate and communicate correctly.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
We use these to analyze the statistics of our site. Collected information is completely anonymous.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
These cookies track your browsing to provide ads relevant to you.
