the upgrade.txt that comes with 5.8 mentions the following: 4. Disable contributed modules and switch to a core theme (Bluemarine or Garland). I seem to recall I had problems way back around 5.3 doing this. I disabled CCK I think it was and tables such as content_type_XYZ in my db were eliminated, together with the content in them. Am I remembering correctly? So this is keeping me from disabling any contributed modules until I'm sure about this as I don't want to lose data. does this ring a bell with anyone? Neil
I seem to recall I had problems way back around 5.3 doing this. I disabled CCK I think it was and tables such as content_type_XYZ in my db were eliminated, together with the content in them. Am I remembering correctly?
Can't say if it's correct or not, but I don't actually change themes nor disable mods when I do a 'minor' update of core Drupal. It may be risky, but I have never had a problem. But yes, disabling some modules will IIRC remove tables and therefore data. Either way, always do the whole process on a spare site, or at the very least, backup your files and DB first. :) Good luck
Quoting Fred Jones <fredthejonester@gmail.com>:
I seem to recall I had problems way back around 5.3 doing this. I disabled CCK I think it was and tables such as content_type_XYZ in my db were eliminated, together with the content in them. Am I remembering correctly?
Can't say if it's correct or not, but I don't actually change themes nor disable mods when I do a 'minor' update of core Drupal. It may be risky, but I have never had a problem. But yes, disabling some modules will IIRC remove tables and therefore data.
In D5 at least disabling modules does not remove tables. You have to use the Uninstall function for that and the module has to provide the hook.
Either way, always do the whole process on a spare site, or at the very least, backup your files and DB first. :)
Yes, always do a backup before changing your environment. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
there are only some modules that can lose association with taxonomy, for example if you are using simplenews, if you deactivate the module, you should associate the newsletter type of content with the right category in taxonomy in order to work properly. anyway, be careful if you have patched some core module, for example to suppress some menu voices, don't forget to re-patch it when you have updated your system.
In D5 at least disabling modules does not remove tables. You have to use the Uninstall function for that and the module has to provide the hook.
Disabling modules anyhow can certainly lose data. Even without uninstalling. I disabled the Ads module on a site once, I believe, and data was lost which we were forced to restore (what we could) from backups. Fred
On Thu, 2008-07-10 at 21:04 +0200, Fred Jones wrote:
In D5 at least disabling modules does not remove tables. You have to use the Uninstall function for that and the module has to provide the hook.
Disabling modules anyhow can certainly lose data. Even without uninstalling. I disabled the Ads module on a site once, I believe, and data was lost which we were forced to restore (what we could) from backups.
I had a similar experience. tables had to be restored by hand in mysql. the key is to make a backup of the database and all the important files in the drupal directory in the webroot path, then make the upgrade on a testsite, and then, if everything works, copy it back to the working site. I must add that I am not an authoritative voice, just a simple user, but thats how it worked for me last time after having gone through a botched upgrade. If you create a test site for the upgrade process first, make the upgrade work there, you can do it without the disabling of modules which can be tricky. once it works on the test site you can copy the whole thing back. probably there are other ways, but it worked for me without the disabling business good luck armin
Fred
Quoting Fred Jones <fredthejonester@gmail.com>:
In D5 at least disabling modules does not remove tables. You have to use the Uninstall function for that and the module has to provide the hook.
Disabling modules anyhow can certainly lose data. Even without uninstalling. I disabled the Ads module on a site once, I believe, and data was lost which we were forced to restore (what we could) from backups.
If it does the module is broken and needs a bug report issued. I've not found this case. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Disabling modules anyhow can certainly lose data. Even without uninstalling. I disabled the Ads module on a site once, I believe, and data was lost which we were forced to restore (what we could) from backups.
If it does the module is broken and needs a bug report issued. I've not found this case.
I believe I made a mistake. The case where I lost data I think was actually that I uninstalled a module. You are correct, because simply disabling module does run any code, so how could any data be lost? It indeed should be the case that disabling modules will NOT lose any data. My mistake for saying otherwise. Fred
Quoting Fred Jones <fredthejonester@gmail.com>:
Disabling modules anyhow can certainly lose data. Even without uninstalling. I disabled the Ads module on a site once, I believe, and data was lost which we were forced to restore (what we could) from backups.
If it does the module is broken and needs a bug report issued. I've not found this case.
I believe I made a mistake. The case where I lost data I think was actually that I uninstalled a module.
Thanks for the honesty. Yes uninstalling the module should remove the table and any associated variable table settings. But that depends on the coding in the module, it isn't Drupal automatic.
You are correct, because simply disabling module does run any code, so how could any data be lost?
It indeed should be the case that disabling modules will NOT lose any data.
I'm glad that we agree.
My mistake for saying otherwise.
As long as mistakes such as these are confirmed as mistakes then no harm has been done. I'm glad to here that what you had said wasn't true. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
I found that disabling modules during minor upgrades causes data loss consistently under specific circumstances, during earlier updates (e.g. 5.2, 5.3). I observed that any module-supplied node type would drop all the data in any assigned CCK fields when disabling & upgrading. For example, if one had a simplenews node with an "editor" cck field attached to it, one would lose all "editor" information. However, the basic simplenews node data would be kept, as would any cck fields attached to standard nodes. Only the combo of cck + module-supplied-node-type seemed to cause problems. Fortunately, I make backups before upgrading and restored each time and did the upgrade without disabling modules and it worked fine. After 5.5, I think, I gave up attempting to disable modules and have had no problems since. Brian On Mon, Jul 14, 2008 at 3:12 AM, Fred Jones <fredthejonester@gmail.com> wrote:
Disabling modules anyhow can certainly lose data. Even without uninstalling. I disabled the Ads module on a site once, I believe, and data was lost which we were forced to restore (what we could) from backups.
If it does the module is broken and needs a bug report issued. I've not found this case.
I believe I made a mistake. The case where I lost data I think was actually that I uninstalled a module.
You are correct, because simply disabling module does run any code, so how could any data be lost?
It indeed should be the case that disabling modules will NOT lose any data.
My mistake for saying otherwise.
Fred -- [ Drupal support list | http://lists.drupal.org/ ]
-- Brian Choc Technology Manager Teaming for Technology Colorado 2505 18th St. Denver, CO 80211 P: 303.561.2377, F: 303.455.6462 http://www.t4tcolorado.org
Yes, that was my recollection from a few months ago. It was definitely CCK related (which, I believe doesn't have a uninstall function: very few modules seem to) and I certainly lost data from merely disactivating, not uninstalling. Needless to say, I learnt my lesson and won't be doing the same again. Neil ----- Original Message ----- From: Brian Choc To: support@drupal.org Sent: Monday, July 14, 2008 7:00 PM Subject: Re: [support] upgrading to 5.8. One question. I found that disabling modules during minor upgrades causes data loss consistently under specific circumstances, during earlier updates (e.g. 5.2, 5.3). I observed that any module-supplied node type would drop all the data in any assigned CCK fields when disabling & upgrading. For example, if one had a simplenews node with an "editor" cck field attached to it, one would lose all "editor" information. However, the basic simplenews node data would be kept, as would any cck fields attached to standard nodes. Only the combo of cck + module-supplied-node-type seemed to cause problems. Fortunately, I make backups before upgrading and restored each time and did the upgrade without disabling modules and it worked fine. After 5.5, I think, I gave up attempting to disable modules and have had no problems since. Brian On Mon, Jul 14, 2008 at 3:12 AM, Fred Jones <fredthejonester@gmail.com> wrote: >> Disabling modules anyhow can certainly lose data. Even without >> uninstalling. I disabled the Ads module on a site once, I believe, and >> data was lost which we were forced to restore (what we could) from >> backups. >> > If it does the module is broken and needs a bug report issued. I've > not found this case. I believe I made a mistake. The case where I lost data I think was actually that I uninstalled a module. You are correct, because simply disabling module does run any code, so how could any data be lost? It indeed should be the case that disabling modules will NOT lose any data. My mistake for saying otherwise. Fred -- [ Drupal support list | http://lists.drupal.org/ ] -- Brian Choc Technology Manager Teaming for Technology Colorado 2505 18th St. Denver, CO 80211 P: 303.561.2377, F: 303.455.6462 http://www.t4tcolorado.org ------------------------------------------------------------------------------ -- [ Drupal support list | http://lists.drupal.org/ ]
Quoting Brian Choc <bchoc@t4tcolorado.org>:
I found that disabling modules during minor upgrades causes data loss consistently under specific circumstances, during earlier updates (e.g. 5.2, 5.3). I observed that any module-supplied node type would drop all the data in any assigned CCK fields when disabling & upgrading. For example, if one had a simplenews node with an "editor" cck field attached to it, one would lose all "editor" information. However, the basic simplenews node data would be kept, as would any cck fields attached to standard nodes. Only the combo of cck + module-supplied-node-type seemed to cause problems.
So what you're indicating is that modules implementing hook_node_info will loose the node_type row and thusly the nodes of that type. This would then be a critical bug in the core base system. Or perhaps your incident is related to only one of the CCK fields modules and then the critical bug would lie with that module. Disabling a module should not under any circumstance cause data to be removed. That said, I do not disable modules either when upgrading from Drupal version 5.x to Drupal version 5.y. However, that isn't the documented method and the documented method needs to work. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Interesting discussion. I also never disable modules when upgrading. I have never lost data when I disabled them originally, but as far as I remember some configurations of CCK were lost. But that was in the early days of cck and Drupal 4.7. Since then I never disabled modules and never had problems (always with backup ready). Its also quite annoying when you have more modules uploaded than enabled to have to write down which modules are needed for each installation. it could be good to hear from somebody who always does it right and disables all modules before upgrading that it has never caused problems, just to add some counterweight to this thread. Hans www.koba.be 2008/7/14, Earnie Boyd <earnie@users.sourceforge.net>:
Quoting Brian Choc <bchoc@t4tcolorado.org>:
I found that disabling modules during minor upgrades causes data loss consistently under specific circumstances, during earlier updates (e.g. 5.2, 5.3). I observed that any module-supplied node type would drop all the data in any assigned CCK fields when disabling & upgrading. For example, if one had a simplenews node with an "editor" cck field attached to it, one would lose all "editor" information. However, the basic simplenews node data would be kept, as would any cck fields attached to standard nodes. Only the combo of cck + module-supplied-node-type seemed to cause problems.
So what you're indicating is that modules implementing hook_node_info will loose the node_type row and thusly the nodes of that type. This would then be a critical bug in the core base system. Or perhaps your incident is related to only one of the CCK fields modules and then the critical bug would lie with that module. Disabling a module should not under any circumstance cause data to be removed.
That said, I do not disable modules either when upgrading from Drupal version 5.x to Drupal version 5.y. However, that isn't the documented method and the documented method needs to work.
Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
-- [ Drupal support list | http://lists.drupal.org/ ]
-- Hans Rossel KOBA Webdevelopment Kerkstraat 228 9050 Gent 09-334.52.60 0472-79.32.16 www.koba.be info@koba.be
I will do some testing too on a test site. I began this thread because I'd read in the upgrade.txt in 5.8 that "officially", you should disactivated all contributed modules before upgrading and I raised an eyebrow, remembering I'd had some issues with CCK by disactivating it and having content_type_X tables disappear. It is possible I'm remembering badly but I've heard CCK mentioned by others in this thread and seeing as it's almost a core module in itself, it's vital we track this problem down, should it exist. Neil ----- Original Message ----- From: "KOBA | Hans Rossel" <info@koba.be> To: <support@drupal.org> Sent: Monday, July 14, 2008 10:14 PM Subject: Re: [support] upgrading to 5.8. One question.
Interesting discussion.
I also never disable modules when upgrading. I have never lost data when I disabled them originally, but as far as I remember some configurations of CCK were lost. But that was in the early days of cck and Drupal 4.7. Since then I never disabled modules and never had problems (always with backup ready). Its also quite annoying when you have more modules uploaded than enabled to have to write down which modules are needed for each installation.
it could be good to hear from somebody who always does it right and disables all modules before upgrading that it has never caused problems, just to add some counterweight to this thread.
Hans www.koba.be
2008/7/14, Earnie Boyd <earnie@users.sourceforge.net>:
Quoting Brian Choc <bchoc@t4tcolorado.org>:
I found that disabling modules during minor upgrades causes data loss consistently under specific circumstances, during earlier updates (e.g. 5.2, 5.3). I observed that any module-supplied node type would drop all the data in any assigned CCK fields when disabling & upgrading. For example, if one had a simplenews node with an "editor" cck field attached to it, one would lose all "editor" information. However, the basic simplenews node data would be kept, as would any cck fields attached to standard nodes. Only the combo of cck + module-supplied-node-type seemed to cause problems.
So what you're indicating is that modules implementing hook_node_info will loose the node_type row and thusly the nodes of that type. This would then be a critical bug in the core base system. Or perhaps your incident is related to only one of the CCK fields modules and then the critical bug would lie with that module. Disabling a module should not under any circumstance cause data to be removed.
That said, I do not disable modules either when upgrading from Drupal version 5.x to Drupal version 5.y. However, that isn't the documented method and the documented method needs to work.
Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
-- [ Drupal support list | http://lists.drupal.org/ ]
-- Hans Rossel KOBA Webdevelopment Kerkstraat 228 9050 Gent 09-334.52.60 0472-79.32.16 www.koba.be info@koba.be -- [ Drupal support list | http://lists.drupal.org/ ]
Quoting "Neil: esl-lounge.com" <neil@esl-lounge.com>:
I will do some testing too on a test site. I began this thread because I'd read in the upgrade.txt in 5.8 that "officially", you should disactivated all contributed modules before upgrading and I raised an eyebrow, remembering I'd had some issues with CCK by disactivating it and having content_type_X tables disappear.
It is possible I'm remembering badly but I've heard CCK mentioned by others in this thread and seeing as it's almost a core module in itself, it's vital we track this problem down, should it exist.
Especially since CCK fields are moving to core for D7[1]. Thanks Neil, it would be good to know where this bad behavior exists. http://drupal.org/node/265604 Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
I think it's better to distinguish between release upgrades, security upgrades and module upgrades (upgrades for individual modules). On the big upgrade (release upgrade) from 4.7 to 5.x, of course, the best practice was to disable all modules, basically due to the objective of making sure the upgrade to a new release was working, and also because modules had to be completely rewritten for the new release. Also, the idea was to enable each contributed module one by one, in order to know what when wrong, if it did, and when it went wrong: specifically with which module lay the problem. And doing a database dump each time, you can always go back to a working scenario. If you leave all modules enabled in a release upgrade you are almost definitely going to have problems and worse, you are not going to know where the problems come from. Imagine someone upgrading from Drupal 5.x to Drupal 6.x; this is a migration, not an upgrade. Many things are going to have to be pinpointed and taken care of. With security releases, I do not disable modules and have never had any problem. On 4.7.x to 5.x see my article at http://awebfactory.com.ar/node/223 (based on webchick's video from Lullabot) Victor Kane http://awebfactory.com.ar On Mon, Jul 14, 2008 at 6:14 PM, KOBA | Hans Rossel <info@koba.be> wrote:
Interesting discussion.
I also never disable modules when upgrading. I have never lost data when I disabled them originally, but as far as I remember some configurations of CCK were lost. But that was in the early days of cck and Drupal 4.7. Since then I never disabled modules and never had problems (always with backup ready). Its also quite annoying when you have more modules uploaded than enabled to have to write down which modules are needed for each installation.
it could be good to hear from somebody who always does it right and disables all modules before upgrading that it has never caused problems, just to add some counterweight to this thread.
Hans www.koba.be
2008/7/14, Earnie Boyd <earnie@users.sourceforge.net>:
Quoting Brian Choc <bchoc@t4tcolorado.org>:
I found that disabling modules during minor upgrades causes data loss consistently under specific circumstances, during earlier updates (e.g. 5.2, 5.3). I observed that any module-supplied node type would drop all the data in any assigned CCK fields when disabling & upgrading. For example, if one had a simplenews node with an "editor" cck field attached to it, one would lose all "editor" information. However, the basic simplenews node data would be kept, as would any cck fields attached to standard nodes. Only the combo of cck + module-supplied-node-type seemed to cause problems.
So what you're indicating is that modules implementing hook_node_info will loose the node_type row and thusly the nodes of that type. This would then be a critical bug in the core base system. Or perhaps your incident is related to only one of the CCK fields modules and then the critical bug would lie with that module. Disabling a module should not under any circumstance cause data to be removed.
That said, I do not disable modules either when upgrading from Drupal version 5.x to Drupal version 5.y. However, that isn't the documented method and the documented method needs to work.
Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
-- [ Drupal support list | http://lists.drupal.org/ ]
-- Hans Rossel KOBA Webdevelopment Kerkstraat 228 9050 Gent 09-334.52.60 0472-79.32.16 www.koba.be info@koba.be -- [ Drupal support list | http://lists.drupal.org/ ]
Quoting Victor Kane <victorkane@gmail.com>:
Imagine someone upgrading from Drupal 5.x to Drupal 6.x; this is a migration, not an upgrade. Many things are going to have to be pinpointed and taken care of.
If the "best path" of disabling modules loses data regardless of migration or upgrade it is still an issue that needs resolved. So far, CCK fields is the only problem reported in this thread. Disabling modules is not supposed to cause the loss of data; that is the job of the uninstall process where it warns about the loss. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
On Tue, Jul 15, 2008 at 9:02 AM, Earnie Boyd <earnie@users.sourceforge.net> wrote:
Quoting Victor Kane <victorkane@gmail.com>:
Imagine someone upgrading from Drupal 5.x to Drupal 6.x; this is a migration, not an upgrade. Many things are going to have to be pinpointed and taken care of.
If the "best path" of disabling modules loses data regardless of migration or upgrade it is still an issue that needs resolved. So far, CCK fields is the only problem reported in this thread. Disabling modules is not supposed to cause the loss of data; that is the job of the uninstall process where it warns about the loss.
Absolutely, this is a priority.
Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
-- [ Drupal support list | http://lists.drupal.org/ ]
On Thu, 10 Jul 2008 16:25:15 +0100 "Neil: esl-lounge.com" <neil@esl-lounge.com> wrote:
the upgrade.txt that comes with 5.8 mentions the following:
4. Disable contributed modules and switch to a core theme (Bluemarine or Garland).
I seem to recall I had problems way back around 5.3 doing this. I disabled CCK I think it was and tables such as content_type_XYZ in my db were eliminated, together with the content in them. Am I remembering correctly?
So this is keeping me from disabling any contributed modules until I'm sure about this as I don't want to lose data.
does this ring a bell with anyone?
Giving a look to the patch in spite of just copying the new version over the old one makes much easier to decide how to upgrade. When DB schema changes are involved it may be worth to make the site inaccessible for a while during the update. The websites I'm babysitting with the modules I'm using didn't have any problem from 5.7->5.8. I just had to revert a couple of changes I did on core to live better with postgresql and sessions, but that's not terrible if you've your site under any rcs. -- Ivan Sergio Borgonovo http://www.webthatworks.it
participants (9)
-
Armin Medosch -
Brian Choc -
Earnie Boyd -
Fred Jones -
Ivan Sergio Borgonovo -
KOBA | Hans Rossel -
Neil: esl-lounge.com -
Simone Dal Maso -
Victor Kane