Moderator
t-p
(@t-p)
what happens when you switch to the default twenty eleven?
You can’t.
Since no themes are listed, the only way you can activate a theme is by uploading it and then immediately clicking activate.
Try switching to the Twenty Eleven theme by renaming your current theme’s folder inside wp-content/themes and adding “-old” to the end of the folder name using FTP or whatever file management application your host provides.
Try switching to another theme. Rex [signature moderated]
Try switching to the Twenty Eleven theme by renaming your current theme’s folder…
2011 theme then takes effect, but makes no difference to bug. Errors still same, no themes listed in dashboard.
Try re-uploading all files & folders – except the wp-content folder – from a fresh download of WordPress.
I redownloaded 3.3.2 and did a full file compare of the expanded zip. No differences. Unzipped with 7-zip and ZipCentral just in case of archive issues, no diffs.
A CRC comparison shows that wp-content and config file are the only diffs between the test site and the zip.
The installation has already been repeated from scratch, so I guess that covers download/installation issues.
I don’t hold out much hope for this one but try adding define('CONCATENATE_SCRIPTS', false ); to the bottom of your wp-config.php file (just before the require_once line).
No effect.
I guess I could live with it as is, by copying a customized theme into the default Twenty Eleven folder.
Though, there surely must be an explanation for this behaviour, after all it’s a default setup on an industry-standard platform. The only thing that’s slightly nonstandard is that the apache htdocs folder is on a server share instead of local.
It looks like the bug arises because the theme name and info variables are undefined. I take it the theme name, etc. is taken from the comment section in the top of style.css ? Could there be a reason why the system cannot read the comment section? Obviously it’s not executing the file under php as that would not give access to comments. So, the question arises, in what way is the comment section being read, and is the method perhaps platform-dependent or suchlike? If you can point me to where in the code the comment section is read, I might be able to figure out what’s going on.
by copying a customized theme into the default Twenty Eleven folder.
No! No! No! Twenty Eleven is the default WordPress theme and having access to an unedited version of the theme is vital when dealing with a range of site issues.
It looks like the bug arises because the theme name and info variables are undefined
If that was the case, it would fail on every single new install when, in practice, this is specific to your install and/or server. If it is a server issue (which is now the the most likely scenario), this could create all kinds of problems for you further down the line.
The server in question has been used to develop a number of websites, and runs joomla, sitellite and a number of custom php sites. I can’t see that it can be that faulty if it works OK for all those.
OK, at least found the nature of the problem, which is that for an unknown reason, wordpress cannot open the template css file if the htdocs folder is on a mapped network share. If I move the install to a local virtual server, the themes become visible.
I’m guessing this might possibly be a problem within php itself. Not sure.
I do hit a problem with relocating the install, in that the original path to the wordpress root seems to be hardcoded somewhere. If the path isn’t identical then the stylesheet isn’t loaded and the layout disintegrates. The setting isn’t in wp-config.php though. Any idea where?
Given that WP is installed thousands of times per day without this problem and you have ruled out plugins, themes or a bad upload, I don’t see how it can be anything other than a server issue.
I’m guessing this might possibly be a problem within php itself.
It’s an issue in your setup generally. You cannot use mapped shares with WordPress. What OS are you using?
Main server with the shares is Debian. Test webserver is Windows 2003. It’s setup this way (a) so that all files can be edited from a single location, and for security, so that the webserver can’t alter files outside of this share.
I can’t see how mapped shares should affect a Web app. The webserver (Apache) accesses the files from the defined webroot. Whether this is on a local drive or a mapping should be immaterial, provided the Apache process has access rights to the share (which it does)
It’s an issue in your setup generally.
My setup does nothing which is not accepted network practice. The Apache process runs in userspace, and it is easy to confirm that it has read/write access to the htdocs share. (Uploads work, proving this) As far as I am aware, php loaded as a module runs under the webserver’s credentials, therefore should have equal access. In any event I have custom php scripts on my own website which read server-side data files. They work on the mapped drive.
So, thanks for advice and I’ll just avoid the issue by developing on a separate virtual server. But, I feel there must be something peculiar going on here.
