A while ago I noticed that some of my older posts had some silly misspellings in it, so I was looking for a way to spell check all my posts in one shot. I couldn’t really find anything that was free, so I figured I’d try to write something myself to do this for me.
I knew about the free and open source Hunspell spell checker and that you can use it from the command line. So I thought using that together with the WordPress export XML file which has all your post’s content it should be possible to spell check the whole lot.
The end result is a PowerShell script which reads out the XML export file and runs it through Hunspell, parses the spelling errors found and finally bundling it all into a simple HTML report.
It worked nicely for me, even though it’s pretty crude and simple. I only had to use this once, so I don’t see the point of fine-tuning it a lot further.
However this could be handy for others who want to do the same thing, so I cleaned it up a bit, slapped a readme file on it and posted it on Github as the WordPress full site spell checker.
Check it out if you want to spell check your WordPress blog in a single run and maybe this will be good enough to get your job done. You find more info on how to set up and use it on the Github page.
I use a number of analytics tools to see how little hits I get a month and one of the things that annoyed me is that my own visits as I’m writing posts or looking up older posts also get counted. There’s a silly trick to avoid this and it’s so easy it’s stupid I didn’t think of it before.
To exclude yourself from those stats all you need to do is make sure that code doesn’t get included when you are browsing your own site. Here’s how it works.
Put your web analytics script code in a sidebar text widget. Leave the title empty if you don’t want anything to show up.
Click the “Visibility” button at the bottom of the widget panel.
In the options, choose “Hide” if: “User” is “Logged in”.
Getting more hits in case of my blog means getting more Google love (90% of my traffic comes from the G), which means I get a higher ranking and end up higher in the search results.
So why could this be?
I don’t know really. I mean, it’s not like I A/B tested this and have raw hardcore scientific data or something like that, but that doesn’t stop us from guessing and coming up with the following list!
1. Google loves my new layout and gives me a better rating cause it’s pretty. Not likely.
2. Google loves HTML5. The previous theme was ugly HTML4.
3. Displaying full posts instead of a digest on the front page gives Google more content to index and it likes that.
4. The Twenty Twelve WordPress theme is a marvel of SEO goodness and Google fell for it.
5. Google likes a minimal layout linking to very few external sources better than something that links to plenty of external sites. Maybe it thought my blog was a bit spammy before. Who knows?
I’m thinking it’s probably 2, 3 and 5 that are doing the trick, but still I can’t be sure.
But apparently your site layout really matters judging from the stats.
The update went live in week 28. Below you can see that in the weeks before the update, I was maxing out around 150 hits a week. Afterwards, It started reached over 200.
The monthly stats show the same thing.
Interesting isn’t it? All of that is without actually publishing a lot of new content in that period. I wonder how long this effect will last.
Stats. Geeks love em and at some point my blog was acting sluggish, and I was all like “OMG would it be that mobile plugin? Or the spam blocker? Or that one that makes it available for mobile?”.
Yep, you guessed it. A shear geek panic attack. So I head over to the virtual plugin store and checked if there was something out there to do that for me. Yep, having the computer do stuff for you. Another one of those things geeks love.
Enter P3, the Plugin Profiler.
After a quick profile test (takes about 5 minutes) it presents you with pretty pie and line charts telling you how long it took for your pages to load (average is less than a second, which is nice), which plugins are slowing you down and how many database queries were launched (56 on average, wow).
To give you an idea of what that looks like without the pretty pie charts, here’s some plain old text output.
WordPress Plugin Profile Report
Report date: July 24, 2012
Theme name: Evening Red (based on Sandbox)
Pages browsed: 11
Avg. load time: 0.7966 sec
Number of plugins: 23
Plugin impact: 54.10% of load time
Avg. plugin time: 0.4310 sec
Avg. core time: 0.3161 sec
Avg. theme time: 0.0474 sec
Avg. mem usage: 19.95 MB
Avg. ticks: 4,232
Avg. db queries : 56.27
Margin of error : 0.0021 sec