Tag: htaccess

Mailbag! .htaccess questions
New thing! So many people email me for tech support, which I’m pretty clear on how you’re not going to get it. But Ken (the web mechanic) asked some pretty basic questions, and I’ve decided to answer some of them.

In public. Lucky you, Ken. Don’t worry! These were good questions. See, one of the (many) reasons I love WordPress and the support forums is that the answers are public so everyone can see what the question was and how it was answered! This is hugely important to foster a community, so that’s why I’m going to answer this in public, with your personal information removed, of course.

Ken’s basic concern is that .htaccess is confusing, and is there a preferred order? The answer is yes. The basic idea is that .htaccess rules are a top-down process. The server reads the file from the top on down, in order, 1-2-3. For this reason alone, it’s obvious why you don’t want a super long .htaccess file: more to read takes longer!

The WP permalink area… Should that always be dead last?

Yes! WordPress rules always go last. Remember what I said about top-down? If you were to put WordPress at the top, you would load WordPress, process it, and then do the rest of the rules. Which once you say that, it’s pretty obvious eh?

Deny IP addresses/ referrers. To me it would make sense for them to be at the beginning… Would that be true?

True! The access controls (including IP blocks) first. Redirects go next, starting from most specific (about-me to about) first to general last. Then your Rewrite rules.

Compression/Caching/mod_expires… I haven’t a clue where they most appropriately go. Securing wp-config, htaccess itself, other files, etc. … Before? After? the WP permalink block.

I put them before my re-writes. Since I use a deny to secure .svn type files, it’s an access control so it goes first.

So how does this work? Here’s a practical example. You want to do the following: remove www from your domains, protect your wp-config file, protect your comments and login from direct attacks, redirect some old pages from before you were WordPress, redirect your old permalink formats, and gzip/compress things. Oh and run WordPress!

The order would go like this:
1. Access Control: This is the part where we’re protecting specific files, but also blocking IPs. Basically it’s ‘Security First.’
2. Remove WWW: We want to make sure everyone’s redirected to the non-www page. If you’re redirecting specific domains (like I send tech.ipstenu.org to halfelf.org), you do it here as well.
3. GZIP: I do my compression here, though it woudl work just as well swapped out with the next one.
4. Redirect: Here we’re talking one-off redirects like sending ‘about-me’ to ‘about’.
5. Rewrite: The ReWrite rules are the ones where you say “Send http://example.com/2014/01/10/postname/ to http://example.com/postname/” with those rules with regex.
6. WordPress Rules: Last. Always always last.
And that is .htaccess!

If you want a look at how my .htaccess is structured, see My super-secret .htaccess file, which hasn’t changed much since 2013. I do a couple things out of order, but they’re minor enough. As long as I can limit any recursive loops with the .htaccess checks, I’m doing good.
7 May, 2014
My Super Secret .htaccess File
This came up back in April in the comments of WordPress Login Protection With .htaccess, where I remarked my .htaccess was pretty long and weird. It came up again when I was doing a MeetWP presentation about hacked sites and some security.

So what is it? Actually less long and weird these days. I’ve been trimming stuff out. But since people ask, here it is, broken out into ‘chunks.’

Security

