Make recolorable, like Garland

Good description of the process of making a theme recolorable here
http://drupal.org/node/108459

I'd love to create a finalized syntax and help colorize acquia marina. It looks like a good candidate.

Will be back here v-very soon.

help steer you guys in the right direction

cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal-contrib checkout -d color_soc08-DRUPAL-6--1 -r DRUPAL-6--1 contributions/modules/color_soc08/

http://kuler.adobe.com/

Peek at style.css, template.php (hook_color()), .info file (color = true), the blank files in images/color

That's about it.

Edit: updated CVS. I'll stay subscribed.

This may require standardization of Marina's CSS color usage (E.g. no color shorthand like white or #000.

I think color module is compatible with shorthand code:

http://api.drupal.org/api/function/_color_unpack/6

Bevan, et al. I am pretty busy during weekdays. But I'm going to take a peak and cleaning code + implementing some of those fixes (which seem relatively easy).

OK. Today I am going to try to address those bugs. If you find anything else...

Just taken care of one.

Both those bugs are taken care of.

I was wondering if you could perhaps, after RTL support is committed, give this thing some public exposure in a -dev release so we can perfect it? I'll gladly act as a "sub-maintainer" to the color support.

I'll be uploading a new zip in a bit. I'm going to simplify this one a bit.

Those bugs you mentioned in color.module, which you made issues to, were both fixed last week, unless you find otherwise. If they are for color module, lets keep that discussion inside that queue so we don't side track here.

Also, I am having difficulty performing the diff, can you tell me the command you use to create that patch? I've only created patches a few times.

I have worked on simplified version of the color file with less fields. It's better to introduce a simple version, and get feedback on that.

Edit: This patch is failing for me

(Stripping trailing CRs from patch.)
patching file acquia_marina.info
Reversed (or previously applied) patch detected!  Assume -R? [n] y
(Stripping trailing CRs from patch.)
patching file style.css
Hunk #1 FAILED at 76.
Hunk #2 FAILED at 84.
Hunk #3 FAILED at 103.
Hunk #4 FAILED at 867.
Hunk #5 FAILED at 1133.
Hunk #6 FAILED at 1279.
Hunk #7 FAILED at 1979.
7 out of 7 hunks FAILED -- saving rejects to file style.css.rej
(Stripping trailing CRs from patch.)
patching file template.php
Hunk #1 FAILED at 645.
1 out of 1 hunk FAILED -- saving rejects to file template.php.rej

I've tried it on my zip, my latest tar, and the DRUPAL-6--1 branch of acquia marina.

subscribing, greet if colors would be supported! Greetings, Martijn

+1 vote for this

@Bevan & @skiquel

This is great! Thanks for taking this on!

I created a new branch - DRUPAL-6--2. I hope that you can continue working on this within the 2.x branch.

I took the baby step of adding the color directory (and images) to the theme's images dir. for the 2.x branch. Once I have a chance to fully play with what you've done, I will add it to the 2.x branch ASAP. I hope this new branch will help with further development of making Marina recolorable.

Hi folks,

I just wanted to express my support for this project. Making this theme's colours changeable would be superawesome. In general I like the direction of the 6x-2x brach very much. Do it!

I am willing to provide some practical feedback/testing of the devs as I cannot code a whiff.

@Bevan - I can confirm that schemes stopped working.

I narrowed down the problem. We recently added to template.php a new way of loading stylesheets which fixes an issue w/ Internet Explorer that limited the number of stylesheets IE can handle. This new code breaks the way stylesheets are loaded for the ng.color module. Essentially, it does not load the stylesheet(s) for the color scheme(s).

We will work on a solution ASAP. In the meantime, for reference, below is the code from template.php, that was added to the DRUPAL-6--2 branch, which break color schemes - removing the following chunk will correctly load the color scheme stylesheet(s).

