WordPress.org
Get WordPress

Make WordPress Core

Opened 15 months ago

Last modified 13 months ago

#60111 new defect (bug)

Twenty Twenty-One: Dark mode toggle script loaded twice in frontend

Reported by: flixos90's profile flixos90 Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 6.4
Component: Bundled Theme Keywords: needs-patch
Focuses: Cc:

Description

I just noticed that the TT1 theme's dark-mode-toggler.js script can be loaded twice in the frontend, and the editor-specific editor-dark-mode-support.js is loaded in the frontend as well although it is only needed for the editor.

It looks like this was introduced by [56300], which changed the hook to support the editor iframe, but in the process may not have considered that now editor-specific scripts are being loaded in the frontend too.

For the frontend, the contents of the dark-mode-toggler.js script are inlined so the script should not be enqueued. And the editor-dark-mode-support.js is irrelevant for the frontend entirely.

Change History (5)

#1 @flixos90
15 months ago

@audrasjb @poena @desrosj for visibility

I'm not entirely sure, but potentially the fix would be to simply not enqueue the assets when ! is_admin()?

This ticket was mentioned in ​PR #5795 on ​WordPress/wordpress-develop by ​@flixos90.
15 months ago #2

  • Keywords has-patch added; needs-patch removed

This PR uses the Interactivity API to replace the custom frontend JS code for the Twenty Twenty-One theme. More concretely:

  • Uses the Interactivity API module if available (currently requires the Gutenberg plugin).
    • In WordPress core, the Interactivity API is still private and cannot be used in that way.
  • Adds a store for handling state and a few other dynamic aspects (in interactivity.js module).
  • Avoids loading the regular frontend JS code (primary-navigation.js, responsive-embeds.js, dark-mode-toggler.js) as it replaces those functionalities.

This is an experimental PR, primarily as a proof of concept and to get a better idea of how the API works, and what _should_ or _should not_ be done with it.

To test it, you need to have the Gutenberg plugin activated. You should then see a script[type="module"] pointing to the new Twenty Twenty-One interactivity.js file in the <head>.

A few observations:

  • 207 lines of custom JS (with Interactivity API) vs 314 lines of custom JS (manual approach)
  • 2.1 kB custom JS (with Interactivity API) vs 4.5 kB custom JS (manual approach)
  • 27.2 kB overall JS (with Interactivity API) vs 16.9 kB overall JS (manual approach)
    • Both numbers include 12.4 kB from import map polyfill.
    • While in this example the Interactivity API itself leads to a net increase in JS, it has to be considered that the benefits will become better the more code uses the API. For instance, a site with just a default WordPress theme is hardly realistic, and the amount of JS typically increases heavily the more plugins are used. With several sites loading 100s of kilobytes of JS, the size of the Interactivity API itself would play a minor role compared to the reduction of custom JS code gained from it (see the amount of custom JS as an indicator for that).

Unrelated: While working on this, I discovered and reported https://core.trac.wordpress.org/ticket/60111 which I think is a bug.

Trac ticket:

#3 @flixos90
15 months ago

  • Keywords needs-patch added; has-patch removed

:/ I just mentioned this ticket in ​https://github.com/WordPress/wordpress-develop/pull/5795, but not in the place to indicate it's a PR for that ticket. Anyway, I guess now it's connected to this one by accident.

​@luisherranz commented on ​PR #5795:
14 months ago #4

The only modification I would do is to use directives for the submenus to make them declarative, instead of manipulating the DOM manually: ​762b3b

By the way, making this part declarative brings the Interactivity API JS lines down to 189, vs the 314 of the vanilla JS approach, a reduction of 40% in the amount of code that the developer needs to write.

#5 @zlvkrxjv47
13 months ago

It appears that there is an issue with the Twenty Twenty-One theme where the dark mode toggle script (dark-mode-toggler.js) is being loaded twice in the frontend, and the editor-specific script (editor-dark-mode-support.js) is also being loaded unnecessarily.

This issue seems to have been introduced by changes made in revision [56300], which modified the hook to support the editor iframe. However, this change may not have considered the unintended consequence of loading editor-specific scripts in the frontend as well.

To address this issue:

  1. Remove Redundant Loading: Since the contents of dark-mode-toggler.js are already inlined for the frontend, there is no need to enqueue it. Remove any enqueueing of dark-mode-toggler.js for the frontend.
  1. Exclude Editor-Specific Scripts: Ensure that editor-dark-mode-support.js is not loaded in the frontend at all, as it is only relevant for the editor. This can be achieved by conditionally enqueueing the script only when needed, such as within the editor context.
  1. Review Changes in [56300]: Take a closer look at the changes made in revision [56300] to understand how the hook was modified to support the editor iframe. Determine if there was an oversight regarding the loading of editor-specific scripts in the frontend.
  1. Test the Changes: After making the necessary adjustments, thoroughly test the frontend to confirm that the dark mode toggle functionality still works as expected and that the editor-specific script is no longer loaded unnecessarily.

By addressing these points, you can resolve the issue of the dark mode toggle script being loaded twice in the frontend and prevent the loading of editor-specific scripts where they are not needed, thereby improving the efficiency and performance of the Twenty Twenty-One theme.

Note: See TracTickets for help on using tickets.