#20146 closed defect (bug) (fixed)
Back compat for 5-year-old MU allowed_themes code
Reported by: | nacin | Owned by: | |
---|---|---|---|
Milestone: | 3.4 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Themes | Keywords: | |
Focuses: | Cc: |
Description
[20029] removed get_site_allowed_themes() and wpmu_get_blog_allowedthemes().
Both of these functions used an option key called allowedthemes that stored an array of allowed themes, keyed by stylesheet and valued with (int) 1.
Five years ago, there was an option called allowed_themes, that stored an array of allowed themes, keyed by untranslated theme name (like get_themes()) and again valued with (int) 1.
For more on this, see http://mu.trac.wordpress.org/changeset/936 (and in general you can search "allowedthemes" or "allowed_themes" on mu.trac, for more changesets and tickets).
We should consider adding some light back compat code to WP_Theme to support the old option.
Change History (6)
#2
follow-up:
↓ 4
@
12 years ago
Light back-compat code... yeah.
How many old MU installs are there anyway?
#4
in reply to:
↑ 2
@
12 years ago
Replying to scribu:
Light back-compat code... yeah.
Well, it is light in terms of performance. The conditional will almost never be hit, and it ends up as a rolling upgrade, so isn't too bad.
How many old MU installs are there anyway?
This would hypothetically affect WP.com, but since they don't use blog-level allowed themes (except for VIPs, which don't go switching their theme anyway), they happen to be okay.
I remain tempted to strip this out; ryan too, I think. It's one of those situations that could get pretty nasty for users in the off chance a network is using it.
[20144]