Everything in this section is for security purposes. That is, I feel it helps my site be safer.
```
# Tinfoil Hat Stuff
Options +Includes
Options +FollowSymLinks -Indexes
```
This is basic .htaccess stuff, says to allow includes and symlinks, but stop indexes. This means if you go to halfelf.org/wp-content/uploads/ you don’t see anything, even if I don’t have an index file.
```
### Blocking Spammers Section ###
<files wp-config.php>
order allow,deny
deny from all
</files>
```
Now we’re into a little odder bits. This stops anyone from surfing to my wp-config.php file. It shouldn’t matter, PHP won’t let it load the content, but if my PHP is off, it protects me just in case!
```
# Stop protected folders from being narked. Also helps with spammers
ErrorDocument 401 /401.html
```
This is because of the next section. It gives a nice error for 401s, which WP normally gets gitty over. And not the fun way.
```
<IfModule mod_rewrite.c>
# Stop spam attack logins and comments
	RewriteEngine On
	RewriteCond %{REQUEST_METHOD} POST
	RewriteCond %{REQUEST_URI} .(wp-comments-post|wp-login)\.php*
	RewriteCond %{HTTP_REFERER} !.*(ipstenu.org|halfelf.org|ipstenu.org|otherplace.net).* [OR]
	RewriteCond %{HTTP_USER_AGENT} ^$
	RewriteRule (.*) http://%{REMOTE_ADDR}/$ [R=301,L]
 # SVN & Git protection
	RewriteRule ^(.*/)?(\.svn|\.git)/ - [F,L]
	ErrorDocument 403 "Access Forbidden"
</ifModule>
```
Ahhh, yes. Here I say “If you’re coming to wp-comments-post OR wp-login and you are NOT refereed by one of my domains, sod off.” And then it says “Oh and if you’re looking for .svn or .git files? Go away.” This isn’t perfect, but it works for some of the botnets. The fun part is that the rewrite sends them back to themselves, which should cause annoying things to happen. Don’t want that? Redirect them to fbi.gov. Actually, if some tool had a page “Redirect botnets here…” I would use that, but generally I send them to http://lmgtfy.com/?q=wordpress+botnet because I’m that sort of kid.

Speed and Bandwidth

Now that I’m safer, lets speed this stuff up!
```
<IfModule mod_rewrite.c>
 RewriteEngine on
# ultimate hotlink protection
 RewriteCond %{HTTP_REFERER}     !^$
 RewriteCond %{REQUEST_FILENAME} -f
 RewriteCond %{REQUEST_FILENAME} \.(gif|jpe?g?|png)$               [NC]
 RewriteCond %{HTTP_REFERER}     !^https?://([^.]+\.)?(ipstenu.org|taffys.org|halfelf.org|poohnau.us|ipstenu.org) [NC]
 RewriteRule \.(gif|jpe?g?|png)$                                 - [F,NC,L]
</ifModule>
```
First up, stop the hotlinks! I got the idea from Perishable Press, and it stops you from embedding my images. This means my site is faster, as you’re not sucking up my bandwidth. I get 5G so it’s not too much of a concern right now, but it’s the principle of the thing. Don’t hotlink images!
```
### Caching Section ###
# mod_pagespeed
<IfModule pagespeed_module>
	ModPagespeed on
	ModPagespeedEnableFilters defer_javascript,combine_javascript,move_css_to_head,insert_dns_prefetch,insert_image_dimensions,inline_preview_images,resize_mobile_images
	ModPagespeedDisallow */FOLDERNAME/*
	ModPagespeedEnableFilters insert_ga
	ModPagespeedAnalyticsID UA-MYCODE-4
</IfModule>
```
I use Pagespeed on my server, so here I’ve added in my extra rules. Not everything is active for all sites. This is my default WP rule-set though, and it works well. I have it skipping a couple non WP folders, who have their own rules inside on their own .htaccess files anyway. If you don’t have pagespeed? Skip this section.
```
# Expired
<IfModule mod_expires.c>
<Filesmatch "\.(jp?eg|png|gif|ico|woff)$">
    ExpiresActive on
    ExpiresDefault "access 1 year"
</Filesmatch>

<Filesmatch "\.(css|js|swf|mov|mp3|mpeg|mp4|ogg|ogv|ttf|xml|svg|html)$">
    ExpiresActive on
    ExpiresDefault "access 1 month"
</Filesmatch>

    ExpiresDefault "access 2 days"
</IfModule>
## END EXPIRES ##
```
Oy. There are a couple ways you can control all these things. One is the way I did (filesmatch) and the other is ExpiresByType image/jpg "access plus 1 year". Is one better than they other? I don’t know. Not that I’ve managed to see, but I find the filesmatch to be easier to read and add things too. It’s shorter. Does that make it better? Only in so far as my management goes.
```
#Gzip
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/text text/html text/plain text/xml text/css application/x-javascript application/javascript text/javascript font/opentype font/truetype font/eot application/x-font-ttf
</IfModule>
#End Gzip
```
Finally we have gzip, which compresses and makes things smaller and thus faster. Using gzip saves me about 80% in filesize, so it makes things faster to download and, thus, display. If you’re using this in your .htaccess, do not also try to use it in plugins/extensions for other web apps, that way likes double compression and garbage on your pages.

