redirect hell

multiple .htaccess files in play

[pglock]

I have integrated a wordpress blog with magento using Sonassi's instructions. This gives our blog content embedded in a page on the main website which is based on magento. Take a look at [splatcooking.net ] to see this in action.

The implementation is dependant on redirects to allow the blog admin pages to be accessed directly while redirecting other /blog requests to the blog page on the main site.

the htaccess file in /blog is

## BEGIN sonassi.com wordpress extension
 

 <IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /blog/
 
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} !^/blog/wp-admin
RewriteCond %{REQUEST_URI} !^/blog/wp-content
RewriteCond %{REQUEST_URI} ^/blog
RewriteCond %{REMOTE_ADDR} !^89\.200\.138\.20
RewriteRule .* ../index.php [L]
</IfModule>

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /blog/
RewriteRule wp-includes/js/tinymce/plugins/mcespell/spell-check-service wp-content/plugins/ajax_spellchecker/service/spell-check-service.php [QSA,L]
RewriteRule wp-includes/js/tinymce/plugins/mcespell/(.*) wp-content/plugins/ajax_spellchecker/tinymce/mcespell/$1 [L]
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /blog/index.php [L]
</IfModule>

# END WordPress

RewriteCond %{HTTP_HOST} ^blog.splatcooking.net$ [OR]
RewriteCond %{HTTP_HOST} ^www.blog.splatcooking.net$
RewriteRule ^(.*)$ http://www.splatcooking.net/blog/ [R=301,L]

The setup works, but is slow to load. Using Firebug and Page Speed I can see that there are several problems with css and js pages called from the magento site. Here is an extract from Page Speed:

* http://www.splatcooking.net/home/splatcoo/public_html/js/lib/ccard.js
 * http://www.splatcooking.net/home/splatcoo/public_html/js/mage/cookies.js
 * http://www.splatcooking.net/home/splatcoo/public_html/js/mage/translate.js
 * http://www.splatcooking.net/home/splatcoo/public_html/js/prototype/prototype.js
 * http://www.splatcooking.net/home/splatcoo/public_html/js/prototype/validation.js
 * http://www.splatcooking.net/home/splatcoo/public_html/js/scriptaculous/builder.js
 * http://www.splatcooking.net/home/splatcoo/public_html/js/scriptaculous/controls.js
 * http://www.splatcooking.net/home/splatcoo/public_html/js/scriptaculous/dragdrop.js
 * http://www.splatcooking.net/home/splatcoo/public_html/js/scriptaculous/effects.js
 * http://www.splatcooking.net/home/splatcoo/public_html/js/scriptaculous/slider.js
 * http://www.splatcooking.net/home/splatcoo/public_html/js/varien/form.js
 * http://www.splatcooking.net/home/splatcoo/public_html/js/varien/js.js
 * http://www.splatcooking.net/home/splatcoo/public_html/js/varien/menu.js
 * http://www.splatcooking.net/home/splatcoo/public_html/skin/frontend/base/default/js/lightbox/lightbo...

It looks as though something in my redirect is adding the file path (/home/splatcoo/public_html).

Any ideas as to what I might be doing wrong?

[Stefan]

You should "examplify" the URL's, otherwise a mod will have to do it. Not allowed under the TOS.

Good luck with the problem, though! And welcome to webmasterworld.

[jdMorgan]

Your rules are incorrectly ordered. External redirects should go first, followed by internal rewrites.

You have unnecessary <IfModule> containers. These are only desirable if you want the code to fail silently if mod_rewrite isn't available -- and that's very unlikely to be what you'd want.

The RewriteConds in the internal rewrite are incorrectly ordered. Always put 'exists checks' last, as these invoke calls to the operating system's filesystem handler, and may result in physical disk reads.

Also, exclude the filetypes that cannot be generated (i.e. 'created') by the scripts from ever being rewritten to those scripts. There is no reason, for example, to go check disk to see if an image, JS, or CSS file exists if in fact the script cannot create an image or css file that is missing.

These problems are quite common with CMS-provided mod_rewrite code. It appears that the authors do not consider the server 'work' caused by their code, and simply do not think things through.

I believe that you'll find this to be a bit faster:

RewriteEngine On
#
RewriteCond %{HTTP_HOST} ^(www\.)?blog\.example\.com [NC]
RewriteRule ^(.*)$ http://www.example.com/blog/ [R=301,L]
#
RewriteBase /blog/
#
RewriteCond %{REQUEST_URI} !^/blog/wp-(admin|content)
RewriteCond %{REMOTE_ADDR} !^89\.200\.138\.20
RewriteCond %{REQUEST_URI} !\.(gif|jpe?g|png|ico|css|js|pdf|doc|avi|mov|wmv|swf|flv)$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^blog ../index.php [L]
#
# BEGIN WordPress
#
RewriteRule ^wp-includes/js/tinymce/plugins/mcespell/spell-check-service wp-content/plugins/ajax_spellchecker/service/spell-check-service.php [L]
RewriteRule ^wp-includes/js/tinymce/plugins/mcespell/(.*) wp-content/plugins/ajax_spellchecker/tinymce/mcespell/$1 [L]
#
RewriteCond %{REQUEST_URI} !^/(blog)?index\.php$
RewriteCond %{REQUEST_URI} !\.(gif|jpe?g|png|ico|css|js|pdf|doc|avi|mov|wmv|swf|flv)$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /blog/index.php [L]
#
# END WordPress

Note that the 'lists' of excluded filetypes are not intended to be all-inclusive. In fact they need not be all-inclusive. They only need to contain the most-frequently-requested filetypes that are not generated using scripts. They simply prevent checking the disk or calling the script for filetypes which should always exist and cannot be generated by the script anyway. Add or delete filetypes as you see fit -- the maximum benefit comes from excluding images, CSS, and JS files -- the most common objects included on pages.

You might also want to exclude that IP address from the second internal rewrite -- I'm not sure what the intent was, but it might be desirable to exclude it from both rules... You decide.

Be very sure that all internal links on your site point to URLs including /blog. If this is not the case, then your code will invoke a client redirect on every request for the /blog-less URLs, and this will both slow your site and constitute a signal of "low quality" to search engines. If you do not wish to link to URLs including /blog, then the redirect should be an internal rewrite instead, and the code needs to be rewritten and re-structured a bit...

Jim

[pglock]

Thank you for the suggestions. I'll test them and get back to you.