[wp-trac] [WordPress Trac] #31078: Continue the better option for <title> tags

[WordPress Trac]

#31078: Continue the better option for <title> tags
--------------------------------------------------+-----------------------
 Reporter:  obenland                              |       Owner:  obenland
     Type:  enhancement                           |      Status:  accepted
 Priority:  normal                                |   Milestone:  4.4
Component:  Themes                                |     Version:  4.1
 Severity:  normal                                |  Resolution:
 Keywords:  has-patch needs-testing dev-feedback  |     Focuses:
--------------------------------------------------+-----------------------

Comment (by nacin):

 Solid work here. Thoughts:

  * Not against deprecating `wp_title()`.

  * Should `$title` inside `<title>` be `esc_html()`? I honestly can't
 remember.

  * It's necessary to keep the crazy `$wp_locale` code inside the
 `is_month()` conditional. Translating a php.net/date string is valid when
 dealing with numbers, but it falls apart when you try to use
 abbreviations, or in this case, a full month name (`F`). Translating `F`
 will not end up with a translated month name. You'll end up with `F`,
 which will then only turn into a translated month name when PHP is
 operating under a different locale. Maybe I'm missing something.

  * I like that this patch requires spaces on each side of the separator,
 and keeps the spaces out of the title_tag_separator filter.

  * I agree with @SergeyBiryukov that `is_rtl()` shouldn't need an
 `array_reverse()`.

  * Where did the `wp_title` filter go? Is there any reason for it to
 vanish? Switching to `add_theme_support()` is the choice of the theme, but
 `wp_title` is going to be used in plugins. (Wouldn't be against
 deprecating the filter.)

  * I like the associative array `$title` used to build the parts. However,
 there are some confusing pieces.

   * I like that `$title['site']` is used, but I don't like how it's
 overloaded with the site description, or how the site title is moved to
 `$title['page']`. This shift makes it harder for tweaks to happen. I would
 probably go with `$title['site']` and `$title['description']` (or
 `$title['tagline']`, which I think is clearer here, funny enough) and have
 `$title['page']` empty here. (I don't love this either, more in a
 moment...)

   * `$title['page']` to me says page number. But that is actually
 `$title['number']`. I would call these `$parts['title']` and
 `$parts['number']`.

   * Thus: `$parts['title']` (if not home page), `$parts['site']`,
 `$parts['tagline']` (if home page), `$parts['page']` (if paged).

   * I think this makes certain things easier, but also makes it a bit
 easier to screw it up in some other ways, like by trying to assign
 `$parts['title']` but failing to realize it's set in `$parts['site']`.
 Open to ideas. I'm thinking `$parts['title']` overrides `$parts['site']`
 if present. As in, treat them as synonyms, but keep them separate so it's
 easier to figure out what you receive through the filter. On the other
 hand, it makes it harder to remove the site title from your `<title>`...
 Perhaps we stick with what's in the patch, but some kind of
 `$parts['home'] = true` indicator?

--
Ticket URL: <https://core.trac.wordpress.org/ticket/31078#comment:19>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform