Posted
by
Soulskill
on Tuesday January 19, 2010 @12:57PM
from the on-the-horizon dept.

itwbennett writes "The Drupal community has been working on Drupal 7 for two years, and there are 'hundreds of changes' to show for it, says Drupal creator Dries Buytaert in an interview with ITworld's Esther Schindler on the occasion of Drupal 7 going into Alpha test this week. Most notable for end users are 'some massive usability improvements,' says Buytaert, while site builders will see the greatest changes in the Drupal Content Construction Kit (CCK), which has been moved into the Drupal core. But one thing that hasn't changed is the not-so-easy upgrade path. 'The upgrade path for a Drupal site has never been really easy, to be honest,' Buytaert says. 'We do break backwards compatibility. It's a little bit painful because it requires all of the contributed modules — and there's 4,000-5,000 of them — to make changes.' But Buytaert doesn't think that's all bad. 'Innovation is key. Backwards compatibility limits innovation,' Buytaert contends. 'The rule we have is: We'll break the API if it makes a better API, and if it allows good innovation and progress to be made. Also: The second rule is that we'll never break people's data. We'll always provide an upgrade path for the data.'"

I stared at the headline for at least 30 seconds trying to figure out what the heck a Dries Buytaert was; figuring it was a typo. What the heck kind of new age terminology would take the verb 'dries' and throw some sort of portmanteau of 'buy' and 'alert' in there? Was this a new form of e commerce shopping cart? Ultimate "RTFS" moment, right there.

I hate to harp on someone's name (Berkely Breathed anyone?), but when I read the title, I had to reread it several times to be sure it wasn't a misprint. I kept wanting to think Dries should have been Tries and that Buytaert was the name of some new software package, thus creating:

Drupal Creator Tries Buytaert on Drupal 7

I guess those in the know understood it perfectly, but for the rest of us...

I find strange that the article talks about the upgrade path, but doesn't mention that Drupal 7 includes a modules and themes auto-update feature [drupal.org]: "Update Manager: Building on Drupal 6's Update module, which keeps site administrators informed when new module and theme releases are available, the new Update Manager module can also install and upgrade modules and themes."

Updating a Drupal site within the same major revision (ie, 6.x) is extremely easy, thanks to the auto-update features you mention.

What the article refers to as being difficult, is upgrading to an entirely new major revision (ie, going from 6.x to 7.x). This is because they tend to refine and rework APIs across major revisions which breaks a lot of modules... so you generally can't use a 6.x module with 7.x core.

Updating a Drupal site within the same major revision (ie, 6.x) is extremely easy, thanks to the auto-update features you mention.

Wrong - the auto-update feature is new to 7.x, so actual sites running 6.x (or earlier) doesn't benefit from it. Also, the new feature will only install and update modules and themes, not 'core', so I'm guessing updating core from 7.0 to 7.1 is probably going to require about as many manipulation steps as you need to go from 6.14 to 6.15. I don't have a lot of experience, but I would not say it's "extremely easy": the stable 6.x version requires you to do a lot of file and configuration manipulation just to

Wrong - the auto-update feature is new to 7.x, so actual sites running 6.x (or earlier) doesn't benefit from it. Also, the new feature will only install and update modules and themes, not 'core', so I'm guessing updating core from 7.0 to 7.1 is probably going to require about as many manipulation steps as you need to go from 6.14 to 6.15. I don't have a lot of experience, but I would not say it's "extremely easy": the stable 6.x version requires you to do a lot of file and configuration manipulation just to

Sorry, I was referring to the feature that automatically CHECKS for updates, colour codes your out-of-date modules, and provides a direct download link to the latest version (ie the Available Updates page). I would classify that as extremely easy.

the stable 6.x version requires you to do a lot of file and configuration manipulation just to go from 6.14 to 6.15 (if you follow all the recommended steps, which I did for my test site recently)

Why do you say Drupal requires a lot of file and configuration manipulation to go from 6.14 to 6.15 ? I have done this numerous times. What I did was, untar the new new php code on top of the old, run update.php, look through a list of things it was about to to do, click OK.

You are advised to put the site in "offline mode" (users can't log in to change data) while doing this, and back up your files and database before hand so you can revert, which I did. I did not have any problems though. I did it all

The new Auto Update feature will be the reason I will upgrade all four of my Drupal sites as soon as the final release of 7 comes out. I'm considering upgrading one of my less used sites to to the Alpha 7 for fun.

I just wish that getting the themes to look like "not shit" didn't require so much custom CSS editing. Something as simple as redoing the colors can be a real pain, which seems counter-intuitive when you consider how amazingly awesome the engine itself actually is.

Still, I just tarball the files I edited by hand, and diff them after each upgrade. It's the only way I have found to keep any customization intact.

I like the list you posted about the top 10, but honestly... the biggest point that should be Num

As somebody who has attempted to do this, that just isn't true. Doing a data upgrade from 5 to 6 was nearly impossible, because the Drupal data model is so open ended. It mixes standard, 'attributes as columns' with EAV data structures, and extensively serializes certain types of data.

It was easier to copy and paste it. So, I suppose technically, they didn't break my data, as they didn't actively delete it out the existing database.