Support

Account

Register Login

Forum Replies Created

  • @rockgeek

    Shame there isn’t any direct support for it here

    There isn’t because this is not related to ACF directly. It’s related more to the WordPress database structure (on which ACF relies) than to ACF itself.

    Implementing such a functionality doesn’t depend on how the post and fields have been created. So it makes no difference if you defined field using ACF, other plugin or even manually using WordPress native custom fields support.

    Firs of all you should read about WP_Query and how to write meta queries. If you want to filter existing query (add/remove/modify) then pre_get_posts filer will be useful.

    If you want I can send you a simple example of a search form built this way.

  • This is some kind of a solution but not the one I have been looking for. But I’m aware that implementing gallery field for non-logged-in users would require a lot of effort (It would probably require to re-implement the WP uploader).

    Thanks.

  • Sure

    
var imageInputOnChange = function ($input) {

    // This is the only way to check what field has been changed.
    if ($input.context.name !== 'acf[field_56d99d7de115e]') {
        return;
    }

    // Finding the image requires DOM traversing
    var $image = $input.closest('.acf-image-uploader').find('img');
    
    // Do something when the uploaded image is fully loaded
    $image.on('load', imageOnLoad);
};

var imageOnLoad = function (image) {
    // Do something...
};

acf.add_action('change', imageInputOnChange);

    So as you can see using this hook requires some additional effort to determine which field’s value was changed. That’s why I’ve posted this request.

  • IMO, there’s a room for many improvements in the JS hooks. Not only adding missing hooks, but also providing more data (like a previous input value, field name, etc) in the callback function would be welcome.

  • I found more issues. this in the callback function is a reference to window. IMO the field settings (including field name and field type) should be attached to this.

    In the current implementation, this hook isn’t very helpful. It requires too much effort to determine which field’s value was changed. The best way at the moment to find which field is it is to check e.context.name which returns a string like this: acf[field_56d99d7de115e].

    // Edit:

    An example:

    
var imageInputOnChange = function ($input) {

    // This is the only way to check what field has been changed.
    if ($input.context.name !== 'acf[field_56d99d7de115e]') {
        return;
    }

    // Finding the image requires DOM traversing
    var $image = $input.closest('.acf-image-uploader').find('img');
    
   // Do something with the $image.
};

