Spontaneous ∂erivation

Note: this only applies to people who don’t use WordPress.com, but have their own hosting and their own WordPress installations.

WordPress blogs are notorious for falling prey to massive automated attacks, anywhere from scanning WordPress versions to exploit known security holes for that version, to scraping error information in dictionary attacks against the login box, to passing specially formulated URLs that cause bad PHP code execution.

If you do nothing else, please install Secure WordPress, go to its options page, and check a lotta boxes, and click “save changes”. Although I suggest a few more measures at the end of this post.

Here are what the options mean, and whether you want to tick the box or not (usually you do, but not always, such as if you’re using third-party software like MarsEdit, ScribeFire, or Windows Live Writer):

Error-Messages…

This removes the error message WordPress gives on a bad login. You’ll still know if you failed to log in (as in WordPress will simply present you with the login box again), but scripts and hackers won’t know specifically why the log in failed—they don’t know if it’s the user login or the user password that failed.

If a hacker does know, for instance, that the password failed but the user login was valid (because WordPress by default gives very specific login errors), they will know to proceed with dictionary attacks rather than keep attempting to guess logins.

Plus there’s certain kinds of security holes that can be exploited if you know the login of at least one user for sure.

Amusingly, many people put more thought into their user login than their password.

You should tick this box.

WordPress Version…

If you ever do a view-source of your blog page, at the top of the source you will see something like this:

<meta name="generator" content="WordPress 4.8" />

By default, WordPress kindly tells every script and hacker out there its version, the better for them to scan thousands of URLs and generate attacks loving tailored for each WordPress version’s security holes.

If you tick this box, Secure WordPress will replace the WordPress version in all publicly viewable pages, as well as in your RSS feed (a less popular but as legit place to retrieve your WordPress install’s version) with a random 4-digit number.

Do not listen to WordPress’s plea to leave that line in for stats. Tick this box for your safety.

WordPress Version in Backend…

Only really necessary for installations that have multiple non-administrative users registered, and which don’t trust their users to not, for instance, accidentally leave a completely crackable password which will allow a script access to the WordPress version through non-publicly viewable pages (i.e., the administrative section of WordPress).

I think you should tick this box regardless. A user with admin privileges will still see the WordPress version.

index.php…

Many web hosts already block the listing of directories, because directory listings are a popular way for crackers to discover specific URLs (like CGI scripts) they can use for attacks.

Tick this box regardless, because it’s a good habit to get into.

Really Simple Discovery….

Really Simple Discovery (RSD) is metadata that WordPress generates in the header of every publicly served file that conveniently tells remote programs which special URLs to use when posting/deleting/editing/etc posts. This is used by third-party blogging software, which depend on knowing these URLs in order to allow you to post from outside WordPress.

Of course, it also allows hackers to find the special URLs to use when posting/deleting/editing/etc posts.

If you really love your third-party external editor—and they range from the WordPress iPhone app to ScribeFire and MarsEdit and even more—then you want to keep this box unchecked.

If you always post from inside WordPress anyways, tick this box.

Windows Live Writer…

Windows Live Writer is also a third-party external editor, but it doesn’t use RSD. Instead, Windows Live Writer uses a special link generated by some blogging platforms, like WordPress.

If you don’t use Windows Live Writer, tick this box.

Core Update…

These days, WordPress displays a little message in yellow atop of administrative screens when a new version is available and you should upgrade. Upgrading is dead simple these days, so there’s no excuse.

But if you want to keep the WordPress version extra-hidden from non-administrative users even when an upgrade is needed, tick this box. Administrative users will still see this rather important message.

Plugin Update…

Similar to the “Core Update” option, with similar recommendations as to tick or not.

Theme Update…

Similar to the “Core Update” and the “Plugin Update” options, with similar recommendations as to tick or not.

WP Scanner…

If you tick this box and then follow the directions about editing your theme temporarily, you can use wpscan to find possible exploits in your system. I’ve seen themes revealed to be really stupid about what they allowed in the search box, for instance. WordPress themes are more powerful than themes in most blogging platforms, which can both rock (in the normal case) and suck (in terms of security exploits).

