search

backdrop / backdrop-issues

Issue tracker for Backdrop core.
144 stars 40 forks source link

Color module not working #1358

Closed stephit closed 8 years ago

stephit commented 9 years ago

I've tried most of the themes with color options available, and only the default color scheme works. Changing to another preset or custom color scheme results in a white background with no color styling. Flushing the cache does not work.

I have just upgraded to Backdrop 1.2.2 from an existing Drupal 7 website. I did follow the instructions and make Bartik the default theme prior to the upgrade.

Thank you!

biolithic commented 9 years ago

Hi stephit,

Yes, most of the contrib themes do not have the color module activated with them yet. For my themes, I just use CSS to color my themes as I see fit (...for example, the PSD or mockup I am theming from does not match "fire engine red "or "plum purple" from the color module options..

If it is important for you to use the Color Module with your themes, please comment so and I will add Color Module support for a/some theme(s) I maintain.

Thanks for the issue!

On Fri, Nov 20, 2015 at 8:51 AM, stephit notifications@github.com wrote:

I've tried most of the themes with color options available, and only the default color scheme works. Changing to another preset or custom color scheme results in a white background with no color styling. Flushing the cache does not work.

I have just upgraded to Backdrop 1.2.2 from an existing Drupal 7 website. I did follow the instructions and make Bartik the default theme prior to the upgrade.

Thank you!

— Reply to this email directly or view it on GitHub https://github.com/backdrop/backdrop-issues/issues/1358.

stephit commented 9 years ago

Hi Biolithic!

Thank you for your quick response! I do think there is a bug here because I have tested most of the themes that have the Color Module included - and it is not working. It doesn't work with the core theme Bartik.

I am capable of editing the CSS by hand but would prefer not to. As a general suggestion, if Backdrop is going to be the "go-to" CMS for small businesses and non-profits, the less users have to mess with code the better.

Ideally, I would love for the CMS to have a total GUI theme builder built-in, where you could go to the themes section and create your own theme by choosing font, colors and a few basic decorative options like rounded corners.

I like how the layout is now separated from the themes, which to me seems like the first step in creating a user interface where the user has control over basic theme design using the GUI.

So yes, the short answer to your question is, including Color Module support for themes would be great, and I think in the long run helpful to small businesses and non-profits. For this particular site, I don't need to re-invent the wheel, so I just want a nice, attractive, responsive theme with some custom colors. The basic blue Bartik theme is a little stale.

Thank you! :-)

stephit commented 8 years ago

OK, I figured out what the issue was -

My Drupal 7 installation had +FollowSymLinks in .htaccess

Backdrop has it set to +SymLinksIfOwnerMatch - which for some reason generates an error message with my Apache setup. I had already changed it back to +FollowSymLinks in the main folder, since Backdrop completely choked when I first upgraded, but I didn't think to check .htaccess in the files directory. I set it back to +FollowSymLinks in files and Colors work now.

I'm not entirely convinced the extra security is absolutely needed but I understand the switch.

It might be worthwhile to just note this somewhere for people upgrading from Drupal. There's a long discussion on changing this in Drupal here, with suggestions on adding comments to .htaccess to give people options with more information:

https://www.drupal.org/node/1269780

quicksketch commented 8 years ago

I'm not entirely convinced the extra security is absolutely needed but I understand the switch.

Huh interesting that this broke Color module. I'll check back into the d.o issue to see if this has been noted over there. We switched it not for the additional security but rather because +FollowSymLinks had stopped working on many web hosts entirely.

It sounds like on some sites, the newer option +SymLinksIfOwnerMatch also causes issues. So it doesn't seem like either option is entirely predictable. Drupal decided to remove this option entirely it seems. I would be fine with following suit if it has the best level of compatibility.

Could you help us out by reporting your version of Apache and where you hosting (whether with a local MAMP/WAMP/whatever or your provider)?

quicksketch commented 8 years ago

Drupal decided to remove this option entirely it seems. I would be fine with following suit if it has the best level of compatibility.

Oh, I see what they did. Alex came up with brilliant solution in https://www.drupal.org/node/1269780#comment-10531440 that just disables the options we don't want, allowing all default server-level options to stay in place (including FollowSymLinks or SymLinksIfOwnerMatch), so we don't need to worry about which one is supported because it will be left on/off based on the global config. This is a great idea.

Note that if we do this, let's make sure we also include the follow-up issue at https://www.drupal.org/node/2619250#comment-10587108.

stephit commented 8 years ago

Could you help us out by reporting your version of Apache and where you hosting (whether with a local MAMP/WAMP/whatever or your provider)?

I don't have that right in front of me but it's a fairly recent (set up a year ago) version of Apache/LAMP installation using Virtualmin to manage the virtual hosts. This is where I was having the problems with +SymLinksIfOwnerMatch - something about the way Virtualmin was setting up the users for the virtual hosts along with FastCGI was causing issues with this setting. I tried to fix this a while back and just finally figured it was not worth my time to wrestle with it.

klonos commented 8 years ago

I don't have that right in front of me...

A quick look in Reports > Status report should display all that info (web server info is the very last row) :wink:

quicksketch commented 8 years ago

PR filed at https://github.com/backdrop/backdrop/pull/1127 that combines the fixes from https://www.drupal.org/node/1269780#comment-10531440 and https://www.drupal.org/node/2619250#comment-10587108.

quicksketch commented 8 years ago

Merged into 1.x and 1.2.x. Thanks @stephit for reporting this issue and referencing the Drupal issue fix!