WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 3 years ago

Last modified 3 years ago

#21442 closed enhancement (fixed)

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

Reported by: lancewillett Owned by: Otto42
Milestone: 3.8 Priority: low
Severity: normal Version:
Component: Themes Keywords: has-patch commit
Focuses: Cc:

Description

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.

Attachments (6)

21442.patch (3.5 KB) - added by lancewillett 4 years ago.
theme-check.21442.diff (2.9 KB) - added by Otto42 3 years ago.
diff for theme-check trunk
21442.diff (5.7 KB) - added by lancewillett 3 years ago.
Refresh patch and add Twenty Fourteen
21442.2.patch (620 bytes) - added by Otto42 3 years ago.
Core changes only, no theme changes, fixed fluid->flexible issue
21442.3.patch (5.7 KB) - added by lancewillett 3 years ago.
Flexible to Fluid after IRC discussion
21442.4.patch (5.8 KB) - added by lancewillett 3 years ago.
Refreshed for Twenty Fourteen

Download all attachments as: .zip

Change History (34)

@lancewillett
4 years ago

#1 @sabreuse
4 years ago

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

#2 @sabreuse
3 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

#3 @nacin
3 years ago

  • Milestone set to Awaiting Review

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.

#4 @nacin
3 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

#5 follow-up: @sabreuse
3 years ago

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?

#6 in reply to: ↑ 5 @nacin
3 years ago

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.

#7 @lancewillett
3 years ago

  • Cc Otto42 added
  • Milestone changed from Awaiting Review to 3.8

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.

#8 @jcastaneda
3 years ago

  • Cc jomcastaneda@… added

#9 @samuelsidler
3 years ago

  • Priority changed from normal to low

#10 follow-up: @dd32
3 years ago

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).

#11 in reply to: ↑ 10 ; follow-up: @samuelsidler
3 years ago

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.

#12 in reply to: ↑ 11 @nacin
3 years ago

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.

#13 @nacin
3 years ago

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.

#15 @nacin
3 years ago

  • Owner set to Otto42
  • Status changed from reopened to assigned

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.

#16 @Otto42
3 years ago

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

#17 @nacin
3 years ago

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.

#18 @Otto42
3 years ago

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

@Otto42
3 years ago

diff for theme-check trunk

@lancewillett
3 years ago

Refresh patch and add Twenty Fourteen

@Otto42
3 years ago

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

#19 follow-up: @Otto42
3 years ago

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.

Last edited 3 years ago by Otto42 (previous) (diff)

@lancewillett
3 years ago

Flexible to Fluid after IRC discussion

#20 in reply to: ↑ 19 @lancewillett
3 years ago

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.

#21 @Otto42
3 years ago

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
3 years ago

Refreshed for Twenty Fourteen

#22 @lancewillett
3 years ago

  • Keywords commit added

#23 @matt
3 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 26711:

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

Props Otto42 and lancewillett.

#24 @nacin
3 years ago

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.

#25 @Otto42
3 years ago

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.

#26 @nacin
3 years ago

In 26725:

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

see #21442.

#27 @nacin
3 years ago

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.

#28 @Otto42
3 years ago

The ORG/API changes have been deployed.

Note: See TracTickets for help on using tickets.