Add support!

This is a really short bit to add in support for filetypes I use that aren’t always standard:
```
# Add filetypes
AddType application/x-mobipocket-ebook mobi
AddType application/epub+zip epub .epub
AddType video/ogg .ogv
AddType video/mp4 .mp4
AddType video/webm .webm
```
Rewrites

In general, this is useless to everyone else, save as an example.
```
### Massive Redirect Section! ###
<IfModule mod_rewrite.c>
RewriteEngine On

# Apple Touch Icons
RewriteRule ^(.*)-precomposed.png /code/images/apple/$1.png [L,R=301]
RewriteRule ^apple-touch-icon(.*) /code/images/apple/apple-touch-icon$1 [L,R=301]

# Ipstenu Moves
RewriteCond %{HTTP_HOST} ^blog\.ipstenu\.org
RewriteRule ^(.*) https://ipstenu.org/$1 [L,R=301]
RewriteCond %{HTTP_HOST} ^ipstenu\.org
RewriteRule ^blog/([0-9]{4})/([0-9]{2})/(.*)$ https://ipstenu.org/$1/$3 [L,R=301]
RewriteCond %{HTTP_HOST} ^ipstenu\.org
RewriteRule ^blog/(.*)$ https://ipstenu.org/$1 [L,R=301]
RewriteCond %{HTTP_HOST} ^ipstenu\.org
RewriteRule ^wp-content/blogs.dir/1/files/(.*)$ https://ipstenu.org/wp-content/uploads/sites/1/$1 [L,R=301]
RewriteCond %{HTTP_HOST} ^ipstenu\.org
RewriteRule ^(.*)favicon.(ico|png)$ /code/images/favicons/ipstenu.ico [L,R=301]

[NB: This sort of thing is duplicated for other domains which also had things moved around]
</IfModule>
```
I cut out a couple of sections, where what I did with the ‘Only redirect ipstenu.org’ stuff is repeated for each site. I built much of that after reading my 404 logs and determining what needed to be redirected. Everything is commented and in logical sections, so I can easily find and remember what the heck I was doing.

This is the longest section, the stuff under # Ipstenu Moves and such, because they’re accounting for files that moved a million years ago. But the moves section is pretty straightforward too, as you can see where things went. I try to keep it as compact as I can. Sometimes I go through and make them more and more efficient, as I learn new tricks.

What used to be here?

I used to include the 5G Blacklist 2013 and/or the 2013 User Agent Blacklist (or whatever the current versions are), but now I don’t have it on all my sites because of the work I’ve been putting in on my firewall and ModSecurity instead. Every once in a while, someone tells me I’m putting too much work on Apache to handle the hackers and spammers, and I generally reply “Better Apache than WordPress.”

Regularly, I go through my .htaccess and see what I can push over to ModSec. I also trim down my PageSpeed rules into things that work on most sites, things that only work on this site, and things that work for everything. This is why there’s no blacklisting here, it’s all handled by my firewall and mod_security and that’s that. I like to take the load off of apache and .htaccess and PHP and make the server do the work.

Why not nginx?

Per site configuration is still a pill. No, really that’s it. It’s a hassle to re-do everything I have in htaccess, I can’t just toss a .nginx file in there on the fly without restarting nginx, which means for shared hosts it’s just not gonna happen. Sucks. For managed hosting, where you don’t allow users to make those changes, sure, it’s great. But that’s not my use case. I may use it for a Varnish in front server one day, after I rebuild everything from scratch.
30 October, 2013
WordPress Login Protection With .htaccess
The Brute Force attack on WordPress and other CMS apps is getting worse and worse right now. Some people don’t have Mod Security (or can’t get it to work on their server), and asked me if there was anything to be done. Yes, you can still protect your site from those brute forcers via .htaccess.

