There seems to be an object cache-related bug in Infinite Scroll in the latest stable as well as the Bleeding Edge | 8.5-alpha-377-ga9c7093
In particular, when "Load more posts in page with a button" is selected, user options seems to be ignored, while when "Load more posts as the reader scrolls down" is selected, user options are respected.
I'm testing with Redis as object cache, using the following plugin: https://wordpress.org/plugins/redis-cache/
Assume a basic IS integration:
add_theme_support( 'infinite-scroll', array(
'container' => 'content-row',
'render' => 'ci_theme_infinite_scroll_render',
'footer' => false,
'wrapper' => false,
'posts_per_page' => get_option( 'posts_per_page' ),
) );
This should respect the user's option to have IS with either a 'click' or 'scroll', according to the Jetpack setting (mirrored in Settings > Reading).
Steps to reproduce the problem:
Go to Jetpack Settings > Writing and enable "Load more posts in page with a button" (i.e. 'click').
1) Problem: Visit blog. IS works as if 'scroll' was selected.
2) Problem: Go to Settings > Reading. "Infinite Scroll Behavior" is checked, as if 'scroll' was selected.
3) Problem: Uncheck "Infinite Scroll Behavior" in Settings > Reading. Save changes. Once the page reloads, the "Infinite Scroll Behavior" checkbox is again checked, user action wasn't saved.
4) Problem: Visit blog. IS still works as if 'scroll' was selected. Neither settings page 'click' option is respected.
Now go to Jetpack Settings > Writing and enable "Load more posts as the reader scrolls down" (i.e. 'scroll').
1) Visit blog. IS works on 'scroll', as selected.
2) Go to Settings > Reading. "Infinite Scroll Behavior" is correctly checked.
3) Uncheck "Infinite Scroll Behavior". Save changes. Checkbox is now correctly unchecked.
4) Visit blog. IS works on 'click', as expected due to step 3.
The above issues don't manifest if there's no object cache backend.
I'd guess that the process of persisting the IS values are slightly different for 'click' and 'scroll', with 'scroll' code being more correct than 'click's code.
cc @dero -- do you think you could take a look? I wonder if this may be caused by the recent Infinite Scroll changes.
Thank you!
@jeherve I can take a quick look, but it seems unlikely. The recent changes have been almost entirely limited to JavaScript changes.
Update: It's a rather deep rabbit hole.
I was able to reproduce the issue with the Redis Cache plugin. The issue traces back to autoloading options not working well with Jetpack infinite scroll settings when Redis is used.
wp_load_alloptions()['infinite_scroll'] is either '1' or '' (empty string).true or false.It's not very intuitive, but a value of '1' means scroll and a value of '' means click. There is a separate option indicating whether infinite scroll should be used at all. And because the plugin identifies the falsy value as identity with '', it will never be able to recognize the click setting.
Other autoloaded options don't seem to be affected, there are plenty empty string and '1' values correctly returned in the alltoptions array. This leads me to suspect Jetpack is doing something wrong here, but a proper investigation would require a non-trivial amount of time.
cc @jeherve
Thanks for taking a look. That should give us a good headstart when we next iterate on the Infinite Scroll feature!
Just for anyone picking this up later: to test with Redis, I simply added a Redis container to Jetpack's docker-compose.yml:
redis-server:
container_name: jetpack_redis
image: redis
ports:
- "6379:6379"
restart: always
... a then updated wp-config.php and added define( 'WP_REDIS_HOST', 'redis-server' );. Then enabled the persisted object cache in the Redis plugin settings.
I am experiencing this same issue, spent hours trying to figure out why jetpack kept switching to scroll mode instead of click mode when I thought there was an issue with my code. But it looks like this is an actual bug with the plugin.
I just tried to downgrade all the way to version 7.9.1 of Jetpack and the radio button still keeps switching to scroll mode. And I am not even using redis caching for WordPress.
I think the problem is with the infinite-scroll array missing from the rest api endpoints file.
These lines
https://github.com/Automattic/jetpack/blob/master/_inc/lib/class.core-rest-api-endpoints.php#L2023-L2037
should be:
// Infinite Scroll
'infinite-scroll' => array(
'description' => esc_html__( 'To infinity and beyond', 'jetpack' ),
'type' => 'boolean',
'default' => 1,
'validate_callback' => __CLASS__ . '::validate_boolean',
'jp_group' => 'infinite-scroll',
),
'infinite_scroll' => array(
'description' => esc_html__( 'To infinity and beyond', 'jetpack' ),
'type' => 'boolean',
'default' => 1,
'validate_callback' => __CLASS__ . '::validate_boolean',
'jp_group' => 'infinite-scroll',
),
'infinite_scroll_google_analytics' => array(
'description' => esc_html__( 'Use Google Analytics with Infinite Scroll', 'jetpack' ),
'type' => 'boolean',
'default' => 0,
'validate_callback' => __CLASS__ . '::validate_boolean',
'jp_group' => 'infinite-scroll',
),
once the new array was added for the infinite-scroll key, the selection on the settings page properly reflects the selection made as well as the json that is generated and used for the JS functionality.
Most helpful comment
Just for anyone picking this up later: to test with Redis, I simply added a Redis container to Jetpack's
docker-compose.yml:... a then updated
wp-config.phpand addeddefine( 'WP_REDIS_HOST', 'redis-server' );. Then enabled the persisted object cache in the Redis plugin settings.