Description

In #37368 we learnt that the Page List will show a spinner forever if you are logged in as a lower permission user (e.g. Contributor).

The reason for this is complicated and a true fix would be far outside the scope of this PR.

As a result, all we can do is show an error message to the user that Pages cannot be retrieved.

This is what this PR does. If the API returns no response (i.e. null rather than undefined), we show an error to say we couldn't retrieve the Pages.

Whilst far from ideal, this is somewhat better than an infinite loading state.

Why do we need to include this in 5.9

The reason I feel this is important is that Page List is used extensively by the Navigation block and also by block Themes which often use the Page List as the default state for the Navigation block (e.g. in patterns).

Currently if a lower permission user were to encounter a Nav block with a Page List inside it, they would see an infinite loading state spinner and assume that Nav block was broken when in fact if would be the Page List. This is shown in the screenshot below:

String freeze change

If we cannot include this PR in 5.9 due to string freeze, then another option would be to reuse the existing error notice which whilst not ideal would still suffice.

Closes #37368

How has this been tested?

• Switch to Contributor role user.

• Add Page List block.

• See no infinite loading state.

• See warning / error notice.

• Now switch to Admin.

• Create a Nav block and click Add all Pages.

• Save.

• Switch to Contributor.

• new Post

• Add Nav block.

• Click Select menu and select the menu you created as Admin.

• See the Page List block inserted and showing the error message and not the infinite loading state.

Screenshots

Standalone Page List

Page List inside Nav block

Types of changes

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• I've tested my changes with keyboard and screen readers.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.
• I've updated all React Native files affected by any refactorings/renamings in this PR (please manually search all *.native.js files for terms that need renaming or removal).