Upgrading from Drupal 6 to Drupal 7
I have noticed on a few occasions that when upgrading from Drupal 6 to Drupal 7 when running update.php things seem to go alright with the first update.php. However, if you execute update.php again you'll have update items that did not complete and will not complete until you fix the code. In particular there are some db_insert() queries that will fail due to duplicate entries for the data being inserted. I have found these in both modules/system/system.install and modules/block/block.install. The simplest resolution to these is to modify those files and wrap the insert with a try {} catch() {} block similar to shown in the api documentation[1] except when you catch the event you need to continue on. [1] http://api.drupal.org/api/drupal/includes%21database%21database.inc/group/da... -- Earnie -- https://sites.google.com/site/earnieboyd
On Thu, May 10, 2012 at 2:11 PM, Earnie Boyd <earnie@users.sourceforge.net> wrote:
I have noticed on a few occasions that when upgrading from Drupal 6 to Drupal 7 when running update.php things seem to go alright with the first update.php. However, if you execute update.php again you'll have update items that did not complete and will not complete until you fix the code. In particular there are some db_insert() queries that will fail due to duplicate entries for the data being inserted. I have found these in both modules/system/system.install and modules/block/block.install. The simplest resolution to these is to modify those files and wrap the insert with a try {} catch() {} block similar to shown in the api documentation[1] except when you catch the event you need to continue on.
[1] http://api.drupal.org/api/drupal/includes%21database%21database.inc/group/da...
Another thing I find on occasion is an error indicating the 'language' field in the node table doesn't have a default. Going to the DB and supplying a default resolves the issue but is that the correct thing to do? I do not have the locale module enabled so there is only the default or undefined language. I am at a loss at trying to find an issue that might exist already for this at issues/drupal. Does anyone know of one that might be a good fit for this? -- Earnie -- https://sites.google.com/site/earnieboyd
Earnie, that sounds like what 7.8 was supposed to fix. There was a long issue on the core queue about it. Nancy Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.
________________________________ From: Earnie Boyd <earnie@users.sourceforge.net> To: support@drupal.org Sent: Thursday, May 10, 2012 4:42 PM Subject: Re: [support] Upgrading from Drupal 6 to Drupal 7
On Thu, May 10, 2012 at 2:11 PM, Earnie Boyd <earnie@users.sourceforge.net> wrote:
I have noticed on a few occasions that when upgrading from Drupal 6 to Drupal 7 when running update.php things seem to go alright with the first update.php. However, if you execute update.php again you'll have update items that did not complete and will not complete until you fix the code. In particular there are some db_insert() queries that will fail due to duplicate entries for the data being inserted. I have found these in both modules/system/system.install and modules/block/block.install. The simplest resolution to these is to modify those files and wrap the insert with a try {} catch() {} block similar to shown in the api documentation[1] except when you catch the event you need to continue on.
[1] http://api.drupal.org/api/drupal/includes%21database%21database.inc/group/da...
Another thing I find on occasion is an error indicating the 'language' field in the node table doesn't have a default. Going to the DB and supplying a default resolves the issue but is that the correct thing to do? I do not have the locale module enabled so there is only the default or undefined language. I am at a loss at trying to find an issue that might exist already for this at issues/drupal. Does anyone know of one that might be a good fit for this?
-- Earnie -- https://sites.google.com/site/earnieboyd -- [ Drupal support list | http://lists.drupal.org/ ]
Ok, well, it still exists in 7.14. :( I'll try to dig up the closed issue. Thanks, Earnie On Thu, May 10, 2012 at 7:12 PM, Ms. Nancy Wichmann <nan_wich@bellsouth.net> wrote:
Earnie, that sounds like what 7.8 was supposed to fix. There was a long issue on the core queue about it.
Nancy Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.
________________________________ From: Earnie Boyd <earnie@users.sourceforge.net> To: support@drupal.org Sent: Thursday, May 10, 2012 4:42 PM Subject: Re: [support] Upgrading from Drupal 6 to Drupal 7
On Thu, May 10, 2012 at 2:11 PM, Earnie Boyd <earnie@users.sourceforge.net> wrote:
I have noticed on a few occasions that when upgrading from Drupal 6 to Drupal 7 when running update.php things seem to go alright with the first update.php. However, if you execute update.php again you'll have update items that did not complete and will not complete until you fix the code. In particular there are some db_insert() queries that will fail due to duplicate entries for the data being inserted. I have found these in both modules/system/system.install and modules/block/block.install. The simplest resolution to these is to modify those files and wrap the insert with a try {} catch() {} block similar to shown in the api documentation[1] except when you catch the event you need to continue on.
[1] http://api.drupal.org/api/drupal/includes%21database%21database.inc/group/da...
Another thing I find on occasion is an error indicating the 'language' field in the node table doesn't have a default. Going to the DB and supplying a default resolves the issue but is that the correct thing to do? I do not have the locale module enabled so there is only the default or undefined language. I am at a loss at trying to find an issue that might exist already for this at issues/drupal. Does anyone know of one that might be a good fit for this?
-- Earnie -- https://sites.google.com/site/earnieboyd -- [ Drupal support list | http://lists.drupal.org/ ]
-- [ Drupal support list | http://lists.drupal.org/ ]
-- Earnie -- https://sites.google.com/site/earnieboyd
Earnie and All, About three weeks ago I upgraded a 6 site site to 7.12 and it was a REAL bear. When Drupal runs into a problem during update.php it abandons the update process. You aren't done until, either via drush or the UI on the update.php screen you see that there are no more updates to perform. I ran into all the issues that Earnie talked about. I actually started over at one point when I found an issue which documented that when you clean out all old node revisions so that the number of rows in the node table and the number of rows in the the node_revisions table are the same, you significantly reduce the errors. The module to help you with that is revision_deletion <http://drupal.org/project/revision_deletion>. Here is a long thread on: http://drupal.org/node/1176186 Some other sticking points I ran into: Some CCK fields upgrade better than others. Leave yourself lots of time. Here is just one example. I had a text field with a select list in which the choices were say: - cat - dog - mouse It wasn't a key|label thing. I guess implicitly the key and label were the same. Using D7 CCK for upgrading that field, it was converted into the new "List (text)" field type with the data structure of: - 1|cat - 2|dog - 3|mouse which was fine.... for any new nodes created. But existing data was not editable. Looking in the database, the labels were still present. CCK converted the data structure but didn't go into the database to replace the labels with the keys it had added. I was using that field as a views argument and that was totally broken. The solution was converting that field *while the site was still in D6* to use a select list with the key|label (e.g. 1|cat) structure. Upon upgrade it worked great. Of course, it is much more efficient if you know this before you upgrade than after; this solution requires that you abandon your current upgrade and start over. *Imagecache*. Abandon your presets and start over. I wasted A LOT of time trying to get them to migrate and nothing worked. Save yourself some time and abandon them. Even if you were to successfully migrate them, you'd still have to reselect them in views that make use of them. *Views.* You need to go into every single display you have in every single view you have and look for missing handlers or other errors. I'm forgetting the details now, but at one point errors from a display that I wasn't using caused problems. Sounds weird, I wish I had the details. I can tell you that after I systematically went through every single display on every single view and got rid of all the errors (typically by assigning an existing handler to a missing one), a lot of problems went away. But think prep: before you upgrade, go through your Views and delete what you don't need. The documentation for upgrading is weak. And that's not to mention that the tools themselves for upgrading could be significantly improved. It's open source, It's a drag, but I'm not blaming anyone. I could certainly help out with the documentation and hope to do so after I finish a very overdue job that I'm working on now (same job as described in this post). Shai On Fri, May 11, 2012 at 7:44 AM, Earnie Boyd <earnie@users.sourceforge.net>wrote:
Ok, well, it still exists in 7.14. :( I'll try to dig up the closed issue.
Thanks, Earnie
On Thu, May 10, 2012 at 7:12 PM, Ms. Nancy Wichmann <nan_wich@bellsouth.net> wrote:
Earnie, that sounds like what 7.8 was supposed to fix. There was a long issue on the core queue about it.
Nancy Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.
________________________________ From: Earnie Boyd <earnie@users.sourceforge.net> To: support@drupal.org Sent: Thursday, May 10, 2012 4:42 PM Subject: Re: [support] Upgrading from Drupal 6 to Drupal 7
On Thu, May 10, 2012 at 2:11 PM, Earnie Boyd <earnie@users.sourceforge.net> wrote:
I have noticed on a few occasions that when upgrading from Drupal 6 to Drupal 7 when running update.php things seem to go alright with the first update.php. However, if you execute update.php again you'll have update items that did not complete and will not complete until you fix the code. In particular there are some db_insert() queries that will fail due to duplicate entries for the data being inserted. I have found these in both modules/system/system.install and modules/block/block.install. The simplest resolution to these is to modify those files and wrap the insert with a try {} catch() {} block similar to shown in the api documentation[1] except when you catch the event you need to continue on.
[1]
http://api.drupal.org/api/drupal/includes%21database%21database.inc/group/da...
Another thing I find on occasion is an error indicating the 'language' field in the node table doesn't have a default. Going to the DB and supplying a default resolves the issue but is that the correct thing to do? I do not have the locale module enabled so there is only the default or undefined language. I am at a loss at trying to find an issue that might exist already for this at issues/drupal. Does anyone know of one that might be a good fit for this?
-- Earnie -- https://sites.google.com/site/earnieboyd -- [ Drupal support list | http://lists.drupal.org/ ]
-- [ Drupal support list | http://lists.drupal.org/ ]
-- Earnie -- https://sites.google.com/site/earnieboyd -- [ Drupal support list | http://lists.drupal.org/ ]
Thanks for the information Shai. I'll keep this under advisement. Fortunately I'm not using CCK but I do use Views. I'll check out the revisions_deletion module you mentioned and review the thread. By the way, the default for the language column in the node table should be 'und'. Earnie On Fri, May 11, 2012 at 8:32 AM, Shai Gluskin <shai@content2zero.com> wrote:
Earnie and All,
About three weeks ago I upgraded a 6 site site to 7.12 and it was a REAL bear.
When Drupal runs into a problem during update.php it abandons the update process. You aren't done until, either via drush or the UI on the update.php screen you see that there are no more updates to perform.
I ran into all the issues that Earnie talked about. I actually started over at one point when I found an issue which documented that when you clean out all old node revisions so that the number of rows in the node table and the number of rows in the the node_revisions table are the same, you significantly reduce the errors. The module to help you with that is revision_deletion. Here is a long thread on: http://drupal.org/node/1176186
Some other sticking points I ran into: Some CCK fields upgrade better than others. Leave yourself lots of time. Here is just one example. I had a text field with a select list in which the choices were say:
cat dog mouse
It wasn't a key|label thing. I guess implicitly the key and label were the same. Using D7 CCK for upgrading that field, it was converted into the new "List (text)" field type with the data structure of:
1|cat 2|dog 3|mouse
which was fine.... for any new nodes created. But existing data was not editable. Looking in the database, the labels were still present. CCK converted the data structure but didn't go into the database to replace the labels with the keys it had added. I was using that field as a views argument and that was totally broken.
The solution was converting that field while the site was still in D6 to use a select list with the key|label (e.g. 1|cat) structure. Upon upgrade it worked great. Of course, it is much more efficient if you know this before you upgrade than after; this solution requires that you abandon your current upgrade and start over.
Imagecache.
Abandon your presets and start over. I wasted A LOT of time trying to get them to migrate and nothing worked. Save yourself some time and abandon them. Even if you were to successfully migrate them, you'd still have to reselect them in views that make use of them.
Views.
You need to go into every single display you have in every single view you have and look for missing handlers or other errors. I'm forgetting the details now, but at one point errors from a display that I wasn't using caused problems. Sounds weird, I wish I had the details. I can tell you that after I systematically went through every single display on every single view and got rid of all the errors (typically by assigning an existing handler to a missing one), a lot of problems went away. But think prep: before you upgrade, go through your Views and delete what you don't need.
The documentation for upgrading is weak. And that's not to mention that the tools themselves for upgrading could be significantly improved. It's open source, It's a drag, but I'm not blaming anyone. I could certainly help out with the documentation and hope to do so after I finish a very overdue job that I'm working on now (same job as described in this post).
Shai
On Fri, May 11, 2012 at 7:44 AM, Earnie Boyd <earnie@users.sourceforge.net> wrote:
Ok, well, it still exists in 7.14. :( I'll try to dig up the closed issue.
Thanks, Earnie
On Thu, May 10, 2012 at 7:12 PM, Ms. Nancy Wichmann <nan_wich@bellsouth.net> wrote:
Earnie, that sounds like what 7.8 was supposed to fix. There was a long issue on the core queue about it.
Nancy Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.
________________________________ From: Earnie Boyd <earnie@users.sourceforge.net> To: support@drupal.org Sent: Thursday, May 10, 2012 4:42 PM Subject: Re: [support] Upgrading from Drupal 6 to Drupal 7
On Thu, May 10, 2012 at 2:11 PM, Earnie Boyd <earnie@users.sourceforge.net> wrote:
I have noticed on a few occasions that when upgrading from Drupal 6 to Drupal 7 when running update.php things seem to go alright with the first update.php. However, if you execute update.php again you'll have update items that did not complete and will not complete until you fix the code. In particular there are some db_insert() queries that will fail due to duplicate entries for the data being inserted. I have found these in both modules/system/system.install and modules/block/block.install. The simplest resolution to these is to modify those files and wrap the insert with a try {} catch() {} block similar to shown in the api documentation[1] except when you catch the event you need to continue on.
[1]
http://api.drupal.org/api/drupal/includes%21database%21database.inc/group/da...
Another thing I find on occasion is an error indicating the 'language' field in the node table doesn't have a default. Going to the DB and supplying a default resolves the issue but is that the correct thing to do? I do not have the locale module enabled so there is only the default or undefined language. I am at a loss at trying to find an issue that might exist already for this at issues/drupal. Does anyone know of one that might be a good fit for this?
-- Earnie -- https://sites.google.com/site/earnieboyd -- [ Drupal support list | http://lists.drupal.org/ ]
-- [ Drupal support list | http://lists.drupal.org/ ]
-- Earnie -- https://sites.google.com/site/earnieboyd -- [ Drupal support list | http://lists.drupal.org/ ]
-- [ Drupal support list | http://lists.drupal.org/ ]
-- Earnie -- https://sites.google.com/site/earnieboyd
participants (3)
-
Earnie Boyd -
Ms. Nancy Wichmann -
Shai Gluskin