'Force page reload' setting is confusing

[jameskoster]

Force page reload Experimental full-page client-side navigation setting enabled.

The label and help text for this setting do a poor job of describing exactly what it does.

[jameskoster]

Generally speaking the circumstances in which a user would actively want to enable this option are extremely rare. For that reason alone we might consider moving it to the 'Advanced' panel.

The language might be refine like so:

cc @WordPress/gutenberg-design

[richtabor]

Generally speaking the circumstances in which a user would actively want to enable this option are extremely rare.

What are those circumstances?

[carolinan]

The option is enabled by default, it is not clear to me if you meant that the default behavior should be the on page pagination, or if you meant that enabling the on page pagination is rare.

[jameskoster]

What are those circumstances?

I don't know, to be honest.

@carolinan I'm saying the copy associated with the control doesn't describe what it does very well, leading to confusion. Also that it's rare that you'd want to enable it in the first place.

Moving it to the Advanced panel would reduce visibility. A more aggressive approach would be to hide the control from the UI altogether.

[carolinan]

That's the confusion, the toggle is enabled by default. So you mean that toggling it off would be rare?

[jameskoster]

So you mean that toggling it off would be rare?

No haha, it's the other way around. When it's toggled on the full page is reloaded, which isn't something I can ever see a user wanting to do. So toggling on would be rare, and it should 100% be toggled off by default.

[carolinan]

To me, saying that "the label and help text is confusing" and changing the default behavior of how links work are two separate issues.

• Has the underlying reasons for why this option was chosen to be enabled by default changed?
• And have all the problems related to the third-party blocks in the query been solved? I believe the answer to the second question is yes, not sure about the first.

[jameskoster]

I agree, but it's not clear to me what the default behavior is. It would be good to clarify that definitively.

In my local environment it's toggled off when I insert a Query Loop, which is what I'd expect. It gets toggled on only when there are incompatible blocks in the Query Loop.

Rich's question is a good one though. Regardless of what the default is, when would a user ever want full page reloads? If the answer is never then maybe the setting can be hidden from the UI.

[carolinan]

I have never seen it toggled off by default. Not even on a fresh WP install that only has the Hello World post and I insert a query, choosing the "start blank" option with only a title and excerpt. Blocks that should not prevent the option from being changed.

When the option can not be changed, when it can't be toggled off because there are non-compatible blocks, the toggle is disabled and this message shows: Force page reload can't be disabled because there are non-compatible blocks inside the Query block.

[jameskoster]

I just tested on a fresh https://playground.wordpress.net/ site and you're right, the option is toggled on by default there. I wonder why that's not the case in my local environment.

I don't see a good reason for this to be toggled on by default, do you?

Making off the default state, moving the control to the Advanced panel (to reduce visibility), and tweaking the copy still feel like good changes imo.

[jarekmorawski]

I wonder if it could be specific to Playground? Maybe there are constraints around the Interactivity API and how it needs a specific site setup. Maybe it isn't compatible with Playground's local setup? Feel free to disregard this suggestion, but maybe there's some nuance we're missing.

If that isn't the case, I can't think of a reason we'd turn the toggle on unless there are incompatible plugins and/or features. Interactivity API is the future and we should default most sites to it.

[afercia]

I'd totally support some drastic simplification of the help text for this setting. See https://github.com/WordPress/gutenberg/issues/63598#issuecomment-2247626433

[carolinan]

I understand the problem with the text, but not the problem with keeping the default as the "force page reload" which is the default behavior for links when not enhanced with the JavaScript.

I would like to ping @SantosGuillamot and @DAreRodz to help us sort any remaining questions about which query pagination setting is actually the default, why, and why we are seeing different results on different environments.

[jameskoster]

@carolinan paginating without reloading the page is the superior experience, so that should be the default (when possible) imo.

[richtabor]

@carolinan paginating without reloading the page is the superior experience, so that should be the default (when possible) imo.

And it auto opts out as well, correct?

[SantosGuillamot]

@jameskoster The message "Experimental full-page client-side navigation setting enabled." you shared in the image should only be visible when the "Enable full page client-side navigation" Gutenberg experiment is activated. That could be why you are seeing it disabled as default while the normal experience is having it enabled by default.

Regarding why the "pagination reloading the page" is the default experience, I believe it was decided that way because not-reloading gets disabled when non-compatible blocks are included, being the Post Content one of them. But @luisherranz or @DAreRodz will know better than me.

Having said that, this setting seems tricky and I agree it needs some discussion.

[carolinan]

