While update: Fatal error: Call to undefined function

Thank you for bringing this to my attention.

This happens only, when FA is disabled during the update attempt, right? I'm puzzled about why people disable modules during the most critical minutes of their life cycle, but apparently it happens.

I think we should be able to load forum_access.module ahead of calling the two functions in question (see #773828-6: Upgrade of disabled modules fails). That would be preferable over duplicating code (which risks to fall apart at some point). Can you try that, please?

Maybe because that is what the documentation says: http://drupal.org/upgrade/preparing-the-site: "Turn off (but do not uninstall) all modules that are not core modules".

It's also not something that one can control all the time. As I just did in an upgrade, I had copied the database and connected it to a fresh install of 6.x. When I did the basic upgrade of core modules I think it reset all the other modules as status = 0. Then I imported all contrib modules and they show up as inactive. It's easier this way anyway to find out which module might have an error. As it turns out it was forum_access.

You may want to consider not running the update unless the the module is active. That is how CCK modules and Date/Calendar do it: they display a warning (in update.php) that the update won't happen until they are activated.

Setting status=1 in the systems table worked.

Maybe because that is what the documentation says: http://drupal.org/upgrade/preparing-the-site: "Turn off (but do not uninstall) all modules that are not core modules".

That's not the end of the instructions. Wherever you look, it says to enable a contrib before updating it. Anything else would be a documentation error that needed to be fixed.

However, if you insist to try it anyway, we'll abort forum_access_update_6102() and forum_access_update_6105() if FA is disabled.

Committed to the -dev version.

Thanks for putting in that fail-safe.

I don't have as much confidence as you might have had in the users following the right procedure so as not to cause stoppage errors. If it is true that I should find such advice "wherever I look" then why is it so hard to find? Instead I can only find documentation that directs me to disable the module before running update.php. Here is another one: http://drupal.org/node/250790 (this page leaves out the part on re-enabling the module after update.php). The comments bring out the controversy since some of the commenters also insist on re-enabling the module before doing update.php, but I wouldn't go as far to claim that this advice is the definitive advice coming out of drupal.org, nor would I rely on users doing such if I was providing an update to a module.

The definitive reference is the file UPGRADE.txt in the root directory of your Drupal installation.

Based on your feedback I've created this issue: #1054248: Please fix the "Upgrading Modules" page. Please read it, especially as it relates to security.

this page leaves out the part on re-enabling the module after update.php

Of course, because re-enabling comes before update.php, as part of "reinstalling" (just like "enabling" is part of "installing"). If you find any documentation that says anything else, then please report it immediately and request correction.