I recently installed the “new” version of phpmyadmin, and noticed that it didn’t work (in Chrome or Firefox, but did work in Safari). After a fair amount of troubleshooting, I found there’s a setting in config that is: $cfg['AllowThirdPartyFraming'] = true; (this overrides the default “false”) that seems to be for blocking iFrame attacks.

This caused the first part of the login page to load, but still missing the login fields, etc. After some more troubleshooting, this turned out to be Cloudflare’s Rocketloader. Which, you can disable either via path rule (just excluding everything with a given path), or by adding a value to the <script> tags. The path rule works great, but you only get 3 path rules with a free cloudflare account. =/

So, going into Scripts.class.php and added the tags to the javascript tags. I created a patch, and posted it to the bug on the phpmyadmin bug tracker here. After the bug initially getting closed as invalid, after posting the patch, they re-opened the ticket, and may include the changes in a release (or find some other way to resolve the rocketloader issue). So far, I get the impression phpMyAdmin won’t be including my patch in their codebase. =/ (UPDATE: In fact, they accepted the patch, and it’s now to be included in 4.4.2!)

I’ve also opened a bug with Cloudflare (which, sadly, I can’t link to). I’ve heard nothing back from them.

Like most people that run a Wordpress site, or any CMS, I’ve struggled with brute force attacks on my site. Having just installed fail2ban on a mail server, this seemed like an obvious. Thankfully, as well, someone had already written a plugin for Wordpress to drop a message in the system log saying a login failed (by default, Apache doesn’t do this, it just shows someone hit the login page). At first, I had set up an iptables/pf rule to block the bad user, but for some reason, this wasn’t happening. My test browser kept hitting the page successfully.

After a break, I realized that I use Cloudflare, and of course blocking the offending IP wouldn’t work… it never actually connects to my host. Thankfully, Cloudflare has an API, and there was already a starting point for a fail2ban action, albeit, out of date (Cloudflare forces json now). Below is that action. You should be able to just call this like any other action, after you fill out the appropriate “token” and “email”.1

Note: I had to disable “always online” with Cloudflare to have the block take effect within 5-10 seconds. With “always online” enabled, it took about 2-3 minutes to block the attack, all the while the “bot” was able to keep hitting my server. [↩]

UPDATE (10/27/2011): As of today, I’m scoring a 99/100 on PageSpeed (missing point is an erroneous error about images being unoptimized), and a 99/100 on YSlow (missing point is about Cloudflare setting cookies on static content, which isn’t a huge issue). So at this point, I can finally say “USE CLOUDFLARE”. It’s more than worth it (which, since it’s free….).

So in a fit of boredom last night, I decided to take a look at page speed increases again.

This time is a bit different as I’m not using Cloudflare and I’ve changed themes. Since moving to the new theme, and an update to W3TC, I’d been getting in the mid-80’s for both Page Speed, and YSlow. Which shouldn’t be the case with Cloudflare. Everything says it should have greatly improved my speeds, and score… so something was clearly up.

So, some testing later, and I’ve figured out what was up. First, was disabling the automatic settings in W3TC. I’m guessing this (automatic minify) would work if you weren’t using a WP_CONTENT_URL (which I guess I probably don’t need anymore with Cloudflare… but changing to not use it would take a bit of work at this point.). The point of the WP_CONTENT_URL, however, is to “parallelize” the browser download process… so Cloudflare probably doesn’t solve this issue.

Anyway, disabling it, then going into W3TC’s minify section and adding all the URLs for your CSS and JS files that are loaded on your home page. Also, I went into my thematic child theme’s style.css, and removed all the @import’s, and added those CSS files to the minify settings. Reordering the CSS and JS was then a trial and error, but got it working.

Now, page loads are damn fast. And YSlow gives me 99/100, and Page Speed gives me a 97. Cloudflare gives me the CDN points, so the only thing hurting my YSlow score is Google Analytics not having long distance expiration.

Optimization takes time, but it works. I’m not positive why Page Speed is knocking off the 6 points, but I think it’s some CSS inefficiencies. *shrugs*

Good luck, and feel free to ask if you run into any issues. Might just redirect you to somewhere else, but it’s working.