Any help would be greatly appreciated. Thanks

Thanks again.

I didn’t know GoDaddy doesn’t have any compression enabled. I’m stunned actually. So thanks for the post suggestion, I will definitely take a look at that, as I’m planning on continuing this “series” about blog optimization. Web optimizing and tweaking is a passion of mine – there is no such thing as “too fast loading blog” :)

As a side note, it is possible to just compress the CSS and JS files manually. And in some cases the static files like main CSS should be compressed anyway, as it doesn’t change, why not compress it once, instead of everytime someone loads it, right? But on the fly compression is perfect for all the third party things like plugins get the benefit too.

I use GoDaddy hosting and recommend them to my clients. Unfortunately, GoDaddy does not enable Mod_deflate or Mod_Gzip, so compression isn’t possible using the methods you describe.

There IS a work-around for compressing JS and CSS (requires mod rewrite and shell access). I’ve found a couple of people that do an OK job of explaining the process, but I’d like to read a post from you on the subject, i.e. Gzip compression for WP blogs on Godaddy, or something like that…just an idea.

BTW, someday I’d like to wake-up and have your depth of htaccess knowledge.

What you said about rules restricting access should be 1st, means I should move the 301 down below them, it is currently 1st.

You have a new Twitter follower and subscriber to this blog! Steve aka JEDs

Without knowing the spesifics it is possible that there is conflicting redirect or rule in there, e.g. some other redirect or such. Thus, you should find the right “spot” for the rule before/after/between the rules. Look for other rules with RewriteCond %{HTTP_REFERER} & RewriteRule, which do the redirect.

In general, everything that restricts access should be at the very top and for example the WordPress rule (added at install) should be at the very end.

Can you advise regarding the order that things go into the .htaccess? I have 2 plugins that have written to it along with the code to prevent directory access and to wpconfig. I used my control panel to add a redirect, but had to move it from where the control panel put it to the front of the file before it would work. (This was a while ago)

http://httpd.apache.org/docs/1.3/howto/htaccess.html#how explains that directives are processed in the order they are found. Not understanding all of the code in the plugins’ directives, I still don’t understand why the redirect wasn’t processed when it was at the end of the file.

Just wondered if you had any advice about the order that these rules are put into the file, and relative to other directives. Thanks again!

JEDs
.-= Steve Warriner’s last blog ..FTC Guidelines – One More Day =-.

There are other plugins that handles compressing the CSS, javascript, images (like SmushIt for WordPress I wrote about earlier), etc.

But setting the .htaccess rules in this post just once takes care of a lot of this as well (which you can take improve even further with other tweaks and optimizing plugins)

The short and concise explanations with code was great to read and easy to get through, something I really need to practice ;) I hope you write about something I don’t already know for your next article… What an intro to htaccess!

Subscribed!
.-= AskApache’s last blog ..Protecting Files with Advanced Mod_Rewrite Anti-Hotlinking =-.

I’m on a shared hosting on DreamHost, and the mod_deflate is in use and it’s all been good so far.

About the cache and WP-Super Cache: The browser cache settings help in a sense that returning visitor or the ones going from page to page have the images, css and such cached on their browser = goodness. On the other hand, for one-time visitor (visiting one page) browser cache doesn’t do anything.

As a side note, I think WP-Super Cache compression option uses mod_deflate, so if you don’t have that on your server, don’t try to activate compression for WP-Super Cache either.

WP-Super Cache stores the html pages in it’s cache, delivers those to the visitor and sets (browser cache) expiration times for the HTML pages to 5 minutes and it’s own cache is one hour or 3600 seconds by default.

With cached HTML from WP-Super Cache (which means no dynamic page must be generated every time), common css and images can be loaded into cache once and then loaded from cache on the following visits/pages. So yeah, cache settings are very useful, even with WP-Super Cache.