Jetpack Infinite Scroll for Single Posts!

Had a problem come up recently where folks wanted to keep engaging visitors on their website on a single post page — keep loading more posts afterwards when they kept scrolling.

I’ve heard of this before, and even seen some plugins accomplish it — for example, Infinite Post Transporter, by Tom / github — the codebase of which looks to be a modified version of Jetpack’s Infinite Scroll from about six years ago — (contemporary link).

So, I was curious to see how far I could go about getting close to what we needed just by playing with Jetpack’s own library, rather than duplicating a bunch of the code in a second plugin.

For anyone that wants to skip to the end and just get something to play with, here’s the gist that I’ve got the code shoved into for now.

First, a couple specifications we’re working with here:

  • I want to make this work on single post pages, specifically of the post post_type.
  • I don’t want to modify Jetpack files, or deregister / replace them with customized versions of the files. Filters / actions only.

So, skimming through the Jetpack Infinite Scroll codebase, there’s a couple conditionals we’re gonna need to short out to get things triggering on single post pages.

The bulk of the per-page code comes from The_Neverending_Home_Page::action_template_redirect() — this is the function that will register/enqueue Infinite Scroll’s scripts and styles, and set up footer actions to populate some javascript globals that specify state. However, for single posts, we’ll need to override two points.

		if ( ! current_theme_supports( 'infinite-scroll' ) || ! self::archive_supports_infinity() )

By default, single posts aren’t archives, and don’t work. So let’s hotwire it! Digging into The_Neverending_Home_Page::archive_supports_infinity() we can see that the whole response to that call is simply passed through a filter — `infinite_scroll_archive_supported`

		 * Allow plugins to filter what archives Infinite Scroll supports.
		 * @module infinite-scroll
		 * @since 2.0.0
		 * @param bool $supported Does the Archive page support Infinite Scroll.
		 * @param object self::get_settings() IS settings provided by theme.
		return (bool) apply_filters( 'infinite_scroll_archive_supported', $supported, self::get_settings() );

So to filter this, we’ll want to make sure we’re using the right conditionals and not filtering too many pages. In this case, is_singular( 'post' ) feels appropriate.

For brevity here, I’ll just be using anonymous functions, but in practice it’s likely far better to name your functions so other code can remove the filters if it becomes necessary.

