Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move the Color module to a contributed project #5667

Open
alanmels opened this issue Jul 2, 2022 · 12 comments
Open

Move the Color module to a contributed project #5667

alanmels opened this issue Jul 2, 2022 · 12 comments

Comments

@alanmels
Copy link

alanmels commented Jul 2, 2022

Description of the need

As https://www.drupal.org/node/3276042 says Drupal has deprecated the Color module in 9.4.0 and will remove it from the core in 10.0.0. Has Backdrop community considered to do the same, because some of the arguments described on https://www.drupal.org/project/ideas/issues/2808151 feels true for also Backdrop:

We should move Color module to a contributed project since as it stands, it doesn't provide enough flexibility to be useful for the majority of sites. To be able to create website matching to corporate identity, you would probably want to change at least background images and font families as well.

We never use the Color module on any Backdrop projects as well as number of other modules in core, but I guess it would be too radical to request to move them too from core. But just in case if this resonates to someone else in the community I wonder how many of Backdrop developers really use the following modules? Should they be in core or could be better off as contributed modules?

See the whole list of core modules on https://github.com/backdrop/backdrop/tree/1.x/core/modules:

book - nice module, but rarely used. is core right place for it?
ckeditor - too heavy, too slow, an overkill for some of the simple websites.

@indigoxela
Copy link
Member

A "feature request" to remove features? 😁

Drupal 8+ deprecates a lot.That doesn't mean that Backdrop should do that, too.

We might discuss to move the Color and/or Book module to contrib in 2.x, but that needs careful consideration.

For sure we don't want to remove the CKEditor module. Having a WYSIWYG editor in core is one of the big benefits compared to D7. And I really don't think it's heavy or slow.

Compared to D9 Backdrop is a lightweight. There's probably no urgent need to get rid of stuff. And it's always possible to turn unneeded modules off.

@alanmels
Copy link
Author

alanmels commented Jul 2, 2022

I knew that some feedbacks would be exactly like that - to possibly remove the Color and Book modules, but leave CKEditor intact. And I understand the importance of CKEditor for lot's of users. Let's see if we could get the Color and Book modules off the core's shoulders.

@ghost
Copy link

ghost commented Jul 4, 2022

I can see why Color and Book could be better suited to contrib. So I'd be OK with that, but at the same time I'm OK with them staying in core too...

I agree that CKEditor should definitely stay.

@ghost ghost added the needs - more feedback label Jul 4, 2022
@stpaultim
Copy link
Member

stpaultim commented Jul 4, 2022

I use all three of these modules and am not inclined to remove any of them from core. Althought, I could be most easily persuaded to remove book module from core.

In my opinion, adding a WYSIWYG editor to core was one of the best decisions that were made for Backdrop and Drupal.

I have created two contrib themes from scratch and both of which have color module support and in both cases, I consider the color module to be pretty important. In both cases, I created the themes specifically for the type of user that would use the color module. They are intended to be themes that support as much customization through the UI as possible. I'd like us to do more to make UI customizations easy and the ability to change the color is pretty useful.

Since Basis does support and work with the color module, I am not sure it makes sense to remove the color module without removing/replacing Basis.

I think we would need to provide the ability to make a theme dependent upon a module if we decide to remove the color module from core, because many themes do require it and I don't think it is possible require a module for a theme today.

I have been using the book module more on some recent sites, for some pretty particular use cases. I've love to see metrics on how many Backdrop sites do use the book module. I expect that usage for book module is pretty low and the need for having it in core is not great.

I would not advocate for removing Book module from core, but I would also probably not oppose it either.

@ghost
Copy link

ghost commented Jul 4, 2022

I think we would need to provide the ability to make a theme dependent upon a module if we decide to remove the color module from core, because many themes do require it...

Themes don't require Color, they're perfectly usable without it. Just like if you were to uninstall the Color module from a site now. It's a nice-to-have, that's it.

@indigoxela
Copy link
Member

indigoxela commented Jul 4, 2022

Themes don't require Color, they're perfectly usable without it

Sure, but would core take care of, for example, the notice on top of theme settings pages, that this theme supports Color, if the module is in contrib? 😉 Probably not.

I think, it's important to state that this is probably a 2.x task. Several modules have been moved out of core in 1.x, but before the first stable release.

https://docs.backdropcms.org/change-records/modules-removed-from-backdrop-which-were-in-drupal-7

@stpaultim
Copy link
Member

I think, it's important to state that this is probably a 2.x task.

I understood the original request to be a 2.x idea, even if it wasn't explicitly stated. I think it would be really unusual to remove a module from core short of a major version release and I'd be surprised if anyone is advocating for that.

Themes don't require Color, they're perfectly usable without it. Just like if you were to uninstall the Color module from a site now. It's a nice-to-have, that's it.

This is literally true, but a little problematic. I created the Opera theme with the specific purpose in mind of allowing site architects to create a front page with full width blocks that contain background colors, without having to write any custom css (based upon the availability of the color module). A site that looks something like this:

image

The settings page for Opera looks like this:

image

These are all color choices that have been provided to the site architect, which are made possible because of the color module. Without the color module, the Opera theme would not break - but it would not serve the purpose it was designed for. As the theme maitainer, I consider the color module to be more than a "nice to have" for anyone choosing to use this theme. In my eyes, it's a dependency. Without the color module, there is no real reason to use this theme.

Having the color module is core is not necessarily a requirement for this, but if it weren't I would really want the ability to declare modules as dependencies for themes (I want it anyway, but right now it's a little less urgent).

@avpaderno
Copy link
Member

IMO, the possibility to change theme colors is useful; it allows me to use a different color schema without altering the used theme.
I would keep it in core, since it's not a module that requires much work to maintain it.

I would rather remove the Book module, as it can be replaced by a contributed module or a view.

I won't remove the CKEditor module, since it provides a functionality that is much helpful. (I won't return to manually enter HTML markup.)

@klonos
Copy link
Member

klonos commented Dec 12, 2022

Since Basis does support and work with the color module, I am not sure it makes sense to remove the color module without removing/replacing Basis.

I would keep it in core, since it's not a module that requires much work to maintain it.

Yup. I agree with the above ^^

When it comes to this:

...To be able to create website matching to corporate identity, you would probably want to change at least background images and font families as well.

I think that the idea of removing a helpful functionality that moves the software closer to no-code/less-code simply because it doesn't achieve "everything" is hardly a strong argument. ...and the use of the word "probably" in that sentence doesn't provide confidence to the whole argument either.

@klonos klonos added this to the 2.x-future milestone Dec 12, 2022
@klonos
Copy link
Member

klonos commented Dec 12, 2022

...this certainly cannot happen in 1.x.

@cellear
Copy link

cellear commented Dec 29, 2023

Apologies for the late comment, but I find myself using the color module in a current project, and I'm horrified at the suggestion that it should be removed! I think color module is one of most "backdroppy" things in Backdrop, and Drupal's removal of it is consistent with the "screw the little guys" direction the Drupal project took in D8.

I feel like color module should be improved, promoted, and documented, and that we should try to make other facilities more like it. Being able to define interface elements inside of the UI, rather than with a text editor, is a huge win.

@docwilmot
Copy link
Contributor

Perhaps color and book are good candidates for telemetry?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants