Layout looks OK now? It’s important to change the “wordpress url” (which would be in that case be different from the “site url”).
At the moment yes, because I set Optimize CSS Code to OFF. If I set the option to ON then the whole layout will break. Yes, the wordpress url is different from the site url. All other things are working fine again. I only have problems with the layout if I active the Optimize CSS Code option in Autoptimize.
But I want to active the option again.
OK, best way forward would be to very briefly activate the option again so we can look at the HTML (and specifically the full URL of the aggregated CSS-file). Could you do that for 5 minutes at let’s say 12h45, so I can have a look?
Ok, can we do it at 12h30? I will post an entry here if I have done it. Ok?
had lunch, ready when you are š
ok, you can turn it back off now.
ok, thanks. Do you have found the problem?
not yet, looking at source now, i’ll keep you posted š
Can you describe step by step how you “moved my wordpress installation from the root folder to a subfolder”?
disregard the previous question š
the problem is probably caused by the fact that “/bits/” is not in the URL, but is in ABSPATH. if so, this confuses Autoptimize’s getpath-function (in classes/autoptimizeBase.php), causing Autoptimize to look for /var/www/yoursite/bits/bits/wp-content/theme/whatever.css instead of /var/www/yoursite/bits/wp-content/theme/whatever.css.
can you open up /wp-content/plugins/autoptimize/autoptimize.php and after the header comment block add:
echo WP_CONTENT_DIR."<br />";
echo ABSPATH."<br />";
load your blog and post these values here? you can (off course) remove those lines immediately after š based on the output of the above, I should be able to confirm my hypothesis and re-write the getpath function.
Well, nothing like a good night’s sleep to find the most simple of solutions! Forget about all the above, just open up wp-content/plugins/autoptimize/classes/autoptimizeBase.php and at the bottom replace
//Converts an URL to a full path
protected function getpath($url)
{
$path = str_replace(get_settings('home'),'',$url);
if(preg_match('#^(https?|ftp)://#i',$path))
{
//External script (adsense, etc)
return false;
}
$path = str_replace('//','/',ABSPATH.$path);
return $path;
}
with the much more solid
//Converts an URL to a full path
protected function getpath($url)
{
$path = str_replace(WP_CONTENT_URL,'',$url);
if(preg_match('#^(https?|ftp)://#i',$path))
{
/**
External script/css (adsense, etc)
Or script/ css just not in wp_content
*/
return false;
}
$path = str_replace('//','/',WP_CONTENT_DIR.$path);
return $path;
}
I’m 99% sure this solves the -slightly obscure š – bug you found.
Thanks for your response š
Now I replaced the getpath-function with the new one. But it still doesn’t work. After replacing the function I implemented the echo commands you mentioned two post above. I received the following results:
/var/www/yoursite/html/bits/wp-content
/var/www/yoursite/html/bits/
In fact, it seems that the paths are correct now. But the layout still breaks.
But I found a new hint in the network logs of firebug:
http://www.blog-it-solutions.de/wp-content/themes/iblog/css/custom.css 404 Not found
This problem also occurs for all other css-files. In result, there must be another function which is using the wrong path. Do you still have any ideas?
damn, I hoped I had nailed this one š
anyway, can you:
