Forum Replies Created

Viewing 15 replies - 1 through 15 (of 19 total)
  • @mostafaeslami20 I’ll just leave a working snippet here anyway too since it will be a faster fix for people.

    Just add a custom HTML block and add this code to it. Make sure that the video is set to autoplay and that the overlay and lightbox is turned on. This will also prevent chrome from blocking audio due to it’s autoplay policies. You could tweak this to work without the lightbox too if you needed. It could also be optimized, but this does work.

    <script src="https://player.vimeo.com/api/player.js"></script>
    <script>

    // Waits for a change in the dom
    const observer = new MutationObserver((mutations) => {
    //Checks if the iframe where the video will go has been created (when a thumbnail preview is clicked)
    const iframe = document.querySelector('.elementor-video-wrapper iframe');
    if (iframe) {
    //Creates the player using the src already on the iframe and plays
    iframe.allow = 'autoplay; fullscreen; picture-in-picture';
    const player = new Vimeo.Player(iframe);
    player.setMuted(false);

    player.play().catch(function(error) {
    console.error('Error playing the video:', error);
    });
    }
    });
    observer.observe(document.documentElement, {
    childList: true,
    subtree: true
    });
    </script>



    @aracelil Is there any github issue or something open for this? I have a working solution that fixes the bug that I would be happy to submit as a pull request. Otherwise I can leave a snippet here for anyone else that happens to find this issue.

    Griff

    (@blgerber)

    Hi,

    This is marked as resolved, but seems to be the same issue I am having, so I thought I would add my results to the pool here in case it’s illuminating. New posts seem to be just fine. But posts that were added before we first added Algolia seem to be hit or miss. They will be missing both in the wp search results as well as the Algolia dashboard. Going to a post and hitting update, gets the post to appear however.

    I checked the api logs and found that the initial indexing did find the missing posts, and returned 200. There are some 404s in the api logs, all ending with ?getVersion=2.

    I do have some custom logic with algolia_should_index_searchable_post (used to only index certain pages, and exclude one post type completely). I don’t believe this is causing the problem; the results seem to be exactly as intended. And the custom post types affected by this bug (?) aren’t mentioned anywhere in the code, and it’s odd that some work and others do not.

    It’s not the end of the world because we can force them into results by updating the post, but it is curious.

    Thread Starter Griff

    (@blgerber)

    Thanks for the quick reply. That’s perfect, exactly what I’ll need. Have set up the base workings and very happy with the results so far.

    Have a great day!

    Thread Starter Griff

    (@blgerber)

    Hi @tw2113

    Sorry for the delayed response here! I’ve finally got some time now so was about to dive back into this and see if I can find a solution. Oddly, it seems to be totally working for me now. I was not able to recreate this problem at all (though I did run into some other weird issues that were eventually resolved by doing a different Jet Engine Query approach). Did this get fixed in a subsequent update? Or did I stumble upon some different settings that just happen to work. In any case I’ll leave my settings here for any who happen to come across this with a similar issue.

    I’m using Elementor and Jet Engine. The search page is built in Elementor’s theme builder. In that template I am using Jet Engine listing and listing grid. You’ll then need to create and use a custom query which has “Query type” set to “Current WP Query”. While testing I also recommend to turn off “Cache Query” which is on by default and is a nightmare when trying to debug.

    I do have one more question that has come up that I’m curious to hear your opinion on, but it’s not quite related to this so I’ll make a new post about it in a bit.

    Thanks for the hard work on development for this one!

    Thread Starter Griff

    (@blgerber)

    Actually in case anyone else finds this with similar goals, jet engine supports the count out of the box with dynamic tags! Thanks again for the help and making the community such a positive experience!

    Thread Starter Griff

    (@blgerber)

    Oh wow, you’re my hero! Thanks so much for taking the time to help out! And best part is I’ve learned a little about how all this works. Very cool.

    I’ve broken my counter function, but I’m pretty sure I can hopefully figure out a work around for this one.

    function total_search_results() {
    if (is_search()) {
    global $wp_query;
    return $wp_query->found_posts;
    }
    }

    function search_results_count_shortcode() {
    return 'Total Results: ' . total_search_results();
    }
    add_shortcode( 'search_results_count', 'search_results_count_shortcode' );

    Thanks again for taking the time, Relevanssi is super cool and I’m excited to use it!

    • This reply was modified 1 year, 5 months ago by Griff.
    Thread Starter Griff

    (@blgerber)

    Hi Mikko,

    Thanks for taking the time to respond even though I now see this might not be the most relevant place to post!

    I added your code, and interestingly now I can change the s to q in the url string and the query succeeds and returns results (it did not before), but when I just use the search bar, it still defaults to using s.

    Any other ideas? No worries if not, I have a lot better idea where to explore now!

    Thread Starter Griff

    (@blgerber)

    @mintmedia Bingo! That did the trick. Nice find!

    Thread Starter Griff

    (@blgerber)

    @alexcozmoslabs

    Hi again, I was investigating a little too. In the network tab on a successful submit on the English form when filtering by POST requests, there’s only one which is a 302. This is via path /en/sign-up/?jet_form_builder_submit=submit&method=reload

    But when doing the same on the Spanish form on an unsuccessful submit, there are two POST requests, both completely different than the successful one. One seems to fire on submit via path /es/sign-up/. The other appears to be an ajax request firing periodically related to translatepress. Both are 200. Maybe there is a clue there?

    If you can’t replicate, let me know and I can post screenshots too!

    Thread Starter Griff

    (@blgerber)

    Hi @alexcozmoslabs ,

    Thanks for the quick response! I tried adding the suggested selectors, but still no luck. I thought I got it to go once, but I must have been on the English side by accident. I do see your 03 test as a user though if that’s helpful for diagnosing. Any other tricks I can try?

    Thread Starter Griff

    (@blgerber)

    Wow that’s super cool! Do you by chance offer a free trial so I could test everything and make sure it will work with my use case? 

    Also, I’m wondering about the security  of sending a password this way. Would it be recommended as safe when communicating with zapier?

    Thanks again for your help.

    Thread Starter Griff

    (@blgerber)

    Hi, thanks for the response! I have sent over the info, ticket number 70013. A couple more details, I noticed that the post counts were off too, but I was able to update those in the database manually. Also I neglected to mention that the first time I ran the plugin it gave me red x’s as failed, I ran it again immediately and that time I got the green check marks of success.

    Thanks for your help!

    Thread Starter Griff

    (@blgerber)

    Sometimes it’s the most simple things. Thank you very much for your help!

    Thread Starter Griff

    (@blgerber)

    Hi Tom,

    Thanks for the response. In the custom styling tab the only custom css I see is

    /** Push menu onto new line **/
    #{$wrap} {
    clear: both;
    }

    I don’t see reference to the 200 px there; am I looking in the wrong place?

    Thanks!

Viewing 15 replies - 1 through 15 (of 19 total)