If wpscan runs and mentions anything about search queries, and you don’t know how to fix your WordPress theme to not allow that sort of thing, switch WordPress themes.

Block bad queries…

This helps protect your blog from malformed URLs and queries that exist as exploits whether you seal everything up or not. Jeff Star created this code in the wake of an extremely bad period, quite recent, of a very malicious worm, and Secure WordPress now incorporates it.

Totally tick this box. There is almost no reason not to. In fact, I can’t think of a reason not to.

There are more recommendations for securing your WordPress install out there, but the Secure WordPress plugin covers many of the vital ones, though not all of them.

Some More Advice

1. I wish I knew how a plugin like Secure WordPress would automate this, but it’s probably not possible. And that is to make sure that the ‘admin’ user no longer uses ‘admin’ as their login. It’s a default that WordPress sets up, and one that hackers of course know about.

2. When you download a WordPress theme, please check its source code for anything suspicious looking before you install it. This is so important, as if you install a hacked WordPress theme, you’ve undermined all your security regardless of what you’ve done.

   Fortunately, many if not all hacks are obvious even to the non-technical eye. Here is a post from Chaos Laboratory that covers what hacked themes look like.

3. Always update your WordPress version. For serious. These days WordPress will, if you tell it to, automatically download and install a new version of itself. It will even tell you when to do this, which is a much better state of affairs than things used to be.

4. Always make sure your plugins are up-to-date, for they are also a source of many security exploits in the past—some plugins, like some themes, are that powerful.

   In fact, WordPress as of version 2.9 provides a very easy way to upgrade multiple plugins at the same time—under “Tools”, click on “Upgrade”, and you’ll see a section full of ticky boxes. Once you select which plugins to upgrade (usually ticking All), and hit the submit button, your site will automatically be taken into maintenance mode (people reading your blog will only see a maintenance message), all your plugins upgraded, and then your site taken back out of maintenance mode.

If you’ve decided to work with your own WordPress installation, rather than WordPress.com, there are some simple plugins and steps it would be wise to take care of.

I’m going to focus on the few plugins you’ll actually need (and that will probably end up in a version of WordPress some day, but at the moment they aren’t). These suggestions tend to be (a) simple and (b) extremely stable. They’re least likely of most comparable plugin selections to break on WordPress upgrades due to their very direct (yet adequate) approaches to the jobs they do.

Note: This article isn’t for WordPress.com users, since WordPress.com has fixed plugins.

WP-DBManager

This is the simplest and least problematic of the various WordPress backup plugins out there. It’s never gone wrong for me and has never eaten up all the space at my hosting provider, and it always reliably emails me an archive of the backup to GMail, thus giving me a reliably backed up list of archives.¹

While WP-DBManager is limited to a backup of the database, and doesn’t include all your WordPress files (such as plugin files or theme files), nevertheless this is the most important part of backing up, since plugins can be reinstalled but plugin settings, which are part of your database, will already be saved.

You’ll find its settings in its own Database menu item (not part of the normal Settings group).

You’re most interested in the DB Options sub-menu item.

On the DB Options page, the default settings for Paths is likely good, because most hosting providers provide sane default paths for the various executables, and the plugin will create directories it needs.

At the bottom of the DB Options page is the Automatic Scheduling section. You’re most interested in the frequency of automated backups (I suggest: Every 1 days, GZip yes) and the email address to send them to.

Simple Feed Copyright

This results in a copyright notice being added to each entry in your RSS feed. It’s hardcoded to say “Copyright © [current year] [Blog name]“, which is usually enough. It has no options to configure, and pretty much just works.

Secure WordPress

This will harden your WordPress installation somewhat, provide you with a few suggestions, and also can add a token for a WordPress scanner to scan your installation and add even more suggestions, although the latter currently requires you to edit your theme file’s header.php.

Its settings are available under the Settings menu, with menu item name “Secure WP”.

Its directions are very clear, which is nice. My suggestions for ticked items are below.

Explanations:

Error-Messages

This helps fight brute-force password crackers that rely on error messages to tell whether they’ve gotten in or not, and whether it’s the user name or the password that’s wrong.

