id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc
20103	Rewrite get_themes() and other enemies of sanity	nacin		"get_themes() is a memory hog (#11214). The data it returns, and how it calculates it, is terribly designed (#15858, #12275, others) and inflexible (#19816, others). It is not possible to translate this data. Its aspects are poorly named (#11215). get_themes() keys things by theme name, rather than slug, which the theme editor and other areas rely on. Indeed, get_current_theme() and the corresponding option in the DB stores the name.

The functions that scan (get_themes(), search_theme_directories()) are stuck in a PHP4 world. They use globals and arrays, and one took your lunch money. They implement unnecessary loops and directory scans, making for very lame performance.

With get_themes(), everything is loaded at once, as there is no opportunity for lazy-loading, even though lists of files are only needed for the theme editor and often all we want is the current theme's information.

Almost none of this is even remotely cacheable, certainly not sanely.

Attempts to work with this API usually lead to disaster. The theme editor is a textbook example. It breaks on basically anything other than A-Z (again relying on names rather than slugs), and does some really evil things. I cleaned up what I could two years ago during my GSoC project, but because get_themes() makes most of MU look good, little of it could flow back into core.

Over the next few days, I will be attaching some patches that rewrite large swaths of this aging area of core."	defect (bug)	closed	normal	3.4	Themes	1.5	normal	fixed	has-patch	scribu ocean90 kawauso info@… mike.schroder@… jeremy.felt@… sabreuse@… aaroncampbell JustinSainton divinethemes dromsey@… gary@… mike@… pauldewouters