New route-based admin pages are empty when no JS

[afercia]

While modern web applications are increasingly based on JavaScript, a no-JS scenario is always possible.

Large organizations, public bodies and the like may use policies to entirely disable JavaScript. Historically, WordPress always took the no-JS scenario into account.

At the very least, for UI consistency, usability, and accessibility, all the admin screens that can't really work without JavaScript must provide users with:

• A main H1 heading.
• An admin motice with some meaningful text.

Most of the existing admin pages take that into account. The new route-based pages don't. When JS support is off, they are completely empty.

To reproduce:

• Disable JavaScript support in your browser via the settings in the dev tools (or use a browser extension).
• Go to teh following admin pages:
  • WP Admin > Appearance > Fonts
  • WP Admin > Settings > Connectors
• Observe they are completely empty.
• Go to the following example pages:
  • WP Admin > Posts > Add Post
  • WP Admin > Media > Grid view
  • WP Admin > Appearance > Design
  • WP Admin > Appearance > Widgets (available for non-block themes)
  • WP Admin > Tools > Site Health
• Observe all these pages do contain a main H1 heading and an admin notice.

[afercia]

Fonts and Connectors admin pages empty when no-js

[afercia]

Other admin pages showing a main heading and an admin notice when no-js

[afercia]

I believe the admin pages to fix are only Fonts and Connectors but it's worth checking if there's more.

[hbhalodia]

Hi @afercia, Thanks for the issue.

I guess we may need to update the code in Gutenberg repository and here in core as well.

WP Core Updates

Add the $description to the files, src/wp-admin/font-library.php and src/wp-admin/options-connectors.php after the title. So both title and description that needs to be added for no-js would be available.

Gutenberg Repo Updates

Add add this notice to /packages/wp-build/templates/page-wp-admin.php.template this template. Something like below,

<div id="font-library-wp-admin-app" class="boot-layout-container">
        <?php
        /*
                * No-JavaScript fallback.
                *
                * This markup is rendered inside the application mount point, so the
                * JavaScript application replaces it when it boots. It is also marked
                * hide-if-js so it is hidden as soon as JavaScript is available, even
                * before the app mounts. When JavaScript is disabled it stays as the
                * page content, providing a main heading and an explanatory notice
                * instead of a completely blank screen.
                *
                * It lives inside .boot-layout-container on purpose: the critical styles
                * above hide every other direct child of #wpbody-content, so a sibling
                * fallback would be hidden even when JavaScript is disabled.
                */
        $no_js_heading     = ! empty( $GLOBALS['title'] ) ? $GLOBALS['title'] : __( 'This screen requires JavaScript' );
        $no_js_description = ! empty( $GLOBALS['description'] ) ? $GLOBALS['description'] : __( 'This page requires JavaScript. Please enable JavaScript in your browser to use this screen.' );
        ?>
        <div class="wrap hide-if-js">
                <h1><?php echo esc_html( $no_js_heading ); ?></h1>
                <div class="notice notice-error">
                        <p><?php echo esc_html( $no_js_description ); ?></p>
                </div>
        </div>
</div>

Also, needs to add the style to the wrap element, because the default style added by template to #wp-content is removed. So the message and heading are being touched to sidebar.

Final implementation is something being shown below

---

I Would create a Upstream issue to track this on Gutenberg end and we can use this to add the update to the WP core.

Update: Have created the issue here to report it upstream - ​https://github.com/WordPress/gutenberg/issues/80626

Thanks,

Trac ticket: https://core.trac.wordpress.org/ticket/65690

## Use of AI Tools

• None

[hbhalodia]

Update: Have raised the PR for the Gutenberg here - ​https://github.com/WordPress/gutenberg/pull/80628 and WP Core - ​https://github.com/WordPress/wordpress-develop/pull/12661

I have some doubt related to adding the description thing. I am not sure this would be the best approach, or should we adopt something else?

Thanks,

[afercia]

I guess we may need to update the code in Gutenberg repository and here in core as well.

@hbhalodia thanks for the PR.

I'm not sure the description should be used that way. Rather, the admin notice text should be passed to wp_admin_notice() like WP does for other similar notices. See for example ​here.

Re: the CSS. The fact some of the CSS for these pages comes from Gutenberg and overrides some CSS in Core is, in my personal opinion, annoying and not the best architectural choice. These are Core admin pages. The related CSS should be in Core. Personally, I would suggest to reconsider the 'route-based' CSS implementation as everything should be in the Core CSS files. Cc @youknowriad

That said, there are workarounds. If you wrap everything within a container with these classes:

