Problem/Motivation
Using the Color Field module in most cases means, you decide for one of the provided color pickers. In modern times this might be the HTML5 Color Picker for many cases (as it has no extra (jQuery etc.) dependencies and is supported by all modern browsers).
Of course the other widgets:
- jQuery Simple Color
- Spectrum
are also helpful for special or more complex cases.
But in any project where we're using Color Field, the Status Report warnings for these libraries are disturbing and confusing and you have no way to disable them?
So as I think they are becoming an edge-case more and more, you should be able to opt in to these additional widgets, if you want and need them!
Of course that could be a setting, but I think the best and most Drupal-like way would be to have the Color Field base module with the native HTML5 color field.
Additional widgets could then simply be provided by submodules that define their dependencies and their status report warnings.
Steps to reproduce
Install Color Field and always see the warnings for the libraries you may never want to use. No good way to get rid of them.
Proposed resolution
- Split out the additional widgets and their status report checks into submodules
- Enable the submodules in an update hook (to not break existing installations). New sites have these submodules disabled by default and can opt-in.
- Show a note in the update hook that administrators can now uninstall the submodules if they don't use these libraries. (If we're super friendly, we could indicate that the libraries aren't present so it can be assumed that the submodule isn't used!)
Remaining tasks
User interface changes
None
API changes
None
Data model changes
None
Issue fork color_field-3453011
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
anybodyComment #3
anybodyI guess this should be relatively simple? What do the maintainers say, should we do it like this?
I'd like that very much.
Comment #4
nickdickinsonwildeVery much in favour of this - would need readme updates as well but the plan written out seems good to me
Comment #5
jrochate commentedTotally agree.
Comment #8
rupertj commentedI've had a go at splitting out those widgets into their own submodules as per the discussion here. My site only uses the HTML 5 widget, so I've tested the update path, and that I can disable the submodules to stop the warnings about the missing JS for the widgets I'm not using appearing.
I haven't tested that the spectrum and grid widgets still work manually, as my site doesn't use them.
Comment #10
rupertj commentedComment #11
rupertj commentedI realised the new submodules are inconsistently named, so I'll fix that.
Comment #12
rupertj commentedDone
Comment #13
anybodyNice work @rupertj! This is a huge win for the module (and its module'arity :D). LGTM!
Comment #14
anybodyAs this is a big change, could you get a maintainer in here, so this won't need endless rebases? If fine, it should get merged asap.
Comment #15
lrwebks commentedWorks as expected! Good work, @rupertj!
Comment #16
anybodyThanks @lrwebks! If maintainers agree I'd strongly vote to merge this ASAP to not get merge conflicts with other issues.
I think this is a very helpful structural improvement.
Comment #19
mandclu commentedThanks for everyone's work here. Merged into the 3.1.x branch.
Comment #21
anybodyGreat to see this merged, thank YOU @mandclu!
Can't wait for the release :)