Are there blockers preventing the experiment from being stabilized? (other than contributors time)

[SantosGuillamot]

Are there blockers preventing the experiment from being stabilized?

There are some challenges that need to be addressed before it can be considered stable. There is a tracking issue specific to this experiment where the issues are listed and progress will be shared.

[luisherranz]

And it auto opts out as well, correct?

Yes, when "Force page reload" is disabled (which means that this "enhanced pagination" is active), we are checking for incompatible blocks on each render. If we find one, the enhanced pagination is deactivated.

We are also checking for incompatible blocks every time the user opens the Editor, as there might not have been one when the template was saved but now one could appear because it is inside a pattern that was edited elsewhere. If that happens, we reactivate the "Force page reload" option and show a modal to the user.

Are there blockers preventing the experiment from being stabilized?

There's still a lot of work to be done on that front, and I don't think we'll have anything stable for at least a couple of cycles, so as of today, I wouldn't expect it before WP 6.9 or WP 7.0.

Regarding why the "pagination reloading the page" is the default experience

It was decided to keep this "enhanced pagination" disabled by default because it is actually a very new functionality and we were not sure if there would be conflicts on certain sites where it might not work well. So, as a precaution, it was decided that the user should manually enable it.

In the future, once it is considered stable and robust enough, we could try enabling it by default. I don't know if, after two major versions, there has been enough time for people to test it and report issues (nobody has reported any problems yet as far as I know).

[carolinan]

I agree with the suggestion to move it to the advanced panel, but I think that would also mean less testing, which may not be what is needed.

[afercia]

paginating without reloading the page is the superior experience

I'm sorry but this sound to me as a very bold statement. It may be perceived by some users as a better experience, but it for other users it may be a worst experience. This kinf of statements should be avoided in a project with millions of users who have all different needs and different levels of ability.

Also, I would like to see this kinf of statements based on actual data and user testing. Otehrwise, with no data, they're only baseed on personal opinions, perception, and preferences.

I would liek to remind everyone that the non-reloading pagination is non-standard, it introduces problems that need to be addressed to replicate all the feature of a standard pagination and, more importantly, could be non accessible for some users. For this reason, I think the default should be the standard pagination because the WordPress defaults should be the most accessible ones.

Cc @joedolson

[luisherranz]

it introduces problems that need to be addressed to replicate all the feature of a standard pagination and, more importantly, could be non accessible for some users

I am not going to get into the discussion of whether it's a superior experience, but if there are any accessibility issues, we should resolve them. This experience should be as accessible, if not more, than reloading the full page.

[afercia]

This experience should be as accessible, if not more, than reloading the full page.

It is important to understand that it can't, because it's not standard. There will always be users or assistive technologies that will suffer from this model of page content 'updating'. There are no specifications or standards that define this model. As such, other software, for example assistive technologies or search engine crawlers, can't be fully compatible because there's no standard they can take into consideration.

Also, there are important SEO concerns with this model of page updating. I'd leave this to the SEO experts but it's something that should be taken in serious consideration.

For these reasons:

• I don't think this should be the default setting.
• I'd argue the wording the feature is presented with is highly biased. WordPress should not make any assumption on what kind of experience is 'better' for users. It should present the feature in a neutral way, explaining the pros and cons. Force page reload sounds pejorative and scaring while it is the standard model instead. I think this terminology is biased and should not be used.

[joedolson]

I'd agree that the assertion that pagination without a page reload is somehow "better" - it certainly isn't better for all users. It is certainly less predictable than a page reload.

I do want to emphasize that the way the Query Loop pagination works is accessible - it has most of the the essential pieces of an accessible interaction; but there's an important distinction between "meets standards" and "is a good and predictable user experience."

The specific problem is that there is no standard pattern for pagination without a page reload. This means that there are no semantics we can communicate to users that will inform them how they should expect this to work. Because the controls are still links in a nav landmark region, the semantics communicated to the user will create the expectation of a page reload - because that's what navigation links do.

Tabpanels, dialogs, navigation menus - these are all standardized interaction models. There is a "right" way to do them, and because of that, we can do them well and communicate clear expectations to a user. JS-driven Pagination doesn't have a standardized model.

There are a few things we could do to create hints; like change the controls from links to buttons when this mode is enabled, but there isn't a standard experience. Which isn't to say that there shouldn't be a standard pattern for this - it's a pretty major gap in standards, but it still remains the case that it doesn't exist.

[luisherranz]

search engine crawlers can't be fully compatible because there's no standard they can take into consideration [...] Also, there are important SEO concerns with this model of page updating. I'd leave this to the SEO experts but it's something that should be taken in serious consideration.

That statement is false. There's no issue with SEO because the HTML that search engines see is exactly the same with or without this option.

Because the controls are still links in a nav landmark region, the semantics communicated to the user will create the expectation of a page reload - because that's what navigation links do

Links navigate to a different page. That doesn't change, we are still navigating to a different page, but faster and without losing the user's context and focus.

[afercia]

That statement is false. There's no issue with SEO because the HTML that search engines see is exactly the same with or without this option.

This should be investigated more in depth before stating it's not an issue. I would like to recommend everyone to have a less assertive attitude and a little more open-mindedness towards observations that are reasonable to take into consideration.

I said there are important SEO concerns. It's not a statament, it's reporting concerns. Some of them are clearly valid concerns. Examples:

• The document title still doesn't update. This is a serious SEO and accessibility problem reported at https://github.com/WordPress/gutenberg/issues/55489 and still unsolved.
• Since the document title doesn't update, all the entries in the browser history have the same title. It is impossible to distinguish which page is which in the browser UI. As such, the editor implementation breaks a native browser feature.
• Since the document title doesn't update, bookmarking a page becomes, in a way, challenging because it's impossible to distinguish a bookmarked page from another one with the same document title.
• When using the Query loop block on a singular page, WordPress will output a link rel="canonical". The canonical URL doesn't change on the paginated pages. Basically, there will be pages with different content but with the same canonical URL. How does this impact SEO? Honestly, I don't know. This is something SEO expeerts should answer to and it should be serously considered. Noting that this happens also with the setting disabled and it's a general issue with the Query Loop block when ued on a singular page.
• SEO plugins may add their own canonical URL on paginated pages: what happens when js-pagination is enabled?
• SEO plugins may add Schema to the paginated pages: what happens when js-pagination is enabled?

I'm not an SEO expert but to me these concerns are valid and I'd like to see them be tested and considered by SEO experts. Still, I don't think this feature is should be communicated as a 'superior experience' because that's an extremely biased statement that WordPress shouldn't make,

[afercia]

we are still navigating to a different page, but faster and without losing the user's context and focus.

From an usability perspective, this is arguable. The fact the page doesn't scroll and focus stays on the clicked link does make users lose context and focus. In certain conditions, users may not ever notice the page content has updated.

[luisherranz]

The document title still doesn't update. This is a serious SEO and accessibility problem reported at https://github.com/WordPress/gutenberg/issues/55489 and still unsolved.

That was fixed in this pull request (before the feature was initially released in WP 6.4):

• https://github.com/WordPress/gutenberg/pull/55446

I've updated the issue.

---

It seems to me that you don't quite understand how search engine crawlers work yet, because, even though that was fixed, not updating the title on client-side navigation doesn't affect SEO.

Crawlers fetch the HTML of the pages and analyze it, but they do not navigate using JavaScript. When they see links, they add that URL to their list and fetch the new page again. Since the HTML doesn't change when the enhanced pagination is active, for search engines, there is no difference between a WordPress site with enhanced pagination and a site without it.

So, to answer your concerns:

Since the document title doesn't update, all the entries in the browser history have the same title. It is impossible to distinguish which page is which in the browser UI. As such, the editor implementation breaks a native browser feature.

The enhanced pagination updates the document title to whatever is on the new page's <title> tag. See https://github.com/WordPress/gutenberg/pull/55446.

Since the document title doesn't update, bookmarking a page becomes, in a way, challenging because it's impossible to distinguish a bookmarked page from another one with the same document title.

The enhanced pagination updates the document title to whatever is on the new page's <title> tag. See https://github.com/WordPress/gutenberg/pull/55446.

When using the Query loop block on a singular page, WordPress will output a link rel="canonical". The canonical URL doesn't change on the paginated pages. Basically, there will be pages with different content but with the same canonical URL. How does this impact SEO? Honestly, I don't know. This is something SEO expeerts should answer to and it should be serously considered. Noting that this happens also with the setting disabled and it's a general issue with the Query Loop block when ued on a singular page.

As you say, this is not an issue of the enhanced pagination but of the Query Loop block with non-inherited queries.

SEO plugins may add their own canonical URL on paginated pages: what happens when js-pagination is enabled?

Nothing. The HTML is exactly the same with or without enhanced pagination, and that's what crawlers inspect.

SEO plugins may add Schema to the paginated pages: what happens when js-pagination is enabled?

Nothing. The HTML is exactly the same with or without enhanced pagination, and that's what crawlers inspect.

