Support

Account

Register Login

Forum Replies Created

  • Quick results with 5.0.3, saving fields is still not working as expected, behaviour is different though. Will give more feedback as soon as I can test more.

  • Would suggest a new filter then, pseudocode:

    $translate = apply_filters( 'new_filter', 'acf_default' );
switch( $translate ) {
case 'acf_notranslate':
	// do not use __() at all
	.. $field[ $s ] ..
	break;
case 'acf_default':
	// use code like now
	.. __($field[ $s ]) ..
	break;
default:
	// use filter_value as domain
	.. __($field[ $s ], $translate) ..
	break;
}

  • Looked into this a bit more now, and it appears that the ACF PRO action save_post in forms/post.php is never called in the current state of my website here.

    Edit: Seems to be different, still testing…

    Edit 2: Seems to be problem around suppress_filter.

    With suppress_filter=false and WPML active, trying to get a field in _acf_get_field_by_key() does not return data.

    If I change _acf_get_field_by_key() to suppress_filter=true, it looks like the correct post is returned by get_posts() but it actually is the opposite language, so a query with acf_field_key=field_1 returns a post with post_name=field_2, weird.

    Example log with suppress_filter=true

    acf/api/api-field.php/acf_get_field
$selector=field_53c599718b60c
$k=key
$v=field_53c599718b60c

    returns a $field with

    $field[ID]=4032 (wrong language)
$field[label]=Adresse (wrong language)
$field[key]=field_53c5986bcd16e

    Note the not matching key.

  • Thanks, I just found the native cleanup in wp_delete_post() of WordPress.

    Seems the left over meta from old revisions were there because the plugin WP-Optimize was used by client which obiously only deletes main post with direct SQL. Removing this plugin now…

  • This reply has been marked as private.

  • The reason for duplication and a possible solution is posted in the other thread.

  • By adding an own domain to __(), the use of the WordPress ‘default’ domain is avoided which tries to translate the labels using e.g. the general strings of admin backend, which is bad.

    With an own domain it would be possible to create a language file (by hand!) for the label translations. An automated tool won’t work here, see also example 2 here.

    Best choice is to remove the __() and to not auto-translate labels.

    If translation plugins like WPML are used, an own fieldgroup for each language has to be added anyway, so the labels can be set as wanted by the user.

  • Talking to myself here, but for interested readers, found a solution now for this problem, via functions.php.

    For the following code a fieldgroup “Mygroup” is added to two custom post types “aaaa” and “bbbb” via ACF PRO.

    The javascript-code then hides that fieldgroup if not “xxxx” or “yyyy” appears in the slug of the posts of these post types.

    As WPML with 2 languages is used on the site, the code looks for the normal “acf-mygroup” and also “acf-mygroup-2” for the 2nd language, the fieldgroup has the same title in both languages.

    http://pastebin.com/QxyRwst2

  • I now have the clients site again in a state where ACF fields are visible in POST-request but actually not saved to database.

    What can I do to track down the problem and/or provide debug-information?

  • As in current example get_template_directory_uri() is used:

    Note that get_template_directory_uri() / get_template_directory() returns the path to the parent theme if a child theme is used.

    Better use get_stylesheet_directory_uri() / get_stylesheet_directory() to always get the currently used theme.

  • Tried that filter, but still json was created on my clients site.

    Edit: With above filter for acf/settings/json the data from json is not included in the post edit screen as expected.

    But with WPML plugin active, the json folder and files are still created because the settings_save_json filter in core/wpml.php always creates the json folder if it does not yet exist and due to this is_writable() in update_field_group in core/json.php will always return true.

    As a solution I would suggest to add the acf_get_setting('json') validation from include_fields also to update_field_group and delete_field_group in core/json.php.

    WP 3.8.3, ACF PRO 5.0.0, WPML 3.1.6

  • Found by accident where the ‘deleted’ data comes from, a folder acf-json was created within my child-theme folder (why would a plugin put data there?!) which contains a folder for each language and the main language folder contains a lot of .json files with all the deleted fieldgroups.

    This should be fixed.

  • ACF v5 will attempt to be fully compatible with WPML!

    Unfortunately 5.0.0 is not (yet).

    Bought ACF 5 PRO today (as free uograde with repeater for 4.x) and installed on a website with WPML 3.1.6 (latest version).

    Added a fieldgroup with a simple text-field in main language, group shows up as expected on an existing page, but not on translated page.

    No problem so far, had to add a translation to fieldgroup itself first. Now it showed up fine on translated page.

    Went back to main language page, wow, fieldgroup is shown twice(!) there now.

    Thought, ok, let’s go back to start, put translated fieldgroup in trash, put main language fieldgroup in trash, empty trash.

    No more fieldgroups are shown on ACF page.

    But, if I edit the existing main language page again, the two fieldgroups are still there!

    I dig into it and find that acf_get_field_groups() in admin_head still returns data if called on edit page.

    No idea where the comes from. There are no posts with type acf-field-group in wp_posts table. I also disabled the wp_cache lines within acf_get_field_groups(), still the same.

    As soon as I disable WPML or ACF PRO the fields are gone.

    Any idea?

Viewing 13 posts - 26 through 38 (of 38 total)
1 2