Forum Replies Created

Viewing 15 replies - 16 through 30 (of 9,734 total)
  • Thread Starter Mikko Saari

    (@msaari)

    Problem solved, it seems that it just took some time.

    Plugin Author Mikko Saari

    (@msaari)

    Yes, that is normal. The debugging view shows all the distinct words in the post in alphabetical order, with stopwords removed.

    Plugin Author Mikko Saari

    (@msaari)

    Relevanssi doesn’t require any extra steps. Searching in Hebrew works fine. Relevanssi can manage any language that can be represented in UTF-8 characters, and that uses spaces to separate words.

    Plugin Author Mikko Saari

    (@msaari)

    As far as I can tell, ACF Better Search should not affect the Relevanssi search in anyway; it modifies the default WP Query and Relevanssi ignores it when doing searches.

    The Relevanssi debugging output you pasted to your posts shows that for the post, the keywords indexed are “detektivky”, “tomas”, “este” and “list-acf2-page=27&list-bookSameGenre-page=7&list-sameGenre-page=10&q={750a35524fe0156cd80cd59311fd226f2c625470debd6f9835acad4a670a525d}2Frecenze{750a35524fe0156cd80cd59311fd226f2c625470debd6f9835acad4a670a525d}2Fdenicek-moderniho-fotra{750a35524fe0156cd80cd59311fd226f2c625470debd6f9835acad4a670a525d}2F”.

    You can also see that the post content Relevanssi sees is long and has all the content of the post (“Post content after relevanssi_post_content”), but then gets turned into “list-acf2-page=27&list-bookSameGenre-page=7&list-sameGenre-page=10&q=%2Frecenze%2Fdenicek-moderniho-fotra%2F” (“Content, tokenized”). So, somewhere between running relevanssi_post_content and tokenizing, the content is lost. What happens there?

    There are a couple of more hooks you can check.

    add_filter( 'relevanssi_post_content_after_shortcodes', function( $content ) {
    error_log("------ relevanssi_post_content_after_shortcodes: ");
    error_log($content);
    return $content;
    } );

    and:

    add_filter( 'relevanssi_post_content_before_tokenize', function( $content ) {
    error_log("------ relevanssi_post_content_before_tokenize: ");
    error_log($content);
    return $content;
    } );

    Add these to your functions.php, save the post 153115 and then check the server PHP error log. What does it show? Is the normal content replaced by “list-acf2-page=27&list-bookSameGenre-page=7&list-sameGenre-page=10&q=%2Frecenze%2Fdenicek-moderniho-fotra%2F” after the first one or the second one?

    Plugin Author Mikko Saari

    (@msaari)

    The problem is not only the title: it seems the vast majority of the post content is also not indexed. The post content becomes “list-acf2-page=27&list-bookSameGenre-page=7&list-sameGenre-page=10&q=%2Frecenze%2Fdenicek-moderniho-fotra%2F” –?and there’s certainly more to the post than that. There’s something on the page that breaks the Relevanssi indexing.

    Does that string ring a bell for you? Where might it be coming from? If you recognise which element on the page that is, I’d start by making sure it is removed from the page before Relevanssi indexes the page.

    The title is also missing; I can’t tell from the debugger output where it’s going. The problem may be the same, so let’s start with the content.

    Thread Starter Mikko Saari

    (@msaari)

    I don’t have the reply feature enabled in the front-end, so I added a new comment. Looks like replying in thread works fine… I need to remember to reply in thread from the WP admin in the future then, it seems.

    Plugin Author Mikko Saari

    (@msaari)

    Looks like that menu search form doesn’t use the get_search_form filter hook to create the search form, so that function does nothing. You can ask the Divi support if there’s a filter hook that can be used to modify the HTML code of the search form. If there is, then this is easy to fix, but if there’s no such filter hook, then installing Live Ajax Search to that search form is very difficult.

    Plugin Author Mikko Saari

    (@msaari)

    When Relevanssi indexes the post object field, it doesn’t see the post object; it sees the post ID. You need to use the post ID to fetch the contents from the related post so that Relevanssi can index everything you want from the post. See https://www.relevanssi.com/knowledge-base/indexing-acf-relationship-content/.

    Plugin Author Mikko Saari

    (@msaari)

    It’s definitely not easy – the WordPress way is to check capabilities, not roles. It would probably be easiest if you could create a new specific capability for each role just for the sake of checking the role.

    The WP_User object, for example, has methods for adding a role, removing a role and setting user roles, but no method for checking the user role. The only method is get_role_caps(), which returns all the capabilities the user has from their roles.

    In any case, this no longer has anything to do with Relevanssi. I recommend you ask a wider audience – try your luck on more general WP support forums, perhaps someone can give you a good method for checking user roles. I don’t know one – I’ve always used capabilities because that’s easy.

    Plugin Author Mikko Saari

    (@msaari)

    Relevanssi doesn’t require using the main query. Using the main query is a good idea for performance reasons because otherwise you’ll end wasting the main query. It’s not mandatory, though. The easiest way to deal with it is to set the relevanssi query parameter to true: add $args['relevanssi'] = true; before you run the WP_Query. Does that fix this?

    Plugin Author Mikko Saari

    (@msaari)

    In normal WordPress use, you don’t check for roles, you check for capabilities. If you want to check if someone is at least an editor, you check current_user_can( 'edit_others_posts' ). So, something like this:

    add_filter( 'relevanssi_post_ok', 'rlv_member_check', 10, 2 );

    function rlv_member_check( $post_ok, $post_id ) {
    // An array of post IDs that only editors can access.
    // This can be created manually like this or automatically, whatever is your criteria.
    $editor_posts = array( 1, 2, 3, 4 );

    $post = get_post( $post_id );
    if ( in_array( $post_id, $editor_posts ) && ! current_user_can( 'edit_others_posts ' ) ) {
    // Post is among the editor posts, and the user is not an editor.
    $post_ok = false;
    }
    return $post_ok;
    }

    Now, I don’t know Members affects this. If it just offers an easy way to extend the WordPress roles and capabilities system, you’d do it like this, but if it’s something else, then you need to replace current_user_can() with whatever works with Members. The Members support forums will help you with that.

    Thread Starter Mikko Saari

    (@msaari)

    (Oops, a duplicate post…)

    Thread Starter Mikko Saari

    (@msaari)

    Thanks! And yeah, working with the state transitions can be a pain ??

    Plugin Author Mikko Saari

    (@msaari)

    I think you need to ask Bricks support. What you’re doing is how it works with normal themes, but Bricks isn’t a normal theme.

    Plugin Author Mikko Saari

    (@msaari)

    Do you mean the duplicate result after “Load more”? I think that’s some problem with the “Load more” feature. I see it requests the page 2 with posts_per_page set to 3, so it shows the post #4 the second time. The posts_per_page should match what you’re showing on the first page to avoid the duplicate.

    Fixing that is Bricks stuff, and I can’t help with that, I don’t know how Bricks works.

Viewing 15 replies - 16 through 30 (of 9,734 total)