To be honest, I worried about posting this, since the last thing I want to do is to inspire hackers to do even more inventive things, but I can’t think of another way to get the word out. I want to say this: If your site is being hammered hard by these attacks, CONTACT YOUR WEBHOST RIGHT NOW. The best protections will be done on their end, because using WP to try and stop this still means people are hammering WP.

So okay, what can you do with .htaccess? Well, taking into account the ages old .htaccess block that has been posted up at WordPress.org, you can block comments made by people with out a Referrer Request, I made the logical extension!
```
### Blocking Spammers Section ###

# Stop protected folders from being narked. Also helps with spammers
ErrorDocument 401 /401.html

# Stop spam attack logins and comments
<IfModule mod_rewrite.c>
	RewriteEngine On
	RewriteCond %{REQUEST_METHOD} POST
	RewriteCond %{REQUEST_URI} .(wp-comments-post|wp-login)\.php*
	RewriteCond %{HTTP_REFERER} !.*(ipstenu.org|halfelf.org).* [OR]
	RewriteCond %{HTTP_USER_AGENT} ^$
	RewriteRule (.*) http://%{REMOTE_ADDR}/$ [R=301,L]
</ifModule>
```
So the rule does the following:
1. Detects when a POST is being made
2. Check to see if the post is on wp-comments-post.php or wp-login.php
3. Check if the referrer is in your domain or if no referrer
4. Send the spam-bot BACK to its originating server’s IP address.
The reason my referrer line has (ipstenu.org|halfelf.org) is because … well I have multiple domains on my multisite! If you don’t, you can just have it be one domain, but this lets me have one line instead of eight (yes, eight, you heard me). Not all of them are .org, but if they were, that line would look like this:
```
RewriteCond %{HTTP_REFERER} !.*(ipstenu|halfelf)\.org.* [OR]
```
Only make variable what you have to, eh?

Edit: If you’re using Jetpack for comments, you should also add in jetpack.wordpress.com as a referrer.

Above that, though, you saw the 401 rule, right? The 401 takes any errors, which can be abused by this, out of the hands of WP. However for this to work best, you have to actually make a 401.html file.

Here’s mine:
```
<html>
<head>
<title>401 Error - Authentication Failed</title>
</head>

<body>

<h1>401 - Authentication Failed</h1>

    <p>Through a series of highly sophisticated and complex algorithms, this system has determined that you are not presently authorized to use this system function. It could be that you simply mistyped a password, or, it could be that you are some sort of interplanetary alien-being that has no hands and, thus, cannot type. If I were a gambler, I would bet that a cat (an orange tabby named Sierra or Harley) somehow jumped onto your keyboard and forgot some of the more important pointers from those typing lessons you paid for. Based on the actual error encountered, I would guess that the feline in question simply forgot to place one or both paws on the appropriate home keys before starting. Then again, I suppose it could have been a keyboard error caused by some form of cosmic radiation; this would fit nicely with my interplanetary alien-being theory. If you think this might be the cause, perhaps you could create some sort of underground bunker to help shield yourself from it. I don't know that it will work, but, you will probably feel better if you try something.</p>

</body>
</html>
```
There are more WordPress specific tips and tricks on the WordPress Codex Brute Force Attacks which we Forum Volunteers have been working on all morning. If you want to do even more, then you’ll want to password protect your wp-login.php page, or perhaps whitelist it so only your IPs have access. Personally, I’m not doing that (I have ModSec working) and I’m not using any plugins. While the plugins are great, they still require WordPress to process something, which means that while they can, and will, prevent people from getting in, they won’t stop the traffic on your server.

I wish I knew more about nginx, but if someone can translate all those things to nginx, please post a link and share it! We need to know!

At a last gasp, CloudFlare and Sucuri CloudProxy both claim to stop this before it hits you. I don’t use either, as you may know, so I can’t speak for them, but if your host is unable of doing anything, and you can’t make anything work, you may as well try it.
12 April, 2013
Cacheless (or not)
ETA: As of a month later, I’ve actually switched from APC to Zend Optimizer+

