Support

Account

Register Login

Forum Replies Created

  • Probably because the *white-boxed* things are Groups/Repeaters etc, rather than individual fields, is that right?

  • FYI, @nicholasarehart’s code seems not to work for me.

  • Looping back on this, I’m surprised to find I can natively set a term-to-term relationship across terms in two different taxonomies (person and company) using wp_set_object_terms() …

    $term_taxonomy_ids = wp_set_object_terms( $bill_term_id, $microsoft_term_id, 'company' );

    They are just objects.

    And I can retrieve the company connected to a person with wp_get_object_terms like…

    $bills_company_terms = wp_get_object_terms($bill_term_id, 'company');

    However, putting a backend UI on that is another matter. Don’t know how to accomplish that. Any ideas?

  • This plugin is no longer showing a map on the front-end for me.

    It works fine in the back-end.

    Here is the code that manifests in the front…

    <div class="leaflet-map" data-height="350" data-map="leaflet" data-map-lng="7.0174313" data-map-lat="43.5507876" data-map-zoom="14" data-map-layers="[&quot;OpenStreetMap&quot;]" data-map-markers="[{&quot;label&quot;:&quot;Palais des Festivals, Boulevard de la Croisette, Cannes, France&quot;,&quot;default_label&quot;:&quot;&quot;,&quot;lat&quot;:43.5507815,&quot;lng&quot;:7.0174321}]"></div>

    The following stylesheet is included at the bottom, and goes to a working file…

    <link rel="stylesheet" id="leaflet-css" href="http://www.example.com/wp-content/plugins/acf-openstreetmap-field/assets/css/leaflet.min.css?ver=1.1.9" type="text/css" media="all">

    That is with the Leaflet JS render setting enabled.

    The iFrame render setting actually still works.

    I don’t see any leaflet.js-type file at the bottom of source; don’t know if that’s necessary.

    Anyone know what’s going on?

  • Top spamming.

  • Thanks.

  • The linked OpenstreetMap field plugin is good.

    It would be useful for ACF to consider OpenStreetMap.

    Google Maps is excellent, but Google’s API switch exposes people to paid API usage, possibly with unknown expense consequences.

    I just switched between these fields and now plan to shut down my Google Maps API account.

  • Answer – the correct formulation is…

          'meta_query' => array(
        array(
          'key'     => 'Topic',
          'value'   => "12057",
          'compare' => 'LIKE'
        )
      )

    In full:

        $args = array(
      'taxonomy' => 'event',
      // 'order' => 'ASC',
      'hide_empty' => false,
      'hierarchical' => true,
      // 'parent' => 0,

      'meta_query' => array(
        array(
          'key'     => 'Topic',
          'value'   => "12057",
          'compare' => 'LIKE'
        )
      )

    );

    $events = get_terms( $args );

    Specifically, it seems 'compare' => 'LIKE' needs to be present.

    Initially, I had thought the solution was to use double quotes on the value, which I inferred from @hube2’s response to another question.

    But actually it works with single or double. The clincher is the present of 'compare' => 'LIKE'.

  • Okay, yes.

    I’m going to need to first check if the field contains anything…

    If it does, then I can use array_push to add another value to the array and then update_field with the completed array values.

    If not, I am free to add just the singular new value, even as a string.

  • Hmmm…

    anything that can be a single object is a post. It’s not how I’m going to relate them that’s important but what they represent. A taxonomy is uses when multiple descriptors can be applied to an object.

    In my case, the primary case is that some existing Posts should relate to an Event. Eg. Conference reports from “CES 2018”, from “Cannes Lions 2019”. I guess multiple posts from a single given event could constitute the “multiple descriptos applied to an object”.

    But there will also be some cases where the thing that relates to an Event will not be Posts at all but, rather, some indication that I had a *function* at the event – eg. speaker/host/panelist. That’s something I’d like to express on the Event page but also collate eg. “all events I hosted”. Regardless, these don’t seem to be expressions that arise out of a relation to any Post content.

    So that seems like a bit of both Taxonomy use-case and Post use-case.

    I would probably also create a “user” post type of some kind, maybe call it “speaker” that may or may not be related to actual site users

    I know where you’re coming from.
    My forethought on this one is deliberate, even if it may complicate things.
    I actually already have a Taxonomy called “People” with a couple of thousand terms, which would be suitable. But, for the forseeable future, the only person I would want to relate to Event roles like host/panelist is… me… and I’m a User. In the future, I can theorise extending the same to other members/Users of the site. Those people would also have Post content and I would be one of the Users alongside them, so it seems natural to think about linking to a User.

    Stepping back to think aloud…
    Let me see…
    If “Events” were a Taxonomy, perhaps I could just not sweat the missing bidirectionality caused by the absence of a two-way Term-to-Term relationship. Thinking about the contexts in which information would be displayed, where things can be saved without needing to see it on both sides, and what’s really required…

    Event object / single term page:
    – Seve/relate the majority of fields here…
    – inc User event role (would not naturally/conceivably be set on the User profile anyway)
    – inc Organisation (could arguably want to set related events on the Organisation page as well as Event edit, but is it really essential?)
    – inc Topics (set the Topic on the Event edit, not the Event on the Topic edit).

    Post object / single post page:
    – Tag the post with the relevant Event, from Post Edit. I shouldn’t fret that I couldn’t do it the other way around.

    After all, in the case of native WordPress relationships, I shouldn’t justifiably expect to use a Term page to set and unset Posts, should I?

    So maybe I should just use Events as taxonomy, then relax about setting some related fields in the right contextual place and not expect to see the related pieces in their mutual backend locations?

    So, sometimes I would be displaying terms, sometimes Posts, depending on the context of the theme file.

    Hmm…

  • Okay,

    – I see the guide on Bidirectional Relationships is a filter that does exactly that… when you relate a post on one side, the code updates to make the inverse link on the other.

    – @hube2’s alternate code is a variant that does not have the above code’s requirement of using the same field name on each side.

    This clears up my Post-to-Post understanding.

    But it doesn’t quite get me to finally determining which route is best for my “Event” type… Post or Taxonomy?

  • Err… I think I see something regarding the “Querying Relationship Fields” doc…

    If you have to query using get_field() on one end but get_posts() on the other, I’m not sure that’s *real* bidirectionality.

    Per the doc…

    “Related Viewpoints”, set on an Article post:

    set 3 x ‘Viewpoint’ posts:

    loop through $related_viewpoints = get_field('related_viewpoints');

    “Related Articles”, set on a Viewpoint post:

    the Article on which I set the Viewpoint post is not seen on the Viewpoint edit:

    have to return it/them with get_posts():

    So, there doesn’t seem like real bidirectionality here. To truly link them, you’d have to manually add the equivalent linked posts on each side.

    Could this be because I used a different field name on each side? related_articles and related_viewpoints. I don’t think so.

    – It looks like the doc on Bidirectional Relationships would implement this.

    – And @hube2’s plugin is a variant of that.

  • And is this native bidirectionality built-in if Events were to be a Taxonomy?

    Ie between

    * the Term and Posts? (add posts Relationship to Term field group, and add Term selector to Posts field group?)

    * the Term and Terms (add different Term selector for each Taxonomy to the opposite Taxonomy’s field group?)

    * the Term and Users (add Term selector to User profile field group, and add User selector field to the Term field group?)

    Is there then a two-way relationship between any of those things?

  • What, the (post) Relationship is bidirectional by default??

    I really didn’t glean that from Relationship docs.

    Ah-hah, it links to https://www.advancedcustomfields.com/resources/querying-relationship-fields/

    I have to try that!

    Where does this leave

    Are they ir/relevant?

    Thanks, @darusharp.

  • As @hube2 points out in the other linked thread, the method to use is…

    In the acf_add_options_sub_page declaration, add 'post_id' => 'article' as a parameter.

    This is how the field data, as entered on the Options page corresponding to my post type, will be saved.

    On the display end, display using $featured_posts = get_field('featured_posts', 'article');

    ‘article’ and ‘report’ are both used.

    In my case, at the display end, I use $queried_object->name to dynamically infer either ‘article’ or ‘report’ post types.

    Thanks.

  • I experimented and think I figured it out…

    If I use 'post_id' => 'options2' in acf_add_options_sub_page per your suggestion, then where corresponding options2 needs to appear on display is…

    $featured_posts = get_field('featured_posts', 'options2');

    This suggests I can use…

    $featured_posts = get_field('featured_posts', 'article');

    $featured_posts = get_field('featured_posts', 'report');

    To display through my singular template fragment, showcase.php, I’m going to need to write a little piece to determine whether to call “article” or “report”.

    You’re right, this is not at all clear from docs. You should write ACF: The Missing Manual.

    BTW, I get a weird white screen when I save these options for the first time.

  • Hmm,

    Okay, adding 'post_id' => 'options2_featured_posts' successfully separates things in the backend…

    // Support showcase Features for this post type, via ACF

