Pagination via the nodeByUri Query

[Plinpod]

Is it possible to perform pagination when using the nodeByUri query?

For example, if you were going to query the following URI /author/me/ with this query, the ... on User fragment would return the first set of posts.

But how do you get the second page of posts via this URI /author/me/page/2/, which is the default pagination path for WordPress?

Thanks!

[cherrygot-personal]

Did you find some workaround for this? Kinda stuck in the same situation.

[justlevine]

Hey @Plinpod and @CherryGot

By default WPGraphQL uses the Relay spec for pagination due to the pitfalls with offset pagination (here's a nice write up on the topic.

Ideally, I'd recommending thinking your site structure (meaning what exactly is the reason to have /page/# as a frontend route if you're no longer stuck using monolithic CMSes that can't handle reactivity and caching as well as modern headless technologies.

If you're still set on using offset pagination, you can try the WPGraphQL Offset Pagination extension.

[cherrygot-personal]

The two things that we're currently struggling to plan are

• Making pages static in nature

  We are trying to render and save as many pages as possible and serve them. This means we can not rely on each client making an async request and putting load on the CMS server to fetch posts in realtime.

• SEO

  As far as I'm aware, doing pagination asynchronously, especially in cursor based scheme, may make google to never crawl the links that don't show up in the first render of the archive pages. Let's say we statically serve 10 posts and then either based on user scroll (infinite scroll route) or user action (view more button), load the rest of the links. How will a crawler be ever able to get to those links if not traditional pagination?

[cherrygot-personal]

Offset pagination extension looks promising, I'll give it a try. I'm not sure if you've used it, but is it possible to know the offset upfront based on the pagination route? Like page/N then N is the offset. The reason why I'm asking as we're targetting multi-lingual site so it's not exactly page/N all the time.

[justlevine]

@CherryGot you calculate the offset based on your posts_per_page (the size arg in the plugin I suggested).

If page/$n is 3, and your size is 10, then your offset is 3*10 = 30

Not sure I follow how either your static generation concerns or SEO issues fit into this discussion. Whether you're using ISR or triggering a build when a new post is created your app can loop through all the posts to build out your archives. And if that's not enough for SEO, then why don't you just use a sitemap?

[Plinpod]

@justlevine

I did actually end up abandoning the Wordpress /page/# URL schema. It doesn't actually make any sense so I setup an async load more button for the archive pages and used the offset pagination.

@CherryGot

[cherrygot-personal]

How are you tackling the SEO then? I can't wrap my head around this issue of what will make the crawler about the load more button and the new links that are rendered?

[Plinpod]

So SEO was initially a concern, but then after running through some crawler data, I decided it may actually be beneficial not to create hundreds of /page/# pages. We have thousands of posts, and posts further down the archive list tend to fall off in relevance over time. So it's not particularly useful for Google to crawl them excessively. It also prevents useless crawl into the hundreds of /page/# pages.

All of our pages are interlinked anyway, so Google can always find a link back to a page. To ensure that Google does find newer pages in case it hits the archive pages first, we load tons of posts on the archive pages before the load more button, 100+.

Overall the idea is to have a URL structure where the majority of the links that Google would crawl are the most important ones and not a bunch of paginated archive pages.