#7348 closed enhancement (wontfix)
Hooks in default themes to encourage standardization
| Reported by: |
|
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.
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)
Change History (19)
#3
@
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.
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.
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.
@jonsurrell commented on PR #7777:
7 months ago
#17
I've created https://core.trac.wordpress.org/ticket/62584 for this.
@Bernhard Reiter commented on PR #7777:
7 months ago
#18
Committed to Core in https://core.trac.wordpress.org/changeset/59467.
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.