Forum Replies Created

Viewing 8 replies - 1 through 8 (of 8 total)
  • Thread Starter Anteaus

    (@anteaus)

    As a matter of interest, think I may have found the cause.

    Apache/Windows shows anomalous behaviour when it encounters filenames containing capitals on a Samba/LAN share. If the filename contains capitals it cannot be opened with either the capitalized or lowercase names.

    Hard to see why this would arise, though it suggests that Apache is not using the standard OS calls to open files.

    So, not a WordPress issue as such but an Apache ‘feature’

    I imagine there are one or two CamelCased files somewhere, and that is why only minor sections of WordPress are affected. Since capitalized filenames are rare on websites, I hadn’t encountered this before.

    Thread Starter Anteaus

    (@anteaus)

    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.

    Thread Starter Anteaus

    (@anteaus)

    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?

    Thread Starter Anteaus

    (@anteaus)

    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.

    Thread Starter Anteaus

    (@anteaus)

    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.

    Thread Starter Anteaus

    (@anteaus)

    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.

    Thread Starter Anteaus

    (@anteaus)

    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.

    Thread Starter Anteaus

    (@anteaus)

    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.

Viewing 8 replies - 1 through 8 (of 8 total)