WordPress Version

Many WordPress attacks look for specific WordPress versions in order to efficiently apply their cracking/hacking. This hides your WordPress version, providing it as simply a random number—by default, the version of your installation appears both in your blog’s HTML code AND in your RSS feed. “Not in admin” simply means that there isn’t a way to turn it off in the normal admin section of a WordPress blog.

index.html

Hides what plugins you’re specifically using from attackers. Again, helps prevent targeted attacks.

Really Simple Discovery

WordPress inserts extra information, by default, into the HTML of your blog, so that external blogging tools (MarsEdit, Ecto, Windows Live Writer, ScribeFire, etc) can determine your blog type.

If you’re not using these tools, check the box to turn to turn this off. (I use these tools right now, so it’s not off for me.)

Windows Live Writer

Windows Live Writer likes a special link that WordPress automatically generates, which allows it to know how to access your blog so that it can, for instance, add new posts, edit categories, delete posts, etc.

If you’re not using Windows Live Writer, check the box to turn this off.

Core Update, Plugin Update, Theme Update

For non-admin users, turns off access to these pretty much admin-level features. Really only useful if you have non-admin accounts for some reason.

WP Scanner

Allows you to temporarily add information to your blog, if you edit your theme, so that the wpscan tool has permission to scan your blog and find exploits.

General Headers and Footers

Easily injects additional HTML code in your header and footer of your entire blog. In other words, useful for tracking Javascript code, such as for Mint (add to Header section) or Google Analytics (add to Footer section).

Once installed, settings are available under Settings &rarrow; General Header, even though it does both headers and footers.

WPTouch

With this plugin installed, your iPhone visitors (and, I think Android) will have a very nice, iPhone-orientated interface to your website. Given that the iPhone can save bookmarks to the Home Screen as app-like items, this more or less eliminates the need for an iPhone app specific to your web serial.²

The options are long, but very simple and illustrated and explained (!) which is something of a rarity in the WordPress plugin world.

I suggest adding an icon of your own, and selecting particular pages for the iPhone readers to see (they all default to off), and then the rest generally takes care of itself automatically.

While WPTouch is generally very stable, and the plugin authors handle upgrades relatively well for a complex plugin, it’s less stable than the rest. But I think it’s nice enough for a mention as a very-nice-to-have plugin for a web serial.

1. And with GMail filters, I can just reroute them into a folder and have them skip the inbox, although I like simply seeing them in my inbox and manually archiving them myself, just to make sure that a backup was made at all. [↩]
2. A nasty detail of the iPhone App Store is that it randomly censors applications that can display naughty words. An iPhone-friendly website view, on the other hand, avoids the App Store. This is the main reason why there are so many ebook reading apps in the App Store that are hard-coded for specific books, with words censored as appropriate. [↩]

Last time I talked about the advantages and disadvantages of a WordPress.com blog versus an individual WordPress install as a platform for your web serial.

This time I’m focusing on the basic settings and plugins a web serial would need/want, with special discussion of a WordPress.com versus an individual WordPress install. Web serials have somewhat different needs from a normal blog.

If you’re planning on your own WordPress installation, this article assumes that either you or your web hosting has already set up your WordPress install.

Both WordPress.com and Individual Installations

Basic Settings

On the left-hand menu of the dashboard for your particular blog, there’s a link to basic settings. It’ll take you to the settings page, and also expand the sub-menu items for Settings.

You’re automatically put into General Settings first. On the side menu under Settings will now display various links to the settings pages, the most important of which we’ll discuss below individually.

From here, I’m going to focus on the necessary options, and leave the other options for you to play with.

Don’t forget to click the save button at the bottom of each settings page to save your settings.

General Settings

Important fields: Blog Title, Tagline, Language, Email address, and Time Zone.

Reading Settings

Important fields: “For each article in a feed”

This is the most important RSS feed setting, I think.