[luisherranz]

The fact the page doesn't scroll and focus stays on the clicked link does make users lose context and focus.

I'm sorry but that's not what happens. After a client-side navigation, we move the focus to the first post of the new page (which makes the page scroll to that position if it's not in the viewport) and we announce the navigation.

If that is not the ideal behavior, we can modify it.

[joedolson]

I think we're getting a bit off topic here. The accessibility of the query loop navigation is pretty good; that's not at issue. It's pretty good within the scope that it's a non-standard interaction that has no standardized model, so it creates an unexpected behavior. As a result, the question here is challenging the assumption that

1) This is the best choice for default behavior, and 2) The option to turn it off should be hidden in advanced options

We'd also like to improve the text (per the original purpose of this issue), to make it clearer to users what will change, and to avoid any implication that one choice is better than the other.

One question: is this default something that can be controlled via theme.json?

[carolinan]

It can not be controlled via theme.json yet. Here is a link to the issue: #57623.

[jameskoster]

We'd also like to improve the text (per the original purpose of this issue)

Yes, let's concentrate on that here, everything else is clearly a bigger discussion.

How do we feel about Force page reload → Reload full page?

[michaelpick]

Yes, let's concentrate on that here, everything else is clearly a bigger discussion.

How do we feel about Force page reload → Reload full page?

+1. I think the proposal at the top of this issue makes this setting a lot clearer:

Commas, em-dashes, or parentheses might further aid readability?

• Reload the full page, instead of just the posts list, when visitors navigate between pages.
• Reload the full page—instead of just the posts list—when visitors navigate between pages.
• Reload the full page (instead of just the posts list) when visitors navigate between pages.

A few alts for coverage, but I'm not convinced they improve on the original solution:

• Reloads the full page when visitors navigate between Query Block pages.
• Reloads the full page, rather than just the posts list, when visitors navigate between the block's pagination.
• Reloads the entire page when visitors navigate between the block's paged items paginated items.

One more thought—it's always a bit of a toss-up between concision and providing a rationale as to why someone would want to take a specific action. Is there a pithy, universal reason we could cite? It sounds like it’s primarily to resolve certain block compatibility issues? Even something as simple as one of these could help the user make a decision, but I appreciate that there are tooltips and documentation that might be a better option:

• This can help with block compatibility issues.
• This can resolve compatibility issues.
• This can resolve block incompatibility issues.

[jameskoster]

We can probably finesse the help text in a PR. I think the main thing is to update the label.

[richtabor]

For that reason alone we might consider moving it to the 'Advanced' panel.

Any reason why we shouldn't do this as a first step?

[carolinan]

For that reason alone we might consider moving it to the 'Advanced' panel.

Any reason why we shouldn't do this as a first step?

If the goal is to first have more people using and testing it, hiding it may do the opposite.

[jasmussen]

First step can be updating the label, as suggested here. A next step can be moving it to the Advanced panel. Whether that's a good idea or not, isn't clear to me; it resonates because it's probably not a setting you need to change that often. And yet it the main feedback has been the lack of clarity of labels.

[afercia]

It seems to me that you don't quite understand how search engine crawlers work yet, because, even though that was fixed, not updating the title on client-side navigation doesn't affect SEO.

Crawlers fetch the HTML of the pages and analyze it, but they do not navigate using JavaScript. When they see links, they add that URL to their list and fetch the new page again. Since the HTML doesn't change when the enhanced pagination is active, for search engines, there is no difference between a WordPress site with enhanced pagination and a site without it.

@luisherranz that is just incorrect. You may want to read the basics of how JavaScript SEO works in this article on Google Search Central. I'll skip over any comments about individual skills because I don't think they contribute positively to the collaboration on this project but I have to say that I didn't particularly appreciate your language and tone in your previous comment. Thanks.

Understand the JavaScript SEO basics https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics

[luisherranz]

@afercia, you are confusing client-side navigation of server-side rendered HTML (what WordPress with the Interactivity API can do) with pure client-side rendering (what single-page applications without support for server-side rendering do).

Would you like to move our conversation to a separate discussion to avoid interrupting the main discussion on this issue?

[afercia]

@afercia, you are confusing client-side navigation of server-side rendered HTML (what WordPress with the Interactivity API can do) with pure client-side rendering (what single-page applications without support for server-side rendering do).

Would you like to move our conversation to a separate discussion to avoid interrupting the main discussion on this issue?

I will ask the SEO specialists in the company I work for to better evaluate potential impact of this feature before creating a new issue. Thanks.