Navstrip default colors not defaulting

[musyc]

ANSWERED: Known bug, cannot be fixed without overrides/layer edits.

I was testing out layouts/themes earlier, and on several, the navstrip was coded to match the theme. This is not a choice I like, but different strokes. I figured I could just reset the strip to default.

However, when I attempted to change the setting in Customize -> Display, it didn't work. I changed the radio button to the light grey gradient, saved changes, and no change happened. Same when I switched back to the dark grey gradient. It's still showing as the theme colors. (I'm currently using Bolt for Corinthian on my testing journal, but it's happened on every theme I tried that had pre-selected custom navstrip colors.)

There's this line on the page - You can customize the color of the navigation strip on your journal. - but there is no option to stop the customized colors if they're embedded into the theme. At least, not one that I can locate.

Is this a bug or a feature? How can I tell the site to stop showing customized navstrip colors on the theme I choose? I only want the default dark grey navstrip, no matter what layout/theme I select.

Comments

[sharpiefan]

(I have the opposite issue - I'd like to color the navstrip in all my journals/communities to match the layout's colours. There are layouts where the only options are the grey navstrips - they tend to be slightly older themes, though, I think.)

[momijizukamori]

Per my comment to musyc below - when the new, shiny navstrip code goes live, all layouts (except Zesty) will have customizeable navstrip colors :)

[sharpiefan]

\o/ This makes me a Very Happy Sharpie! \o/

[momijizukamori]

You're welcome! It's inching along - getting the settings stuff to behave right now *g*

[momijizukamori]

Um. Unfortunately I think the simple solution is to wait until I've finished fixing the custom navstrip color code.

Basically the text appears that you can customize the color of the navstrip because we have some core2 functions that let you do this. These have actually never been enabled, I suspect in part because they're not 100% functional. So a bunch of layouts hardcode color variables in, and the only real way to get the default back is to manually edit the layer to remove that CSS (or do a whole pile of overrides).

...AKA this is a Known Bug :c

[musyc]

*nose wrinkle* Ah. Very disappointing, but I'll just avoid those layouts henceforth. At least until this is fixed. Thx for letting me know.

Pondering:
Is this something that is worth altering the wording on the customize page and/or notating in the layout-selection wizard, for values of long-term-low-priority bug fixage? So that there's less potential user frustration from running into this?

[momijizukamori]

The list of ones that override the default selection, if you're curious:
Bases
Corinthian
Crisped
Databases
Dusty Foot
Five AM
For The Bold
Line Up
Practicality
Wide Open

And it'd probably be a null point - I'm really really pushing to get the navstrip coding fixed for the next big code push, which is probably when any wording changes would go live. It's probably like 80% patched right now, but I took a small break this week to push at the new comment page *g*

[musyc]

*\o/* *\o/* *\o/* *\o/* *\o/* <-- Applause, pom-poms, and imaginary internet cookies of coder-encouraging cheer XDXD

If it's that close to fixed ('probably next code push' is 'magically done' for most things, to me XD ) then I shan't fret about it. Layout rotation on my comms can wait for that to go through.

[momijizukamori]

It is basically my next priority after the last of the new comment page bugs (which will hopefully happen today, possibly in the next half an hour), so, yes. I'm really pushing to get this done, because I had complaints about it in Corinthian (which is based on Crisped, and I have the navstrip turned off on my DreamHack so I didn't notice I'd carried over the code).