[wp-trac] [WordPress Trac] #12753: Add two setting in Settings/General to enable more flexibility with <h1> and <title> tags with sites using a static front page.

[WordPress Trac]

#12753: Add two setting in Settings/General to enable more flexibility with <h1>
and <title> tags with sites using a static front page.
--------------------------+-------------------------------------------------
 Reporter:  mikeschinkel  |        Owner:         
     Type:  enhancement   |       Status:  closed 
 Priority:  normal        |    Milestone:         
Component:  Themes        |      Version:  3.0    
 Severity:  normal        |   Resolution:  wontfix
 Keywords:  needs-patch   |  
--------------------------+-------------------------------------------------
Changes (by mikeschinkel):

 * cc: mikeschinkel@… (added)


Comment:

 Replying to [comment:1 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

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/12753#comment:3>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software