Our main Teaching & Learning Centre website runs on Drupal, with extensive use of CCK, Views, Events and Signup modules. The site had been running on the Drupal 4.7, with only security patches applied. But it was starting to act up (content was suddenly not showing up), so I decided to pull everything up to the current 5.2 line, with updated modules. It’s an easy enough upgrade. When it works.
The CCK update appears to have really botched things. As in, most of our custom content types are now missing data for several of their fields. The data’s safe – I can see it in the database – but it’s not showing up when viewing or editing the nodes. Annoying.
So, my task over the next couple of days (hopefully much shorter than that) is to debug wtf went wrong, and figure out how to manually upgrade the various CCK database tables from wherever they were to where they need to be for 5.2. Fun stuff.
Also, the embedded Views have decided to go TU, so I get to debug wtf is going on there, as well.
Thankfully, I have backups of the data, so can play a bit if needed, but I need to leave the main site up and live to support workshop registrations while I fix things. It’s taken much of today to get the site to the state it’s in now. Haven’t even had a chance to check all of my feeds yet. The horrors!
I may need to dig up one of those circa-1995 “Under Construction” animated GIF images for the site in the meantime…
Update: Thanks to a tip from Webchick, I got the CCK tables manually reconstructed. All I had to do was rename the tables as per the pattern described. It looks like the 4.7 – 5.x upgrade path for CCK got really complicated, and may have been overlooked. My Drupal 4.7.7 site was fully patched, all modules were up to date, as was core. Upgrading from a fully patched 4.7.7 to 5.2 just plain didn’t work, from the perspective of CCK. Turns out it was a pretty easy fix, but still, a bit annoying. Huge thanks to Webchick for the tip. It’s amazing just how active and helpful the Drupal community is.
My last big issue is wrt embedded Views in several nodes. They appear to be ignoring arguments (but not all of the views are misbehaving, making it a bit harder to diagnose). That’s my task for today, to get the rest of the site behaving properly. Then to fix some layout issues that are unrelated to the Drupal upgrade (the UCalgary theme we had been using was a 4.7 variety, and the 5.0 variety has subtly different css, and lacks our custom stuff).
Where’s Bill Fitzgerald when you need him? He seems to be Johnny-on-the-Spot when something goes wrong with Old Faithful WordPress!
Hope you’re wearing your WordPress shirt for the next few days!
I think the problem was that I was wearing my shiny new red WordPress shirt today. Of course that’s the day Drupal acts up… If I got a Drupal shirt, my blog would blow up. Maybe I should stick to wearing Joomla or Microsoft shirts – I’d be safe then.
Never any fun.
I’ve got a half dozen or so sites running well under Drupal’s multi-site feature and am nervously contemplating an upgrade from 5.1 to 5.2. I can’t count the number of hours I’ve spent debugging Drupal installs and don’t want that total going up yet again with a “simple security upgrade”.
There’s no denying Drupal’s potential – but there are “issues”. You don’t have to step very far out of the box before the learning curve would give Hilary pause.
I’d suggest there’s a bigger issue though – the “free” in FOSS. We all know there’s no such thing as a free lunch and the next couple of days (hopefully less) you’re going to spend debugging your upgrade (and the countless hours I’ve spent tuning my installs) are further proof of that.
I’d suggest that if Drupal were a commercial product your upgrade would have truly been “easy”. Or, if not, one could be reasonably sure that someone else would be debugging the problems. Assuming, of course, the developer wants to stay in business.
Open Source is essential. “Free” makes me nervous whether it’s a CMS or an OS or anything else that’s important. “Affordable” would, in my view, be better.
Jim, Open Source isn’t the problem, nor is Drupal, nor is Free. I’m MUCH more comfortable and effective using Drupal to drive websites than I would be with a commercial CMS. To do what I need, I’d need to be using contributed plugins/modules/extensions/widgets in any commercial CMS as well, which would put me back in the same boat, but with the pleasure of paying someone to build their software.
I’m still not exactly sure what happened, but I’m positive it’s not a Drupal problem per se – the core stuff upgraded perfectly. It’s a problem with the contributed module. Whether a bug in the upgrade code, or operator error on my part (did I miss an update?), or just lacking documentation (what should the table structure look like? what do the fields and tables do? etc…)
If this was a commercial CMS, I also wouldn’t be able to go through the source code to find the answers. It might be a pain, but thankfully I have the right to find the answer, without having to cut any cheques.
“Affordable” might be worse – a low-cost, small-scale app that does a couple things well, but has all of the trappings of a commercial app (no access to source, etc…). I’ll be sticking with FOSS everywhere I can, especially on the server. Drupal for websites. WordPress for blogs and some small websites. Commercial CMS platforms don’t offer any benefits.
Sounds like it might be this: http://drupal.org/node/138978
Aside from Opera where one of its engineers actually VNC’d in to my machine to fix stuff some years ago, I never had any positive experience with paid for support. Quite the opposite.
@Jim – If Drupal were a commercial product the only part they would support is core. A pure Drupal core upgrade is just as robust.
@webchick: YES! That sound exactly like what happened! I’ll poke around with the suggested fix first thing in the AM. Thanks! Another very strong vote for the Open Source community! 🙂
@chx: agreed. Apple’s been consistently awesome wrt support for me, and I use that exclusively on the desk/laptop. Other than that, it’s pretty hit and miss in the commercial world. OmniGroup is awesome, and a small handful of others…
@Simon: exactly. And the Core upgrade went perfectly, so support wouldn’t have been needed anyway 🙂
Seems like we experienced a similar issue. If I remember correctly, we wound up not upgrading straight to 5.x … seems like we had to make sure all relevant patches were applied to CCK on 4.7 and then do module updates, and then upgrade to 5.X … then do module updates again (even the dot releases). And then we ran into some issue w/ rebuilding permissions. I can’t remember exactly, but hopefully that might help further hone in on the issue if webchick’s link doesn’t help.
Good luck!
Matt
@Webchick: thanks SO much for the tip. That solved it for me. My Drupal 4.7.7 site was fully patched, as were all modules. Looks like jumping from 4.7.7 – 5.2 is a bit bumpy if CCK is used. Thankfully, it’s a really easy fix to do in the database once upgraded. Thanks again! 🙂