MT 3.2 is a vile piece of buggy bloatware. But, before I get ahead of myself, allow me to start at the beginning...
Yesterday, I discovered Media Manager, the evolved version of BookQueueToo, which promised some pretty cool shite, with one caveat: it would only run on MT 3.2.
I had a bad feeling in my gut about installing it, but. I said to myself, "what the hell, maybe that MT zealot/employee, Anil Dash, had a point, and I was just over-reacting because of my personal, dismal experience with MT over the years." I could not have been more wrong.
One of the most frequently-touted features of the MT 3.2 beta (and, yes, I don't give a fuck that it's a beta - and you'll see why in a sec) was its supposed ease of installation, showcased in this deceptive video. Just upload the files to a server, click on any part of MT and it would do everything for you.
Indeed, a closer look at "Easiest. Upgrade. EVAR..." reveals these interesting tidbits:
Ok, I sent an email to report this, but I found that all my comments were not published when I upgraded from 3.16 to 3.2b1, with the exception of those posted by people using KeyType [sic] registration.and one from the great Jay Allen himself:[...] when I click that "Proceed to UPgrade [sic]" button I"m [sic] taken to my login page. It says my session has ended. When I try to login from there I get a 404 error.
I've tried uploading the files twice and the only ones I've left out are the cfg and the db-pass.
Now you tell us! Going on what I saw in the video, I upgraded. There was no warning in the video about not overwriting the cfg file. I assumed it was as easy as all other MT upgrades have been. Consequently, my site is screwed. I can't log in. MT Support won't help me. And I'm having to pay for a second install :-(The MT web site and associated blogs are too subtle and assume too much knowledge on the part of ALL users. Please do a better job of warning.
My fault entirely. But I think my blunder was caused at least in part by the "every one should try this" and "easiest upgrade ever" rhetoric that's alot [sic] easier to find than the important warnings.
It would probably be safer for you, at this point, to roll back to 3.17 and stay there until we have the instructions for 3.2 out and maybe even wait until the production release of 3.2.But who would I bother to look up MT woes before I had problems with a supposedly-flawless installation?
Merely uploading the files was, of course, not enough. I had to chmod 755 all the .CGI scripts again (I am quite certain this can be done programmatically, if a seamless installation is promised), after which I got this greeting:
Got an error: Bad ObjectDriver config: Your DataSource directory ('/home/mgknet/public_html/cgi-bin/mt/./db') does not exist.It turned out that I had to remove DataSource ./db from my mt.cfg file (even though it was never a problem in the past, regardless of whether I used MySQL or not, which I now do), because the Berkeley DB is no longer considered the default database. Did the installer tell me that? No, it's noted on a webpage I would never come to, unless I actually got the error message.
The early attempt to damage-control the lack of backwards-compatibility sounded benign enough:
We've now made a change which will force the user to specifically indicate which database option they want to use, rather than relying on a default assumption of BerkeleyDB. But an unresolved bug related to this change could pose some problems for those upgraders who still have an uncommented DataSource setting in their configuration file, as Movable Type may try to incorrectly use it during the upgrade process.Mhumm. Reminds me of when Microsoft jacked up all the security settings on Windows XP after SP2 so one could barely download a file without a warning - all in the service of security. What about simply prompting the user about his preferences during installation, you brainiacs?
Interestingly, two hours after the initial announcement, there was a post about the same issue, admitting that
As this most recent bug has shown, many people (perhaps the vast majority?) who upgrade Movable Type simply use their old config file. This makes sense, since we've never explicitly told people that they should do anything but that.But, oh, it's actually the user's fault!
One time I helped a friend upgrade to MT 3.1 and found that they still had a config file from MT 1.x. It was only one page long and had no explanations of any directives! He had no idea how much control over the system he was lacking.and it's even a "best practice" to "upgrade your config file," while
mt.cfg and mt-db-pass.cgi are now deprecated. Wow, it's a bug and a feature. ;)
Great, so I fix that little issue, then proceed with the "easiest upgrade ever" which fails once, and then finally succeeds after a page refresh, only when I want to access my overview page, MT pleasantly notifies me (in a tasteful-pink message box):
Can't call method "is_superuser" without a package or object reference at lib/MT/Permission.pm line 78.year/month/entry_name.php individual archive system, whereas I have a very careful sequential numbering system set up, based on the entry's ID.
There is no mention of entry ID archiving syntax in the manual, the MT forums and Google say nothing, so now I have a broken site in which I can't administer two out of the three blogs, all my archives are gone, Activity Log says "permission denied" and, of all my plugins, only the default "Nofollow" shows up in the list. Thank you, Movable Type, and thank you, Mr. Dash. You've proven your point superbly: other than being a couple of thousand files overweight, MT 3.2-whatever is a bloated piece of buggy code. But wait, you think I was fucked then? You ain't heard nuthin' yet! ;)
There is, of course, no simple downgrading from MT 3.2b2 to 3.16, since it polluted my good MT install with a shitload of MySQL tables and files. Now I have three broken blogs and a backup that has been done on May 23. Now what? Well, I played it by ear. First of all, knowing I had a complete (albeit outdated) installation of MT backed up, I dumped the mt_entry and mt_template tables into .SQL files (but, for some reason, not the mt_comment table), and then wiped my MT database clean.
The problem now was how to upload a 69MB .SQL file to the server and execute it. The CPanel backup recovery form failed, the PHPmyAdmin form also failed (whether in .GZ form or not - there were just too many lines to process). Thus, I spent the next two hours or so with PHP/MySQL cool-guy Vladimir Kim, (whose typing-tutor program, VerseQ, I am helping translate into English right now, by the way).
At any rate, he coded me a script that connected to the database and attempted to execute the query; however, yet again, because of the file's massive size, the query invariably timed out after a server-set limit of 60 seconds. By a stroke of luck, just before going to sleep, at about 6 AM, I came across a script written by some Russian guy named Alexey Ozerov, called BigDump, (yes, very funny, I know ;) It is basically a "staggered MySQL dump importer," a script that essentially bypasses "web-servers with hard runtime limit[s] and those in safe mode [by] execut[ing] only a small part of [a] huge dump and restart[ing] itself. The next session starts where the last [...] stopped."
Awesome. Props to Ozarov, too.
I was too tired and too depressed (I spent two days fixing this shit; literally, five years of my life flashed in front of my eyes in MySQL format ;) to do anything that night, but in the morning BigDump did what it promised. I could not be happier. It was then only a matter of time to upload the old MT installation (after failing to decompress a corrupted .tar.gz file generated by CPanel in WinRAR and finally succeeding by extracting the files in WinZIP), as well as the mt-static directory, chmod 755 all the .CGI scripts once again, drop the old mt_entry and mt_template tables, import the latest, much smaller .SQL queries for mt_entry and mt_template back into the database and then breathe a sigh of relief.
Lessons I learned:
a) make daily backups;
b) never trust MT's self-assured, lie-filled marketeering pies;
c) if it ain't broke, don't fix it, dammit.
I said that Six Apart is a profit and monopoly-driven (cf. LiveJournal purchase) faceless corporation pretending to be a friendly, young, hip grassroots organisation. SA values split-tongued marketing (and then later, inevitably, damage control) over content (cf. Apple, Red Hat); this position of also produces quite a bit of cognitive dissonance with regard to their tech support, on the part of their users; no one cares about your problems unless you are a paying customer, but you're welcome to use the user-to-user "support" forum, where the likelihood of finding advice on current issues is nil (but some people there do try to resolve the plethora of old or ongoing MT bugs and issues.
At any rate; MT is no longer humble enough to be free of simple, yet annoying, bugs, "features" that are mere bugfixes, "progress that is code bloat, (cf. my beloved Microsoft), freedom is slavery and ignorance is strength - I said all this, and I still stand by my words, Mr. Dash.
What can I say? Your company's software sucked ever since version 2.661, but you have enough shallow zealotry in store to keep the entire enterprise moving forward. My heartfelt congratulations.
Why do I use MT? Because I have to, because I am a content-creator first and a blogger second; I'm tired of rebuilding shit (yeah, show me a nice way to migrate to dynamic rebuilding), I'm tired of re-learning proprietary tags that go obsolete the next day, I'm wearied by your shitty product support and surly gurus lurking the user-to-user support forums, and I'm sick of MT's bugs and SA's damage control.
Close, but no cigar.
Ever Think about moving to a CMS Such as mamboserver? It can be found at www.mamboserver.com. It's Stupid easy to used
Hey, man!
Yeah, I thought a lot about moving to a whole lot of stuff (B2, for instance), but the question in the end is: how easy is it to migrate? Then again, if Mambo does daily postings and category archiving, that's all I need. ;)
Thanks for the tip, I'll definitely check this out.