Don’t get me wrong, I love caching. I love W3 Total Cache (I’m willing to spend my ‘free time’ testing it, after all), and WP Super Cache saved my life once. So why, on a day where I got a 400-600% uptick in traffic (not a joke), did I turn all my caching off? I’m daring, and a little crazy, but I wanted to see if it could be done. I would not have tried this if I was on a smaller server: if you’re getting as much traffic as I am, and you’re on shared hosting, you really need to move to a VPS or Dedicated Server if you want to turn off caching via plugins. It’s not to say that caching is better or worse than not-caching, or vice versa, or that one is a rich-man/poor-man equivalent of the other. Caching plugins are an inexpensive way to speed up your site, and if you can’t afford a bigger server they will buy you the time you need to figure out a better solution. Even with a good plugin and setup, if you get hammered with a lot of traffic, you will crash your site unless the server’s optimized too. Again, what I’ve done is not something I’d try on a low-end server with high traffic.

When I started measuring the effectiveness of all this, I used:
- WebPageTest
- GT Metrix (tests Yslow and Google Page Speed at once)
- ByteCheck
- Apache HTTP server benchmarking tool
To understand what caching is and why we use it, it’s good to understand the basic concepts, and to start by looking at what caching plugins are, how they work, and where their pitfalls are.
- There are parts of your website that don’t change often (images, javascript, CSS, etc).
- You want the user to only download what’s changed.
That sounds easy, but WordPress isn’t static HTML, it’s PHP, and that means every time you visit the page, it runs various proceses to give you the latest and greatest files. The problem with this dynamic code is where content changes rapidly (think ‘comments’ or ‘forums’ or ‘BuddyPress Groups’). Suddenly caching ‘pages’ as wholesale chunks of html doesn’t help if you have to re-cache when someone leaves a remark. Add in the possibility of 4 or 5 people commenting at once, for 12 hours, and now you’re risking a thrashing situation where you keep trying to cache, but it keeps flushing. This is why most people use plugins that handle things elegantly, or try to, where the ‘static’ part of the page (sidebar, etc) are HTMLized, but the dynamic part is left alone. This helps when you have a portion of every page is dynamic, like a shopping cart with a ‘Your order…’ box.

But the downside is that you have to write fancy code that remains dynamic portions, and while it certainly can be done, it’s not fun, and let’s be honest, a theme developer doesn’t know which cache you’re going to use, so how can it write the right way for that? The only way to make a truly dynamic and cachable site is to do it from day one, with your theme, server, and plugins all crafted to provide the best experience. And then we have reality, which is we start with something simple, wake up to something large, and experience growing pains.

Accepting the fact that we’re not starting from nothing, that we have an existing site with content and activity, the first thing most people do is install a plugin. Now, back to what I said before, this isn’t a bad thing. It’s a good first step and will buy you time. It’ll also show you where you need to go. If you don’t have server root access, this may be a your limit, too, as some of the other things I like to do to speed things up without a cache will require it (or you’ll have to ask your hosts and they may tell you to upgrade).

If you’re going to use a plugin, WP Super Cache (WPSC) and W3 Total Cache (W3TC) are the best two. W3TC is way more advanced, and has a lot of extra bells and whistles, but personally I find that once you can master it, you’re well on your way. Remember though, you’re sacrificing a lot of control here by using a plugin. They’re going to, by their nature, cache everything they can, and we’re back to where we were with the dynamic site generation issue. W3TC has a bunch of extra .htaccess/nginx rules which parse data before you hit WordPress. WPSC can do that, or use PHP (which is slower).

The dynamic nature of my site is what drove me away from caching plugins. I use other CMS tools, and for my infrequently updated Wiki and ZenPhoto Gallery, where content is very much static, caching makes perfect sense. But when I want to run a simple community site with WordPress, I have to consider all aspects of user experience. Speed is hugely important, but so is the user getting the content they want. Stale content is a killer.

The reason I decided to see if my site ran slower without caching was that I was reinstalling caching and I thought “This is a perfect time to benchmark.” When I did I was astounded. There was very little difference in a benchmark test. Really no difference between at all, since it was within the results of each other, but I neglected to save the results at the time. I did however snap a picture of my server load(The unrelated part is where I was uploading 10megs of media. Unrelated.):

