Hi
Thanks for answering. The problem is not front end or in generated meta boxes. Just edit a field group, and you se like “Required?” and other settings are using this cluttered sliders.
Propably we need to turn some javascript off as well to restore the standard checkbox?
Is there any one out there? This question is 2 years old and unread
Hi, and @scheurta,
Right now we export the “workspace” language all ACF fields, then delete every lang (ALL ACF), import the exported, and “dublicate all” in Translation management extension (insteadone by one in edit ACF field)
TIP: Make shure “Delete original posts will also delete translation” is active checked in the settings (languages), The delete process would be fast.
BUT, I think som lines in the XML file could do the trick to force the “Fields” to be dublicated and override the PRO “translate only”. But this problem just occured for us as well – we don have time to experiment with this for now…
I been using ACF and WPML and Woocommerce for a long time with very complex ACF and language setup. I Just installed the ACF PRO and this become Changed:
The “Duplicate” of a ACF is no longer dublicated, it creates a translated independent copy of the original language field setup. Before you could see the WPML box “Make xxx fieldgroup independent” (WPML will no longer sync…)
Today, if we add changes in the Field group, we must add the “new” fields in that fieldgroup, values, etc etc manually for EACH translated field group. Not fun when using 10 languages.
On the other hand, To make headlines, titles translated, the field group MUST released as a “duplicate” and become independent. (As before)
We always keep the fieldgroups as “dublicated” (But now ACF cant do it) as long as possible, and when all testing and the client is happy, we release all translations and finally, translate the labels and titles.
ALSO:
REF Elliots article “Multilingual Custom Fields”
in WPML “Mulitilingual setup — Custom fields translation”, These properties (Custom fields) has to be checked as “Copy from original to translation”:
-allorany
-field_1
-hide_on_screen
-layout
-position
-rule
Then, everything works fine for us, as for many installs, last 3 years, update after update WPML + ACF.
It seems the ACF Google map is broken, when I don know, have not use it for a while (a year), until a project today. We have not change the theme or the ACF field for Google maps, but there been many updates, we forgot to check this one…
Ok, I keep the topic open for a while, until then, I have to make shure to NOT update / edit the original field. The “manually” added rule then get lost again.
As mentioned, A small multilang install, it is ok to re-do the missing parts, but when having 3 or more secondary langs, it getting anoying and take time to add for each language.
/ Thanks for looking into this.
Hi, @liesju
a) The translation with a LOT of rep fields and other works pretty well but it s important to do things in a certain order. elliot mentioned that the new version will be more compatible with wpml, but I can tell in our setups with very complex ACF setup it works as it is in all our “cases”.
b) In my mind, for reading and writing this on a hollyday trip during chrismas, the
-rule
-position
-layout
-hide_on_screen
must be “traslateable”, in the wpml settings, or I think you can activate them in the meta box on ANY ACF edit page the FIRST TIME, before saving any changes.
c) I think the “rule” is the “show on” example type = posts and / or user = admin , and so on.
If this is not set to be translateable, the fields never show on the “other” languages = will not be accessable or might not be recorded if you dublicate the fields to that language
d) It easy to forget that the ACF fields must be dublicated. Just go to the edit ACF field ON THE DEFAULT ADMIN LANGUAGE (selected), choose “dublicate” (AFTER the rule, position, etc etc is radio-checked translateable). Click on the “language” ( the pen) and let the page reload to the actual language and re-save the edit screen.
d2) do not dublicate a “translated” created ACF setup
e) Leave the rest of “_your_field_names” as they are, do not “translate them”. (they are a lot of them if y using repeater fields)
As long as you se the meta-boxes on the “new” languages when edit a page or post or custom post type, you are ok. But the DATA of the field must be “dublicated” AFTER this setup is ok.
You can not “move” ACF data from the original fields ( all of them ) ONCE you cretaed the tranlated post… Make shure the setup is fine BEFORE you start to translate (including rules that ACF is ok to use AND visible, on the translated pages as well = 99,99% we want)
Its a little tricky, but it works for us! Actually, the logic make sence, (for a tech point of view). But We cant speak for every setup.
Hope it can help, and as I mentioned earlier in this thread, some “routines” – the order of setup – will be published with a turtrorial on our domains (my developers team deep circle….) later this year. But for now, we are in the ** of delivering projects…
/ Big user of ACF struggling with Multi-languages and WordPress
Hi, thanks for answering.
Now I know that they belongs to ACF, and I will record each step for diffrent setups wich fields that must be set as translateable to work correctly
– The custom content itself
– The setup itself (Views)
– The titles and names, current labels itselfs
The most important / or neccesssery and leave the rest alone to keep the string tables lighter in WPML
allorany – this is a location rule setting which I believe was removed in v4.2 or something similar. The all or any value was removed in favor of grouped location rules. What version of ACF are you using?
Im using latest versions and in a 1 week old clean install. But I also have Location addon installed, maybe a leftover is popping in.
Next year I will publish som articles about this kind of setups, I might return with a reference link for other people to use.
/ Merry Chrismas and thanks for the great ACF plugin to our world!
Solved
Hi!
I just tested the latest update and it seems to work fine. Thanks for the smooth and fast soution and fix. One line with an extra statement, well “size matter” after all….
Superb, marking this as solved.
/ Jonas
Hi
zip attached:
I created a zip with the export and some images, also the 2 main functions using the setup + XML version of the ACF export. Some notes in the files. The picures shows how it looks in the backend and frontend to understand what we are doing…
This setup has been working fine using ACF many years, and implemeted in the repeater some yars ago, always working superb version after version..
/ sad but hopeful Koala
I tried to track the issue a little. I let the browser spinn 20 min until it stopped. The third content was rendered 200 times…
The third nestled get_sub_field “belives” it has its parents sub_field.
It is called within while(has_sub_field(flexible, $current_id)
so all get_sub_field() “below” this $current_id should be unique, but its not.
if finds a subfield, and when I echo the id within, that post id has no subfield data (but the parent had)
Maybe your fix was not complete:
Im not using a repeater who has a repeater who has a repeater…
my setup is
a repeater has a flexible content field who has a repeater who has a flexible who has a repeater who has a flexible …
Im feeling a little bit sorry for you, I know how it is when you think something might be solved, and you have to brainstorm again…
Thanks for your work
Hi,
Problem NOT solved. The only thing that has changed is that the server itself doesnt shut down, but the page try to load in infinity loop/ just spinning.
Hi,
sounds great. Where is this on Github? Would like to test it so I can report this as solved for all my clients.
Hi!
Great support for this issue. Thanks.
Working version is Versions:
4.2.2 ACF Core
1.0.2 Flexible Content Field
1.0.1 Repeater Field
Wondering what this is:
What’s new
Core: get_field can now be used within the functions.php file
If you could not before, something with the scope should have been changed?
We are in the middle of late working nights right now to rollback all the projects that been affected by the auto update by the admins all over. ACF has a hight update freq, and has Always been stable, relyible. Its one of the few plugin we update without do the testdrive on each install first.
As soon as p, within a few days, I will do the die() trace, but it so much easier if we get a understanding of the changes in the latest version. This is where we need to track what the latest update does diffrently:
// loop
$other_page = get_the_id();
doit($other_page)
function doit($other_page){
while(has_sub_field('repeater_field_name', $other_page))
if(get_sub_field('sub_field_1')){
while(has_sub_field('flexible_field_name', $other_page))
if(get_row_layout() == 'row_name_1'){
if(get_sub_field('posts')){
foreach(get_sub_field('posts') as $p){
$new_other_page = $p->ID;
goto_function_write_post($new_other_page);
function goto_function_write_post($new_other_page){
$obj = get_post($new_other_page);
$other_page = $obj->ID;
$ACF = get_post_meta($other_page, 'repeater_field_name', true);
if($ACF) doit($other_page);
}
It is a brain resoucing procedure … If you cant see anything particular in this chain that might couse a global scope, then give me a hint.
Otherwise I come back within a few days and report my tracking / comparing versions output, and we go from there with this thread.
Thanks so far!
Hi and Thanks for answering and for your time!
To simplify a little:
“note: you don’t need to specify the $post_id for any sub field functions”
This is in your documentation, for the new version of ACF. We think this change is the problem.
When we rolled back ACF one step, everything works again.
The structure example posted before, is not a real function, just a ‘dummie’. Our setup is very complex and hard to explain. But I try:
EVERY POST have the exact same ACF setup fields:
The Repeater has a subfield with a Flexible content with layouts, and in one layout a relationship post object field.
This is what we accomplish:
Every post and page has the same Repeater. With this we build the content below the standard editor. And a post can include another post(s) repeater-content, and that post can include repeater-content from another post… No depth limit, but a post id can never be include itself in each chain.
We are not using widets. We are using posts. Example: One post using ACF Gallery and location field (in the repeater). We wanna re-use this post as a widget.
Example: The main query POST “Delayed travels” says (in the repeater):
Include POST Gallery on Sidebar 2 on top, and
Include POST Airport Links on Sidebar 3 …
Then the latter POST Airport Links, says: (in its own repeater field)
Include POST Airport Germany links on Below main content
Include POST Airport Sweden links on Below main content
Include POST Airport Sydney links on Below main content
Include POST Airport New Zeeland links on Below main content
This is done with a simple output strategy. The Main post ( the page ) is using the wp single.php template, and the loop. Thats where the reading of the ACF fields starts. But it passes the post ID to a FIRST function with its own scope. Every post object called from here are NOT using any templates for output the html. Its done in a second function who echoes out its HTML. If this has repeater content, this posts id are passing up to the FIRST function. Its standard script function pass to unique scope.
The key is to pass the ID to the FIRST function that holds “while has subfield”, and all the stuff to see if any post objects are gonna be included after rendering its own content.
This scope is not unique anymore, couse ACF starting to use sub fields from the loop (where it all begins). WE THINK…
Here is the REAL PHP the beginning of the 2 main functions and the loop.
//MAIN LOOP
the_content();
$extra_content = get_field('activate_content_below', get_the_ID());
if($extra_content) whatever(get_the_ID());
// END MAIN LOOP
This is in functions.php
// unique scope :
function whatever($id){
while(has_sub_field('ua_acm_rf_master', $id)){
if(get_sub_field('ua_acm_rf_activate')){ // true or false switch
while(has_sub_field('ua_acm_rf_fc_master', $id)){
if(get_row_layout() == 'ua_acm_rf_fc_post_include'){
if(get_sub_field('posts')){
foreach(get_sub_field('posts') as $p){
$inc_id = $p->ID;
ua_post_this($inc_id); <-- REMARK NEW ID
// unique scope :
function ua_post_this($inc_id){
$obj = get_post( $inc_id );
echo '<h1>'.$obj->post_title ... and so on
Now, we check if THIS post have som ACF field, calling the SAME function as the LOOP did.
$extra_content = get_post_meta($inc_id, 'activate_content_below', true);
if($extra_content) whatever($inc_id); <-- RE-USING FIRST FUNCTION
}
Im shure its a small, tiny change like global $something that destroys this setup. But the worrying part is that we are completley building with ACF, and it is a Huge invested time in this modular building setup. We must get it to work and keep up with latest versions…
Many many thanks for looking in to this.
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!
We use cookies to offer you a better browsing experience, analyze site traffic and personalize content. Read about how we use cookies and how you can control them in our Cookie Policy. If you continue to use this site, you consent to our use of cookies.