Move the .js class logic into a new module, then deprecate it for removal in Drupal 12

Created on 11 June 2024, 4 months ago
Updated 14 June 2024, 4 months ago

Problem/Motivation

Per 📌 Remove .js class from core Needs work the .js class triggers a layout invalidation on every page view and is not used consistently.

We should remove it from core, but doing so will break any current CSS that's relying on it, and because it's document-wide that could be almost anything anywhere, so somehow need to indicate that it's deprecated.

Steps to reproduce

Proposed resolution

Because this is set via js, we could add a new core module 'Legacy no-JavaScript styling', alter the core/drupal library to add in an extra file that just does and remove that from <code>drupal.init.js.

A post update in system module would install the module on existing sites, it wouldn't be installed for new sites but they'd be able to install it if using a theme relying on the class.

Then we can deprecate the entire module, and make it obsolete in Drupal 12 with no replacement.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

📌 Task
Status

Active

Version

11.0 🔥

Component
Javascript 

Last updated about 2 hours ago

Created by

🇬🇧United Kingdom catch

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @catch
  • 🇨🇭Switzerland berdir Switzerland

    Would it be easier to just add a setting instead of a whole module? Similar to how hal had the BC type cast setting in D8/D9.

  • 🇬🇧United Kingdom catch

    We could hook_library_info_alter() the js and css supporting this based on a setting, that bit is fine.

    The setting would need to default to on for existing sites, so we'd need to treat NULL as TRUE, new sites we could add a default.settings.php entry with it FALSE so it gets written for those. We could have a hook requirements warning if it's NULL or TRUE?

    It's doable but I'm not sure it would be less code than a module.

  • 🇨🇭Switzerland berdir Switzerland

    I meant regular config, that's what we've done then. A post update to enable the setting on existing sites, and later on another to remove it again. Thinking about update database dumps and similar, I believe that would be easier to deal with than having to remove it again from those.

  • 🇬🇧United Kingdom catch

    Ahh OK config is tricky because we also have to handle config schema/validation etc., we're getting into Add an API for feature flags Active territory.

Production build 0.71.5 2024