• thomask

• in reply to: Saved Drafts not displaying custom fields
• November 3, 2020 at 9:22 pm

FYI, hotfix appears also to work fine with WordPress 4.9.16.

Thanks everybody for reports, investigation and quick support.

• thomask

• in reply to: Saved Drafts not displaying custom fields
• November 2, 2020 at 9:59 pm

Same issue here, WordPress 4.9.16.

@figureone If you need test results for suggested changes, let me know.

Edit: Found similar issue here in another thread, suggestion of CamiloAPR there seems to work, not sure why.

• thomask

• in reply to: How get value by field name in JavaScript API?
• September 19, 2019 at 1:58 am

Ok, thanks for explaination.

Using this workaround (edited) for now:

var val = (val = acf.getFields({name:'my_field_name'}).shift()) ? val.val() : '';

• thomask

• in reply to: ACF not playing nice with WPML
• October 21, 2016 at 11:57 pm

@raison Just curious, are you using the Advanced Custom Fields Multilingual (ACFML) plugin?

• thomask

• in reply to: German translation, menu title too long
• June 17, 2016 at 9:49 pm

Another wrong/bad german translation was introduced with 5.3.9.x

When editing a field in a field-set, field type dropdown-select:

New: “- Wähle -” (gives the impression that no type is selected)
Old: “Auswahlmenü” (correct)

Edit: Both issues are solved in the meantime, had to trigger a manual WPML re-scan of ACF Plugin, now correct strings show up. Had an old version of ACF installed long ago, seems WPML remembered these old strings…

• thomask

• in reply to: Remoce ACF option page menu item
• November 8, 2014 at 12:09 am

You could also try to use a higher priority for your action. The documentation says, the options page entry is added with priority 99, so you could try e.g. 100:

add_action( 'admin_menu', 'my_remove_menu_pages', 100 );

• thomask

• in reply to: Remoce ACF option page menu item
• November 7, 2014 at 11:38 pm

What about adding it only for admins? Would that solve your problem?

if ( function_exists('acf_add_options_page') ) {
	if ( current_user_can( 'administrator' ) ) {
		acf_add_options_page();	// or similar
	}
}

• thomask

• in reply to: Passing page ID to another page to display ACF values.
• November 5, 2014 at 7:13 am

1. Variable $goody_title is defined nowhere, probably you mean $goody_file

