Support

Account

Register Login

Forum Replies Created

  • Right, here it is! https://www.advancedcustomfields.com/blog/acf-pro-5-8-0-beta3/

  • Good call, didn’t think we could use acf_maybe_get_POST('post_id') on the frontend! Much cleaner, thanks.

  • Digging through code, it appears that Gutenberg blocks are just custom post type. What’s happening is that block (and so their previews) are standalone: $post_id is actually the block ID! On the frontend, blocks are rendered inside a post, but it’s not always the case. So the problem is a little trickier than I first thought…

    I found a temporary workaround though: add this (second line) in /wp-content/plugins/advanced-custom-fields-pro/includes/gutenberg/blocks.php line 403:

    `
    // render_callback vars
    $content = ”;
    $is_preview = true;
    $block[‘data’][‘post_id’] = acf_maybe_get_POST(‘post_id’);
    `

    Next edit your custom block template, add this at the top:

    `
    if(!$GLOBALS[‘post’] && $block[‘data’][‘post_id’]) {
    setup_postdata($GLOBALS[‘post’] =& get_post($block[‘data’][‘post_id’]));
    }
    `

    And don’t forget to add this too at the end:

    `
    wp_reset_postdata()
    `

    Now you can access current parent post datas. Functions like the_title() work too.

    Hope it helps, and hope ACF team will find a cleaner way to add this feature 🙂

  • Just clarifying for future readers with a bit of code! Inside a block, you’d need to force the ID of the parent current post, like this: get_field('myField', get_the_ID())

  • Seems fixed in 5.8-beta2 😉

  • When editing your page, you can also type this in your console :

    jQuery('.acf-button-delete').click();

    It will trigger a fake click on **every** delete button on image fields. Dont’ worry it won’t delete anything, just cancel the selection of the image that, you know, you can’t do anymore because the link is invisible… So you might select again other image fields.

    But if you are comfortable with debug tools, you can precise which field to apply the hack this way :

    jQuery('[data-field_key="field_54ca1472acea6"] .acf-button-delete').click();

    Hope this helps.

  • The correct constant is ICL_LANGUAGE_CODE :

    http://wpml.org/documentation/support/wpml-coding-api/

    Prefixing is not really maintainable because I don’t know which languages our client will add… And can become a mess.

    Creating a “global variables page” is what I was doing before using ACF Options… So I’d rather not regress 😛

    For now I think I will replace “translatable” fields in the Options page by Repeaters ones, in which the key will be the language code.

    It’s a shame that it’s not better handled, is it on your roadmap to enhance this Elliot ? It’s really a pleasure to work on complex and multilingual sites with ACF and WPML, except this part 😉

  • That would be a huge work and we won’t never be sure to have listed them all. Plus, how would you decide if a name is forbidden or not ? And it would be a shame if we can’t create fields simply named “title”, “description”, or “picture” that are very common names, maybe used by other plugin, now or in the future ?

    IMO, the fact that All In One SEO is actually migrating their DB to prefixed field names proves that it’s the good way to do. After all, even WordPress itself prefix its tables names !

    Misunderstand me not : I think that ACF should interpret field names itself, in order to not surcharge the templates code uselessly. For example, my code would still be get_field('description') but it actually would check the acf_description field in the database, according to the “prefix option” set in the back-office. The transcription would be transparent for developers.

  • @sireneweb How would you be sure to list all custom field names used by other plugins ? Prefixing by “acf_” would ensure by 99,99% that there will never be another conflict I think.


    @elliot     I didn’t mean that ACF should check other field names or other installed plugins, it would be crazy ! I just meant that a prefixing option would be safer. Because both ACF and All in One SEO Pack are well known and there’re a lot of chances that someone else use those 2 plugins and create a field named “description”… just like me. I’m not sure my case is that rare. I might not be aware of the implications of such a new feature however ?

Viewing 9 posts - 1 through 9 (of 9 total)