I attempted 5.x->6.x upgrade on a testing copy of my site, and got handful of errors. Attaching a patch.

- The existing single update function is a monster. Needs to be split, to finish without hitting PHP time limit.

- The attempt on set_time_limit() to unlimited won't work on many (most?) real sites, hosting accounts mostly run in safe mode.

- The code enables two modules dependent on privatemsg, without ensuring that privatemsg is enabled (6.x core run updates of disabled modules too!). Quite a few upgrade tutorials tell to disable contributed modules, then enable one-by-one. This way, we get into a state, where privatemsg is disabled, but still the checkbox on modules page is grayed-out due to dependency of (force-enabled) sub-modules.

- The code around transforming old folders into tags throws warnings, and imports all tags as empty-named. There are two problems: db_fetch_array / db_fetch_object mismatch, and extra space (syntax error) after COUNT in the query.

- Final cleanup attempts to drop 'privatemsg_block_user' table, even if that does not exist.

With the fixes (attached patch) the update works for me. But the tags part probably needs more changes (I believe this is being discussed somewhere else?), because the old folders were private (per user), and now a mix of all these is exposed to all users as tags. Plus, no old messages appear to be tagged according to their old folder-location?

As a sidenote, I'm not much excited about all the massive changes - to me it looks like turning a serious mail feature into a chatroom :-/ Especially that, when a message is sent, the message-writting form re-appears; that's like a call to spam people. But this is of course matter of taste. Seems like I need to delay upgrade of my real site yet another half a year, too.

CommentFileSizeAuthor
privatemsg-update.patch5.17 KBJirkaRybka

Comments

naheemsays’s picture

I don't think it is a good idea to break the upgrade function into multiple chunks as done here as each invdividual chunk could still go over the php execution time limit.

If need be, the correct approach is to use the batch api as used is some other upgrade patches.

berdir’s picture

The problematic thing is to change these functions now.

"Never renumber update functions.", from http://api.drupal.org/api/function/hook_update_N/6

JirkaRybka’s picture

Hmm, the renumbering is perhaps a problem related to the fact, that privatemsg is now doing development (i.e. in fact a wild -dev version) after RC release. I was confused by this, and wasted two days attempting to get the (I thought) "almost stable" RC release to work. The upgrade patch is a by-product of that, but now I'm more inclined to wait half a year, and/or go on my site with custom-hacked upgrade, because Batch API is not my friend yet, and my time is quite limited.

I also had an idea of renumbering backwards (i.e. 5990 to 6000), which is ugly, but works and shouldn't break anything. It's also easier to troubleshoot, when split up.

The other parts (apart from splitting) still apply, I think (?)
Edit: Not rolling a patch "minus splitting", unable to test that, sorry.

naheemsays’s picture

Status: Needs review » Needs work

Setting back to needs work as the only realistic way that the patch will go in is if its still in the same update, but is refactored to use the batch api.

For most people, this is not a problem or can be worked around in some way.

fortis’s picture

Version: 6.x-1.x-dev » 6.x-1.0-rc4

Excuse, I badly speak in English, but your help is very necessary to me.

I have seen your message: http://drupal.org/node/410374

When you did upgrade privatemsg 5.x-> 6.x all messages were saved?

privatemsg you used what versions?

berdir’s picture

Status: Needs work » Closed (duplicate)