Refactor customizer as a Drupal form

Created on 1 July 2025, 12 days ago

Problem/Motivation

THe current customizer made in Artisan 2.x works very fine but it has the following problems:

  1. It adds all variables from all components into the widget, which make hard to know which exactly variable to use.
  2. It is done as a independent webcomponent, all the logic does not follow Drupal conventions. In a future, this may lead to technical debt.

Proposed resolution

Revamp the customizer so it is a Drupal form component. This component will have several field groups, one for each component, and another for the main component. In this task, we will only allow to create and modify variables for the main component.

Data model changes

The previous customizer will be lost, so sites using 2.x version may need to add their customizations into a CSS file.

✨ Feature request
Status

Active

Version

2.0

Component

Code

Created by

πŸ‡ͺπŸ‡ΈSpain omarlopesino

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

Merge Requests

Comments & Activities

  • Issue created by @omarlopesino
  • πŸ‡ͺπŸ‡ΈSpain omarlopesino

    Working on a first version that allow replacing global variables. They appear inside a fieldset, and for each one there is a textfield.

    Preview:

    Pending:

    1. Coding style
    2. Use custom textarea to allow creating new variables.
    3. Consider validate if new variables are not the same than overriden variables.
  • πŸ‡ͺπŸ‡ΈSpain omarlopesino

    Coding style --> fixed
    Use custom textarea to allow creating new variables -> Done
    Consider validate if new variables are not the same than overriden variables -> I have added a validation to check new css variables have correct format, plus they do not conflict with the variables of the current selector.

  • πŸ‡ͺπŸ‡ΈSpain omarlopesino

    This is ready to review

  • @omarlopesino would it be possible to have a way of "classify" CSS vars?

    Artisan already ships with ~50 vars, and probably themes extending Artisan will add more, making it difficult for site builders to change the value of a specific variable.

    Im thinking about doing it with CSS comments, since customizer reads the src/main.css.

    /* @customizer Typography */
      --theme-font-family: var(--font-sans);
      --theme-font-family-secondary: var(--font-serif);
    
      --theme-font-size: var(--text-base);
      --theme-font-size-sm: calc(var(--theme-font-size) * .8);
      --theme-font-size-lg:calc(var(--theme-font-size) * 1.125);
    
      --theme-h1-font-size: calc(var(--theme-font-size) * 3);
      --theme-h2-font-size: calc(var(--theme-font-size) * 2.5);
      --theme-h3-font-size: calc(var(--theme-font-size) * 2);
      --theme-h4-font-size: calc(var(--theme-font-size) * 1.5);
      --theme-h5-font-size: calc(var(--theme-font-size) * 1.25);
      --theme-h6-font-size: calc(var(--theme-font-size));
    
      --theme-line-height-sm: var(--text-3xl--line-height);
      --theme-line-height: var(--text-base--line-height);
      --theme-line-height-lg: 1.8;
      ...
      /* @customizer-end Typography */
    
      /* @customizer Colors */
      --theme-primary: var(--color-primary);
      --theme-primary-content: var(--color-primary-content);
      --theme-secondary: var(--color-secondary);
      --theme-secondary-content: var(--color-secondary-content);
      ...
      /* @customizer-end Colors */
    

    where Typography and Colors might be inner Details, collapsed by default.

  • πŸ‡ͺπŸ‡ΈSpain omarlopesino

    Done.

  • πŸ‡ΊπŸ‡ΈUnited States mortona2k Seattle

    Any interest in integrating with UI Styles?

  • πŸ‡ͺπŸ‡ΈSpain alzz

    Reviewed!
    Works great

  • πŸ‡ͺπŸ‡ΈSpain alzz
  • πŸ‡ͺπŸ‡ΈSpain omarlopesino

    Integrating with UI styles currently is not in our scope, but it could be good to considerate as UI styles integrates at entity bundle level and it is more abstracted from CSS variables.

    Having said this, the MR has been reviewed so it has been merged.

Production build 0.71.5 2024