acf.add_action('change', imageInputOnChange);

  • I was wrong. There is a undocumented hook (acf-input.js, 2483 line), it’s called… ‘change’ 🙂
    So it’s possible to listen for the ‘change’ event.

    It would be good to create a documentation for JS hooks anyway.

  • Thanks, I already did it, but I was looking for a better solution. I don’t want to rely on DOM. The HTML structure might change in the new version and my JS will stop to work.

    I’ve posted a feature request.

  • I’ve just noticed that the popup is required, but for hierarchical taxonomies only. For flat ones, there’s no need to show the modal.

  • How is the existence of WP editor related to the ability of adding custom fields to the posts archives? I don’t get it. We’re able to register custom fields to custom options pages, user pages and widgets, etc. There’s no editor on these pages as well.

    Maybe my explanation in the first post wasn’t clear enough. I just want to show custom fields on archive pages, but store them the same way as options pages are stored at the moment. The only difference would not using the default ‘options’ string as an ID but some auto-generated id: for example acf-archive-{post_type_name}

    An options page for archive pages could be registered automatically if the custom field group that belongs to post archive is defined.

    Fields groups could be shown before or after the posts list table.

    The only thing I’m worried about is that I haven’t found yet a proper action to hook into (I mean the action that runs before and after the posts list table). Maybe there’s no hook for such things?

    The only hooks I found are all_admin_notices and in_admin_footer.

  • http://support.advancedcustomfields.com/forums/topic/get_field-doesnt-return-a-value-when-fields-are-created-with-update_field/

  • http://www.advancedcustomfields.com/resources/query-posts-custom-fields/

  • So my solution is to register as many options pages as the number of languages we have. Each options page has a unique page_id:

    foreach (['ru', 'en', 'es', 'de'] as $lang) {

    acf_add_options_sub_page([
        'page_title' => "Page name ${$lang}",
        'menu_title' => __("Page name ${$lang}", 'textdomain'),
        'menu_slug' => "page-name-${lang}",
        'post_id' => $lang,
        'parent' => 'parent-slug'
    ]);

}

    Then there’s a need to create a field group and duplicate it as many times as the number of options pages we have registered. Each options page has it’s own ID so fields names can be the same.

    Now we can simply do:
    the_field('my_field_name', 'en');

    or even:
    the_field('my_field_name', pll_current_language('slug'));

  • @dabernathy89
    According to what @hube2 said it’s possible, bot not implemented because of:
    1. The complexity (it requires much more effort to “guess” the field name: more DB queries and matching location rules, etc).
    2. Possible performance issues.

    IMO it would be great if such feature was implemented. There could be a function like: acf_get_field_name_by_key();

  • OK, I mark it solved. I’ve just found that options page doesn’t require an ID of existing page. I can use any string as a post_id.

  • I didn’t expect such detailed explanation. Thank you very much.

  • @dabernathy89

    There is nothing special about manually saving a post that means it should be the only way for ACF to generate these meta values.

    This is exactly what made me to write this post!


    @hube2
    Thank’s for very detailed explanation. But I’m still wondering is it possible to programmatically do the same “magic” which happens when the post is saved manually.

  • Thanks.

    This is what I’ve already done and it works of course. But it’s a bit annoying, especially when you have plenty of custom fields.

    I’ve read the documentation before posting the first post, but the explanation isn’t 100% clear to me. I still don’t fully understand the following issues:

    1. Why the post don’t exist yet when it’s created with wp_insert_post()? wp_insert_post returns the post ID, so I assume that post is already created.
    2. When I use fields names instead of fields keys then I can see fields values when I enter the post edit page in the WP admin. How is it possible?
    3. When I re-save the post manually then values set previously by update_field() function (using fields names, not keys!) are properly saved. How is it happening? What happens when I save the post manually, and why it can’t be done programmatically? I assume it’s not any magic 🙂

  • Thanks.

  • I know it works like it was meant to work, but IMO it’s not a proper way.

    I know that ACF JSON directory should be writeable and ACF documentation says about it.

    I found this “bug” because the server configuration was wrong. It was OK on my local environment, but didn’t work on production. So it was a bit confusing and it wasn’t so obvious that ACF JSON directory is not writeable. I spent some time to figure it out.

    IMO there should be a notice displayed, at least, when WP_DEBUG is set to true.

  • I know it’s not a trivial task and it requires much more work than making a simple WP_Query. But still, it’s doable and it would be a great improvement, especially for new users who might not fully understand what these rules mean.

    Remember that we’re in a “feature request” sub-forum, not in a “must-have features request” 🙂

  • +1

  • Hi @Jonathan

    I can partially agree. Yes, it’s very easy to implement such a feature on one’s own… but we could say the same about other ACF features. For example about return value option of image field. Why do we need a choice between url and array when we can simply do:
    <?php echo get_field('image')['url']; ?>

    The second reason why such a feature could be implemented is related to what you have said. Less advanced users might not now that fields should be escaped, so for URL field this option could be set to true by default because the most common use case for URL field is to output its value inside a href attribute.

  • Great. tx.

  • Thanks a lot for your detailed explanation.

  • Thanks. This is exactly what I’m looking for.
    But it would be good if such a feature was available out of the box.

    // Edit;
    I found a little bug in the example you’ve provided. There’s a typo: isset($option['post_id'] instead of isset($options['post_id']

    // Edit 2;
    I’ve found another bug. $page_level doesn’t return a correct value.
    The logic is overcomplicated. It could be simplified:
    $page_level = count(get_post_ancestors($options['post_id'])) + 1; works fine.

    Here’s a fixed version: https://github.com/wujekbogdan/acf-filters-and-functions/blob/patch-1/page-nth-level-location-rule.php

    One more comment:
    There’s one disadvantage of this solution. acf/location/rule_operators filter doesn’t allow to set operators for a specific rule. It’s a general filter that applies for all the rules. But as far I know there’s no other option at the moment.

Viewing 25 posts - 26 through 50 (of 55 total)
1 2 3