Rantings, mostly…

I have just unchecked the option of, “Users must be registered and logged in to comment.”

Let’s see how well Spam Karma does it job now.

After publishing my previous post on how much I love Spam Karma, I got to thinking, I don’t believe any new spam beyond that point had been removed.

Or rather, no comments period seemed to be coming through.

So the first thing I did was see if I could register a user name and post a comment.

…the e-mail never came to inform me of my password.

I killed all tables, and reset the default factory settings pertaining to Spam Karma and all of a sudden, users are registering, and already there is a comment to the previous post.

I can’t help but think that Spam Karma may have gotten bogged down with all the logs it was keeping.

I have since changed the settings to basically clean up after itself after a relatively short period of time.  Keeping logs no longer than 2 weeks old for example.

So, if you experience any problems with this plug-in, try giving that a go.

I was checking my server’s logs today, and noticed that in the past few days hits have jumped dramatically.  So much so that well, I am thinking about adding all that Google-ish stuff to you know, make me a 1/10 of a penny per click and all that jazz.

Not bad though, almost 10,000 hits last month.  Don’t know why… most of my content sucks (OK, arguably all of it sucks).

Seriously though, it seems to me that people just *love* to attempt to insert spam comments.  What is so funny, is that most of these *bots* actually pass CAPTCHA tests.  Ooo, spooky!

As of this post, 67,727 spam comments have been “eaten.”  If you run WordPress I highly suggest you check out Spam Karma 2.

In inspecting the file even further, I see that buried at the end of the document are several unmoderated comments, comments that were blacklisted, and even some comments that were never approved because Akismet banned them!

This just goes to show the level of standards that WordPress supposedly adheres to when two plug-ins, written by the same author, don’t even play nicely together.

I imagine if that could be resolved, it *might* inevitably result in a smaller file.  Not whilst, the original wp-db-backup gzips the backup, but a smaller file nonetheless.

Again, I still this solution, currently, as useless.

“WordPress Export will create an XML file for you to save to your computer. The format, which is called a WordPress eXtended RSS or WXR file, will contain your posts, comments, custom fields, and categories.”

Custom fields, huh?  Then where are my links, Spam Karma tables, blacklisted domains, IPs and whitelist tables?  They sure the hell aren’t in the XML file.  This therefore brings me back to the conclusion that the resultant XML file will *always* be larger than the gzip’d SQL alternative, because the links table, and post2cat could be considered “core” files.

Being wholly unimpressed with the implications of a purely XML backup option for my databases, I sought further options.

Oh wait, you cannot believe how moronic a solution like backing up an RDBMS to XML is?  Neither can some other people.

Firstly, let’s discuss the specifics of an XML backup solution.  Or better yet, let’s look at the size of an exported SQL file in comparison to its XML equivalent.

I chose to backup *all* tables relating to my WordPress installation, excluding Spam Karma’s blacklist, and spam entries logs.  They exceed 80 Megabytes in case you are wondering why.

So, I am left with a gzip’d SQL file containing *EVERYTHING* needed to fully restore my WordPress blog.  That means, all my author’s, subscriber’s information, all their comments, and all of my posts and comments, including categories and related tags.

The file is a whopping 234 Kilobytes.  The XML file is 1,620 Kilobytes (1.6 Megabytes roughly).

To be fair, let’s go ahead and gunzip (decompress) the SQL file.  OK, now we have a file 1,163 Kilobytes (1.1 Megabytes roughly).  Still 457 Kilobytes less than the XML option, that’s almost a half a megabyte!

Here is the kicker though.  The XML export option backs up *only* core WordPress tables.  There is no option to add additional tables, thereby limiting the effectiveness of the XML backup solution.  In fact, I retract calling it a solution.

The SQL file on the other hand, contains all the relevant information to create anew, rebuild, restore, or share with another RDBMS.  Granted you may need to run a conversion on the storage engine to insure compatibility, but this is a trivial item in and of itself.

The XML file contains WordPress-specific code, and I am sure anyone bothering to read this understands the dilemmas raised from proprietary standards.  Also, the XML file is cluttered with markup, whereas the SQL contains relevant field data type and values only.

Granted, this may become a full-fledged backup solution, but I don’t see it happening anytime soon.  XML as a storage solution is simply not a mature technology.  The closest thing I have seen to XML as a backup is Runtime’s DriveImage XML.

1.  Matt Mullenweg/Automattic will most likely never listen to reason and provide options to backup whichever tables the user sees fit.

2.  I wonder which brave soul is going to write the ridiculously regressive “WordPress WXR/XML to SQL” plug-in.  Or other such application: “to Blogger,” “to TypePad,” hell, even “to Habari.”  I bet Skippy would just love that one.

3.  I wonder which slightly less brave soul is going to add to the mess, kiss Mullenweg’s arse, and add the aforementioned items for him.  Seeing as how if it is in development, Mullenweg’s code release cycle will dictate it takes far much more time than it should.

Some of the politics that the egomaniacal “#1 most important Matt in the world” religiously lives by can be seen in this post by Scott Merrill, er… Skippy.

In fact, it is in part due to this “Autocrattic” imperialism that we, as loyal WordPress users have been deprived an ingenious programmer, and author of *several* well known WordPress plug-ins.

As a side note, I have had issues with DreamHost before, but all in all have been more than satisfied with them.  One thing that I can say about them is that they are Nazis when it comes to security risks and updates.

If there is a problem with *anything* to do with any of their One-Click installs, versions of whatever server-side technology, vulnerabilities in kernels… *anything*… they are on it.

Despite having the fanciful XML export feature, DreamHost, by default in it’s WordPress 2.2 One-Click install still offers Skippy’s original wp-db-backup 1.7.

As far as I can tell, the one and only vulnerability to ever be reported (at least publically), and the solitary bug it had, are both patched in the version DreamHost has.

If it’s good enough for DreamHost, it’s definitely good enough for me.

Of course, Skippy has discontinued this, and several other plug-ins, so some may find a better alternative in the new maintainer, Austin Matzko or an entirely separate plug-in altogether.

A note on the first one though, it does not support gzip’ing the resulting SQL as far as I can tell.  That is a definite no-no in my book.  Another reason why I won’t be upgrading.

For those of us who recently installed WordPress 2.2, get to it again people.

WordPress 2.2.1 has officially been released as of an hour ago.

This upgrade has some *very* serious issues addressed in it, not the least of which is an SQL injection security flaw, and a flaw found in PHPMailer.

You can read more about the upgrade, the fixed bugs, and the vulnerabilities addressed at the following link.

http://wordpress.org/development/2007/06/wordpress-221/