Autocount does not seem to work (multisite installation with 2 sites)

Anonymous

#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

#240251

This reply has been marked as private.

Ross Moderator

#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

Anonymous

#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

#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

Anonymous

#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

Anonymous

#241159

This reply has been marked as private.

Ross Moderator

#241161

This reply has been marked as private.

Anonymous

#241172

This reply has been marked as private.

Ross Moderator

#241632

This reply has been marked as private.

[Author]

Posts