template.php line 300 - 323

  // Use grouped import technique for more than 30 un-aggregated stylesheets (css limit fix for IE)
  $css = drupal_add_css();
  if (theme_get_setting('fix_css_limit') && !variable_get('preprocess_css', FALSE) && css_count($css) > 26) {
    $styles = '';
    $suffix = "\n".'</style>'."\n";
    foreach ($css as $media => $types) {
      $prefix = '<style type="text/css" media="'. $media .'">'."\n";
      $imports = array();
      foreach ($types as $files) {
        foreach ($files as $file => $preprocess) {
          $imports[] = '@import "'. base_path() . $file .'";';
          if (count($imports) == 30) {
            $styles .= $prefix . implode("\n", $imports) . $suffix;
            $imports = array();
          }
        }
      }
      $styles .= (count($imports) > 0) ? ($prefix . implode("\n", $imports) . $suffix) : '';
    }
    $vars['styles'] = $styles;
  }
  else {
    $vars['styles'] = drupal_get_css();                                   // Use normal link technique
  }

Donations, bounties or enquiries welcome.

How bout heaps of kudos?! ;)

skiquel, Bevan, does the module add the colorized style.css stylesheet to the stylesheet queue using drupal_add_css() or does it only put it into the $vars['styles'] variable?

In order to add some custom theme setting stylesheets in template.php we grab the stylesheet queue and write it back out to $vars['styles']. So if the colorized stylesheet is in the queue then it should be included, otherwise it'll get wiped out if it's only in $vars['styles'].

If it's not currently being added to the queue, it'd be great if it could be. Adding stylesheets at the theme layer is not uncommon, so anyone using drupal_add_css() to add stylesheets and then using the result from drupal_get_css() to re-populate $vars['styles'] is going to end up overwriting the colorized stylesheet.

Of course, I could also grab $vars['css'], add our stylesheets directly to the array, and then call drupal_get_css() with it. I've tried it and it works.

But that's seems less Drupally and would be something that other themers (or module developers?) might miss when they try to use drupal_add_css()/drupal_get_css() to repopulate $vars['styles']. So the problem might crop up again.

In addition, manipulating the $vars['css'] array directly might (?) be bypassing the css aggregation system, but I'm not sure about that.

Also, I'm not familiar with the color_nextgen code base so maybe there is a technical reason why adding the stylesheet to the queue won't work.

Thanks!

I don't know how much the approach described here (http://www.alldrupalthemes.com/drupal-blog/omg-were-live (somewhere in the middle)) is applicable to the problem at hand. But it might be worth a look.

Bevan,

The ie6 css aggregation technique is purely optional and only used when actively selected in the development section of the theme settings. It is not recommended for production use. Instead, aggregation should be used to get around the 32-stylesheet limit. The aggregation technique in template.php is solely for the convenience of theme developers during development.

So that code is actually tangential to the issue. Even if it wasn't there, I'd still be calling drupal_add_css()/drupal_get_css() in order to add the stylesheets for custom theme settings (e.g., for width, fonts, etc.).

I wasn't aware that using add/get would incur a significant performance hit. I assumed that caching would be used on larger sites, which would eliminate the added processing penalty after a page was cached.

Another option would be for me to add the custom theme setting stylesheets separately like the ie6/7-fixes.css stylesheets. They wouldn't get aggregated, but it would side-step the color_nextgen problem, at least for our themes. Would there be a net performance gain by not calling add/get?

The approach you linked to for adding css stylesheets was a very interesting approach. One question I had was where this technique would put your stylesheets in the queue. The comments state that it still occurs late in the rendering process, but would there be any chance that they could be put in front of module and/or core stylesheets? Hopefully not, as this would eliminate the certainty of overriding other stylesheets.

If there aren't any significant downsides to your approach and if it still works in template.php, then i may give it a shot.

Thanks!

I've been busy with the surgery thing for the past 2 weeks, but this weekend I'm going to devote some time to getting this thing working. Just make sure the dev is updated

tony

/acquia_marina-DRUPAL-6--2

patching file style.css
Hunk #1 FAILED at 76.
Hunk #2 FAILED at 84.
Hunk #3 FAILED at 875.
Hunk #4 FAILED at 1141.
Hunk #5 FAILED at 1287.
Hunk #6 FAILED at 1926.
6 out of 6 hunks FAILED -- saving rejects to file style.css.rej
(Stripping trailing CRs from patch.)
patching file template.php
Hunk #1 FAILED at 674.
1 out of 1 hunk FAILED -- saving rejects to file template.php.rej