if( function_exists('acf_add_options_page') ) {

	// add sub page
	acf_add_options_sub_page(array(
		'page_title' 	=> 'Articles Features',
		'menu_title' 	=> 'Articles Features',
    'menu_slug'   => 'articles-features',
    'capability'  => 'edit_posts',
		'parent_slug' 	=> 'edit.php?post_type=article',
    'position'    => false,
    'icon_url'    => false,
	'post_id' 		=> 'options2_featured_posts'
	));

}

    But what does this mean for how I should call/display the resulting data?

    So far, I have used a common template part, “showcase”, to serve up the features in a consistent layout, including…

            // Must get IDs from ACF options page...
        $featured_posts = get_field('featured_posts', 'option');

    … as seen in the docs.

    How should that change to reflect options2_featured_posts?

    Do I perhaps have an issue using an underscore in the original field name?

    Thanks.

  • @hube2 Thanks…
    But I am currently using acf_add_options_sub_page without acf_add_options_page().

    The following code…

    // Support showcase Features for this post type, via ACF

if( function_exists('acf_add_options_page') ) {

	// add sub page
	acf_add_options_sub_page(array(
		'page_title' 	=> 'Articles Features',
		'menu_title' 	=> 'Articles Features',
    'menu_slug'   => 'articles-features',
    'capability'  => 'edit_posts',
		'parent_slug' 	=> 'edit.php?post_type=article',
    'position'    => false,
    'icon_url'    => false
	));

}

    … makes a sub-page underneath the “Articles” post type menu entry.

    The post_id parameter seems to pertain to acf_add_options_page() and not acf_add_options_sub_page.

    Is there another way, eg. to use acf_add_options_page() for what I want?

    I intended to integrate the options page in to the post type menu folder since, rather than break it out elsewhere in the nav, since it pertains to the corresponding post type.

  • @briandichiara How would I implement that workaround for the case I describe at https://support.advancedcustomfields.com/forums/topic/same-relationship-field-for-multiple-post-options-sub-pages/ ?

    (ie. I want an Options sub-page or similar to store different sets of featured-post Relationships for two different custom post types).

  • You used a field group, but did you use a taxonomy field or eventually create a custom taxonomy

    Whilst I experimented with this, I chose ACF Checkbox for all such “company” sub-descriptions, as there are multiple of them. On the one hand, I feared over-use of taxonomies but, on the other, it would have certainly afforded me native taxonomy term page creation like this.

    So,

    Method 1) Page:
    Write a template file, apply it to a Page and pass the ACF Checkbox “tag” values to the Page, in a link from wherever I’m linking. I guess I’m going to need to learn how a Page can pick up those parameters and how to interpret them (Eg. https://dmjcomputerservices.com/blog/passing-url-parameters-to-a-wordpress-page/ ?)

    Method 2) Rewrite rules:
    So the page in this case is “company-type”?

    And then add custom rewrite rules to WP to transform the URL and add the correct query string

    So would this effectively be the same method as Method 1), ie. it needs to utilise URL query string parameters? And then it just uses rewrites to make the user-facing URLs prettier?

    Thanks.

  • For the historical record, the solution (per tech support) is…

    Via update_field(), Checkbox needs to take an array, not a string item.
    So my items had to be passed inside array() (convert them to array for supply to update_field().

    Apart from one of my lines which was already an array.

  • Okay, thanks John.
    Back to support…

  • Still curious to solve this. Is there a URL at which I can see my support tickets? I was sure I posted (since the forum rejected it), just before the busy period, but can’t find anything and feel like I may be going crazy. Thanks.

  • Per my last message, using just the field key…

              // sector
          $field_key = 'field_5c1bb19b00004';
          update_field($field_key, $json_object->category->sector, $org_id_prefixed);

    … successfully saves the value – but still not in such a way as to solidify it as a Choice.

Viewing 25 posts - 26 through 50 (of 107 total)
1 2 3 4 5