WordPress MU

When selecting a theme within the WPMU interface, I noticed that a lot of my themes didn't display a preview of the site before confirming activation. It popped up the thickbox js window but that window was then blank. However, the theme was still successfully activated.

Upon investigation, it appears that all theme folders must be at the ROOT LEVEL of the themes folder (within wp-content > themes) for the theme preview to display correctly.

Unfortunately, if like me, you need themes to be logically filed in separate folders within this default theme directory (e.g. wp-content > themes > mainsite > Mandigo folder, Kubrickfolder, k2folder etc) then this subsequently kills the preview window.

Can anyone else confirm that they experience this behaviour too. Its most frustrating as all the themes in these subfolders are still selectable and usable within Wordpress. Its just that previews that don't seem to work.

And no, I don't have any spaces or other rogue characters in the directory names that could be causing any issues.

WPMU 2.6.3, MySQL 4.1.22-standard

I suspect it probably does this in regular WP as well, since you can have sub-sub-theme folders there too.

Hi andrea_r, yes there are a few reports of similar preview issues in WP, but it always seems to have been resolved by removing spaces or full stops from directory names. No one else seems to have mentioned or noticed this sub folder issue.

I have had a hunt about in the WPMU core code to see if I can apply the same logic as WP uses when simply detecting themes (after all WP doesn't seem to care whether themes are buried within the themes folder, so why should the preview window?), but I can't seem to find any suitable places to change the code.

So I will report it to Trac then as I can't be moving all my themes back out of the directory structure (with all the reactivating of themes that will entail - gulp!)

Yeah, I dunno why you had them in subfolders anyway. i mean, on one hand I know it kinda makes sense to group them, but on the other hand... :D

Well you just said it yourself, "...it kinda makes sense..."!

And seeing as though WPMU still doesn't grumble at detecting themes within subfolders, I figure it's acceptable to do

Which indeed it is, except for this preview fouling up. Grrrr....

mrarrow, some time ago I posted a 'hack' to manage themes :)
Check here: http://wpmudevorg.wordpress.com/project/Themes-in-backend-sorted-by-tags

Hi VentureMaker, thanks for the link. But for me its more to do with logically arranging the actual Themes folder structure (viewed in Terminal or Virtuozzo or whatever), so if I need to go in and edit some of the template files for that theme, then I can immediately find which folder I require.

mrarrow, well we tried doing it this way but failed :( Don't remember where the BIG problem was.

I found the same issue. I dont know where in the code the problem is, but examining the preview URL and log files it seems to be an issue with not escaping the / for the sub directory.

A working URL looks like
/?preview=1&template=default&stylesheet=default

A nonworking URL looks like
/?preview=1&template=subdir/name&stylesheet=subdir/name

That / before the name seems to disapear when processed.

To test I copied the link of a working theme in the root theme dir called default to the URL bar and watched the logs. I then did the same with a non-working theme in a subdir.

What was interesting is when I used the working template variable and non working stylesheet variable. The text came up in the preview, but the css link was missing the all important /

log output for following URL (notice default theme and dir/name for template)

URL: /?preview=1&template=default&stylesheet=100bigones/waterlily-20&TB_iframe=true&width=1018&height=728

LOG: "GET /wp-content/themes/100bigoneswaterlily-20/style.css HTTP/1.1" 500

Notice 100bigones/waterlily-20 in the URL, but the / is gone after its processed as shown in the apache logs.

The problem exists at line 852 in the wp-includes/themes.php file:

$_GET['template'] = preg_replace('|[^a-z0-9_.-]|i', '', $_GET['template']);

It also does this at line 861 for the style sheet.

$_GET['stylesheet'] = preg_replace('|[^a-z0-9_.-]|i', '', $_GET['stylesheet']);

The problem is it is replacing everything that isn't a character, number, underscore, period or dash. Changing the expression in these two lines to:

|[^a-z0-9_.-/]|i

fixes the problem.

I submitted this in trac (http://trac.wordpress.org/ticket/9019) to add to a future release. Simple fix really!

Ok, guess this will be fixed in 2.7.1:

http://trac.wordpress.org/ticket/8548

Funny that I didn't find that when I searched trac for "preview not working" - didn't search for "preview fails". :)