If you select “Full Text”, your readers can easily read your story in their RSS feed, and you can also add your blog to Amazon’s Kindle website for subscription via Kindle. However, this a) opens you up to people who scrape RSS content, which is bad enough for a blog, but in some ways I think is worse for a web serial, b) you’ll miss out on people visiting your site, which is where your extra menus and possible ads and possible donation buttons are, c) you’ll have less control over how your story is displayed for people who read via RSS feeds (doesn’t matter for 99% of serials).

If you select “Summary”, you may annoy people who read only through RSS, and you won’t be able to use Amazon’s Kindle subscriptions. However, you also avoid the disadvantages above.

When in doubt, go with Summary; you can change it later if you want to.

(And yes, I personally prefer full text for RSS feeds, and know plenty of other people do. But while it’s very reader-friendly, it’s less writer-friendly, and most readers will visit your site directly. Plus a Summary RSS feed will still provide direct links to your individual posts.)

Discussion Settings

Important fields: “Default article settings”

I’m going to go against popular wisdom for blogs again, and suggest you turn off commenting by default. Mostly because this avoids inadvertant spoilers and avoids needing to a) moderate people, and b) kick out spam.

If you still want to host discussion separately, you can create a special post that allows comments specifically, or you can use a forum of some sort.

Appearance Settings

This is a whole ‘nother section of your WordPress administration, and it’s the easiest and most fun to play with. Select a theme, and select and rearrange widgets with drag-and-drop, and so on. Some themes allow you to set a Customer Header, which also appears in the Appearance sub-menu if your theme happens to support it (some don’t).

Most themes have a sane set of default widgets, but I suggest that you have the following:

• a Text widget, with a short blurb about your serial; it can accept arbitrary HTML, so you can include images and links. This is a good place to put a link to the very first entry of your serial so that people can follow happily along.
• a Recent Posts widget, for that omnipresent access to your most recent post.
• an Archives widget.
• another Text widget, with Paypal donation/subscription links.

WordPress.com Only

Removing Related Links From Posts

On WordPress.com, by default your posts will have an automatically generated section at the end with random “related” links that hit other blogs.

For web serials, this can be distracting. Really distracting. Turning this option off will lose you the possibility of getting your links randomly generated on other WordPress.com blog posts, but I think such links are terrible for a web serial anyways.

You can turn this off via a sub-section under Appearances, called “Extras”.

Straight-up HTML is in some ways the simplest way to kit up a little website. But on the other hand, it’s also the hardest, especially if you’re

• Making regular updates,
• Live web statistics,
• Automatic UTF-8 encoding so that typographical quotes and dashes look professional on multiple browsers,
• Automatic RSS feed generation with UTF-8 encoding,
• iPhone-special and even Android-special views of your website (and the iPhone is getting rather popular amongst SF readers),

and so on.

So a blogging platform is nice to have. WordPress¹ is one of the easiest and nicest, and even has a free site a la Blogger.com where you can set up multiple free blogs with many of the most necessary features above, though not all of them (the last, iPhone views, in particular).

If you decide to set up your own WordPress install, that’s not much harder (even John Scalzi, for quite some time, could keep up his own WordPress install without a dedicated web elf, and he’s not the most technical of writers). You can even set it up as a subset of your author website, just for your serial(s).

The future installments of this little technical-advice-for-layman-writers series, in fact, will mostly focus on WordPress as a platform.

So here are your two options, and their pros and cons: a) using WordPress.com, or b) using your own WordPress install.

WordPress.com Advantages

For the busy writer, this is the fastest way to set up a blog, with minimum fuss, the most important features, and it’s free with possible pay-for-use upgrades if you like.

Pros:

• Someone else takes care of house-keeping the WordPress software, some of the more useful plugins, the hardware, the security, the backups, and the DNS and web URLs.

• You can have your own blog addresses, ending in wordpress.com, for free. You can also have your very own domain with a paid upgrade, if you like to do so later (you can even have multiple domains point at a single blog).

• Easy set up (even easier than Blogger, I think).

• Features like live statistics, RSS feeds, commenting (which can be turned off) with spam protection, polls, etc.

• Themes you can choose from, many of which allow you to set the header image for your serial blog to give it an identity (and usually this is enough).

Cons:

