Color module is outdated and was created for a nitch release/theme:

The current color.module is more of a garland-addon than a useful module for recoloring themes.

Proposed resolution

  • Refactor the color module by creating a more comprehensible hook-able API
  • Use modern CSS3 techniques.
  • Update or add additional libraries.

Completed tasks

Remaining tasks

  • Create a sandbox for development purposes.
  • HSL/RGB +alpha transparency support
  • Create swatch API
  • Create swatch library

User interface changes

You can find various mock-ups of how things might/should look in comments bellow. The UI changes will be:

  • Use a color/swatch palette on the theme settings form.
  • Render the color settings form in the selected theme for preview.

API changes


Original report by JurriaanRoelofs

The current color.module is more of a garland-addon than a useful module for recoloring themes. I know because I've managed to build 5 themes for color.module _despite_ how it is built.

Various parties are interested in recoloring abilities for Drupal for various purposes. For me it's building great-looking themes that are abstracted from colors and given the freedom recoloring stylesheets and complex graphics with accuracy as well as good usability. Other parties are interested in using color.module as a feature on community websites, to enable users to recolor their profile page theme and/or recolor the sitewide theme to their preference.

In order to achieve these things, we need a Color API and some modules that interface with it. To ensure backward compatibility with colorable themes (garland) color.module should be a regular external module so that users can choose to download color module or any other modules that enable recoloring capabilities.

Freeing the color module out of core allows for new technologies to be developed for better recoloring and better writing/rewriting of images, and it will be an opportunity to redo the color module "The Drupal Way".

Members fund testing for the Drupal project. Drupal Association Learn more


tonyn’s picture


It'd be nice. color.module isn't good for core inclusion. I recommend moving to contrib:

- It's not just colors anymore. ("Hot swapping" stylesheets is the new kool)
- We can do core theme patches to help assist in CSS alteration/swapping for themes

Demo of enhancements to color.module, color_soc08. (you may have to refresh)

There are other ideas for modifying themes in the works (CSS API, style). As for Color API, it's just colors, you don't interface with 'em.

Color.module should be just for themes (avoiding feature creep). Even if there comes a CSS implementation in contrib that can do it all.

I'd love to help maintain color.module for d6 in contrib, and live up to the promise continuing it in d7.

soxofaan’s picture

I'm not a themer, so I wont comment on the theming aspects of this issue or the in/out core question.

I'm maintainer of the (image) CAPTCHA module and at one point I tried to reuse the color picker wheel thingy from color.module for the selection of the background and foreground colors. I soon gave up as I realized that the color picker was too tightly coupled with the theme recoloring functionality of color.module and I didn't want to fork parts from color.module in another module. It didn't felt like good code reuse/reusability (is that a word?).

I just wanted to say that I hope the discussion about color.module goes a bit further than theming, like offering a reusable color picking widget that can also be used by non-theme related modules. You need such a widget anyway for theme related functionality.

JurriaanRoelofs’s picture

I guess there is need for several functionalities that are all trapped in the color module:

1. farbtastic color picker
2. slicing/generating images
3. shifting colors in HSL space
4. rewriting stylesheets. Though in my themes I bypass this last option because it use is very limited. I use some custom colorshifting functions to generate new colors.

tonyn’s picture

When you really think of it, Drupal would be boring if we didn't have this.

Unfortunately, Color.module SoC '08 (Version 1.x) is one of my first modules. It's less hard-coded, however, not core quality.

When Peach mentions it, he makes it sound easier. Basically, I already have the code done, I just can't organize it on my head right.

I will give this a bit more thought.

boombatower’s picture

Looks like we either need to start designing an API/architecture or take a look at the SoC color module and see if it is close enough to use as a basis to clean up and get into core.

dman’s picture

I found to be a pretty good job. Slightly odd in a few places internally, but it did a great job of replacing core color.module.
I've used it a bit. Just needs a broader base of maintainers and a few interested code gurus to push it along.

RobLoach’s picture

