Make WordPress Core

Opened 17 years ago

Closed 17 years ago

Last modified 7 months ago

#7348 closed enhancement (wontfix)

Hooks in default themes to encourage standardization

Reported by: technosailor's profile technosailor Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: General Keywords: has-patch has-unit-tests
Focuses: Cc:

Description

We're having this discussion over on my site.

http://technosailor.com/2008/07/16/revolution-vs-thesis-the-premium-theme-cage-match/#comment-226901

It would be very useful to place some guidelines around theme creation. It is entirely possible to control the granular aspects of a theme and its layout if theme developers used common conventions that we layout and use within the default theme.

I don't want to crazy with this idea if it doesn't have merit and if it does, I fully expect to do some patch cleanup and extension. But to provide some context to what I'm talking about, I'm including this patch which integrates a few theme hook conventions that we might use.

Thoughts?

Attachments (1)

7348.diff (1.7 KB) - added by technosailor 17 years ago.

Download all attachments as: .zip

Change History (19)

@technosailor
17 years ago

#1 @technosailor
17 years ago

A theme should be entirely (or at least mostly) configurable by plugin, whether homegrown or publicly released. Wanna put an ad under the first, third and fifth post.... Hook on loop_post_count1, loop_postcount3, etc.

Modify a logo without hacking the code to point to a different URL?

hook on the filter theme_logo (which I didn't write because the default theme doesn't have a logo file)

Etc.

#2 @santosj
17 years ago

You crazy bro.

Why don't more themes include more widget areas instead?

#3 @jacobsantos
17 years ago

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

People should include more widget areas instead.

This ticket was mentioned in PR #7742 on WordPress/wordpress-develop by @jonsurrell.


7 months ago
#4

  • Keywords has-patch has-unit-tests added

Depends on #7348

Trac ticket:

@jonsurrell commented on PR #7742:


7 months ago
#5

96919912fe8455c2f3744485fb9905ebc0625fac extracted to https://github.com/WordPress/wordpress-develop/pull/7754

This ticket was mentioned in PR #7777 on WordPress/wordpress-develop by @jonsurrell.


7 months ago
#6

This PR builds on #7348.

This modifies ::create_fragment( $html, $context ) to use a full processor and create_fragment_at_node instead of the other way around. This makes more sense and makes the main factory methods more clear, where the state required for fragments is set up in create_fragment_at_node instead of in both create_fragment and create_fragment_at_node.

This allows for more HTML contexts to be provided to the basic create_fragment where the provided context HTML is appended to <!DOCTYPE html>, a full processor is created, the last tag opener is found, and a fragment parser is created at that node via create_fragment_at_node.

The HTML5lib tests are updated accordingly to use this new method to create fragments.

Trac ticket:

@jonsurrell commented on PR #7777:


7 months ago
#7

there’s a hidden performance surprise in there

I thought about that. One thing we could do is optimize the most common case where the context is <body> and have some optimized setup that skips creating a full parser.

Do we need to prefix the DOCTYPE declaration though? What if someone wants a parser in <!DOCTYPE quirks><p><table><td>? I don’t know if that makes sense or is warranted.

I added the DOCTYPE because I suspect we usually want to be in no-quirks mode. If that is not added, then the <body> context that has been used until now would behave differently. The most advanced and low-level option is still available to create a full processor and then create a fragment parser from that if folks _really_ want a fragment in quirks mode.

I'd like to better document this behavior and explain the more advanced option.

@dmsnell commented on PR #7777:


7 months ago
#8

I thought about that. One thing we could do is optimize the most common case where the context is <body> and have some optimized setup that skips creating a full parser.

The opposite of that is that <body> doesn’t require that much processing in a case like this.

The advanced option is still available…I'd like to better document this behavior and explain the more advanced option.

This seems proper. That makes a safe default with an escape hatch for those who want to do something where they adopt their own risk.

@jonsurrell commented on PR #7777:


7 months ago
#9

This can pull in tests from https://github.com/WordPress/wordpress-develop/pull/7141 and should also do this (mentioned in that description):

Review all documentation looking for places stating that <body> is the only supported context.

@gziolo commented on PR #7742:


7 months ago
#10

Nice progress here. In https://github.com/WordPress/wordpress-develop/pull/6838, an HTML API subclass was explored to add support for a new Image attribute. It might be interesting to use it as a reference and potentially borrow the unit test when playing with it.

@jonsurrell commented on PR #7777:


7 months ago
#11

I've pulled some valuable changes like tests and documentation from https://github.com/WordPress/wordpress-develop/pull/7141 into this PR.

@jonsurrell commented on PR #7777:


7 months ago
#12

https://github.com/WordPress/wordpress-develop/pull/7348 has landed. I've merged trunk, added some improvements like tests and _doing_it_wrong from https://github.com/WordPress/wordpress-develop/pull/7141.

I'm opening this up for review now 🎉

@Bernhard Reiter commented on PR #7777:


7 months ago
#13

The PR says that there are currently conflicts; would you mind rebasing this? 😊

@jonsurrell commented on PR #7777:


7 months ago
#14

Branch is up-to-date and should be conflict free now 👍

@Bernhard Reiter commented on PR #7777:


7 months ago
#15

Branch is up-to-date and should be conflict free now 👍

Conflicting again now 🙈 Mind rebasing once again? 😅 I'll review today.

@jonsurrell commented on PR #7777:


7 months ago
#16

I'll create a dedicated ticket for this. It's a very logical step after https://github.com/WordPress/wordpress-develop/pull/7348, but does introduce a new feature and is a significant refactor.

Note: See TracTickets for help on using tickets.