• You can’t install your own plugins. This is actually nice in some ways, since it increases security, but can be limiting in other ways. For instance, no iPhone special view plugin.

• You can’t install your own themes without a pay-for upgrade.

• You can’t even edit the CSS or code of the existing themes without a pay-for upgrade.

• If you want to switch to your own hosting, it’s going to be difficult to pry domains and add redirection (no plugins, no theme editing) from the cold, cold hands of WordPress.com. This is a rather big con.

Your Own WordPress Install Advantages

Pros:

• Many hosting sites will install WordPress for you, and even upgrade it (although WordPress has added features like a one-click upgrade, which makes the already easy administration dead easy if you want to do that yourself). Some hosting companies is better at this than others.

  For instance, my hosting, EsoSoft, takes care of lotsa things like insane DNS crap, and debugging things that go wrong with my WordPress install. Their prices are reasonable, their support is great, their hosting is reliable, there is no upload/download cap, and Smart Bitches, Trashy Books uses them—and they’re a fairly high-traffic review blog. Esosoft even went out of its way to add extra servers when SMTB got a much higher than usual traffic rate.

• You can install your own plugins (including all the ones that WordPress.com provides).

• You can install and edit your own themes and their CSS.

• Ability to use your own domain without extra payment on top of the web hosting, naturally.

Cons:

• You still have more things to take care of than with a WordPress.com blog, although most hosting sites will still take care of many of these things for you. Not backups or security usually, though that’s easy enough to fix.

• Unless you’re messing around with WordPress Mu, multiple blog addresses will be annoying.

My Recommendation

If you desperately need free, use WordPress.com.

If you can spare a little bit of money, EsoSoft and your own WordPress install is a great place to be.

1. And yes, I was a WordPress skeptic for many years. [↩]

And we’re back to a non-election style for the wondrous Simple Balance theme, which is easy to style and yet still easy to configure through a set of bodacious options offered in its configuration page.

You know, I’ve been having fun contemplating Simple Balance styles for winter.

I cleared out all the widget caches¹ and reloaded the page to regenerate them all.

Total load time for the front page, all widgets, and also the WP Widget Cache writing them to disk:

86 queries. 1.314 seconds.