I'm against the removal of Color module as it's almost the only place where you can quickly get an almost unique design for your site without having to download a contrib theme. People considering other systems, very much love dynamically changing their theme without having to write CSS themselves. I am in extreme support of revamping Color module though. Doing stuff like this would be awesome:

  • Turn theme engines into modules so that you can have multiple "theme engines" enabled at once
  • Make it possible to have themes require certain modules (phptemplate and color)
  • Revamp color.module to use more of the new Drupal 7 page rendering stuff
dman’s picture

Good point, it's a good start for a demo.
However, can we decouple it enough to provide color.module development in contrib - as a drop-in replacement?
color-ng has shown that this is feasable. Maybe we just have to endorse that. Drupal core gets the basic existing functionality. color.module gets duplicated to contrib? I think the movement to remove it from core is all about getting interested contributors to work on it/support it a bit more.
That is not happening with it inside the core repo.

rickvug’s picture

I'm on the fence about this. On one hand, Color module is a special use case as it is now and is not "core worthy" in terms of quality. On the other hand, color could be a really solid building block piece if better utilized. For example, Seven could use color module and perhaps even graphics such as the AJAX progress meter. See jQuery UI's theme roller for ideas outside of themes. I also like that it may have the most sex appeal for new users.

Perhaps the question here is if there is enough interest in Color module within the core developer community that justifies it staying in. If it is simply stagnating, it would be better off dropped. If champions emerge, it would be worth keeping in. Obviously just my opinion here.

Damien Tournoud’s picture

