Forum Replies Created

Viewing 15 replies - 46 through 60 (of 61 total)
  • Thread Starter Martin Taylor

    (@docdunning)

    So it sounds like the Block Lab build above does fix the issue, right

    Yes indeed. Or at least, it gives custom taxonomies a chance to be registered first.

    Thanks

    Just to say that one of the things I like about Block Lab is that I can create shortcodes from values entered in a block, just as @sunhawk was/is doing.

    By the way, I prefer to use this structure for templates – it seems a bit tidier.

    theme/blocks/blockname/block.php
    theme/blocks/blockname/preview.php

    Thread Starter Martin Taylor

    (@docdunning)

    Good question 🙂 The taxonomy is created by a plugin, and I realised overnight that my two test sites had different versions of the plugin. After I updated the second site to the later version, all was well. The author must have changed the code around and the register_taxonomy() is now in a “good” place.

    Edit: Confirmed – the earlier version of the plugin had
    add_action( ‘init’, ‘register_taxonomies’ );
    The new version has
    add_action( ‘init’, ‘register_taxonomies’, 3 );

    Don’t know why this was changed – the plugin isn’t supported any more (which is one of the reasons I’m using Block Lab).

    Anyway, you’re not here to support other authors’ work 🙂

    Thanks for the help.

    • This reply was modified 6 years, 3 months ago by Martin Taylor.
    Thread Starter Martin Taylor

    (@docdunning)

    Hmm. I’m just trying this on another WP test site, and the problem has returned. Using get_terms() in the block_lab_add_blocks action returns a WP Error. I can’t work out why at the moment, but just to note that I’m not sure whether this fix has been successful. Sorry 🙁

    Thread Starter Martin Taylor

    (@docdunning)

    No problem, Ryan.

    I’m using the “select” field for situations where there’s only a limited number of options (as in my other post re “get_terms”). In this case there are potentially hundreds of items to pick from, so an autocomplete/suggest would be good.

    I did eventually manage to get an autocomplete working on the WP edit page in a block field, but the field only remembers the keystrokes I made, not the selection from the autocomplete dropdown (despite several attempts to trigger the change).

    Oh well, I’ll just have to use a straight text box and put some validation on it in the preview template.

    • This reply was modified 6 years, 3 months ago by Martin Taylor.
    Thread Starter Martin Taylor

    (@docdunning)

    Thanks, Ryan

    Confirmed – all working. In my theme functions.php, I have this code that now works, whereas previously “get_terms” returned a WP Error object.

    $terms = get_terms( array(
    ‘taxonomy’=>’ddownload_category’,
    ‘hide_empty’=>false
    ));
    $options = array(array(‘label’=>’Select’, ‘value’=>’none’));
    foreach ($terms as $term) {
    $name = $term->name;
    $slug = $term->slug;
    $options[] = array(‘label’=>$name, ‘value’=>$slug);
    }
    block_lab_add_field (‘download’, ‘download-category’,
    array (
    ‘label’ => ‘Download category’,
    ‘control’ => ‘select’,
    ‘width’ => ’50’,
    ‘options’ => $options
    )
    );

    I also went through your test script as per the github page, with no issues.

    Thread Starter Martin Taylor

    (@docdunning)

    Yes, I guess a text field is the most likely. In the past, I’ve used jQuery’s Autocomplete which can have an inline array of data suggestions, or an Ajax source, which is what I’ve more often done. Type in a few letters and it pops up a dropdown with matching items … I’m sure you know what I mean.

    I tried to add some home-brewed JS to the post editor page, but of course, all of the blocks are added dynamically. That makes it rather more tricky to add the Autocomplete widget to the items. I think it would have to be added to the fields when they are added to the page.

    I see that in your Pro version, there’s a “post” field type, which might have a similar sort of functionality, but I’m only using the free version at the moment.

    Thread Starter Martin Taylor

    (@docdunning)

    Gee, this is complicated. I’ve tried a few permalink settings now.

    Using “plain” permalinks:
    – When the calendar page is first displayed, the URL query string is /?post_type=tribe_events (it defaults to month view)
    – If I immediately use the date dropdown to select March, the query string becomes ?post_type=tribe_events&eventDisplay=month&eventDate=2020-03, and it shows March. OK.
    – Now, however, the date dropdown doesn’t work any more. I try to select Feb or April and it still displays March.

    It seems that when there is an “eventDate” value in the query string, the date dropdown doesn’t work.

    By the way, with “plain” permalinks, the “next” month link works OK.

    I think I’d better stop posting now … each time I try it there’s another complication.

    Thread Starter Martin Taylor

    (@docdunning)

    Oh. 🙁

    If I update the permalinks so that the “next month” link works, it breaks the date dropdown at the top of the month view. I can click the down arrow, and select one of the months – the display refreshes but it’s still on the same month.

    Hmmm.

    Thread Starter Martin Taylor

    (@docdunning)

    OK, this seems to be to do with permalinks. I tried it on another site of mine, and the “next month” link was working OK. So then I updated the permalinks on the original test site and that link started to work. Originally I thought it might be to do with using the “Custom” permalink type, but that works as well.

    May be that it just needs the permalinks to be updated and it works.

    Edit: In my original test site, the “next month” link href was “sitename/events/month/2020-03/”. That was the one that failed. In the site that works, the href on the link is “sitename/?post_type=tribe_events&eventDisplay=month&eventDate=2020-04&page&name=wp-test3”

    Thread Starter Martin Taylor

    (@docdunning)

    Hi @bordoni

    No JS errors are reported. I tried tracing the click event through the script, and could see where it was going to do an Ajax call to “….index.php/wp-json/tribe/views/v2/html” but it was difficult to see what happened after that. The three dot “loading” image was displayed, but then it just displayed the first month again, not the next one as I expected.

    Happy to help with other diagnostics if you need 🙂

    Hi

    Have a look at the reply to my question about this:

    https://wordpress.org/support/topic/breakpoint-filters-do-not-work/

    Gustavo provided a link to the new way of doing it.

    Thread Starter Martin Taylor

    (@docdunning)

    Thanks for confirming, Trynda. Let’s hope there’s a fix on the way fairly soon.

    Thread Starter Martin Taylor

    (@docdunning)

    Thanks for the help, Gustavo. That works 🙂

    OK, the view needs a few more changes to look good when it’s not full width, but I can do that. At least I can still see the names of the events in the calendar.

    Thread Starter Martin Taylor

    (@docdunning)

    OK, so I’ve found that the problem is caused by the “Upcoming Events” widget. It has an option to “Generate JSON-LD data”. If that is checked, then it causes an error in breakpoints.js. If I uncheck the option, then no JS error.

    This does look like a compatibility issue for Modern Tribe to investigate, given that it’s between two of the plugin’s components.

Viewing 15 replies - 46 through 60 (of 61 total)