![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
#21231 closed defect (bug) (fixed)
Twenty Twelve: Adjust backwards compatibility
| Reported by: | obenland | Owned by: | lancewillett |
|---|---|---|---|
| Priority: | normal | Milestone: | 3.5 |
| Component: | Bundled Theme | Version: | |
| Severity: | normal | Keywords: | has-patch |
| Cc: | Focuses: |
Description
Twenty Twelve provides back-compat with 3.3.
It'll be bundled with 3.5 and released to extend at the earliest with 3.4 in the wild for over two months...
Attachments (2)
Change History (11)
#1
follow-up:
↓ 4
@
14 years ago
- Milestone Awaiting Review → 3.5
- Summary Twenty Twelve: Remove backwards compatibility → Twenty Twelve: Adjust backwards compatibility
#2
@
14 years ago
So in this case, the only thing not to be removed would be the wp_get_theme() check.
With providing no back-compat for custom headers, the get_custom_header() calls in header.php will never be accessed, since the Theme does not register support. (Just tested with 3.3.1, too)
Do you agree?
#4
in reply to: ↑ 1
@
14 years ago
Replying to nacin:
I prefer the inline function_exists() approach that Twenty Eleven used to the conditional define of get_custom_header() used here (and by _s), so that was probably going to change either way.
Let me know the preferred method and I'll fix it.
I am fine with making it backwards compatible with only 3.4, but we should avoid it from fatal erroring in lower versions, as the theme directory does not contain compatibility aspects yet.
Shouldn't default themes go back 2 versions? I'd suggest making it 3.3 compat if possible.
#5
@
14 years ago
While WPTRT guidelines allow you to provide support for two prior versions, it recommends to max it to one.
With the custom header shiv removed, Twenty Twelve would still be compatible to 3.3 in the sense of not breaking. It would just lack custom header support.
Would that be acceptable?
#6
@
14 years ago
- Keywords needs-refresh added; dev-feedback removed
Chatted today in IRC #wordpress-dev, and decided to go back-compat to 3.1 (which is essentially the same as 3.3).
obenland is going to look and refresh his patch to remove the custom header fallbacks.
3.3 and earlier will not have custom header support, which is OK because there isn't one on by default in this theme.
I prefer the inline function_exists() approach that Twenty Eleven used to the conditional define of get_custom_header() used here (and by _s), so that was probably going to change either way.
I am fine with making it backwards compatible with only 3.4, but we should avoid it from fatal erroring in lower versions, as the theme directory does not contain compatibility aspects yet.