Browser Caching is the first thing to tweak, as that tells browsers to cache content. The way this works is your .htaccess tacks on extra information while content like images and CSS are being downloaded, to say “This content is good for X days.” With WordPress, you don’t have to worry about changing the CSS, as most themes and plugins are extra smart, in that they append a version to the end of your CSS like this: style.css?ver=1.9.1 That 1.9.1 is the version of Genesis I’m running, so when that changes, the version changes, and browsers see it as a new file and re-download. That’s pretty cool. (I do wish that child themes pulled in their version, so you could increment that way.) We still have to tell the broswers to cache, and for how long, so near the top of my .htaccess (just below my hotlink protection) I have this:
```
## BEGIN EXPIRES ##

    ExpiresActive On
    ExpiresByType image/jpg "access 1 year"
    ExpiresByType image/jpeg "access 1 year"
    ExpiresByType image/gif "access 1 year"
    ExpiresByType image/png "access 1 year"
    ExpiresByType image/x-icon "access 1 year"

    ExpiresByType text/css "access 1 month"
    ExpiresByType text/html "access 1 hour"

    ExpiresByType application/pdf "access 1 month"
    ExpiresByType application/x-javascript "access 1 month"
    ExpiresByType application/javascript "access 1 month"
    ExpiresByType text/javascript "access 1 month"
    ExpiresByType text/x-js "access 1 month"

    ExpiresByType application/x-shockwave-flash "access 1 month"
    
    ExpiresByType video/quicktime "access 1 month"
    ExpiresByType audio/mpeg "access 1 month"
    ExpiresByType video/mp4 "access 1 month"
    ExpiresByType video/mpeg "access 1 month"
    ExpiresByType audio/ogg  "access 1 month"
    ExpiresByType video/ogg  "access 1 month"

    ExpiresDefault "access 2 days"

## END EXPIRES ##
```
I’ve added in only the types used by my site. I used to use Pragma caching headers as well, but I noticed that Google PageSpeed Insights and YSlow ignore them. Turns out that Pragma headers aren’t honored all the time, in fact, they aren’t honored often, so I just removed them. I don’t think it slowed my site down to have them, but the less to maintain, the better. This had an immediate positive impact, so it was time to look at the server.

Over the years, I’ve tuned httpd.conf so it doesn’t crash, I’ve got CSF locked down to prevent people from DoS’ing me over TimThumb, and I of course have APC turned on. Recently I broke down and installed mod_pagespeed when I upgraded to PHP 5.4. Just those things have done a lot to make my site run faster. I intentionally skipped things like Varnish or TrafficServer, as well as a CND or Google’s PageSpeed Service. I (still) don’t need them.

Since I’m new to Page Speed, I decided to look deep into the filters and enabled the following for the whole server: rewrite_javascript, rewrite_css, collapse_whitespace, elide_attributes. This had a right-away impact of what I jokingly called ‘Effective Minification.’ These filters are new to me, so I spent a lot of time reading up on all the filters, and I find them highly interesting. By having PageSpeed handle things like offloading jQuery, I take the load off of WordPress and other CMS tools, and don’t have to use a plugin.(Don’t get the wrong idea. There are uses for plugins! But I’m all about using the right tool for the right job. I don’t have plugins handle my WordPress database, because I feel it’s like using a screwdriver to hammer in a nail. You can….)

I added in a couple more to my standard: remove_comments and rewrite_images. Then I went back to my site’s .htaccess and started turning on the things I wanted per-site.

The ones I picked are:
Putting those in my .htaccess looks like this (note: no spaces between the filter names, or it all blows an error 500):
```
    ModPagespeedEnableFilters move_css_to_head,defer_javascript,insert_ga
    ModPagespeedAnalyticsID UA-MYCOOLID-1
```
That also means I don’t have to use a plugin to use Google Analytics for my whole site! This may not mean a lot to you, but I have multiple ‘apps’ on my site (four now) and when I edit themes, if I don’t have to do anything, it’s easier. Google will tell you not to do this, but unless they have a way for me to set pagespeed.conf in the /home/user/ folder of my server, I don’t know another per-user way about this.

