WordPress.org

Make WordPress Core

#24932 closed defect (bug) (fixed)

HTML5 support for specific features doesn't work.

Reported by: nathanrice Owned by: nacin
Milestone: 3.6.1 Priority: normal
Severity: normal Version: 3.6
Component: Themes Keywords: has-patch commit fixed-major needs-codex
Focuses: Cc:

Description (last modified by SergeyBiryukov)

The check for the second parameter in current_theme_supports() in [24417] is irrelevant.

Unit test here:
https://gist.github.com/nathanrice/6143003

There is no exception in the switch statement for html5 support, so the function just returns true (early) if html5 is supported at all. The second parameter is essentially ignored.

So, if you intend to turn on html5 output for just 1 of the 3 options, it doesn't matter. All 3 will output in html5.

Which is, perhaps, intentional. I'm really not sure.

If not, I'm prepping a patch to correct it.

Attachments (4)

24392.diff (2.4 KB) - added by nathanrice 20 months ago.
24932.diff (3.5 KB) - added by nacin 19 months ago.
24932.2.diff (2.8 KB) - added by SergeyBiryukov 19 months ago.
24932.3.diff (3.5 KB) - added by nacin 19 months ago.

Download all attachments as: .zip

Change History (22)

@nathanrice20 months ago

comment:1 @nacin20 months ago

  • Milestone changed from Awaiting Review to 3.6.1

comment:2 @SergeyBiryukov20 months ago

  • Description modified (diff)

comment:3 @nacin19 months ago

  • Keywords commit added
  • Owner set to nacin
  • Status changed from new to accepted

Going to remove the whitespace changes from a commit to 3.6.1. Looks good, thanks.

comment:4 @nacin19 months ago

24932.diff makes two functionality changes:

  • Calling add_theme_support( 'html5', array( 'comments-list' ) ); add_theme_support( 'html5', array( 'comment-form' ) ); should merge. If a theme wants to replace, they need to do a remove_theme_support( 'html5' ) first. This is a change in behavior that we can really only get away with now, in 3.6.1. Reasoning is the mess that is #22080.
  • add_theme_support( 'html5' ) (no arguments) no longer works. This was never supposed to work, as it would prevent us from adding future types in the future. current_theme_supports( 'html5' ), however, does continue to work, and will return true if *any* feature is supported. This might help a plugin author decide what markup to serve, but core should never check for this.

In both cases, this is how the functionality was designed. It just wasn't implemented correctly.

Also adds some unit tests.

@nacin19 months ago

comment:5 @nacin19 months ago

In 25193:

Fix 'html5' theme support.

  • Require it to have a second argument when adding.
  • Merge, rather than replace, on second add.
  • Make current_theme_supports() work when two arguments are passed.

Adds unit tests.

props nathanrice for initial patch.
see #24932 for trunk.

comment:6 @nacin19 months ago

  • Keywords fixed-major added

@SergeyBiryukov19 months ago

comment:7 @SergeyBiryukov19 months ago

24932.2.diff:

  • Enables the existing three types if no second argument was passed (per the IRC discussion).
  • Adds a _doing_it_wrong() notice for an empty or non-array argument.
  • Updates the tests and fixes a few typos in [25193].
Last edited 19 months ago by SergeyBiryukov (previous) (diff)

@nacin19 months ago

comment:8 @nacin19 months ago

Alas, I'm fine with 24932.2.diff. I've updated it with more tests, see 24932.3.diff. It now tests that A) a non-array is invalid, and B) passing nothing gives you all three existing types and nothing wrong.

Also updated the _doing_it_wrong() to reflect 3.6.1 and added some context for the first parameter there. Agree with not translating the string for 3.6.x.

comment:9 follow-up: @nathanrice19 months ago

If I could, I'd like to formally request that this NOT return false if no array of types gets passed.

Short story, this will break Genesis child themes, which we can't push updates to address.

In Genesis, we only define HTML5 as being on or off. We have no need to specify types, since if html5 theme support is added, we don't want anything outputting in any other format except for html5.

I understand the "intended" behavior from the core perspective, but it's silly to assume that the following would somehow return false.

add_theme_support( 'html5' );

return current_theme_supports( 'html5' ); // false?

I'm not trying to pull special privilege here or anything ... but I can't stress enough how a 3.6.1 update that includes this short circuit will immediately and catastrophically damage the look of sites running Genesis 2.0 and a child theme that supports HTML5.

comment:10 @nathanrice19 months ago

Good grief, nevermind. I see in 24932.3.diff that you haven't let it return false if no types array is passed. My mistake.

Obviously, we'll still get a warning, and we'll have to deal with that at some point, but at least it's not going to bork a site.

Might I still recommend that JUST enabling theme support for html5 with no types array isn't necessarily doing it wrong? It's more like a universal "html5 everything" directive.

comment:11 in reply to: ↑ 9 @nacin19 months ago

Replying to nathanrice:

Might I still recommend that JUST enabling theme support for html5 with no types array isn't necessarily doing it wrong? It's more like a universal "html5 everything" directive.

So, this is to prepare you for the fact that if/when we add additional values (there are more template tags that could probably get this treatment?), you won't actually opt-in by specifying only html5. The problem here is if we add a future type, we might completely break a site and/or its CSS by pulling the rug out. That's why it was meant to be explicit. I don't want to hamstring us from future changes. As you said, overhauling markup suddenly could "catastrophically damage the look of sites".

comment:12 follow-up: @nacin19 months ago

We also possibly don't need to add the _doing_it_wrong() until we actually add new markup somewhere, or at least confirm there is new markup to be added somewhere, but we have a lot of template tags and I'm sure there will be something.

Quick search finds some could-use-some-modernization markup in wp_login_form() (and eventually, #17948), maybe get_calendar(), some page menu / page links / nav menus stuff (and other walkers), term/cat/tag lists and such, using dropdowns as jump fields in widgets, maybe some other default widgets. The point is, let's make sure themes are explicit now, for forwards compatibility purposes.

comment:13 @nacin19 months ago

I'm also fine with waiting until 3.7 for the _doing_it_wrong().

comment:14 in reply to: ↑ 12 @SergeyBiryukov19 months ago

Replying to nacin:

We also possibly don't need to add the _doing_it_wrong() until we actually add new markup somewhere

I tend to agree.

comment:15 @SergeyBiryukov19 months ago

  • Keywords needs-codex added

We should update Codex to clarify that passing an array of types is recommended.

The list of pages where add_theme_support( 'html5' ) is mentioned:

comment:16 @andrewryno19 months ago

Updated documentation to mention the changes from this ticket. I didn't mention 3.6.1 since it hasn't been released yet, but I think the docs should mention the version once released.

comment:17 @nacin19 months ago

In 25235:

add_theme_support( 'html5' ) now defaults to comment-list, comment-form, and search-form.

This was the implicit case in 3.6.0, modified in [25193].

see #24932.

comment:18 @nacin19 months ago

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

In 25236:

Fix 'html5' theme support.

  • Merge, rather than replace, on second add.
  • Make current_theme_supports() work when two arguments are passed.
  • Require the second argument to be an array.

Merges [25193] and [25235] to the 3.6 branch.
fixes #24932.

Note: See TracTickets for help on using tickets.