Support Forums

The forums are closed and will be removed when we launch our new site.

Looking for support? You can access the support system via your account.

Forums › Forums › Search & Filter Pro › Autocount does not seem to work (multisite installation with 2 sites)

Viewing 10 posts - 1 through 10 (of 15 total)
1 2
  • webteam webteam
    (Private)  April 15, 2020 at 5:04 pm #240165

    Hi Trevor,

    We’re using a Multisite setup with 2 sites: Site A (Dutch language site) and Site B (English language site).
    Both are using S&F Pro (enabled per site). We have developed a custom plugin which adds custom posts to Site A automatically and Site B at the same time.

    This works with S&F Pro and the numbers S&F Pro shows are correct on Site A. However, the numbers are incorrect on Site B, unless we manually rebuild the cache (by pressing the button in the settings) on Site B.

    We’ve implemented ‘search_filter_update_post_cache’ to automatically update the cache on Site B, but this does not fix the issue with Site B displaying the wrong numbers.

    Can you give us some hints on what might cause this issue on Site B?

    Thanks in advance!

    Trevor Moderator
    (Private)  April 16, 2020 at 12:52 pm #240251
    This reply has been marked as private.
    Ross Moderator
    (Private)  April 17, 2020 at 9:57 am #240384

    Hi there!

    It sounds like a complex setup, we’re going to have to break this down so I can understand what’s going on exactly to help you further.

    Can you explain a little more about how you publish posts to two different sites at the same time?

    And how exactly is this being added to the DB?

    If you are using any caching plugins, can you disable and test?

    Thanks

    webteam webteam
    (Private)  April 20, 2020 at 9:37 am #240553

    Hi Ross,

    Sure, we’ve built a plugin which based on a cronjob (wordpress or system) creates a post for a Dutch language site and an English site. This post is inserted in each site using wp_insert_post(). We use switch_to_blog() to select the required site. It seems the S&F Pro Cache does not invalidate after a wp_insert_post()? Can you tell me how S&F decides when to rebuild the cache automagically?

    I’m testing this on my local development environment without caching plugins.

    Look forward to your response,

    Ross Moderator
    (Private)  April 20, 2020 at 10:29 am #240559

    Hi again

    In your cron job (assuming its being set by php somewhere) – do you have an exit at the end of your script?

    I think if S&F autodetects an wp_insert_post from admin, it just collects the Post ID (it can be multiple post IDs depending on how many posts are inserted in the request) , and then build the cache for them on wp_shutdown

    wp_shutdown never gets fired if you use exit but if you use wp_die it should and then S&F should build the posts.

    Let me know if that makes sense / is worth trying!

    As an FYI, the way the cache works, is that it hooks into various WP events – save_post (which is triggered from wp_insert_post, updated_postmeta, set_object_terms)

    And then stores the IDs of any posts that have been modified in anyway.

    Then on wp_shudown, we loop through the IDs and update the cache.

    If you use our action search_filter_update_post_cache – it doesn’t not work the same, but instead forces a rebuild right there and then of the Post ID supplied.

    Thanks

    webteam webteam
    (Private)  April 23, 2020 at 3:59 pm #241143

    Hi Ross,

    We’ve found the issue.

    The culprit seems to be the way you are handling database table names in includes/class-search-filter-post-cache.php in the constructor. When using switch_to_blog() the wrong prefix is set (previous site) and the cache of the site we’ve switched to is not used. Instead of the prefix of the site we were in before the switch_to_blog() is used. This can have bad side-effects in WordPress Multisite installations, as we’ve experienced.

    The solution is to use $wpdb->prefix and the table name at the last moment e.g. in or just before doing the query instead of setting the table name including the prefix in the constructor. This allows switch_to_blog() to set the correct prefix.

    We are working around this issue by setting the correct prefix explicitly in the global search_filter_post_cache instance, but it would better for all your plugin’s clients if this can be fixed in Search & Filter Pro.

    In case you need help with this, or if anything I wrote is unclear let me know. I’m happy to help you getting this fixed for everyone.

    All the best,
    Björn Wijers

    webteam webteam
    (Private)  April 23, 2020 at 5:10 pm #241159
    This reply has been marked as private.
    Ross Moderator
    (Private)  April 23, 2020 at 5:14 pm #241161
    This reply has been marked as private.
    webteam webteam
    (Private)  April 23, 2020 at 5:42 pm #241172
    This reply has been marked as private.
    Ross Moderator
    (Private)  April 27, 2020 at 7:49 pm #241632
    This reply has been marked as private.
  • Author
    Posts
Viewing 10 posts - 1 through 10 (of 15 total)
1 2

The forum ‘Search & Filter Pro’ is closed to new topics and replies.