[wp-trac] [WordPress Trac] #25580: Twenty Fourteen: Custom Accent Color Variants are Published Too Soon

[WordPress Trac]

#25580: Twenty Fourteen: Custom Accent Color Variants are Published Too Soon
------------------------------+------------------
 Reporter:  celloexpressions  |       Owner:
     Type:  defect (bug)      |      Status:  new
 Priority:  normal            |   Milestone:  3.8
Component:  Bundled Theme     |     Version:
 Severity:  normal            |  Resolution:
 Keywords:  needs-patch       |
------------------------------+------------------

Comment (by celloexpressions):

 Ways to simplify `customizer.php` and adjust the feature, from doing
 nothing to totally removing it:
 1. Implement [attachment:25580.diff] and do nothing. Continue tweaking and
 fixing bugs and only reconsider if an even more involved bug surfaces.
 2. Keep the current implementation, despite the bug.
 3. Start simplifying: keep the current implementation, but generate the
 color variants on page load instead of saving them to the database. This
 removes the need for any functions other than those that actually display
 the UI and output the css (and the one that generates colors). I know it
 seems bad and inefficient, but in the scope of running WordPress two extra
 function calls (to a technically un-complicated function) won't slow
 things down or have much of an effect really. The slight loss in
 optimization would be the trade-off for code simplicity, and making that
 one adjustment makes a huge difference in the complexity of code necessary
 to run this feature. It also fixes this bug, of course, since we're only
 saving one color from the customizer. (FWIW, this is how I originally
 envisioned the feature, but it does make sense to store these values if we
 can do so easily).
 4. Reduce the number of colors needed from three to two by eliminating the
 `accent_lighter` color that is very close to the primary accent color. We
 could compensate for this (as it is used for hover states) with opacity or
 something along those lines, but it'll be less effective to do that for
 the buttons than for the search toggle. Once we've done this, we have two
 options:
         a. Implement 1, 2, or 3 but with only two colors.
         b. Add a separate colorpicker for each of the two colors. At this
 point we're basically just demonstrating how to add a single colorpicker
 control to a theme, twice. This gives users much more control with the
 colorscheme and they could pick a two-toned one; however, it does add
 another option (still very useful, so I'm okay with that). This color is
 not exposed without hover/focus states, so it may not be immediately
 obvious what they're changing in the customizer. Worth noting that we
 can't generate the default for this color, so perhaps it should have its
 own control anyway.
 5. Reduce the feature to a single colorpicker that controls the primary
 accent color used for links, highlight, search toggle, nav hover,
 mediaelement players, etc. In order to do this, we still need to collapse
 the slightly different color into this one (4), but we also need to do
 something with the third color so that it doesn't clash with and potential
 accent color. Unfortunately, I think that means making it grayscale. It's
 only used for hover states (though for most hover states).
 6. Remove the custom accent color entirely. Everyone who doesn't like the
 green either has to make a child theme (which I've seen butchered way too
 many times for simple changes), or know to look for a plugin that adds
 functionality to the theme (an issue with my "Thirteen Colors" plugin, I
 think, as users don't necessarily understand the idea of theme-specific
 plugins versus child themes). (Implement [attachment:25580.1.diff])

 I can patch any of these if it isn't clear what I'm proposing.

--
Ticket URL: <http://core.trac.wordpress.org/ticket/25580#comment:3>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software