<div class="wrap hide-if-js boot-layout-container">
    ...
</div>

That would mostly work. The spacing around the content would need some adjustment. See attached screenshot.

However, the boot-layout-container class comes from Gutenberg and may change in the future. That's one of the reasons why this CSS should not be in Gutenberg.

At the very least, Gutenberg should provide a CSS class alternative to boot-layout-container that is still excluded by the broad display: none ​that comes from Gutenberg.

[hbhalodia]

Thanks @afercia for the review.

My initial implementation was the same, but my main concern was around the CSS only. I did added the div and use the classes as suggested in above comment.

But then everything was tied with Gutenberg, hence thought to include that in Gutenberg as was not sure to override it in core.

I will update the core PR to add in the suggested way, but yes we may need to think about CSS and how to override that.

Also instead of wrapping it as an div, we may wrap it in <section> so that we do not need to add the .boot-layout-container class, just need to adjust the spacing, that needs override. wdyt?

Thanks,

[hbhalodia]

Hi @afercia, Have updated the PR to add the notice in core instead of adding to GB routes admin pages. Here is how it would look.

Have override the CSS in common.css, but not sure that's the correct overriden. This resovles our issue for now, but we need to revisit on how GB overrides the core WP style on admin pages.

[afercia]

Also instead of wrapping it as an div, we may wrap it in <section> so that we do not need to add the .boot-layout-container class, just need to adjust the spacing, that needs override. wdyt?

@hbhalodia good idea, as long as the CSS in the Gutenberg page template doesn't change. It's unlikely but someone may add section to that display: none in the future and no one would ever notice the no-js content here would stay hidden.

What about adding to the Gutenberg CSS something like :not(.hide-if-js)? It would be a little more explicit.

[afercia]

@youknowriad when you have a chance: any specific reason why all that CSS that, if I'm not wrong, was initially introduced in ​https://github.com/hbhalodia/gutenberg/commit/c69eedf0a73b6686967abb4cd52991ef88c463e3, is in the php template that comes from Gutenberg? Those are styles for the Core admin pages. Ideally, those styles should be in core otherwise we will face issues like this one again and again in the future.

[hbhalodia]

Replying to afercia:

Also instead of wrapping it as an div, we may wrap it in <section> so that we do not need to add the .boot-layout-container class, just need to adjust the spacing, that needs override. wdyt?

@hbhalodia good idea, as long as the CSS in the Gutenberg page template doesn't change. It's unlikely but someone may add section to that display: none in the future and no one would ever notice the no-js content here would stay hidden.

What about adding to the Gutenberg CSS something like :not(.hide-if-js)? It would be a little more explicit.

Yeah that would make more sense. I would update the Gutenberg PR to add that and update the core PR to only use .hide-if-js class. We need to then backport the Gutenberg PR to merge it in core before core PR merge. Is that correct? I am not sure on process.

Thanks,

[hbhalodia]

Hi @afercia, This is now fixed.

Have added .hide-if-js while building the route pages to exclude it from display:none. Here is the Gutenberg PR - ​https://github.com/WordPress/gutenberg/pull/80628

Core PR - ​https://github.com/WordPress/wordpress-develop/pull/12661

Thanks,

[afercia]

The PR for Core at ​https://github.com/WordPress/wordpress-develop/pull/12661 works as intended but it requires a related PR for Gutenberg to be merged and back-ported to Core. See ​https://github.com/WordPress/gutenberg/pull/80628

LGTM assuming the required PR for Gutenberg at ​WordPress/gutenberg#80628 gets merged and backported to Core. I left only two minor comments.

Thanks @afercia, I have updated the PR with the feedbacks!

I did not have enough time to include this PR in Beta4, but ​https://github.com/WordPress/gutenberg/issues/80626 has already been shipped in Beta4. Let's aim to ship this PR in RC1.

Thanks for the review. I have address the feedbacks.

[wildworks]

In 62954:

Administration: Add no-JS fallbacks to route-based pages.

The Fonts and Connectors screens are rendered entirely by JavaScript, so they were completely empty when JavaScript is disabled. Both screens now render the page heading and an error notice, shown only when JavaScript is unavailable.

Props afercia, hbhalodia, wildworks.
Fixes #65690.

[afercia]

@wildworks thank you for coordinating this change!

[youknowriad]

Can we move the change to the build tool to ensure this work in all pages that are developed like that and avoid duplicating the code on each page.

[wildworks]

Can we move the change to the build tool to ensure this work in all pages that are developed like that and avoid duplicating the code on each page.

I'll try this out.