echo "$pageid";
  if($goody_title) {

2. $pageid missing at the_field(), try this

// Spits out the full URL for now as a test.
  the_field('goody_file', $pageid);

instead of this

// Spits out the full URL for now as a test.
  the_field('goody_file');

• thomask

• in reply to: Google Maps Marker as Image
• November 4, 2014 at 11:49 pm

Works fine here.

Here a running version of the acf example-code with a custom “A” image as icon/marker: http://jsfiddle.net/0zL3mt4z/

The only change compared to the example-code is the added ‘icon’ parameter.

• thomask

• in reply to: Google Maps Marker as Image
• November 4, 2014 at 3:59 am

Based on the google maps acf example-code (and google maps api), I would suggest to change this:

// create marker
var marker = new google.maps.Marker({
position : latlng,
map : map
});

to something like this:

// create marker
var marker = new google.maps.Marker({
position : latlng,
map : map,
icon: ‘http://example.com/my_icon.png’
});

• thomask

• in reply to: ACF not playing nice with WPML
• October 29, 2014 at 9:48 pm

Just finished writing this article:

http://www.advancedcustomfields.com/resources/multilingual-custom-fields/

Please let me know if it is helpful or can be improved in any way.

Thanks for the article, a few questions:

1. Which (exact) version of WPML did you use?
2. Is the article valid for ACF 4 and/or for ACF PRO 5?
3. Do fields still save and is selecting the post type translation still possible after you enable any other plugins or switch themes (doesn’t matter which) after the ACF setup?

• thomask

• in reply to: Translation with WPML Plugin
• October 24, 2014 at 9:34 pm

The WPML support said today:

ACF is not currently compatible.

And you should “hack” the database to fix it.

http://wpml.org/forums/topic/wpml-3-1-8-1-field-groups-not-translatable-acf-now-working/#post-498588

Draw your own conclusions…

Edit: The technical background is explained here:

http://wpml.org/forums/topic/broken-acf-languages-after-activate-plugin/page/3/#post-493055

Summary: WPML 3.1.7+ downloads a remote config from WPML server which currently tells WPML that ACF can not be translated. The update of this remote config is triggered at every after_switch_theme and activated_plugin wordpress action and at custom wpml-actions.

• thomask

• in reply to: I removed a custom field but it still shows on the backend
• October 24, 2014 at 9:00 pm

Had a similar problem a while ago, a folder acf-json was created by the plugin within my (child-)theme folder. It contained .json files which are used as a cache and were not updated after delete in backend.

Deleting that folder acf-json by hand fixed the problem.

• thomask

• in reply to: Unable to activate ACF Field Groups for translation with WPML
• October 23, 2014 at 12:16 am

Thanks for the link, that “special” remote config for “acf” in latest WPML is actually very interesting…

• thomask

• in reply to: Hide ACF if password protected
• October 14, 2014 at 9:38 am

Wrap your acf output calls with a conditional statement using post_password_required(), example here:
http://codex.wordpress.org/Using_Password_Protection#Protect_Custom_Fields
http://codex.wordpress.org/Function_Reference/post_password_required

• thomask

• in reply to: Values are not always saved, WPML
• September 25, 2014 at 6:58 pm

At the moment the combination of ACF PRO and WPML is not ready for production sites at all.

And I don’t think this will change in near future, too bad.

WPML support says: Drop ACF, use Types, but current version of Types also has many problems.

Using old school standard WordPress custom fields for now, ugly backend but at least reliable.

• thomask

• in reply to: How to echo the File Type uploaded?
• August 22, 2014 at 9:43 pm

If the frontend links to the file, you could use css 3 selector as workaround, e.g. a[href$=".pdf"]

http://www.w3schools.com/cssref/css_selectors.asp

• thomask

• in reply to: What level of support for paying users?
• August 22, 2014 at 2:57 am

Maybe you should read the threads, not a single problem has been solved, no workaround has been provided or suggested.

ACF 4.x is a great plugin, ACF PRO 5.x is currently a great betatest.

And as you maybe have noticed, threads in this forum usually get marked as solved based on number of replies, not based on given or not given solutions.

• thomask

• in reply to: What level of support for paying users?
• August 22, 2014 at 12:11 am

Have posted several requests in forum and via support email, see my profile.

Bought ACF PRO 5 because it was posted on twitter etc. that ACF 5 and WPML would be compatible. Sad truth: WPML compatibility is not even “beta” status.

Also the forum is full of serious problems without visible reaction of author or support team (if any exists):

http://support.advancedcustomfields.com/forums/forum/acf-pro/

ACF PRO 5 is a big project and author is adding new features with each 5.0.x release (which is good) but has no time left to track down and fix bugs or test releases (which is bad).

• thomask

• in reply to: What level of support for paying users?
• August 18, 2014 at 10:48 pm

Also bought ACF PRO and obviously there is room for improvement in terms of customer support.

Probably have to abandon ACF PRO soon due to some unsolved WMPL compatibility issues, my clients patience is almost used up, too bad 🙁

• thomask

• in reply to: acf_form errors
• August 14, 2014 at 6:29 pm

@Pau: The form labels in backend (if you are talking about these) are added dynamically and translated in context of the WordPress ‘default’ domain.

A possible solution for you could be to use a translated version of the whole fieldgroup/fields and adjust the labels there.

There is currently no way to find these labels with an automated tool like WPML theme/plugin scanner.

More about wrong/bad textdomain in ACF here.

A solution for WPML automated scanner could be 1.) an own textdomain for these labels, e.g. acf_label and 2.) a dynamic creation of a .php file in a path where WPML theme/plugin scanner would find them which contains all the used labels in default language like e.g. $label = __('Label 1', 'acf_label') = __('Label 2', 'acf_label') = __('Label 3', 'acf_label') ...

• thomask

• in reply to: WPML backend
• August 13, 2014 at 7:12 pm

Unfortunately can’t test older version of WPML, invested too much time already in this.

• thomask

• in reply to: WPML backend
• August 13, 2014 at 6:58 pm

Also having lots of problems with ACF PRO 5.0.x and WPML 3.1.6

Something seems to be fundamentally broken. I tried a lot of things, hacked the ACF and WPML files to generate debug-output etc. but I can’t track down the real problem. Behaviour seems to change even with activation order of ACF and WPML plugins and/or other weird requirements.

Some fields are obviously not saved if they do not exist in corresponding translated fieldgroup (weird), at the moment a simple field in a 1-field fieldgroup can not be changed any more, etc.

From reading the WPML support forum it seems that they try to sell their “Types” plugin [#1, #2, #3, ..] as a working alternative instead of support.

As I already bought ACF PRO 5 for a customer, I would really like to use it, invested a lot of time already, but probably now have to look at “Types” as well. 🙁

• thomask

• in reply to: Values are not always saved, WPML
• August 12, 2014 at 10:30 pm

Can you confirm/reproduce that values are saved to wrong language?

• thomask

• in reply to: Values are not always saved, WPML
• August 7, 2014 at 6:19 pm

Short update, it appears that values are saved to and read from the wrong language with 5.0.3 and before.

Have a fieldgroup in main language with field 1 and field 2. Added a translation of this fieldgroup in secondary language, with field 1 only.

Now saving values in field 1 works in both languages. But if I enter something in field 2 in main language it does not get saved, field 2 stays empty.

I think that’s because field 2 does not exist in translation of fieldgroup and so the value can’t be saved.

This problem usually won’t be noticed if main language and translation have same fields. Everything looks fine, but actually values are both saved to and read from wrong places.

This observation matches the above described behaviour with the not matching key in my log.

Edit: I don’t know why this topic is marked as solved, it is not.