Part 1 – A rant about flaws in the design concept of WordPress
This site launched on September 11, 2006.
At the time, I didn’t love the concept of running software on the server to create the site. I was also looking at this Blosxom software which generated a static site. It’s usage was a little programmer-like rather than writing-like, and WordPress promised a friendly interface for typing.
(If only Microsoft Frontpage had kept on developing…)
Running live website creation software on the server seemed like a bad idea to me. So open for all kinds of security issues, performance issues, and (as time has proved) software update issues. So much yuck for the sake of a certain type of convenience.
Note: that link to Blosxom is something I just found. It used to be at a URL like raelity.org and that seems to be some sort of copy on sourceforge. I don’t think Blosxom is updated anymore (although static site generation is becoming a thing again.)
Note: Every time I hit “Save Draft” there is a 10 second cycle of a spinning circle as I pray that it is actually saving what I wrote, followed by a slow, Slow, SLOW page reload until I can get back to typing. Yay for modern convenience!
Since this site has been around since 2006, it has all kinds of plugins installed — some still running and some disabled because they eventually caused too many other issues. All kinds of problems in WordPress were addressed with plugins. Adding tags. Adding widgets. All kinds of basic functionality. A WordPress website is a living, breathing piece of software that needs constant care and attention lest it wilt and die.
A WordPress website is a living, breathing piece of software that needs constant care and attention lest it wilt and die.
Some of the stuff has been addressed in the past in painful bits of doing things like changing the administrator account name from admin (remember when WordPress kindly made that the default (and only) way to install and then told you that having an admin account made it a lot easier for hackers to break in?) and at some point around WordPress 2.6 I had to add in by hand all the stuff for the AUTH_KEY things into the config file.
I have no idea how many security issues are left unaddressed when updating WordPress because they can’t be back-installed.
Fortunately, all my WordPress sites sit in the same hosting account — so when one is hacked, ALL are hacked. Just brilliant.
And I’d add that back in the day, WordPress forums took the “blame the victim” stance for any hacked site. If WordPress issued a security update on a Friday, you were supposed to spend the whole weekend updating your sites before a hacker used the recently publicized vulnerability to spam up your sites.
Since I’m cleaning and updating this as best as I can, the first step is going through old plugins and deleting what I can. Some of these are just gems with how old and not-updated they are.
But the lesson to be gained from looking at these is this:
Every WordPress plugin you are using will eventually be abandoned and leave you with a hot stinking mess of broken functionality and security issues. Yay!
Enjoy these blasts from the past!
Love this! The politics of plugins bitching about other plugins! That’s another thing with this endless upgrade / abandon situation.
Anyone remember the fun of Tim Thumb?
YARPP — that’s funny!
Note: I have no idea what the “Active Installations” number means in current day usage for these old plugins. How do they calculate it on plugins that haven’t been updated in a decade? And didn’t it used to show a download count for things? I don’t know…
The 4 Parts of this Series
Part 1 – cleaning out old (ancient) plugins that aren’t relevant or useful anymore
Part 2 – actually updating the database etc. inside WordPress to use https
Part 3 – updating to a modern, mobile-friendly theme
Part 4 – dealing with some robots.txt etc. plugin conflict
You must be logged in to post a comment.