WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#12753 closed enhancement (wontfix)

Add two setting in Settings/General to enable more flexibility with <h1> and <title> tags with sites using a static front page.

Reported by: mikeschinkel Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.0
Component: Themes Keywords: needs-patch
Focuses: Cc:

Description

This is a follow up from #12542 where there has appears to have been a strong divergence in believed best practices regarding the use in themes of the
<h1> and <title> tags. "Consistency with how the default theme has treated page titles in the past" was valued by some whereas evolution to support CMS uses was more valued by others.

To (hopefully?) satisfy both sides I'd like to propose we add two (2) admin settings in the "Settings/General" section to support user customization of themes that enable changed behavior of site-title and <h1> tags. The two settings would be:

  1. "Wrap site branding with <h1 id="site-title"> on front page but use <div id="site-title"> for all other pages."
  1. "Disable the display of page title on (static) front page."

Note: As proposed these options will only be displayed when a static page is selected for the front page and when current_theme_supports('front-page-uses-h1-for-site-title') and current_theme_supports('disable-page-title-on-front-page'), respectively.

Then with these options in place we could address #12542 to enable support for these new options with the prior behavior as the default.

That said, It's late and I'm tired so I'm not submitting a patch today but if I can any reasonable support for this idea I'll code it up ASAP.

Change History (3)

comment:1 follow-up: @jane5 years ago

Don't we generally try to avoid adding extra options? Aren't we supposed to make the best decision we can and leave the alternative to plugins, whenever it's feasible? Using options to determine whether or not to display individual theme elements and to make distinctions between templates is beyond the pale. The theme should do what the designer wants it to do, and if a user wants it to do something else, they should make a child theme or pick a different theme (possibly a theme framework, where it might actually be appropriate to have options for minute details like this).

I recommend closing as wontfix.

comment:2 @nacin5 years ago

  • Milestone Unassigned deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Closing as wontfix. This can be continued in #12542.

comment:3 in reply to: ↑ 1 @mikeschinkel5 years ago

  • Cc mikeschinkel@… added

Replying to jane:

Don't we generally try to avoid adding extra options? Aren't we supposed to make the best decision we can and leave the alternative to plugins, whenever it's feasible?

To be clear, plugins cannot possible (or at least reliably) affect this unless hooks are added to the theme. Note my comments below are made to address your comments in general and not necessarily a request to reopen this; I'd be happy to continue addressing at #12542.

Using options to determine whether or not to display individual theme elements and to make distinctions between templates is beyond the pale.

I don't understand the colloquial use of "beyond the pale"[1] in this context. WordPress already has almost 10 settings to display individual theme elements. How is what's already there unacceptable?

The theme should do what the designer wants it to do,

Seems a bit authoritarian, especially when so many theme designers make arbitrary choices based on copying what other theme designer did. Since most theme designers are not really PHP developers, this assert seems baseless to me.

and if a user wants it to do something else, they should make a child theme

As implemented, child themes are not a panacea. After having to copy entire files (header.php, loop.php, etc.) you get the worst of both worlds; you have to maintain a lot of orphaned code, you have to put up with the constraints of another theme and you potentially will see your break if the parent theme is upgraded.

That's not to say that child themes are bad in concept; they are quite good actually, but to make them a more viable solution WordPress would be better to identify standard patterns that are in use by most themes and then role those patterns into core so it doesn't take so darn much code to implement a slightly modified child theme. Ironically this ticket is attempting to identify one of those patterns so addressing it can be rolled into core.

BTW, TwentyTen took a huge step in the right direction regarding themes but there's still even more left to be done.

or pick a different theme (possibly a theme framework, where it might actually be appropriate to have options for minute details like this).

There are no other themes available that will be *the* theme that sets the standard by which most new themes will derive their architecture from. Make a bad architecture decision here and you'll doom thousands of themes to have a bad architecture. (Just ask the Microsoft-centric world how many truly horrid Access and SQL Server database designs mirror the fully brain-dead architectural decisions of the Northwind database!)

So in summary:

-- Settings in WP core that affect how a theme displays are not inherently evil; some are actually good if they acknowledge emergent patterns in the use of WordPress and enable theme developers to build more robust, reliable, and flexible themes assuming they don't burden the user with excessive complexity.

-- One of WP's strengths has been it's architecture's flexibility to load and execute a template after processing a URL request, but to enable that WP has continued to identify more and more common use-case patterns and enabled those patterns via "helper" code that templates can call. Child themes will improve in concept if WP adds more support for the patterns identified as WP evolves so that themes don't always have to start from scratch on known patterns and so that when a themer making child theme must copy numerous parent theme templates that they will have far less actual code to copy.

-- This concern is everyone important for the theme that most themers will soon be copying.

-- This issue can be addressed by empowering plugins with theme hooks instead of adding admin options; either way works but what doesn't work (for me at least) is to continue to hardcode these things into the theme and thus force prospects with a decision between several suboptimal choices (copy and then have to maintain lots of code vs. choose a new theme when this one is 99% good.)

Thanks for listening.

[1] http://www.phrases.org.uk/meanings/64100.html

Note: See TracTickets for help on using tickets.