I posted my problem in the forums under THEMES and got absolutely no response. This is probably because I have a compact setup and the bug would only show up on a setup like mine.
Here is the post:
I have five blogs running off one database, and only one core install, with everything symlinked. This worked in 2.5.1 the occasional plugin couldn’t deal with it but too bad. The core install is /home/www/wordpress
HOW IT’S SET UP
Each blog is /home/www/thisblog It contains symlinks to all the code files and folders in the core install except for wp-content
I have an actual (not symbolic) wp-content folder for each blog, with a symlink to the main install’s plugins folder but an actual individual themes folder for each blog. This is better organized than tossing all my themes into the main install’s themes. And besides who knows I might want to use the same theme on two blogs but that would cause trouble with naming folders if I didn’t have them separated out.
OK, well, now it appears as if the new wordpress is only looking for themes in /home/www/wordpress/wp-content/themes not in /home/www/blog/wp-content/themes because the only choices are classic or default–the ones in the install. Also, the only theme that shows a thumbnail or works is the default. I tried dragging a random theme into the main install’s themes to see if it would show. WordPress made an entry for it, but no thumbnail, and when I tested it it had no formatting, and neither did classic. neither in the preview, nor when I actually activated it for the blog.
I discovered a new file in the new install which the virtual blog folders did not have a symlink to: wp-load.php. So I made a new symlink in each virtual blog pointing to wp-load in the core install to match all the other symlinks. But that did not help with this problem.
I looked around at the config files: Here is the trick I use: My wp-config.php in the main installation is just this:
<?php require(‘local/wp-config.php’); ?>
assuming local will point to different places in different contexts and that seems to work.
In the root of each blog I have a folder called local with a config in it. In each config I hardcode ABSPATH to the root of each blog.
(e.g. /home/www/dorkage) and the code seems to calculate THEME_DIR based on ABSPATH. It always worked before in 2.5.1 I scanned quickly thru settings code and I just don’t see why it’s not looking for the themes where I want it to, and why they are all bad except default. Please help! I hate my blogs this way and I don’t want to toss all the themes into the core install’s folder, it’s soo much easier to manage when each blog has it’s own.
Here is another test we did: In one of the blogs we renamed “default” to “olddefault” and “someothertheme” to “default”. Now poof the other theme is showing up on the blog itself. So the THEME renderer actually IS looking for the themes where I have them and where I want it to look.
It’s just the ADMIN module that isn’t working. If I go to admin for that blog, the DEFAULT thumbnail still looks like the standard DEFAULT (because it’s getting the /default in the core install) but it’s USING the default folder in the blog’s directory. THIS IS A HUGE BUG!
I hacked theme.php
and I echoed $theme_root right after the get_themes function calculated it and then die. It echoed
/home/www/wordpress/wp-content/themes (which confirmed it is opening the core install) NOT WHAT I WANT AND HAVE CONFIGURED AND WHAT WORKED BEFORE. I tried just going to the home page of the blog, it didn’t die, so it probably has this theme cached or something.
But the takeaway is that in the admin it is NOT looking for the themes in the same place as the ones it is using. Can I hack the themes somewhere else besides the admin panel?
- The topic ‘I am having theme problems and I prove it is a bug’ is closed to new replies.