add_filter( 'infinite_scroll_archive_supported', function ( $supported ) {
	if ( is_singular( 'post' ) ) {
		return true;
	return $supported;
} );

Groovy, now we’ve got the function registering the scripts we care about. But there’s a second conditional later in the ::action_template_redirect() method that we also get snagged on — ::is_last_batch().

		// Make sure there are enough posts for IS
		if ( self::is_last_batch() ) {

Fortunately, like our last example, The_Neverending_Home_Page::is_last_batch() is also filterable.

		 * Override whether or not this is the last batch for a request
		 * @module infinite-scroll
		 * @since 4.8.0
		 * @param bool|null null                 Bool if value should be overridden, null to determine from query
		 * @param object    self::wp_query()     WP_Query object for current request
		 * @param object    self::get_settings() Infinite Scroll settings
		$override = apply_filters( 'infinite_scroll_is_last_batch', null, self::wp_query(), self::get_settings() );
		if ( is_bool( $override ) ) {
			return $override;

So again, we can just override it as we had before, only this case returning false:

add_filter( 'infinite_scroll_is_last_batch', function ( $is_last_batch ) {
	if ( is_singular( 'post' ) ) {
		return false; // Possibly retool later to confirm there are other posts.
	return $is_last_batch;
} );

Great! So now we’ve got the scripts that do the work being output on our single posts page, but we’re not quite there yet! We need to change some of the variables being passed in to Jetpack’s Infinite Scroll. To modify those variables, we have — you guessed it — another filter.

The JS Settings are being output in The_Neverending_Home_Page::action_wp_footer_settings() (rather than being added via wp_localize_script), and here’s the filter we’ll be working off of:

		 * Filter the Infinite Scroll JS settings outputted in the head.
		 * @module infinite-scroll
		 * @since 2.0.0
		 * @param array $js_settings Infinite Scroll JS settings.
		$js_settings = apply_filters( 'infinite_scroll_js_settings', $js_settings );

so we’ll start with a generic action like this, and start customizing:

add_filter( 'infinite_scroll_js_settings', function ( $js_settings ) {
	if ( is_singular( 'post' ) ) {
		$js_settings['foo'] = 'bar'; // any we need to make!
	return $js_settings;
} );

We can verify this change is in place by loading up a single post page, and searching for foo — confirming that it’s in the encoded string that’s being output to the page. So now we need to start looking at the javascript that runs and see what changes to inputs we may need to make.

First, we’ll need to make sure that the wrapper container we want to append our new posts to is the same as the ID that we use on archive pages. If it’s not, we just need to override that. In my case, I had to change that to main on the single post pages — which can be done like so:

$js_settings['id'] = 'main';

If your wrapper id is the same as archive pages, this can just be skipped. Here we can also override some other options — for example if we would rather change the verbiage on the load more posts button we could do

$js_settings['text'] = __( 'Read Next' );

or to switch from the button click, to autoloading on scroll we could do

$js_settings['type'] = 'scroll';

Now, if you tried what we have so far, you may notice that instead of getting new posts, you’ll likely see the same post loading over and over forever. That’s because of the parameters getting passed through as query_args — if you pop open your browser window to examine infiniteScroll.settings and look at the query_args param, you’ll likely notice that we’ve gotten the populated! This is getting passed directly to the ajax query, so when trying to pull up more posts, it’s restricting it to only the already queried post, as that’s from the query WordPress ran to generate the current url’s response.

So let’s just nuke it, and for good measure ensure we don’t inadvertently re-display the post in question.

$js_settings['query_args']['name'] = null;
$js_settings['query_args']['post__not_in'][] = get_the_ID();

Cool cool cool. So at this point, when you run the post, everything /should/ look about right, except for one small thing! You may see the url updating as you scroll to append /page/2/ to the path!

Unfortunately a lot of this functionality is hard-coded and I couldn’t find a good way to override it to update the url to — for example — the url of the post you’ve currently got in view, so I wound up doing the next best thing — nuking the functionality entirely.

	 * Update address bar to reflect archive page URL for a given page number.
	 * Checks if URL is different to prevent pollution of browser history.
	Scroller.prototype.updateURL = function ( page ) {
		// IE only supports pushState() in v10 and above, so don't bother if those conditions aren't met.
		if ( ! window.history.pushState ) {
		var self = this,
			pageSlug = self.origURL;

		if ( -1 !== page ) {
			pageSlug =
				window.location.protocol +
				'//' + +
				self.history.path.replace( /%d/, page ) +

		if ( window.location.href != pageSlug ) {
			history.pushState( null, null, pageSlug );

As the js relies on rewriting the url via calling .replace() on a string, if we eat the token it searches for off the end, it’ll just wind up replacing the url with itself, and doesn’t look awkward. And so —

$js_settings['history']['path'] = str_replace( 'page/%d/', '', $js_settings['history']['path'] );

So, functionally this should get you most of the way there. The only other bit that I had added to my implementation was something that could trivially be done anywhere — Custom CSS in the Customizer, or theme files — but I wanted to hide Post Navigation links in my theme. So I just did a fun little trick of enqueueing my one line css tweak (with appropriate conditionals) like so:

add_action( 'template_redirect', function () {
	if ( ! class_exists( 'Jetpack' ) || ! Jetpack::is_module_active( 'infinite-scroll' ) ) {

	if ( is_singular( 'post' ) ) {
		// jisfsp = Jetpack Infinite Scroll for Single Posts
		wp_register_style( 'jisfsp', null );
		wp_enqueue_style( 'jisfsp' );
		wp_add_inline_style( 'jisfsp', ' { display: none; }' );
} );

This way, if someone disables either Jetpack or infinite scroll, the conditional trips and it stops hiding post navigation links.

I hope this has been somewhat useful to someone. It’s probably not at the point where I’d be comfortable packaging it up as a plugin for end-user installation, but if you’ve got a passing understanding of code and how WordPress works, it shouldn’t be difficult to re-implement for a client. If there’s any other tweaks on Infinite Scroll that you wind up finding and would like to suggest, please feel free to leave a comment below, and it’ll hopefully be useful to others. Cheers!

Why Jetpack isn’t a Collection of Plugins, Part the First

In keeping with a previous post I’d made a couple months ago explaining the oft-discussed rationale of why we do things the way we do with Jetpack, I’ll be doing it again today, on a different — but related — topic.

I may as well make a series of it.

This is the first of two posts (in theory, I’ll remember to write the second) explaining why Jetpack is a big plugin with many features, rather than many individual plugins.  This post will be looking at the primary technical reason.  The abundance of other reasons will be in the subsequent post.  (So please don’t read this post and think it’s the only reason — it’s not)

tl;dr: Dependency management sucks.

Jetpack, as you may be aware, is structured as a bunch of modules.  Many — but not all — require a connection to to function.  This isn’t for vanity purposes, it’s because they actually leverage the server infrastructure to do things harder, better, faster, stronger than a $5/month shared host is capable of.  To do that, they need to be able to communicate securely with, and must be able to communicate securely back to your site.

Some of the modules that require a connection are things such as Publicize (which uses the API keys to publicize to assorted third-party systems, rather than making users register various developer accounts and get their own API keys), Related Posts (which syncs some content up to the servers and indexes it on a large ElasticSearch index more efficiently and accurately than could be done in a MySQL database), Monitor (which pings your site every five minutes and emails you if it’s down), Comments (which passes data back and forth behind the scenes to enable secure third-party comment authentication) — you get the idea.

We could bundle the connection library with each individual plugin.  However, we’d need to make sure it was namespaced correctly so each different plugin can use its own correctly versioned instance of the connection classes.  Which would then mean a user could have well over a dozen copies and different versions of the same connection class active at a given time.  Which will make things more difficult with respect to developing the plugins, as you can’t assume methods in one are necessarily in another.  And when you make a change in the master class, you need to scan each repository to make sure you’re not breaking anything there, and keep changes synced to well over a dozen repositories.  But I digress.

To avoid duplicate code, the modules that depend on talking back and forth with all use a common library that handles signing and verifying requests, API calls, and the like.

Because it’s all packaged in a single plugin, we can be sure that it’s all running the required version.  If Publicize needs a change in the core connection library, we can be sure that the version of the connection library in Jetpack has those changes.  If the core connection library needs to change structure, we can make sure that any modules that used the old methods are updated to run the new ones instead.  Everything is maintained so that it’s running smoothly and works properly with each other.

Now, if Likes, Single Sign On, After the Deadline, Post by Email and others were their own plugins, and connected to a separate Jetpack Core plugin, versioning gets tricky.  It could work, in theory, if every plugin is kept up to date, always and forever.  But the instant that the user is using, say, an outdated version of Subscriptions with an outdated Jetpack Core (which work perfectly together), and then installs the up-to-date Shortlinks plugin, things could break because Shortlinks expects a more up-to-date Jetpack Core.  So you go ahead and update Jetpack Core to current, but now Subscriptions — which used to work perfectly — now breaks because there was a method change in Jetpack Core, that is fixed in the up-to-date version of Subscriptions, but the user isn’t running the up-to-date version.  Horrible UX.

Plus, if the user doesn’t have any Jetpack stuff, the installation flow for their first Jetpack Plugin that needs the core would be something like this:

  1. Install Stats.
  2. Activate Stats.
  3. Get error saying you need Jetpack Core for Stats to function.
  4. WTF is Jetpack Core? I just want Stats!
  5. Okay, install Jetpack Core.
  6. Activate Jetpack Core.
  7. Wait, what was I doing?
  8. Stats!  Okay, right.
  9. Connect the Jetpack Core to
  10. Drink Scotch in celebration.

Compare this to the status quo of:

  1. Install Jetpack.
  2. Activate Jetpack.
  3. Connect Jetpack to
  4. Stats is already active (unless you’re Mark Jaquith, in which case you activate it in this step)
  5. Drink Scotch in celebration.

As I said, dependency management is hard, and there’s not really a good way to manage it in WordPress.  There have been some very worthwhile attempts made, but none that can have a sufficiently solid user experience for an average user to compare with our current system and flow.

Any questions or suggestions about dependency management and Jetpack? Ask away!

On Jetpack and Auto-Activating Modules

Hopefully, this is the last time that I’ll have to answer this question.

Frankly, it’s been answered dozens of times before. Now, I’m hoping to use this as a canonical ‘Answer Link’ that I can refer people to.  I’ll keep up with comments, so if anyone would like to ask

So, why does Jetpack auto-activate features?

Well, to start off, I should probably clarify what we currently do on this. We don’t auto-activate every new module that comes in.

We never auto-activate features that affect the display or front-end of your site — or at least not unless a site administrator explicitly configures them to.

So, for example, something like Photon, which would swap all your content images to CDN-hosted versions, doesn’t auto-activate. Our comments system doesn’t auto-activate either, as that would swap out your native comment form. Our sharing buttons do, but they don’t display unless you take the time to drag down some sharing buttons to the output box under Settings > Sharing.

However, modules like Publicize, Widget Visibility, and the like — they just give you new tools that you can use, with no risk to affecting your everyday visitors. When users upgrade, we give them a notification of what just happened, and point out some new features we’ve built in that they may want to activate themselves.

One thing we’ve recently expanded on, perhaps six months ago, is a ‘plugin duplication list’, for lack of a better phrase. These aren’t plugins that have an actual code-based conflict with a module, they’re ones that may be … duplicating effort. Previously, we were just scanning for plugins that would output OG Meta Tags, and short-circuit our own provider. However, since Jetpack 2.6, which shipped in November 2013, we’re actually doing it via a filter for all modules. For example, if you’ve got Gravity Forms or Contact Form 7 installed and active, our internal Jetpack Contact Form won’t auto-activate. If you’ve got AddThis or ShareThis active, our sharing buttons module won’t even kick in.

Now, obviously, we can’t catch every single plugin that may be similar enough to one of our modules to give cause to negate auto-activation. So there’s a filter, `jetpack_get_default_modules`, that can be used in any plugin to cancel auto-activation on any module.

add_filter( 'jetpack_get_default_modules', 'my_jetpack_get_default_modules' );
function my_jetpack_get_default_modules( $modules ) {
    return array_diff( $modules, array( 'module-slug' ) );

But I don’t like auto-activation of new features!


You’re totally allowed not to.

We’re going to continue using our discretion to auto-activate select modules by default, but if you’d like to turn it off permanently for yours or a client’s site, we’ve made it ridiculously easy to do.

add_filter( 'jetpack_get_default_modules', '__return_empty_array' );

That’s it.

We believe that judiciously enabling new features is a win for users, especially considering 1) how low-impact most features are when ‘active’ but not actually implemented by a site owner, 2) how awkward it is for a site owner to have to enable something twice — for example, enabling the Custom Post Formats bit, and then having to visit Settings > Writing in order to actually enable the Portfolio custom post type.

We’ve spoken to many, many users who find a default feature set convenient, and resent having to make a bunch of ‘decision points’ if they had to manually activate each and every module. Good software should run well out of the box. So we’ve set up the defaults as we have. Yes, some people disagree and are vocal about not wanting anything to auto-activate. That’s okay. We try to design for the majority, with the best user experience we can provide.

If you have clients, that you’d like to be active in the relationship with, and customize the Jetpack experience for — that’s terrific. You’re the type of people that we add bunches of filters for. We’re all about empowering you to override our decisions, we just prefer to keep the default user interface free of a thousand toggles.

Decisions, not options — no?