Shot in the dark: Help migrating Addergoole to WordPress requested

Some time ago, I started migrating Addergoole from its old roll-your-own to a wordpress site:

However, if you look at the original table of contents (, you can see that this is a monumental project.

Is there anyone willing to be bribed with promises of future fiction to help me with this work?

Moving a page involves:

Copying and pasting it from the original page
Checking formatting – it took me a couple tries to find what worked for me
Checking for two name changes from original canon to new
Scanning the chapter for all characters and tagging them in the correct tagging format
Marking each chapter in the correct categories

As I said, it’s rather monumental, but I am drowning in long-term writing & personal projects and am not doing well at getting it done myself.


This entry was originally posted at You can comment here or there.

2 thoughts on “Shot in the dark: Help migrating Addergoole to WordPress requested

  1. I can’t help with the migration. What I can help with is a few things to avoid. I work as a system administrator, responsible for (among other things) a web server. Despite there being no active WordPress sites on the server, we see regular attempts at breaking into WordPress thrown at the server. Please note that everything I name from here down may or may not have the extension ‘.php’; consider that extension invisible for naming purposes. Based on what I’ve seen in those attempts, the following are popular attack vectors. * A thumbnail generator, which is most tellingly named ‘timthumb’, but which can also be called just ‘thumb’. * An uploader, sometimes named ‘uploadify’, but which may also be ‘uploader’ or ‘upload’. Installing an uploader mechanism within WordPress seems a bad idea in general, but as I’ve never actually run WordPress, I don’t know how viable it is to use other, non-WordPress mechanisms instead. * Blind probes at wp-admin, likely looking for default or poorly-chosen passwords. * Attempts at creating accounts through (presumably) badly-configured account creation mechanics. * Attempts at link-spamming/spamdexing in the comment areas. * Attempts at downloading the site configuration files, through presumably insufficiently restricted (or badly configured) download mechanisms. * Attempts to download archives of the whole site, presumably to pore over for vulnerabilities. I also have a list of several hundred themes and extensions that I’ve seen attack attempts on. For whoever is doing the conversion, I have some recommendations. Again, I’ve never run WordPress. Some of these may be in the “violates laws of physics” or “simple matter of programming” categories. * Run with as few extensions as possible, ideally zero. * Choose themes and extensions from well-regarded, heavily-tested sources. * If possible, change the name of wp-admin and any other administrative interfaces to something else. That something else should preferably not contain the prefix ‘wp’ or anything resembling the word ‘admin’. * Place IP restrictions on all administrative interfaces to restrict those interfaces to only those people who need access. * Disable comments outright. Failing that, restrict them to registered users (but see below). If you do have a comment section, beware of link spammers, trolls, and other abuses. * Prohibit automated user creation in the administrative interface. There are presumably a tiny handful of people — possibly only one — who need administrative or even update access to the site. Make those accounts, and then turn off the account creation mechanism. If you need to make an additional account, turn the mechanism back on, make the account, and turn it back off again. * Prohibit automated user creation in the comment area. (I hope that the commenting-user and administrative-user spaces are separate!) If you’re disabling comments, that’s easiest. Failing that, a human should review every account request. This serves two purposes. First, a time delay. Scripted attacks don’t like long delays. Introduce one, and many of them fail. Second, an actual eye on the proceedings can weed out a tremendous amount of crap. * When shifting content onto the site, avoid leaving an archive of any sort in a place where the web server can reach it. The web server doesn’t — or shouldn’t! — have access to the entire disk. Put the archive somewhere that the web server can’t get. This may mean unpacking a directory tree and then moving it into place. * Make sure that the site configuration is somewhere that the web server can’t get. * For any extension or theme you use, read the documentation carefully. It is likely that even a well-tested WordPress add-on can be configured badly. Beware of gotchas! And, a final warning. The most security-minded person at work — I’m not that person! — says of WordPress, “expect to get owned“. It’s a popular content management setup, possibly the most popular. It’s a big target, so there are a lot of bad actors trying to find holes in it. And when they do, they have a field day.

    • Wow, that’s a thorough list, thank you. It’s not my first WordPress site, and, yes, they do get a bit of spamminess. I’ll take your notes into account. Thanks!

Leave a Reply

Your email address will not be published. Required fields are marked *