Earnie and All,<br><br>About three weeks ago I upgraded a 6 site site to 7.12 and it was a REAL bear.<br><br>When Drupal runs into a problem during update.php it abandons the update
 process. You aren&#39;t done until, either via drush or the UI on the 
update.php screen you see that there are no more updates to perform.<br><br>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 <a href="http://drupal.org/project/revision_deletion">revision_deletion</a>. Here is a long thread on: <a href="http://drupal.org/node/1176186">http://drupal.org/node/1176186</a><br>
<br>Some other sticking points I ran into:<br>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:<ol><ul>
<li>cat</li><li>dog</li><li>mouse</li></ul></ol>It wasn&#39;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 &quot;List (text)&quot; field type with the data structure of:<br>
<ul><li>1|cat</li><li>2|dog</li><li>3|mouse</li></ul><p>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&#39;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. <br>
</p><p>The solution was converting that field <i>while the site was still in D6</i> 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.</p>
<p><b>Imagecache</b>.</p><p>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&#39;d still have to reselect them in views that make use of them.<br>
</p><p><b>Views.</b></p><p>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&#39;m forgetting the details now, but at one point errors from a display that I wasn&#39;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&#39;t need.</p>
<p>The documentation for upgrading is weak. And that&#39;s not to mention that the tools themselves for upgrading could be significantly improved. It&#39;s open source, It&#39;s a drag, but I&#39;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&#39;m working on now (same job as described in this post).<br>
</p><p>Shai<br></p><br><div class="gmail_quote">On Fri, May 11, 2012 at 7:44 AM, Earnie Boyd <span dir="ltr">&lt;<a href="mailto:earnie@users.sourceforge.net" target="_blank">earnie@users.sourceforge.net</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ok, well, it still exists in 7.14. :(  I&#39;ll try to dig up the closed issue.<br>
<br>
Thanks,<br>
Earnie<br>
<div class="HOEnZb"><div class="h5"><br>
On Thu, May 10, 2012 at 7:12 PM, Ms. Nancy Wichmann<br>
&lt;<a href="mailto:nan_wich@bellsouth.net">nan_wich@bellsouth.net</a>&gt; wrote:<br>
&gt; Earnie, that sounds like what 7.8 was supposed to fix. There was a long<br>
&gt; issue on the core queue about it.<br>
&gt;<br>
&gt; Nancy<br>
&gt; Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King,<br>
&gt; Jr.<br>
&gt;<br>
&gt; ________________________________<br>
&gt; From: Earnie Boyd &lt;<a href="mailto:earnie@users.sourceforge.net">earnie@users.sourceforge.net</a>&gt;<br>
&gt; To: <a href="mailto:support@drupal.org">support@drupal.org</a><br>
&gt; Sent: Thursday, May 10, 2012 4:42 PM<br>
&gt; Subject: Re: [support] Upgrading from Drupal 6 to Drupal 7<br>
&gt;<br>
&gt; On Thu, May 10, 2012 at 2:11 PM, Earnie Boyd<br>
&gt; &lt;<a href="mailto:earnie@users.sourceforge.net">earnie@users.sourceforge.net</a>&gt; wrote:<br>
&gt;&gt; I have noticed on a few occasions that when upgrading from Drupal 6 to<br>
&gt;&gt; Drupal 7 when running update.php things seem to go alright with the<br>
&gt;&gt; first update.php.  However, if you execute update.php again you&#39;ll<br>
&gt;&gt; have update items that did not complete and will not complete until<br>
&gt;&gt; you fix the code.  In particular there are some db_insert() queries<br>
&gt;&gt; that will fail due to duplicate entries for the data being inserted.<br>
&gt;&gt; I have found these in both modules/system/system.install and<br>
&gt;&gt; modules/block/block.install.  The simplest resolution to these is to<br>
&gt;&gt; modify those files and wrap the insert with a try {} catch() {} block<br>
&gt;&gt; similar to shown in the api documentation[1] except when you catch the<br>
&gt;&gt; event you need to continue on.<br>
&gt;&gt;<br>
&gt;&gt; [1]<br>
&gt;&gt; <a href="http://api.drupal.org/api/drupal/includes%21database%21database.inc/group/database/7" target="_blank">http://api.drupal.org/api/drupal/includes%21database%21database.inc/group/database/7</a><br>
&gt;&gt;<br>
&gt;<br>
&gt; Another thing I find on occasion is an error indicating the &#39;language&#39;<br>
&gt; field in the node table doesn&#39;t have a default.  Going to the DB and<br>
&gt; supplying a default resolves the issue but is that the correct thing<br>
&gt; to do?  I do not have the locale module enabled so there is only the<br>
&gt; default or undefined language.  I am at a loss at trying to find an<br>
&gt; issue that might exist already for this at issues/drupal.  Does anyone<br>
&gt; know of one that might be a good fit for this?<br>
&gt;<br>
&gt; --<br>
&gt; Earnie<br>
&gt; -- <a href="https://sites.google.com/site/earnieboyd" target="_blank">https://sites.google.com/site/earnieboyd</a><br>
&gt; --<br>
&gt; [ Drupal support list | <a href="http://lists.drupal.org/" target="_blank">http://lists.drupal.org/</a> ]<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; [ Drupal support list | <a href="http://lists.drupal.org/" target="_blank">http://lists.drupal.org/</a> ]<br>
<br>
<br>
<br>
--<br>
Earnie<br>
-- <a href="https://sites.google.com/site/earnieboyd" target="_blank">https://sites.google.com/site/earnieboyd</a><br>
--<br>
[ Drupal support list | <a href="http://lists.drupal.org/" target="_blank">http://lists.drupal.org/</a> ]</div></div></blockquote></div><br>