Update Twenty Ten and Twenty Eleven to use 3.4 features

[nacin]

Twenty Eleven can be given three distinct updates for 3.4:

• Flexible heights for headers (when a post thumbnail header is not in use)

• Adding Twenty Eleven's theme options to customize

• Providing Text Domain and Domain Path headers

Additionally, a theme just doesn't need a $locale.php file — indeed, core almost never needs one either anymore. I suggest we remove the reference, something I had already done for Twenty Twelve when it was in trunk.

In [20470]:

Flexible heights for Twenty Eleven's custom headers. see #20448.

In [20471]:

Twenty Eleven: Remove $locale.php file support. see #20448.

In [20473]:

Twenty Ten: Remove $locale.php file support. see #20448.

In [20474]:

Flexible heights for Twenty Ten's custom headers. see #20448.

twentyeleven-customize.diff:ticket:19910​ from Otto42 adds postMessage support for Twenty Eleven.

In [20649]:

Theme Customizer: Pass the WP_Customize instance to all actions fired inside the class. Plugins/themes should not refer to the $wp_customize global. see #19910, #20448.

Patch for twentyeleven to support postMessage updating of title, description, and header text-color

20448.twentyeleven.diff is an updated version of the previous patch (in #19910) to take into account [20649] and to add a somewhat smarter way of doing the JS includes for the postMessage handling.

Add color scheme and partially working link-color options to customizer

New patch adds color scheme and link color choices to the customizer.

The link color stuff is partially broken because twentyeleven stores the link color in the database with the # in front of it, while the customizer's color control expects it to not have that. I wrote a function to add the # to make the previewer work, but the control appears wonky when you first load the page.

Uploading the patch anyway in case somebody can see a better solution than myself. I think we'll probably need to make the color control capable of handling the data value with or without the # on the color to get the widest use out of it.

Replying to Otto42:

New patch adds color scheme and link color choices to the customizer.

I take it you might have missed 20448.diff​ :-) Looks good. Obviously far more comprehensive than my initial attempt. I ran into the same issue with #, and I think koopersmith said he was going to work on that.

Add layouts too

Yeah, I did miss that. :)

Patch 3 adds layouts using much the same method nacin's patch used, but with the addition of calling twentyeleven_layouts() to get the list of layouts instead of hardcoding them.

Just a note that header_textcolor is also the checkbox that should show/hide the header text. Hidden when "blank" or empty string. Also see #20600

I've hit a bug where the default "full page refresh" preview of an option doesn't work unless I already have values saved in the DB for the theme.

So, to replicate:

• Delete the twentyeleven_theme_options value from your database.
• Open the customizer for TwentyEleven and toggle the dark/light color scheme, and it won't update.
• Click "Save" on the customizer pane to save the current options.
• Try toggling the color scheme again, and it will work.

It looks like the customizer is expecting a value to be in the DB? This doesn't have to do with saving defaults in the database, does it?!?

Hahahahaha! #blamenacin

andyadams: Patch that should correct this problem is now in #19910. However, I'm not sure that it's the final version of the patch that will be used. But I can confirm that the problem exists.

Replying to Otto42:

Patch 3 adds layouts using much the same method nacin's patch used, but with the addition of calling twentyeleven_layouts() to get the list of layouts instead of hardcoding them.

Would it make sense to move the JavaScript into its own file, and enqueue it via the 'wp_enqueue_scripts' hook? ​Works well for me.

#15858 — we also should add Text Domain and Domain Path headers until a subsequent phase of i18n ideally renders those unnecessary.