Rewrite the FullCalendar Colors API to be the Colors API using the CTools CSS system

#1348604: Rework to use CTools CSS plugin to store generated CSS as a file is how I think we should fix this.

Wow is the ctools css stuff easy.

Okay, so pretend that fullcalendar_colors_create_css_file() is a colors.module function. I just put it in fullcalendar_colors so it could be patched against fullcalendar.

The changes to fullcalendar_colors_set_color() are not ideal. I need to think about that more. It needs to be something closer to the changes in fullcalendar_colors_admin_settings_submit().

There is likely a lot more in fullcalendar_colors.module that can be ripped out, but this is a start.

Yeah I messed that up last night. Fixed now.

I also realized the empty handler is completely unused now....

Okay so a couple issues:

• Rearranging is broken
• The pattern to trigger a rebuild is bad
• Not every module needs to implement hook_colors_build_selector() so we need a new way of doing that

aspilicious suggested we just rebuild the css on every submit, but that's not exactly ideal either.

Here's a first stab. Still haven't addressed the first two points of #6, and I might refactor more.

Ugh 0 bytes fail

At the end of this, fullcalendar_colors should be about four functions:
fullcalendar_colors_colors_build_selector() to dictate the selector
fullcalendar_colors_preprocess_fullcalendar() to add the file
fullcalendar_colors_create_css_file() or something to generate the file
fullcalendar_colors_fullcalendar_classes() to add the classes

The default color stuff is still not done, but the rest looks pretty good to me.
Upgrade path is still untouched.

We could add a flag per plugin to exclude when adding classes not colors. Would that work? Your code NEVER gets added as classes, right?

Okay, now those implementing hook_colors_classes can choose to exclude themselves from classes, and only be in the CSS file.

See the bit in colors.api.php for hook_colors_classes().

I didn't get anything more accomplished, but I did push up branches. Updated the issue summary.

I pushed up the alpha7/beta1 version of the upgrade path.

I can adapt the old fullcalendar_colors_update_7200 pretty easily, I just have to add some module_exists calls and use the new API functions. Also, I need to whip up an alpha6 site. That's for tomorrow.

Alright, tested it from both alpha6 and beta1, everything works great.

The only thing I haven't checked is exactly what happens if you don't get the new colors version before updating fullcalendar.

Okay, added checks to make sure the updates don't run if Colors is out of date.

Ready for review!

Here are patches for the less git inclined.

n00b confusion here:

$ git apply -v colors-1348538-20.patch 
Checking patch colors.api.php...
Checking patch colors.info...
error: while searching for:
name = Colors
description = API for coloring selectors.
core = 7.x

error: patch failed: colors.info:1
error: colors.info: patch does not apply

The fullcalendar patch applies fine. What exactly do you mean by 'latest version' of Colors? I've tried with -dev and -alpha2.

@pjcdawkins, the Colors module is separate: http://drupal.org/project/colors

@aspilicious, awesome! I'll be sure to document the empty handler part.

http://drupalcode.org/project/fullcalendar.git/commit/8b9eb10abfcdecb375...
http://drupalcode.org/project/fullcalendar.git/commit/6be0f7076a2d70bf9e...
http://drupalcode.org/project/fullcalendar.git/commit/e790f3bdc62f2de984...
http://drupalcode.org/project/fullcalendar.git/commit/346770d75666e52d76...
http://drupalcode.org/project/fullcalendar.git/commit/83e438d831494c0043...
http://drupalcode.org/project/fullcalendar.git/commit/3911418917a738eeb0...

Awesome! Tagged a new beta2.

@#23

fullcalendar_update_7201() was insisting I didn't have the latest version of Colors, because I couldn't get colors-1348538-20.patch to run. But it's working beautifully now with your beta2 release. Thanks!