Finally I went back on my word, and I installed a plugin. APC by Mark Jaquith. This isn’t a full reversal on my ‘No Plugins!’ stance before, though. All APC is, you see, is but one file that sites in wp-content and kicks things over to APC. Doing this alone moved my TTFB from an F to a B. Which is pretty impressive. Giving it a little time to bake, this worked out okay.
19 February, 2013
Kick PageSpeed Up A Notch
If you’re using Apache and PHP 5.3 on your DreamHost domain, you have the magical power to enable Google PageSpeed. Just go and edit your domain and make sure you check the box for “Page Speed Optimization”:

But what does that even mean, I hear you ask?

PageSpeed is Google’s way to speed up the web (yeah, that was redundant), and it serves as a way for your server to do the work of caching and compressing, taking the load off your webapps. Like WordPress. Anyone can install this on their apache server, and it’s free from Google Developers: PageSpeed Mod. Since you’re on DreamHost, you lucky ducky you, we did it for you. Now you can sit back and relax.

The first thing to notice when you turn on PageSpeed is that it minifies your webpage. That means it takes your pretty formatted source code and gets rid of the extra spaces you don’t use. This is called by using the PageSpeed filter “collapse_whitespace.” Another filter we use is “insert_ga” which is how we’re magically able to insert your Google Analytics for you from your panel. That filter automatically inserts your GA code on every page on your domain. That’s right! No more plugins!

If you’re like me, you may start to wonder what other filters you should use, and that entirely depend on what you want to remove. I knew I wanted to remove code comments like the following:
```

```
That’s easy! There’s a filter for “remove_comments” so I can just use that. They have a whole mess of filters listed in the Filter Documentation and reading through it took a while. If you read each one, at the bottom they talk about how risky a certain filter is. Taking that into account, I went ahead and added some low and some high risk filters, since I know what I’m using.

The magic sauce to add all this is just to edit your .htaccess and put in the following near the top:
```
<IfModule pagespeed_module>
    ModPagespeed on
    ModPagespeedEnableFilters remove_comments,rewrite_javascript,rewrite_css,rewrite_images
    ModPagespeedEnableFilters elide_attributes,defer_javascript,move_css_to_head
    ModPagespeedJpegRecompressionQuality -1
</IfModule>
```
Really, that’s it.

The ones I picked are:
- remove_comments – Remove HTML comments (low risk)
- rewrite_javascript – minifies JS (med. to high risk, depending on your site)
- rewrite_css – parses linked and inline CSS, rewrites the images found and minifies the CSS (med. risk)
- rewrite_images – compresses and optomizes images (med. risk)
- elide_attributes – removing attributes from tags (med. risk)
- defer_javascript – combines JS and puts it at the end of your file (high risk AND experimental!)
- move_css_to_head – combines CSS and moves it to the head of your file (low risk)
Now keep in mind, not all of the features will work. While DreamHost is on a pretty cutting edge version of PageSpeed, they’re constantly innovating over there and improving. The best thing about these changes is, if you do it right, you can speed your site up faster than any plugin could do for you. And that? Is pretty cool right there.
22 January, 2013
Dumping ms-files
NOTE: You do not, under any circumstances, have to do this to continue using WordPress Multisite. I just wanted to see if I could.

I have been toying around with this. Since WP 3.5 doesn’t use ms-files anymore, I wanted to see how much of a pain this would be. While I was at the DMV (I now have a California Drivers License), I started sketching out the methods and possibilities for how one might do this as safely as possible, without bolluxing up your site. I got about 90% successful with it, so this is something I would never suggest you do on a massive, live site. If you compare it to what I did to move images from uploads to blogs.dir for the main site, it’s far more complex and annoying.

Do you have to do this? Again, no! Everything will work just fine. Can you do it? Sure. Why did I? Support. I already know all the mishegas with blogs.dir, but the new location, and it’s lack of ms-files, promises other, weird, errors. I want to repeat, you don’t need to do anything. The Core Team was fantastic with the work they did to turn off ms-files for fresh 3.5 and up installs is nothing short of phenomenal. This was just to assuage my curious nature, and learn more about the way things work.

