By permutations on

I just spent 10 hours trying to upgrade Drupal from 4.6.5 to ... well, anything current. Every time I tried to convert the database, I got zillions of errors. But when I looked at the tables, the stuff that the report said failed seemed to be there.

First I tried upgrading from 4.6.5 to 5.7. All my site content was lost - nothing displayed. This may have been related to the database error "Object of class stdClass could not be converted to string", but I'm guessing.

So I backed out of that, and tried upgrading to 4.7.11. Worse!! The site content was there, but I had these problems:

- Could not reply to comments - suddenly it's all flat commenting in reply to the original post.

- Could not figure out how to get tinymce working again, and there is no documentation.

Every single module I'd installed was changed with no backward compatibility so all my settings were lost (AdSense, for example).

It was such a nightmare that I just deleted everything and rolled back to 4.6.5.

This should not be so hard.

WHY ARE THERE SO MANY DATABASE ERRORS WHEN UPGRADING, THAT DON'T EVEN SEEM TO BE LEGITIMATE ERRORS????

WHAT'S WITH THE INABILITY TO REPLY TO COMMENTS?????

WHY WAS SUCH A HUGE MESS MADE OF TINYMCE, AND HOW DO I GET IT TO WORK AGAIN????

Comments

pwolanin’s picture

pwolanin commented

Your choice of contrib modules often will make updating easy or a real pain.

Note, you should try first making sure you can get everything working on 4.6.11 first: http://drupal.org/node/106957

If so, then try to update to 4.7.11. Note that I've recently been trying to move a site form 4.7.2 to 4.7.11, and some of the contributed modules (e.g. CCK) had changes (such as in their convention for naming content types) that broke the settings of other modules and required hours of hunting down and manually fixing them via little SQL snippets.

---
Work: BioRAFT

permutations’s picture

permutations commented

Thanks for the info.

I turned off all the user-contributed modules before upgrading. Not enough to prevent this?

What I can't figure out is all the database errors when I run upgrade.php. I don't see why I'm getting any errors in the first place, and second, the errors don't seem to be valid. I'll see an error that some field wasn't added, but when I look at the table it was added.

Any insights?

pwolanin’s picture

pwolanin commented

If you've updated already, you may see such errors. The update tries to add a field, but the field exists due to an earlier update - hence an error.

---
Work: BioRAFT

permutations’s picture

permutations commented

I did not run the database update twice. I tried running it, got a million errors, restored the database from backup and tried again (and again got a million errors).

I wish someone would answer about the database errors. I've searched on the site, and can't find anything.

I've never tried to update forum software that generated this level of errors. I'm not doing anything ununsual - it's basic installation with half a dozen user modules that I disabled before the update. Is the update program that badly written?

One possibility I've thought of is that it's detecting the module versions of my current version incorrectly (it displays this at the start of the update). But there is no way to check - or not that I can find. How do I find the module versions?

jordanka’s picture

jordanka commented

after the upgrade (where everything went ok, and I could access my site and log in) but I noticed that I can't access some modules, it gives me "you are not authorized to access this page" message.

I install the event claendar module, but when I try to add an event, I got that message. I done the upgrade not with the user 0, but I've made changes in update.php and everything went ok.

Does someone knows a solution? It has to be something with the node access, but I don't know exactly what to do.

Jordanka

jordanka’s picture

jordanka commented

finally after four days of hard work and trying different solutions (and none worked for me) I noticed that when I install new module and put it in /sites/all/modules folder (as it's stated in Drupal readme file, that custom modules and themes should be put in /sites/all/modules or /sites/all/themes folders) I got access denied when I wanted to add a task from that module.

It's really unclear to me, why when you put modules to thefolder you got access denied message, even the folder has 755 permissions. Finally I put the modules in the main modules folder in Drupal and everything worked ok.

Pretty strange. Hope this will help someone with similar problem.

Cheers,
Jordanka

permutations’s picture

permutations commented

My modules work fine under "sites/all". I just looked at the permissions, and they are 775. Try that. With 755 you're not giving write access to "Group".

I like that the 3rd-party modules and themes are no longer all mixed up with the core modules and themes. It makes it much easier to keep track.

permutations’s picture

permutations commented

I've been looking at the update.php code, and I see why the update is so incredibly messy and full of errors.

Version documentation was extremely bad through Drupal 4.6 - basically no records were kept. So the program is guessing about what needs to be updated. What a mess.

Worse, many of the previous updates were buggy, and the code tries to back them out. It's a nightmare - no wonder it never runs right. And it makes me unsure whether I should apply previous updates before later updates.

I'm used to the SMF code, which is beautiful. Drupal code is horribly obfuscated and poorly documented. How I wish I'd never started with it, but I have three years of content on the site where I installed Drupal, and I don't want to lose it.

permutations’s picture

permutations commented

I finally had to recognize I had two choices - spend hours manually updating the database (doing a clean install of Drupal and a side-by-side comparison with my updated database), or lose all my site content and move to another CMS.

I didn't want to lose my site content, so I took the time-consuming and tedious route of a record-by-record, table-by-table comparison. It took about 10 hours. Here's what I learned:

  • Most of the database errors were generated by running updates that shouldn't have been run in the first place (trying to create tables that were already there, etc.).
  • Some important changes were not made by update.php. Many field widths have been widened, and update.php did not address this at all. People who upgrade their databases from earlier versions are in danger of overflowing these variables, which can generate weird problems that are next to impossible to diagnose if you don't know what to look for.

I hope that the Drupal development team is keeping better version records now - the exact build of each module and what changed between versions - so upgrades aren't such a time-consuming nightmare.

I hope, also, that the Drupal developers will think more about backward compatibility and stop breaking things for no good reason. You have to have a good reason to change a function name - just liking the new name better is not a good reason.