Total load time for the front page and just WP Widget Cache reading the widgets from disk (no individual widget cache has yet expired:

45 queries. 0.191 seconds.

The queries have pretty much been cut in half, and the load time cut down in much more than that. Sometimes the number of queries/load time increases a little, because some of the widgets have expired their cache and thus must be regenerated, but otherwise the page just loads quickly.

WP Widget Cache: made of win.

1. I’d added the new widget from Twitscoop. It’s in an iframe, and thus the executing Javascript inside doesn’t add to the load time of my page. That’s different from straight Javascript widgets, like Google Reader or the Twitter badge; the naked Javascript executes and blocks your page load. In other words, iframes rock with respect to this kind of thing—unless you need the generated HTML to match your theme, in which case, not so much. [↩]

I decided to run some speed tests, after speeding up Spontaneous Derivation. You’ll note that S∂ still has quite a few plugins enabled.

My domain has a couple other sites on it, so I decided to run a speed test on all three.

Without further ado: the contestants!

The Speed Test

We’re using iWebTool’s Website Speed Test and running the three against each other six times (since that’s the number of times the tool can be run without a paid account in an hour, and I didn’t feel like wasting more time…).

The results of each run:

Spontaneous Derivation

Size: 212.54 KB of HTML
Six Runs:

Total time (s)		Average: s/KB
2.63				0.01
2.52				0.01
1.15				0.01
1.12				0.01
1.16				0.01
1.07				0.01

Average total run time: 1.61 seconds
Average seconds per KB: 0.01 seconds

Holmesian Derivations

Size: 23.65 KB of HTML
Six Runs:

Total time (s)		Average: s/KB
0.52				0.02
0.53				0.02
0.52				0.02
0.52				0.02
0.59				0.02
0.52				0.02
0.53				0.02

Average total run time: 0.53 seconds
Average seconds per KB: 0.02 seconds

Fictional Derivations

Size: 37.94 KB of HTML
Six Runs:

Total time (s)		Average: s/KB
1.59				0.04
2.26				0.06
1.61				0.04
1.61				0.04
1.67				0.04
0.54				0.01

Average total run time: 1.55 seconds
Average seconds per KB: 0.04 seconds

Comparisons

Holmesian Derivations performed the best overall, reliably downloading in half of a second each time. Even on a KB per KB basis, it’s still only 0.2 seconds per KB. It had the least to render.

Fictional Derivations performed second best, with an average run time of 1.55 seconds. Its speed was slowest (0.4 seconds per KB), and while it had more to render, it was only 14 KB more. That’s an egregiously long time, but is probably mostly due to 10 posts versus only 5.

Spontaneous Derivation was the slowest at an average of 1.61 seconds to download. However, S∂ also had the most to render by far—nearly 9 times more than Holmesian Derivations, and 5.5 times more than Fictional Derivations. Its speed was by far the fastest—0.01 s/KB.

Conclusions

Now, this is a really informal and totally unstrict benchmark test, so conclusions are pretty fluffy to draw.

However, S∂ performed the best in terms of getting its content out, if not in terms of how much it needed to get out there. Holmesian Derivations was the trimmest, but with a worse speed than S∂.

What if S∂ was running with WP Super Cache, too? Who knows? I don’t want to try; this was mostly for fun. But realistically speaking, S∂ should have taken much longer—and it would have, were it not for WP Widget Cache.

So I will say this: WP Widget Cache rules the house when it comes to not performing expensive queries and not pulling down and re-parsing RSS XML on every single load.

Best. Plugin. Ever.

Speeding Up Your Blog

Because it’s been annoying me more than usual, I want to keep this theme because I don’t need to waste time trying to get another one up to speed, and I’m going to be on a shared host for some time to come (thank you, economic downturn).

You might not need to do this (I personally am obsessive). Indeed, it takes some time and knowledge to do some of the more serious items on this list.

General Approach

1. I killed every plugin I didn’t absolutely need, especially the ones that add more filtering execution time to my posts. They’re usually the ones with special tags/short codes.

2. I learned how to use page templates and built-in WordPress capabilities to remove more plugins and filtering.

3. WP Widget Cache is awesome. I can include some of the more expensively queried widgets (blogroll and categories) and automatically achieve caching on my RSS widgets. That cuts the number of queries my front page needs in half while keeping interesting parts around.

4. Since my RSS widgets are now cached with the WP Widget Cache, I killed every widget containing Javascript, which always hit some service remotely and never cache.

5. I removed as many plugins as possible that require cron jobs (e.g. regular executions of something or other), especially if they hit my site often (which is how WordPress cron jobs usually work).

6. I used to have redundant website metrics trackers for my site (they all tell you different things). No more; I’ve settled on Mint.¹

Below the cut: stuff I kept, stuff I dropped, detailed reasons why, and replacements if applicable. This list is long, but there are some interesting plugins listed down there.

Click here to read more →

1. For people interested in free, and who wouldn’t be, yet still want live statistics rather than Google Analytics‘ delayed statistics, look into Woopra or WordPress.com Stats (which also work for independent sites). [↩]

Some plugins don’t make the most of the new hierarchical categories in WordPress (well… new since 2.1 anyways). Most plugins that fashion their own SQL queries take only a single level of a category hierarchy into account.

For example: my blog Spontaneous Derivation, has this partial category hierarchy underneath Fantasy and SF category:

Fantasy and SF [id 1]
+-- Awards     [id 2]
+-- News       [id 3]
+-- Reviews    [id 4]

Most plugins, when asked to work on category 1, will neglect to include the posts under ids 2, 3, and 4; yet all posts in the child categories implicitly belong to the parent category 1.

Here’s how to add hierarchical category support to these plugins, under the cut.

Click here to read more →

Goodbye old Simplicity (Sd edition) theme! You were a good one.

And helloooo hot red Kindle Love.

By the way, if you’re stopping by for the first time, say from The Last Colony Pimp thread on Whatever, here are three entries’ worth of pimpery for various writers.