Unused js/css assets are queued into frontend.

[dadish]

Steps to Reproduce

1. Go to home page of a website where Sensei is installed.
2. Open browser devtools.
3. Navigate to the Network tab.
4. Select JS and CSS filter tags.
5. Type sensei/ into the url filter.

What I Expected

To not see any sensei related styles or scrips. Because there is nothing sensei related on the Home page.

What Happened Instead

Seeing four sensei related styles and/or scrips. Even if they are not used on the Home page.

With Divi theme activated

With Divi theme activated, sensei related styles and/or scripts increase on the Home page up to 7. See screenshots below.

PHP / WordPress / Sensei LMS version

• PHP: 7.2.34
• Sensei LMS: 4.9.1

Browser / OS version

MacOS: 12.6.1 Firefox: 107.0.1

Screenshot / Video

Theme Twenty Twenty-Three

Theme Divi

Context / Source

p1671555705477719/1671454129.373949-slack-C02P7FHLVR9

[alexsanford]

I took a look at this, and thought I would comment here with some insights:

Without Divi

• Both the pages-frontend.css and frontend.css files are included in the main Sensei_Frontend class's enqueue_styles function which is hooked into wp_enqueue_scripts.
• modules-frontend.css is similarly included in Sensei_Modules and enqueued in wp_enqueue_scripts.
• page-block-patterns.css is included in the Sensei_Block_Patterns class, and enqueued using enqueue_block_assets.

For the first two points above, an argument could be made for only loading these CSS files conditionally, but we would want to be pretty careful about this, and we might not be able to avoid breaking backwards compatibility (some sites may be implicitly depending on these CSS rules).

If we do decide to load them conditionally, then we need to make sure we get the conditions right. For example:

• If we're on a page or post with any Sensei blocks.
• If we're on a Sensei CPT page.
• If we're on any custom Sensei-defined routes (e.g. the legacy Course Results page).

As for the third point, this CSS file appears on any frontend rendered post (of any post_type). Ideally we should only need it for posts that have used one of our block patterns. I'm not sure whether we can actually detect this, though.

With Divi

In addition to the above, a frontend page in Divi includes two more stylesheets and a JS files.

For the stylesheets (sensei-theme-blocks.css and sidebar-mobile-menu.css) it appears that these are stylesheets that are being used for specific block types. When I search the code for ['"]style['"]\s*=>\s*['"], and look at the matches which are registering a new block type, I see sensei-theme-blocks, sensei-sidebar-mobile-menu, and sensei-learning-mode. It would appear that maybe Divi automatically loads all of the styles for all of the blocks, rather than only loading the ones that are necessary?

As for the JS file (blocks/frontend.js), this is also used in a block registration, and so the same thing may be going on here.

This is just a guess, but it seems likely. In which case, maybe there is a setting somewhere in Divi to disable loading styles and scripts for all blocks?