This site jumped from Drupal 6.22 to 7.4 and is still under reconstruction. Recent updates installed Drupal 7.7 then 7.8. The remaining work is not quite a recovery from a car wreck, more like a rebuilding half a house after a partial demolition.
The site started with a range of add-on modules and themes including some custom built modules and a custom built theme. You should be able to upgrade with all the add-on modules and themes in place. The upgrade is not that easy. You first have to switch off all the add-on modules and themes, everything non core. Then you upgrade Drupal core. Then you reintroduce your add-on modules and themes one at a time.
I started this project a couple of weeks ago then went on holidays with some modules and pages broken. Converting modules from Drupal 6 to Drupal 7 is too hard. Converting content from module based content types to Field based content types is too hard. I tried several approaches and they all failed to work in a reasonable time frame. Drupal 7.4 is really only suitable for new sites or relatively simple existing sites.
When I tried to use CCK in Drupal 7.4 to create a simple content type, CCK failed completely. I could not create a content type with anything better than the default Drupal content type creation options. Drupal 7.7 fixed something and CCK started to work.
Converting Drupal 6 module based content direct to Drupal 7 CCK based content is extremely difficult because you have to make your content module work first then you lose too much information.
The best approach appears to be undocumented anywhere in Drupal.org. You have to somehow convert your module to work in Drupal 7 then transfer your module based content to the body of the content then remove the module, leaving a standard Drupal content type, then add back in the extra Fields using CCK, then move the data from the body to the extra fields. Weird.
Captcha
Update September 21. I found a change that stopped the Captcha module working. Captcha adds extra information to forms based on the form id. The contact form changed from contact_form to contact_site_form. comment_form changed to comment_node_page_form, comment_node_story_form, etc, with the content type in the middle.
IMCE
Update September 21. IMCE is dead. Trying to make IMCE work with the new Drupal 7 private image handling required using two brains, three arms, four legs, and lots of tentacles. I gave in, deleted IMCE, and installed the Inswert module, which does the same thing but in a different way. The Insert module, like most Drupal 7 modules required switching on a list of prerequisites. Insert requires the core optional Image module, which requires the core optional File module. You then have to fight a while to get everything working.
The Image module uses the Image toolkit which has JPEG compression switched on. JPEG compression is bad. Anything less than 100%
just sucks the life out of your images. The default in Image toolkit is 75% which sucks half the quality out. When you are stuck with JPEG, you have to fight hard.
I am thinking about switching off all the options in image toolkit and uploading every version of each file myself so I can guarantee quality. There must be some configuration that will let people use Insert, Image, and the Image toolkit the way you use IMCE.
After you install all the modules, you have to attach an image field to each content type then go through your thousands of Web pages manually reloading all those image files. You do not get any of the IMCE features for organising images. The whole approach is either primitive or the documentation lacks the information about how you use the combination for more than a few images.
Errors during update.php
update.php
Update.php suppresses errors in line 340:ini_set('display_errors', false);
Turn the errors on when you get the White Screen of Death in failed updates:ini_set('display_errors', true);
Forum module
The following AJAX HTTP error occurred.
HTTP Result Code: 200 Debugging information follows. Path: http://petermoulding.com/update.php?id=592&op=do StatusText: OK
ResponseText: Fatal error: Call to undefined function _update_7000_field_read_fields() in /home/example/public_html/modules/forum/forum.install on line 354
The solution is to delete the forum module then run update.php again. After you fix some other problems and run update.php successfully, reinstall the forum module then run update.php again.
Block table
After I removed the Forum module, there was the following error in the block table.
system module
Update #7004
Failed: PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'garland-book-navigation' for key 2:
UPDATE {block} SET delta=:db_update_placeholder_0 WHERE (module = :db_condition_placeholder_0) AND (delta = :db_condition_placeholder_1) ;
Array ( [:db_update_placeholder_0] => navigation [:db_condition_placeholder_0] => book [:db_condition_placeholder_1] => 0 ) in update_fix_d7_block_deltas() (line 362 of /home/example/public_html/includes/update.inc).
There are several issues raised for the block table error. I followed the suggestions from the issues. None worked. I eventually deleted everything out of the block table then ran update.php successfully. I started adding the blocks back in after the upgrade to Drupal 7 was finished.
Your home made blocks are not lost as they are stored in the block_custom table. The block table stores only the connection from a block to a region in a theme. You go through each active theme and assign the blocks back to the right regions. All the themes require allocation of the new content block. Some themes may have changes their region names to comply with the Drupal 7 standard and will require reallocation anyway. Check all the blocks in all your active themes.
contact module
The following error was reported by update.php and disappeared when I reran update.php after fixing the block table error.
Update #7002
Failed: PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'module' in 'where clause': SELECT 1 AS expression FROM {role_permission} role_permission WHERE ( (rid = :db_condition_placeholder_0) AND (permission = :db_condition_placeholder_1) AND (module = :db_condition_placeholder_2) ) FOR UPDATE; Array ( [:db_condition_placeholder_0] => 2 [:db_condition_placeholder_1] => access user contact forms [:db_condition_placeholder_2] => contact ) in contact_update_7002() (line 127 of /home/example/public_html/modules/contact/contact.install).
filter.module
The filter module has a problem that is fixed in Drupal 8 and needs a back port to Drupal 7. It might be fixed by the time you upgrade.
Configuration changes
Cron
You run periodic maintenance on your site using a utility named Cron. In Drupal 6 you could use an external cron or configure an add -on module named Poormanscron. The first releases of Drupal 7 added a security identifier for the external cron. Drupal 7.4 has Poormanscron built in. There is nothing to install or configure. Go to Administer, System, Cron, to configure the new cron service. It defaults to every 3 hours.
Creating content types
Creating a new type of content was easy in Drupal 6 using a module. The same approach is broken in Drupal 7. You can change modules to create content types using the Application Programming Interface for fields In Drupal 7 but that is broken. In Drupal 7 you are supposed to create content types using the Drupal content type creation process with the shiny new Fields feature. Unfortunately that is also broken.
There are no tutorials on creating content types by any working method because there are no working methods. There are videos on how to create content types and anyone who has tried to follow videos knows how hard it is compared to a proper tutorial. Plus videos are never corrected. You are forever stuck with the alpha version. A real tutorial can use feedback to refine the tutorial. Vidios are rarely reshot to fill out the missing parts or to correct the obsolete bits or to replace the completely incorrect bits.
So there are no usable tutorials and the various approaches fail no matter how long you waste trying to work out a usable system. Drupal 7.4 is not ready for use by anyone who wants to create a new content type.
Libraries
Some modules require external libraries of code and they go into /sites/all/libraries/. There is a page on the libraries I use.
Modules
When you are about to upgrade from Drupal 6 to 7, you can switch modules off, replace the code, then switch the module on without losing the module data. Drupal modules have a separate uninstall step that deletes the data. If you do not uninstall, the data stays in in the database.
The update step may change the data and the change may fail. Backup your data before an update. If the update fails and leaves the data corrupt, you may have to restore. You can reduce the pain of failed updates by updating one module at a time, especially modules where the Drupal 7 version is still in development.
Some modules can be deleted at any time while others should be deleted after you switch your Drupal 6 site offline. The general process is outlined on the Modules page. my experience with various modules is also listed on the Modules page.
Speed
Drupal 7 is slower than Drupal 6 when presented with the same resources. this site responds slower when building a fresh Web page. Anonymous users will see the same speed because the pages are cached. Everyone who is logged in will see a fresh page for every request and will see the tiny increase in delay before delivering the first content on a page.
Some pages are faster to deliver all the content. In some cases it is better processing within Drupal 7 but most cases of faster pages are the result of having some modules switched off. When I have all the modules reinstated, some of the longer pages will slow down.
Drupal 7 introduces a higher level of cache granularity and that will make some pages faster. Blocks and other components can be cached separate to the page. If everything works together in the right way, a fresh page can save time by reusing some blocks from cache. This will not work for every module because some Drupal 7 modules are simply conversions of the Drupal 6 equivalents. Modules require a major rewrite to make full use of the extra features in Drupal 7. Performance will evolve as people learn how to best use the new Drupal 7 features.
Drupal 7 core modules use three times more memory than the Drupal 6 core. my site has ten times more memory than is needed for Drupal 7. Memory is not the problem. Extra database activity is the problem. If your Web host has the database separate from the Web server, you could spend weeks tuning the Web server without seeing an improvement. Look for a Web hosting company that provides good support for your database and is willing to look at the database performance.
Themes
Before you upgrade, switch your Web site offline then change the theme to the default Garland theme. Upgrade with Garland in place then introduce your updated custom theme then switch back online.
Some themes and modules have to be deleted after they are switched off because the code in the Drupal 6 version creates problems in Drupal 7. You can test the Drupal 7 version of your theme in a test site and load the new version of your theme when loading Drupal 7.4. make sure your test site uses Drupal 7.4 because there were some changes in Drupal between Drupal 7.0 and 7.4.
- Facebook Like
- Google Plus One
- Log in or register to post comments