Psst? Anyone there?
It appears that after a bit of technical chaos and angst that we are back. In a slight breach of protocol I’m going to spend a bit of time sending a big raspberry to the “developers” who create the wonderful weblog publishing software that we spend so much of our time using.
Take the WordPress upgrade and migration scheme. Please.
It’s not clear to me who thinks that this is a well designed process. Here is how upgrade works:
1. Replace your current install with the new install.
2. Make all of your customizations again by hand.
3. Upgrade your database and pray that something doesn’t get irreversibly destroyed.
Who thinks that this is anything but a poor retarded excuse for a technical solution?
Migration is a similar hassle. You copy everything to the new server by hand, import the database and then try to test it. And… you get redirected to your old server, which you left up until you are sure things are working. This is because the mental midgets at WordPress put some critical server configuration data in the database which causes this redirection to happen. Therefore, without hand surgery to the database, you can’t run a live and staging server at the same time while you migrate. This makes it a bit hard to test the new server.
Of course, I should not really blame WordPress, because their competition is no better, and usually worse. We switched to WordPress a while back in the first place because the previous system could not even restore itself from a native data format dump of the entire weblog. So everything is relative.
Weblog software is a strange beast. It is strange because so many relatively naive end users use the software, and yet the software itself is so bad. You really have to wonder about a software segment where every single desktop posting client is actually more painful to use than just connecting to the web server and typing in the little text areas. For example, are there any desktop clients on the Mac that let you post drafts to the server and then let you edit them conveniently with your writing partner? No? This situation is like some kind of genius level of brain damage that deserves recognition.
And speaking of the text areas: here is a plea to web developers everywhere. Stop stealing my god damned key bindings in text areas. I do not want Ctrl-e or Ctrl-p or Ctrl-a to do your pet little thing. I want them to do my pet little thing. I need those keys to act like Emacs, lest my brain melt.
Thanks for your time. More regular programming on this channel when I get done playing Fallout 3.
Welcome back!
All of the above is why I concatenate my blog together from tiny text files written in Nano/Pico. Sounds cumbersome, but seems to work pretty well, all things considered.
Let me just go ahead and ask a dumb question… Why the need for weblog software in the first place? For a relatively simple (that’s a compliment) weblog isn’t Blogger or some other hosted service just as good? Wait, I just thought of an answer. Must have something to do with the ability to place revenue-generating ads on the site? There’s no hosted solution to that either?
Thanks
At the time the hangup was wanting to use our existing domain name. I think now there are solutions to such problems, but moving the data to a hosted solution at this point would make my eyes explode.
The wordpress upgrade process is indefensibly poor. I do wish to share my current practice. See if it helps one more person.
(1) use “svn co” to install from their svn, make sure everything works as much as possible without making any file changes
(2) use “hg init” to snapshot the directory structure (or use any other distributed scm, I happen to like hg)
(3) make your file changes
(4) “hg ci” for another snapshot
At this point, the changes in (3) will be seen as modified files in svn. But you have an hg snapsot in (4). I note that the use of hg is simply to help you track what changes you’ve made. (You could have just left the changes as a bunch of modified files when doing “svn st”.)
When I have to upgrade wordpress, say because of a security problem (that feels like every other day), I do an “svn up” while praying that there will be no conflicts. 90% of the days it seems to be so and I am happy. Then I “hg ci” to snapshot.
You have to choose if you track the .svn directories in hg or not. The advantage is if you roll back using hg, your .svn will be accurate. The disadvantage is diskspace, which is cheap anyway for this amount of code.
The most important benefit is, however, when you get hacked, you know exactly what the hacked changes are. Indeed, I have a job that do an “hg st” on a regular basis and notify me if there are file changes. Here hg comes to rescue to get rid of the hacked changes quickly. I have collected a whole bunch of “tools” and “images” since deploying this.