Provide a parser for THEME.colors.yml

Per @bbrala in #73:

At some point in the pipeline before parsing we always know its an yml, and even what kind of yml (.KIND.yml).

I think we need to make sure we are at least reading a YML file so some sort of check is needed in my opinion. Even if is just a check for .colors.yml.

Updated patch & interdiff addressing this point attached.

Updating IS.

MR opened in #81 is still a work in progress, but moves the form element creation into core/modules/system/src/Form/ThemeSettingsForm.php. Moving the logic away from individual themes like this allows us to add just the THEMENAME.colors.yml file to a theme and have all the forms appear automatically. For example, create a claro.colors.yml file and add the code below:

colors:
  primary_color: 'Primary color'
  accent_color: 'Accent color'

schemes:
  default:
    label: 'Admin Blue'
    colors:
      primary_color: '#1b9ae4'
      accent_color: '#0000ff'
  admin_red:
    label: 'Admin Red'
    colors:
      primary_color: '#a30f0f'
      accent_color: '#ff0000'
  admin_purple:
    label: 'Admin Purple'
    colors:
      primary_color: '#7a4587'
      accent_color: '#ff00ff'

This should add a new section to the Claro settings with no additional changes.

I had anticipated the MR failing some Olivero tests at this point, but that doesn't appear to be happening.

#3257274: Implement color changing theme settings for Olivero → added 4 tests:

1. core/tests/Drupal/Nightwatch/Tests/Olivero/oliveroColorTest.js
2. core/themes/olivero/tests/fixtures/update/olivero-3257274.php
3. core/themes/olivero/tests/src/Functional/Update/OliveroPostUpdateTest.php
4. core/themes/olivero/tests/src/Unit/OliveroHexToHslTest.php

I'm not sure if any of these need modified. OliveroColorTest.js is the one that covers the MR the most, and while it's not Olivero-specific code now, Olivero is the only place using it right now.

Moving to needs review to get eyes on this at this stage.

During a call this morning with @bnjnmn, @mherchel, @ckrina, and @andypost, we discussed the next steps for this issue:

1. Do a dependency eval for spatie/color. The PHP side was determined to be the more important need and likely an easier win than also adding a JS runtime dependency.
2. Adding in new schema types for HSL(a) and RGB(a) at a minimum. These are both widely supported & used, and are a minimal addition to the core data types. Other color schemas could be added in the future if their addition makes sense.

#f052bfdc begins work on both of those points.

Below is the beginning of the dependency eval → process for spatie/color:

1. Maintainership of the package

Color is maintained by a Belgian Laravel agency, Spatie. The company has a strong history of open source. The package was created in fall of 2016, and was last updated December 2022. There are three open issues in the issue queue, all enhancements, from 2017. This package has ~830k downloads on packagist and ~280 stars on github.

2. Security policies of the package

The project's README states, "If you've found a bug regarding security please mail security@spatie.be instead of using the issue tracker."

3. Expected release and support cycles

Project releases do not appear to have a regular cadence, but the need served by the project is fairly small and unchanging. Releases are outlined on the project's github page, and there were multiple releases in each of 2020, 2021, and 20222.

4. Code quality

I do not know how to evaluate this, but I didn't have any issues reading the code and understanding what was available.

5. Other dependencies it would add, if any (the full tree, not just direct dependencies), and evaluations for those dependencies as well

spatie/color only lists two development dependencies for testing purposes, "pestphp/pest" and "phpunit/phpunit".

Adding tags for framework manager and release manager review per dependency evaluation docs →

FYI OpenSocial depends on spatie/color https://github.com/goalgorilla/open_social/blob/e5656027a3f3e0000cb97625...

The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Hi All, As we know this "color" module will be removed in drupa10 and and we can use this module of its contributed version.
Can anyone please help me what is the best way to switching color module from core to contrib version.
Below steps I followed but not sure anything more needed here.

1. Took backup of my db
2. Commented out the dependency of this module (we are using color module in our custom theme)
3. Uninstall core color module
4. Download contributed COLOR → module using composer
composer require 'drupal/color:^1.0'
5. Now COLOR module is not showing under core

Can anyone please suggest me is there any more steps need to do here or is it fine?

Thanks in advance

@Sana.Neyazi you just need to install contrib module via composer, see https://www.drupal.org/docs/core-modules-and-themes/deprecated-and-obsolete →

The MR still needs work for 11.x branch

Dependency evaluation added to issue summary.

Checked composer.json of spatie/color and it has "php" : "^7.3|^8.0" which is a good sign. Either adopting PHP versions too late, or dropping them too early, has been one of our bigger issues with PHP dependencies.

To me this looks like a low-risk dependency addition.

The guys from spatie are well know for their open source packages. It's a belgian agency and extremely well known entity in the laravel ecosystem

Agree with everything @catch said in #98. I checked the release history and they were quick to add support for PHP 8 and then 8.2. The code is fairly simple - largely just a bunch of calculations to convert colour values of one type to another - and it has unit tests. I don't expect there to be any security issues nor any large scale rewrites given that it is a narrowly focused utility library.

Removing the tag given that two RMs have reviewed this and come to the same conclusion.

I haven't looked too closely but we could probably deprecate \Drupal\Component\Utility\Color after bringing this in.