Status: Active » Closed (won't fix)

Patches are welcome to improve the color module like every other parts of core. There are a lot of good ideas in this issue, why not trying to put them in motion first?

dman’s picture

I personally lack the ability to write a simpletest that will verify that a derived PNG image is what I want.
Therefore I lack the ability to write a patch that is likely to get anywhere near accepted for core.
Therefore while color.module remains in core, I can't see me writing any patches for it.
I avoid patching core on production sites, for upgrade stability.

Instead I've tweaked Color NG instead, even a few accepted patches there. That is interesting, and sorta productive for getting actual results.
Color NG, to my mind was a lot of good ideas in motion. Sure seemed to be a lot of code that could be adapted. But even though I like it, I don't think it's likely to all get into core, nor should it.

I think that those advanced or unique ideas will flourish better outside of core.

boombatower’s picture

I can help with the test, if someone is willing to improve on it.

rickvug’s picture


jennifer.chang’s picture


macrodesign’s picture


JurriaanRoelofs’s picture

Title: Color module needs to be removed from core » Color module needs to be removed from core +(or Revamped)
Assigned: Unassigned » JurriaanRoelofs

Does the above -> won't fix mean that color module is definitively staying in core? I guess thats how it has to be as long as Garland is the flagship theme of Drupal. I don't like garland (anymore) but I understand how the transition from Bluemarine to Garland may have contributed to Drupals succes, so I respect this choice.

I guess I should put my money where my mouth is and start turning some of my ideas into core patches. A themer trying to get core patches in Drupal..... (/starts playing Benny Hill theme).

axyjo’s picture

Assigned: JurriaanRoelofs » Unassigned

I think the won't fix above means that without a patch, this won't get fixed. + It's way after code freeze and isn't as critical as some of the other issues so the chances are slim.

Jarek Foksa’s picture

There is still chance for having color module fixed in Drupal 7. Please help testing the patched version.

bsherwood’s picture

Changing to 'active' for 8.x.

bsherwood’s picture

Title: Color module needs to be removed from core +(or Revamped) » Color module needs to be removed, revamped or refactored
Version: 7.x-dev » 8.x-dev
Status: Closed (won't fix) » Active

wow, I cant believe I didn't tag it right!

RobLoach’s picture

Title: Color module needs to be removed, revamped or refactored » Meta Issue: Color module needs to be removed, revamped or refactored
tim.plunkett’s picture

Status: Active » Postponed

I'm trying to tackle this for D8. First big issue is #1064484: Support RGB/HSL in color module, which might result in some drastic changes.

dodorama’s picture

Status: Postponed » Active

I wonder if a solution could be to introduce a sort of simplified css preprocessor (like less.js) so that we can use variables in our stylesheets to control not just colors but even font family, font-size etc.. We would then have something like this in the stylesheet

#header {
color: @color;
background-color: @backgroundcolor
h2 {
font-family: @fontfamily;
font-size: @fontsize;

This would then correspond to theme settings where these variables are defined.

-- Choose a font family :
-- Choose a base font size :
-- Choose a background color:

A simple xml file could then make it easy for theme developer to define supported variables.

markcarver’s picture

Title: Meta Issue: Color module needs to be removed, revamped or refactored » Color module needs to be re-invented
105.33 KB
72.36 KB
69.49 KB
80.9 KB
92.4 KB
74.48 KB

When I first started going through the issues for Color, I was horrified to see people talking about removing it from core. We seriously can't do that (see conclusion below if you need a quick explanation).

I'm a developer AND themer so I am now taking it on myself to get this bandwagon rolling and bring Color up to modern web browser and theming standards.

I took a crack at a preliminary UI enhancement last night: (NOTE: Please keep in mind there is a lot of commented code/rearranging and it's not even up to my standards, let alone Drupal's. I just wanted to get something workable ASAP to show everyone what I have been envisioning for Color for quite some time).


  • theme_settings_form and color_scheme_form separation - This was done for two reasons: 1) Keeps the submit handlers separate so changing a theme settings will not invoke Color and vice versa. 2) Removes the overbearing scheme, palette and preview from the theme settings form and replaced it with an actual scheme palette display.
  • New menu callback - Uses the following path for configuration of a theme's color settings: admin/appearance/settings/%/color. It also renders that page in the selected theme (for a live preview (not working yet), so no more static HTML templates).
  • jQuery UI Dialog - It's included in core, let's use it. It's re-sizable and draggable. Allowing the configuration process to not be so intrusive with the preview process.
  • Changed libraries - Added Tipsy for adding label tooltip support when hovering over the color fields. Added Color Picker and removed Farbastic, I never liked it. Please keep in mind that these libraries are not necessarily set in stone for me. I know that licensing COULD be an issue, but both of these are MIT.


Theme Settings

My goal here was to simplify the ever so blatant statement that the theme supports the color module by taking up half the page. As many themer's may recognize, I replicated the same technique from COLOURlovers in an effort to "beautify" the display of the currently selected scheme. 9 times out of 10 when you're going to the theme settings page, you're not necessarily going to change the colors.

Images (opens in new window):
. .

Color Scheme Form

By separating the color scheme form into it's own callback, it gives the color module the ability to render the page in the selected theme. Before could provide a template (a static html one at that) which didn't really allow a true "Preview" to be displayed. Granted if you got crafty, and copied your entire CSS and page layout over, sure it might work... but that needs a nail in the coffin, two releases ago. Now, the "Preview" template is really just a themed (by the selected theme) version of the color scheme form. Simple.

Images (opens in new window):
. . .

There has been an few ideas about how a theme should supply the information to the color module (info file and creating an API). While I didn't really focus on this particular aspect this commit, let me explain what I'm envisioning.

I think we should keep a file somewhere in the theme. There's just too many types of variables and arrays going on for configuration purposes to really pull this. What we COULD do is provide an option to specify where the include is located in the theme's .info file. By default it would assume it is located in the root directory of the theme.

Previously we specified our color scheme field keys as synonymous text that referred to what would be changing in the CSS. I'm proposing that we change it to the actual selectors. This gives us far more flexibility for the purpose of CSS and JavaScript manipulation.


$info = array(
  // Available colors and color labels used in theme.
  'fields' => array(
    'top' => t('Header background top'),
    'bottom' => t('Header background bottom'),
    'bg' => t('Main background'),
    'sidebar' => t('Sidebar background'),
    'sidebarborders' => t('Sidebar borders'),
    'footer' => t('Footer background'),
    'titleslogan' => t('Title and slogan'),
    'text' => t('Text color'),
    'link' => t('Link color'),


$info = array(
  // Available colors and color labels used in theme.
  'fields' => array(
    t('Header')             => '#header',
    t('Background')         => '#page, #main-wrapper, #main-menu-links li, #main-menu-links a',
    t('Sidebar')            => '.sidebar .block',
    t('Footer')             => '#page-wrapper, #footer-wrapper',
    t('Title and slogan')   => '.region-header, .region-header a, .region-header li, #name-and-slogan, #name-and-slogan a, #secondary-menu-links li a',
    t('Text color')         => 'body, body.overlay',
    t('Link color')         => 'a, a:link, a:visited',

I don't know if this would be the actual format but you get the idea. This type of implementation can give us a couple advantages: 1) No more css file (as one could then be generated automatically). 2) It would allow for practically automatic preview on the new color scheme form page by selecting exactly what the CSS will be altering in jQuery.

What I would like to do is also put a style guide on this page, so that you can see how everything would be rendered. Ultimately I think we could also extend the "Custom" scheme set to allow dynamic selectors to be set. So in theory, you could hover over the messages div, click it and a new field would be added allowing you to set the color for it.


My inspiration: Ultimate CSS Gradient Generator, jQuery UI Theme Roller and Photoshop.

All up to now, the color module only supported a single solid color for a single color field. If we're going to support things like transparency, it only makes sense to turn the color field into a swatch field and take the concept a step further. Instead of having a color well popup, you would get a swatch popup. This would give you the ability to set stops, add transparency, change the border, text, and shadow colors. These presets would be able to style the entire selector and cut out the need for using two (or more) color fields for one selector.

Ultimately I would like a massive swatch library (I know, one thing at a time), but I think initially Color could provide a few, then themes could provide more and we could even put in a hook that would allow other modules to include some. Alas I don't have an image for this (only so much time in a night).

Also, processing images is rather... old technology. That is, now that we have more advanced browsers. I don't think it's really necessary to keep the image processing overhead in Color. Instead I think we should be moving forward and utilizing the existing browser capabilities for rendering advanced styling techniques, even IE (SVG).


I'm removing the "remove color" from the title and changing it to "re-invented". A lot of the issues that currently exist would be solved by this. For people wanting to remove one of the few obvious sources (albeit, lacking) of UI enhancement in Drupal, it's kind of like shooting ourselves in the foot... on purpose. Also, there is too much opportunity here to showcase what Drupal can actually do. Everyone is very well aware that Drupal needs major improvements in UI and usability. Granted, a lot was accomplished with D7, but we can't plateau. No, we need to make people go "Oooh and Ah!". Not to mention this would drastically reduce the amount of time that's required to sub-theme a site, for a themer's sake.

RobLoach’s picture

I love the designs, Mark! Haven't checked out your sandbox yet, but will definitely have a look.

Added Tipsy for adding label tooltip support when hovering over the color fields.

Quick note: If we hit up #1085590: Update to jQuery UI 1.9, we'll be able to bring in jQuery UI Tooltips.

markcarver’s picture

Title: Color module needs to be re-invented » [META] Color module needs to be re-invented
Issue tags: +meta
JurriaanRoelofs’s picture

Hi Mark, I feel like we should keep the farbtastic color picker and not replace it with something elaborate like in your screenshots.
Since the color pickers have to be usable by novice users too, simplicity is the greatest sophistication here.

For the same reason I always limit my color schemes to 5 different colors. I know designs will sometimes use more colors, but these are always shades of the same color.
Color modules CSS rewriting code automatically takes care of these shades, the module guesses which color a hex code is a shade of and then tries to reproduce the shade with different hue. Unfortunately color module often guesses wrong, and can produce strange side effects like turning greys in pinks. I think this is because of rounding errors when converting between color spaces.

To fix this I produce the shades manually in some of my themes, I implement color shifting functions in the background, hidden away from the user so they don't have to do the laborious task of managing 10+ colors.

This works by simply adding some css to the theme from it's templat.php file:

$CSS .= "body .slideshow h2,body .slideshow .views-field-title,body .slideshow .view .title,body .slideshow .view .nodetitle { color:".color_shift($ctopalette['base'],0,-0.75,-0.05).";}\n";

These are the functions I use, anyone should feel free to reuse them in color.module if you think you can work it in:

* Shift colors in HSL color space
* @param color
* CSS hex color to be shifted (e.g. #000000 )
* @param $h
* Hue shift, normalized to a fraction of 1
* @param $s
* Saturation shift, normalized to a fraction of 1
* @param $l
* Lightness shift, normalized to a fraction of 1
* @return a string containing a CSS hexcolor (e.g. #000000 )

function color_shift($color,$h,$s,$l) {
  $newcolor = _color_unpack($color,TRUE); // hex to RGB
  $newcolor = _color_rgb2hsl($newcolor); // RGB to HSL
  $newcolor[0] += $h;
  //if ($newcolor[0] > 1) { $newcolor[0] = 1; }
  //if ($newcolor[0] < 0) { $newcolor[0] = 0; }
  $newcolor[1] += $s;
  if ($newcolor[1] > 1) { $newcolor[1] = 1; }
  if ($newcolor[1] < 0) { $newcolor[1] = 0; }
  $newcolor[2] += $l;
  if ($newcolor[2] > 1) { $newcolor[2] = 1; }
  if ($newcolor[2] < 0) { $newcolor[2] = 0; }
  $newcolor = _color_hsl2rgb($newcolor); // Back to RGB
  $newcolor = _color_pack($newcolor,TRUE); // RGB back to hex
  return $newcolor;

* Autohift colors in HSL color space
* @param color
* CSS hex color to be shifted (e.g. #000000 )
* @param $X_min
* Hue/Saturation/Lightness minimum value, normalized to a fraction of 1
* @param $X_max
* Hue/Saturation/Lightness maximum value, normalized to a fraction of 1
* @return a string containing a CSS hexcolor (e.g. #000000 )
function color_autoshift($color,$min_h,$max_h,$min_s,$max_s,$min_l,$max_l) {
  $newcolor = _color_unpack($color,TRUE); // hex to RGB
  $newcolor = _color_rgb2hsl($newcolor); // RGB to HSL
  if ($min_h){
    if ($newcolor[0] < $min_h) { $newcolor[0] = $min_h; }
  if ($max_h){
    if ($newcolor[0] > $max_h) { $newcolor[0] = $max_h; }
  if ($min_s){
    if ($newcolor[1] < $min_s) { $newcolor[1] = $min_s; }
  if ($max_s){
    if ($newcolor[1] > $max_s) { $newcolor[1] = $max_s; }
  if ($min_l){
    if ($newcolor[2] < $min_l) { $newcolor[2] = $min_l; }
  if ($max_l){
    if ($newcolor[2] > $max_l) { $newcolor[2] = $max_l; }
  $newcolor = _color_hsl2rgb($newcolor); // Back to RGB
  $newcolor = _color_pack($newcolor,TRUE); // RGB back to hex
  return $newcolor;

The first function is for shifting any or all of the HSL components of a color by a fixed amount. Like, colorY is 20% darker and 30% less saturated than colorX.
The second function is to to make sure any or all of the HSL components of a color stay in a specific range. For example, when you know the background of a text is white, you will want to prevent colorZ (used as a text color here) from having a lightness of more than 70%.

JurriaanRoelofs’s picture

You can see how well different shades are processed by playing with the touchpro theme:
It doesn't use the color_shift functions, because it's monochromatic scheme is easy to interpret by color.module. I think it can still produce faults though, like if you want to make touchpro all grey, it will produce reds.

markcarver’s picture

Assigned: Unassigned » markcarver


Hi Mark, I feel like we should keep the farbtastic color picker and not replace it with something elaborate like in your screenshots.
Since the color pickers have to be usable by novice users too, simplicity is the greatest sophistication here.

I can agree that simplicity is often the greatest form or sophistication, which is why I chose the picker that I did. In reality, it is no different than farbasic and really isn't that "elaborate" at all! The only reason it may seem drastically different is because the hue selection is a vertical box to the right of the shade selection box instead of a circle around it (like in farbastic). It also provides the MUCH needed value inputs (RGB, HSL and HEX). This allows novice users to select the color on the left and allows experts to fine tune the color to a desired result on the right, best of BOTH worlds.

I like your ideas about color shifting and think they definitely have merit, just not necessarily in this issue (at least not at this moment). I feel this issue should really be focused on the UI and logistical approach of re-inventing the color module. If you have or would like to create another issue, I will update the issue summary with color shifting as a possible goal that we can tackle in a separate issue.

markcarver’s picture

Issue summary: View changes

Updated issue summary.

markcarver’s picture

Issue summary: View changes

Added issues section

markcarver’s picture

Title: [META] Color module needs to be re-invented » [META] Refactor color module
calvintennant’s picture

It's been a while since someone posted in here, but I thought I'd add my two cents. The Color module provides great functionality, and the concept behind it is really cool, however I can't imagine using this on most websites. The only use case I can find for this is for Drupal Gardens-type websites and for contributed themes that want to offer re-colouring functionality.

I feel that these features would be better suited by a contributed module.

markcarver’s picture

Title: [META] Refactor color module » [META] Remove Color module from core and make it a contributed module.

@calvintennant: Yes. After rereading and rethinking this topic, I now think Color should be pulled out of core.

I'll admit, when I initially jumped on this topic I was a bit resistant to this happening. After having quite a few discussions about the direction of D8 though, I think this is actually necessary.

Core is becoming more of a framework and Color is more of a "feature". Color does not really provide any "framework" or critical functionality to core. Like you said, there are usually only certain use cases where it IS needed (which in retrospect, is usually just an initial setup and then it is not really used).

Also, removing Color from core would allow the development of Color to become much easier (there's a lot of overhead in maintaining and developing core). There wouldn't be any sandboxes or core approval process. There would also be specific people maintaining it and a smaller focused issue queue, etc.

What I DO think should be in core though, is something like: #1530074: Create Theme UI API. It would most certainly allow this transition to be more seamless, not to mention allowing other contributed modules and themes to provide configuration options for the theme.

I would like to get Rob's (and others) feedback on this issue now. If and when it's decided we should remove color from core, we should do so ASAP and make it a contributed module.

tim.plunkett’s picture

Title: [META] Remove Color module from core and make it a contributed module. » [META] Refactor color module
Issue tags: -meta

I strongly disagree.

There are plenty of modules that aren't necessary for a framework. Most of them, in fact. Color module is optional.

But most importantly, Color drastically improves the out-of-the-box experience for new Drupal users. They can easily recolor their site to distinguish it from stock Bartik even before discovering the existence of contributed modules.

markcarver’s picture

Title: [META] Refactor color module » [META] Remove Color module from core and make it a contributed module.

Yes, Color is optional which means that if a distributions or theme supports it, it can include Color as a option. I strongly disagree that Color is a core essential module.

Yes Garland and Bartik integrate with Color, but it isn't required. Keeping Color in core seems to be counter productive to the goal of where core is going. It's strictly an enhancement feature.

  • How many people are going to make a decision about choosing Drupal based on changing a theme's color?
  • What would the ramifications be if we removed it?
  • How many themes support color?
  • How many developers actually understand HOW to integrate Color into their theme?
  • What APIs exist for Color?
  • If it's really essential to core, why hasn't anyone worked on it in years?

As stated in my previous comment, moving it into a contrib module would allow it to be actively maintained. Color has been stagnant for years. It was moved into core and practically forgot about. Why is it in core???

In regards to the argument for providing an "out-of-the-box" UX:

So the user can navigate to the appearance settings and change a few colors. Ok, that's cool... but what can I actually DO with my site. UX arguments should really be focused on things like how easy it is to edit the site, implement certain functionality, etc. Colorizing a theme is really about taking an existing theme and "tweaking" it. I see Color becoming more of a utilitarian module than one for "coolness".

Say for instance: a site that has departments/sub-sites and use the same theme, but want different colors. They don't want to have to re-theme each site. THIS is the use case for Color.

tim.plunkett’s picture

I'm not going to play title ping-pong with you, but please note that support for the Color module is a requirement for every core theme:

I think you are underestimating the out-of-the-box UX.

markcarver’s picture

Well, that's an easy fix: core themes can remove that requirement.

I agree about the title ping-pong, it's petty. What needs to happen is actual work on the color module. I created a sandbox and tried to get this process started with no real feedback. Instead the issue seems to focus on the semantics on whether or not it should remain in core. I actually really could care less on where it lives and would rather focus on the task at hand.

Either way, a decision needs to be made on where it lives so we all can stop bickering about it. Who makes that decision? I am unfamiliar with if I should tag this issue with something. Can we get their input and put this part of the color module to rest?

I would REALLY just like to get some momentum (and feedback) on improving the functionality and awesomesauce of this module!

tim.plunkett’s picture

The new direction needs consensus. Eventually it will need feedback from catch or Dries.

dman’s picture

Although our portfolio mega-sites don't need or use color.module - it IS a huge thing for (as tim.plunkett says ) first-user experience.
We can set up a site in 5 minutes and make some ugly but effective changes to get folk playing with options and finding their way around the UI.

It's easy and rewarding to have it there for brand-new users who can get to making useful changes really fast. This is really important for out-of-the-box UX.
*sometimes* that is enough to get buy-in.

It is certainly not essential (and can be turned off easily enough) BUT the fact it is there gives a good amount of momentum on the Drupal learning curve. Even if they do have to kick off the training wheels after a while.

Core theme requirements are driven by this - not because it's a *good* thingTM, but because it's a *useful* thing.

Improvements can be made and color_ng etc may be able to step in for out-of-core upgrades, but I don't want to see it removed entirely.

dodorama’s picture

I agree that the color module might increase the out of the box experience of Drupal but it seems pretty clear at this point in time that Drupal 8 will be more about distributions geared toward specific audiences rather than one Drupal for all. A "blog with Drupal" distribution could certainly ship with a (contrib) color module but many other will not. The truth is that most of the time Drupal is used by developers to build websites for content editors and authors rather than an out of the box solution a-la wordpress.
This is why, in my opinion, color module belongs to contrib.

webchick’s picture

Can we make another issue to discuss whether to move Color module to contrib? The beginning of this issue has all kinds of great improvements for the module, and I'd prefer to keep this issue focused on reviewing/committing those.

tim.plunkett’s picture

Title: [META] Remove Color module from core and make it a contributed module. » Refactor color module
markcarver’s picture

Status: Active » Needs review
122.81 KB
FAILED: [[SimpleTest]]: [MySQL] 47,579 pass(es), 50 fail(s), and 33 exception(s). View

Feature freeze is creeping up. Created a patch against the latest HEAD. Note this patch also depends the changes made in #1067408-75: Themes do not have an installation status. This patch is similar to the work I did in my sandbox, however didn't get a lot of feedback so here's a patch.

Status: Needs review » Needs work

The last submitted patch, 445990-color-refactor-42.patch, failed testing.

markcarver’s picture

Assigned: markcarver » Unassigned
markcarver’s picture

Version: 8.x-dev » 9.x-dev
Assigned: Unassigned » markcarver
Status: Needs work » Postponed

Now that I'm the D8 component maintainer for color, I'm postponing this to 9.x. We're past feature and code freeze, this is just too big of a task for D8 (and my vision for this module).

markcarver’s picture

joachim’s picture

Came here from #1457200: Provide an API function for setting theme color schemes which has been marked as a duplicate.

Perhaps it might be an idea to break this down into smaller tasks? Eg:

- adding API functions for color module
- adding new theme functions

If each of these were a single issue per change, then a) they'd be a lot easier to review and b) they'd count as API additions, and so could slowly progress during the D8 lifecycle.

markcarver’s picture

Title: Refactor color module » [META] Refactor color module
Issue tags: +Needs issue summary update

Indeed, I completely agree. We should create sub-issues for these. Also, for everyone's information: I went ahead and created the D9 to D8 backport module: What work we do here should be reflected in that project.

markcarver’s picture

Issue summary: View changes

Quoting original issue.

catch’s picture

Version: 9.x-dev » 8.1.x-dev

Moving back to 8.x for a minor release. Anything that would break BC we could if necessary add parallel functionality and hide the old stuff from the UI.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.