Themes: change allowed term taxonomy from Width to Layout and add responsive-layout term

[lancewillett]

See #21065 and discussion with WPTRT on ​http://make.wordpress.org/themes/2012/07/18/id-love-your-thoughts-on-adding-two-new/.

"Width" is not accurate since themes can have fluid, fixed, or responsive height as well as width.

"Layout" makes this more abstract.

[sabreuse]

+1 on "layout" - and let's get Responsive in there!

[sabreuse]

Closing in favor of ​http://meta.trac.wordpress.org/ticket/78

[nacin]

As found buried at the bottom of 21442.patch​, a change is required in theme.php for this to truly take effect. If WP.org and core gets out of sync there could be problems.

[sabreuse]

Oops! Thanks for the catch on that. For any other requests to add tags to the theme filter, is the best process to have a ticket here for theme.php linked to one on meta for the wp.org interface?

[nacin]

Replying to sabreuse:

Oops! Thanks for the catch on that. For any other requests to add tags to the theme filter, is the best process to have a ticket here for theme.php linked to one on meta for the wp.org interface?

I think here (only) is likely sufficient. It realistically needs to be cleared through core before going further. Once it is, we can sync it to WP.org. I think WP.org uses a copy-paste of the core function.

[lancewillett]

Could we get this change into 3.8 please? Otto mentioned updating the WP.org directory taxonomy and this is the most urgent change at the moment with hundreds of new themes that are responsive and don't have a way to show that.

[dd32]

As found buried at the bottom of 21442.patch​, a change is required in theme.php for this to truly take effect. If WP.org and core gets out of sync there could be problems.

Could we get this change into 3.8 please? Otto mentioned updating the WP.org directory taxonomy and this is the most urgent change at the moment with hundreds of new themes that are responsive and don't have a way to show that.

FWIW, The list of Features is primarily loaded from api.wordpress.org in core, we only include a list as a backup incase the API is unreachable.. It won't be the end of the world if a few installs display/query the old name (afterall, plenty of pre-3.8 sites will do exactly that).

[samuelsidler]

Replying to dd32:

FWIW, The list of Features is primarily loaded from api.wordpress.org in core, we only include a list as a backup incase the API is unreachable.. It won't be the end of the world if a few installs display/query the old name (afterall, plenty of pre-3.8 sites will do exactly that).

I was under the impression that translations used what was in core, not the API, otherwise tags wouldn't be translated in localized WordPress installs.

[nacin]

Replying to samuelsidler:

Replying to dd32:

FWIW, The list of Features is primarily loaded from api.wordpress.org in core, we only include a list as a backup incase the API is unreachable.. It won't be the end of the world if a few installs display/query the old name (afterall, plenty of pre-3.8 sites will do exactly that).

I was under the impression that translations used what was in core, not the API, otherwise tags wouldn't be translated in localized WordPress installs.

It's a bit of both. The API dictates the current list. The core strings are then used to overlay the translations.

[nacin]

What happens to themes using the current flexible-width and fixed-width tags? Should they automatically (on the WP.org side) be re-classified as flexible-layout and fixed-layout for search purposes?

I think it has been good to take our time on this one, because there's been a lot of wavering over the years on some of these, especially as technology and techniques have evolved. If it still looks good to us now, then let's go with it.

[samuelsidler]

See also #26157.

[nacin]

I'm going to ask Otto42 to change WP.org to:

• add flexible-layout, fixed-layout, and responsive-layout as allowed tags
• recommend (on upload) that -layout be used instead of -width
• for the requested list of tags, serve -width to < 3.8 and -layout to >= 3.8 (the HTTP API's user agent can be parsed; if a plugin is overriding it, not really a big deal)
• for each individual theme API response, append the -layout tags if it only has -width (and vice versa)

3.7 installs will then be able to search for -layout and find themes updated for 3.8. 3.8 installs will be able to search for -width and find themes still using the old tags.

So more or less, deprecate and alias. This is not particularly easy to do, but it's time to do it.

[Otto42]

What API methods will this impact? /themes/info? Any others?

If so, then I recommend bumping the version from /themes/info/1.0 to /themes/info/1.1 to handle the 3.8/not-3.8 case, instead of using user-agent parsing.

1.0 can be altered to only serve -width
1.1 can be altered to only serve -layout

[nacin]

We need to bump to 1.1 anyway, so that may be doable. However, /themes/info/ for 'feature_list' is the easy part. The more complex problems are aliasing and adding it to theme check.

[Otto42]

Theme check should be easy enough. Attached a diff of the plugin. Also fixed up the i18n code while I was there.

[Otto42]

diff for theme-check trunk

[lancewillett]

Refresh patch and add Twenty Fourteen

[Otto42]

Core changes only, no theme changes, fixed fluid->flexible issue

[Otto42]

21442.2.patch​ is the necessary change for core, ignoring the themes which can be done separately or ignored for now. Also, changed "fluid" to "flexible" to match the wording.

This patch will go along with changes to the .org theme search and theme/info APIs to allow for these three new tags.

Theme Check changes will need to be committed and applied to .org shortly after 3.8's release.

[lancewillett]

Flexible to Fluid after IRC discussion

[lancewillett]

Replying to Otto42:

Also, changed "fluid" to "flexible" to match the wording.

Sorry for the change, Otto42 -- my earlier patch was wrong. Discussed in IRC ​log and decided Fluid was better.

[Otto42]

Okay, well, I guess it's a good thing I didn't commit the .org changes yet, since now I have to change those. :)

[lancewillett]

Refreshed for Twenty Fourteen

[matt]

In 26711:

Add and display new tags to highlight the ever-growing number of responsive themes available. Fixes #21442.

Props Otto42 and lancewillett.

[nacin]

I think Otto42 has a plan (and code) for themes currently tagged fixed-width and flexible-width from the WP.org side. Ideally they are just aliases.

[Otto42]

Yes.

• Theme search modification: fixed/flexible-width tags will be treated identical to fixed/fluid-layout tags for search purposes. Searching for either will get the equivalent other one too, so if you search for "fluid-layout" you also transparently get "flexible-width".

• Approved theme tags change: "Layout" replaces "Width", three new tags to replace the two existing ones.

• API change: Pre-3.8 feature_list requests will still get the old fixed/flexible-width tags. 3.8 feature_list requests will get the three new Layout tags instead. This is not actually necessary, strictly speaking, but sending the new tags to old installs has them show up as untranslated slugs on the theme search screen.

• Theme Check update (to be implemented at time of 3.8 release): Suggest new tags instead of old tags.

I'll put the relevant code in place tomorrow. I'll bring this to the attention of the theme reviewers list tomorrow as well.

[nacin]

In 26725:

Map old -width theme tags to new -layout tags for the purposes of translation in the admin.

see #21442.

[nacin]

When we show a list of tags for a theme, we don't just remove the hyphens and capitalize the first letter of each word (though code from THX to do that was just removed). Rather, we translate each tag we know of, based on the feature list in core.

As of [26725], if core finds a tag it doesn't know, it consults a list of old => new tags. Thus "fixed-width" will be transformed into "Fixed Layout" and translated accordingly.

[Otto42]

The ORG/API changes have been deployed.