You ready? Here we go.

I decided to move the images at http://test.ipstenu.org/ to start with, so everything will use that as my example. This is after I played with it on a local site and got my steps mostly solid. I knew that live is always different than test, so I backed up the DB first (always, always, backup first!) and went to town.

Move the images

This is obvious. Move your images from blogs.dir/SITENUM/files/ to /uploads/sites/SITENUM/ (or make an alias). I went and did it via command line in the /uploads/sites/ folder, doing this:
```
$ cp -r ~/public_html/wp-content/blogs.dir/10/files .
$ mv files 10
```
Lather, rinse, repeat. I could have scripted it, but I was working out the kinks until I had two left.

Edit all sites

Upload Path, Upload URL Path and Fileupload Url. You can blank them all out.(Corrected thanks to Nacin.)

Since you’re blanking it out for everyone you can probably do this via SQL, but since I was doing the sites one at a time, I did them one at a time.

Fix the Database
Search/replace each posts table for each site, changing /files/ to /uploads/SITENUM/
```
UPDATE wp_10_posts SET post_content = REPLACE (
post_content,
'=&quot;http://test.ipstenu.org/files/',
'=&quot;http://test.ipstenu.org/wp-content/uploads/sites/10/');
```
Why did I do it that way? Because of this blog. I talk a lot about code here, and I know I’ve talked about moving files around before. If you don’t do that, you’re okay with a less precise search, but why bother? This works, it’s safe, and I’d use it again.

That got annoying really fast. I went and grabbed my favorite Search And Replace for WordPress (and any other database) tool. Seriously I love that. I used that to follow up, change everything, and it actually worked really well for me.

Another DB Fix!

One of the changes in 3.5 was turning off rewriting. This took me forever and a day to find. After I did that, my images showed up fine, but the little buggers kept uploading to /files! Turns out it was all because of the site option ms_files_rewriting

The way I got around this was by putting the following in my wp-config.php file:
```
define( 'UPLOADBLOGSDIR', 'wp-content/uploads/sites' );
```
And then I ran this in SQL to turn off ms_files_rewriting. Or so I thought. More in a second.
```
INSERT INTO `my_database`.`wp_sitemeta` (`meta_id`, `site_id`, `meta_key`, `meta_value`) VALUES (NULL, '1', 'ms_files_rewriting', '0');
```
I came up with that after reading through /wp-includes/functions.php line 1515.

For most sites, this worked, but in my later work, I determined that it actually wasn’t working. It was ignoring this. I don’t know why, but every test I did merrily ignored this setting, so I finally growled and wrote this mu-plugin function:
```
function stupid_ms_files_rewriting() {
        $url = '/wp-content/uploads/sites/' . get_current_blog_id();
        define( 'BLOGUPLOADDIR', $url );
}
add_action('init','stupid_ms_files_rewriting');
```
It’s stupid simple, it’s probably not a good idea, but it works for the three sites that have the stupids.

Finish up .htaccess.

.htaccess, remove the ms-files.php line for ms-files, or comment it out. This is pretty simple.

Why not move the main site to /uploads/?

Because of the way I fixed the uploadblogsdir. It defaulted everyone to /sites/ and after an hour I said fuck it.

Any weird problems?

Yeah, two sites (this one and my grandmothers) decided that they wanted to be repetitious and spat out URLs like this: wp-content/uploads/sites/8/sites/8/

Since that wasn’t right at all, and I was a little too eggnoggy to parse why, I did this:
```
RewriteCond %{HTTP_HOST} ^taffys\.org
RewriteRule ^wp-content/uploads/sites/8/sites/8/(.*) /wp-content/uploads/sites/8/$1 [L,R=301]
```
I swear I have no idea why three sites got stuck with /files/ and two more decided to double down, Vegas style, but frankly I’m pleased I got through this far on my own.

I can’t stress enough that you do not have to do this!
24 December, 2012