Ticket #12397 (closed enhancement: fixed)

Opened 2 years ago

Last modified 19 months ago

get_body_class should show more IDs

Reported by: filosofo Owned by: filosofo
Priority: normal Milestone: 3.1
Component: Themes Version: 3.0
Severity: normal Keywords: has-patch
Cc:

Description

  • We show the IDs of posts and pages.
  • We support category-[ID].php- and tag-[ID].php-style templates, but do not show their IDs in the body class.

Attachments

body_class_ids.12397.diff Download (929 bytes) - added by filosofo 2 years ago.
body_class_ids.12397.2.diff Download (1.2 KB) - added by filosofo 19 months ago.

Change History

comment:1 follow-up: ↓ 2   nacin2 years ago

See also #11331 and #8446. There's also the general concern that slugs are stable while IDs are not, especially when terms are shared in multisite setups.

comment:2 in reply to: ↑ 1   filosofo2 years ago

Replying to nacin:

See also #11331 and #8446.

Was something in particular there about IDs? They seem to concern slugs.

There's also the general concern that slugs are stable while IDs are not, especially when terms are shared in multisite setups.

I understand that, but it seems to me that the stability sufficient enough to allow category-[ID].php-style templates is also sufficient to allow such body class names. They should rise and fall together.

And to tip the scales further, it's consistent with the behavior of other request types, such as posts and pages.

Two points about stability: the "stability" of a category ID, for example, is an issue only for MS. And between MS and standard, MS is the least likely to be the recipient of a very specific, custom theme--the very situation when you need to be able to do something like category-2.php.

In other words, it's more likely that I'll be creating a theme that gives category X a particular treatment, when the site is not MS. MS setups tend to use out-of-the-box themes for the purpose of flexibility.

Second, I've found that slugs change a lot during development time, which is just when I have to decide the template logic for a client.

For example, the client first calls the category "Movie Reviews," and then changes her mind to "Movies," "Reviews," or "Critic's Corner." Not only does it mean more work for me to re-do slug-based logic, it's frustrating to the client who can't change the slug without breaking functionality she doesn't have the technical means to fix.

  • Keywords early added
  • Type changed from defect (bug) to enhancement
  • Milestone changed from 3.0 to 3.1

Looks good, let's shoot for early 3.1 here.

  • Owner set to filosofo
  • Status changed from new to accepted
  • Milestone changed from Awaiting Triage to 3.1

Or just close it.

  • Keywords needs-refresh added; has-patch early removed

The new taxonomy body classes also need this.

Or just close it.

Tempting.

  • Keywords has-patch added; needs-refresh removed

Refreshed patch.

I think using IDs is consistent with other behavior, at least.

IDs are good for single client themes not good for generic ones.

However, extra ids are not a bad thing.

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

(In [16283]) Add support for ID style classes in get_body_class(). Fixes #12397 props filosofo

Note: See TracTickets for help on using tickets.