If someone can see if that patch works on a clean DRUPAL-6--2 checkout... I think I'll still be able to work on it.

@skiquel - I've created separate patch fies for each file needing to be patched in the hopes of easing your patching process. The following steps will get you acquia_marina-6.x-2.x-dev patched and working with the color:ng module:

1. cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal-contrib checkout -r DRUPAL-6--2 -d acquia_marina contributions/themes/acquia_marina

2. place all attached patch files w/in the acquia_marina checkout dir.

3. patch -p0 < acquia_marina_info.patch

4. patch -p0 < style.patch

5. patch -p0 < template.patch

6. patch -p0 < theme-settings.patch

Please note that removing the following, from template.php, fixes the issue with the color:ng stylesheets not loading as I mentioned in the above post:

  else {
    $vars['styles'] = drupal_get_css();                                   // Use normal link technique
  }

The template.patch removes the above mentioned else while also adding the function acquia_marina_color() section.
However, removing the else is not ideal.

Attached are the modified images.

I'll add these to CVS soon-ish. I still need to clean a few up.

How is removing the else not optimal?

Color.module's current way of overriding may not work with drupal_get_css because it's not using the global $var variable's stylesheets.

Still looking into a work-around on either end.. As for the else, what is its purpose?

Looking forward to this, can't code but am willing to test.

There some "clash" with Wysiwyg API module and associated editors using javascript. Don't know what it is yet.

@skiquel - removing the else, specifically the $vars['styles'] = drupal_get_css();, is not optimal because it disables the loading of styles for other sections of the theme, e.g., every feature within theme_settings dir wont work. To clarify, the "Custom settings" section w/in the theme-settings need $vars['styles'] = drupal_get_css();. Theme width & Theme fonts settings break w/out $vars['styles'] = drupal_get_css();

@gumdrop - Please file a separate issue. The WYSIWYG issue you're reporting has nothing to do w/ the recolorable efforts.

@jwolf - My apologies however I am using everything in #34 and thought it might be relevant to this topic as well.

Have the patches on #34 been added to the dev version yet?
Many thanks :):)

subscribe

volunteer to be beta tester for recolorable Marina. Thanks to you folks for doing this!
our acquia marina site: http://voiceseducation.org

As Aquia Marina is one of the best looking free Themes for Drupal it would be a great enhancement when it is colorable.

Is there any progress on this topic or any timeframe when you think it would be available as dev or release?

thnx in advance.

subscribe

subscribed

subscribe

subscribe

Looks like this is not going to happen with any new releases of Marina since Marina is moving to Fusion.

There are instructions on how to implement this here and here.

Is that moving to "won't fix" because Fusion implements this functionality, so it is no longer needed in Acquia_Marina? Or is it that the theme has changed so much, with the link to Fusion, that work already done towards colorability is now redundant?

If the latter, should I open a new issue, as a feature request, against 6.x-2.x, to request coloration? I see that adding integration to the color module is still in the release notes for 6.x-2.x (http://drupal.org/node/472094)

JamesOakley wrote:
> Is that moving to "won't fix" because Fusion implements this functionality, so it is no longer needed in Acquia_Marina?

No, the Fusion base theme doesn't seem to support the Color core module at this moment. On How do I change colors in my Fusion Drupal theme? they say: "You'll need to alter both the graphics and CSS."

Maybe before/instead of marking it "won't fix", it would be useful to know whether this feature (colorizable theme) should be a feature request for Acquia Marina 3.x, or Fusion, or both.

Sorry this isn't something that is possible with how the theme is currently built and we will be looking at a method to redo it as colorable in the future, just not at the moment. Remarking as "won't fix" because this is a feature request and we won't be adding this support for the 2.x version. Feel free to create a new issue with it as a feature request for the 3.x version though as someone might want to tackle that before we get around to it and release it for the public.