My taxonomic color changes are working fine, but although the events show up with the right background color, the titles seem always to be in white--no way to make it match the settings in the "colors" module, which seems to sense the black/white choice automatically. How can I change the text color on my events to match what's showing in the colors modules?

Comments

tim.plunkett’s picture

Project: FullCalendar » Colors
Version: 7.x-2.x-dev » 7.x-1.x-dev
Component: FullCalendar Colors » User interface

Not yet, there is code for it in the Colors API, but nothing in the UI.

If you could come up with screenshots of how that might look, I can implement it. I just couldn't figure out how to do it.

TwiiK’s picture

Place the below code in any module and replace MYMODULE with the module name and you'll get this:
http://i.imgur.com/kUNVi.png

Should be fairly easy to include into the module itself. It's just the module code copied with a few small changes here and there.

I've only done this for the user colors as those are the only colors I'm currently using in my project.

/**
 * Implements hook_form_alter().
 */
function MYMODULE_form_alter(&$form, &$form_state, $form_id) {
  // Only do this for the users part of the colors settings form.
  if ($form_id == 'colors_generate_settings_form' && $form['#colors_type'] == 'users') {

    // Add our override css.
    drupal_add_css(drupal_get_path('module', 'MYMODULE') . '/colors.admin.override.css');

    // Most of the code below is just copied from colors.admin.inc
    $type = $form['#colors_type'];
    $info = $form['#colors_info'];

    $multiple = !empty($info['multiple_function']);
    $repeat = !empty($multiple) ? $info['multiple_function']() : array(NULL => NULL);

    foreach ($repeat as $id => $repeat_value) {
      $enabled_type = !empty($multiple) ? $type . '_' . $id : $type;
      $enabled_string = 'colors_' . $enabled_type . '_enabled';

      foreach ($info['function']($id) as $key => $value) {
        $class = 'colors_' . $type . '_' . $key;
        $colors = colors_get_colors($class, 'colors');

        // Here we override the old textfields with fieldsets.
        $form['fieldset'][$class] = array(
          '#type' => 'fieldset',
          '#title' => t($value),
          '#collapsible' => FALSE,
          '#collapsed' => FALSE,
          '#states' => array(
            'visible' => array(
              ':input[name="' . $enabled_string . '"]' => array('checked' => TRUE),
            ),
          ),
          '#attributes' => array('class' => array('user-colors')),
          '#tree' => TRUE,
        );

        // And put our background, border and text colors as children of those fieldsets.
        foreach ($colors as $key => $color) {
          $form['fieldset'][$class][$key] = array(
            '#title' => t($key),
            '#type' => 'textfield',
            '#attributes' => array('class' => array('colorpicker-input')),
            '#default_value' => $color,
            '#size' => 7,
            '#maxlength' => 7,
          );
        }
      }
    }

    // Use our own submit handler.
    $form['#submit'] = array('cal_colors_admin_users_settings_submit');
  }
}

/**
 * Our custom submit handler for the users colors settings form.
 *
 * Identical to the one in colors.admin.inc except for the part which
 * saves the colors.
 */
function MYMODULE_colors_admin_users_settings_submit($form, &$form_state) {
  if (empty($form['#colors_type']) || empty($form['#colors_info'])) {
    return;
  }

  $type = $form['#colors_type'];
  $info = $form['#colors_info'];

  $multiple = !empty($info['multiple_function']);
  $repeat = !empty($multiple) ? $info['multiple_function']() : array(NULL => NULL);

  $multiple_enabled = FALSE;
  foreach ($repeat as $id => $repeat_value) {
    $enabled_type = !empty($multiple) ? $type . '_' . $id : $type;
    $enabled_string = 'colors_' . $enabled_type . '_enabled';

    variable_set($enabled_string, (bool) $form_state['values'][$enabled_string]);
    if (!empty($form_state['values'][$enabled_string])) {
      $multiple_enabled = TRUE;
    }

    foreach ($info['function']($id) as $key => $value) {
      $class = 'colors_' . $type . '_' . $key;

      // Here we save all 3 colors properly instead of just background.
      $colors = array(
        'background' => $form_state['values'][$class]['background'],
        'border' => $form_state['values'][$class]['border'],
        'text' => $form_state['values'][$class]['text'],
      );
      colors_set_colors($class, $colors, $type);
    }
  }

  if ($multiple && $multiple_enabled) {
    variable_set('colors_' . $type . '_enabled', TRUE);
  }

  colors_css_clear();

  drupal_set_message(t('The configuration options have been saved.'));
}

colors.admin.override.css:

/**
 * @file
 * Overrides for Users color settings admin page.
 */

.fieldset-wrapper .user-colors {
  display: block;
  float: left;
  width: 33%;
  border: none;
}
.fieldset-wrapper .user-colors .form-item {
  display: block;
  float: none;
  width: 100%;
  margin: 0;
  padding: 0;
}
.fieldset-wrapper .user-colors .form-item label {
  display: inline-block;
  width: 80px;
}
scass’s picture

Issue summary: View changes

TwiiK

It's been a while since your post above. You do offer a nice fix for user colors. Unfortunately, I would like a similar fix for the event taxonomy colors.

I'm developing my second community site with Drupal. Unfortunately, I'm not a programmer, though I have a rudimentary idea (hmmm... learned a bit of Fortran using punched cards back in the late '70s!). I do seem prone to jumping in at the deep end...

I did make your code above work for users. I then tried replacing instances of 'users' with 'taxonomy', but that doesn't work. If you or anyone else could help extend the code to deal with taxonomy, I'd be very grateful.

Incidentally, although the above worked for me, I'm wondering if there's not an error in the code? On line 57:

$form['#submit'] = array('cal_colors_admin_users_settings_submit');

Should this not actually be:

$form['#submit'] = array('MYMODULE_admin_users_settings_submit');

(ie the actual custom module name was inadvertently left in place?)

Anyway, many thanks to anyone who can extend this fix for my case, which I would think would be a common requirement.

Cheers,

Steve