Drupal Upgrade
more_horiz
close

on 10th September 2013 / by webmaster
We had recently worked with a client of ours to help port the Drupal 6 version of the Moneris Payment Gateway module for Drupal to Drupal 7. Moneris is a popular payment gateway in Canada. The upgraded module has been submitted in an issue under the Moneris issue queue - https://drupal.org/node/1276770. Once it is tested and verified by the community the maintainer will be pushing the code to the repository. The upgraded module currently does not support recurring subscriptions. If there are users who are looking to get recurring payment support enabled for Moneris in Drupal 7 we will be happy to help with the development and maintenance of the same. We would require that you allow us to contribute these changes back to Drupal.org :) Drupal Drupal 6 Drupal Modules Drupal Upgrade Drupal 7 Drupal Contributions Drupalgive Leave a reply Your email address will not be published. Required fields are marker *
more_horiz
close

on 30th May 2013 / by Anoop John
The last version of Drupal 5 was released on Aug 11, 2010 and the maintenance of Drupal 5 was stopped on Jan 5, 2011. The current stable branch of Drupal (as of March 2013) is Drupal 7 and the previous version Drupal 6 will be maintained till the release of Drupal 8 which is expected to happen towards the end of 2013 or early 2014. Drupal 7 will be maintained till the release of Drupal 9 which should happen probably in 2015. Given that Drupal 6 maintenance will likely be discontinued by end of 2013 it would not make any sense to upgrade Drupal 5 sites to Drupal 6. There are two real choices open for sites which are still in Drupal 5. One is to go ahead and upgrade the site to Drupal 7 and the other is to upgrade the site to Drupal 8 once Drupal 8 is released. If you are upgrading to Drupal 7 you would still have to take the data in the site through the Drupal 5 -> Drupal 6 -> Drupal 7 upgrade pathway. The custom code and custom theme need not go through Drupal 6 but can be upgraded straight to Drupal 7. If you are upgrading to Drupal 8 then you could start working on a Drupal 8 upgrade and plan for an upgrade by the time Drupal 8 is released. Given that you have waited this long it might be alright to wait a few more months for Drupal 8 release. Once that upgrade is done you could possibly wait till Drupal 10 release (perhaps by 2016) for the next upgrade. The data on the site would have to go through Drupal 5 -> Drupal 6 -> Drupal 7 -> Drupal 8 upgrade pathways. Custom modules and custom themes can be upgraded straight to Drupal 8. If you are not sure about which version of Drupal you should upgrade your site to do get in touch with us and we can help you make that decision for you. Do note that this is a time sensitive article written in March 2013 and the opinions cited in this article may not be relevant after a few months from writing this article. The concepts would still hold though. Contact us to get our recommendation on what version of Drupal should you be upgrading your site to. Drupal Drupal 5 Drupal Upgrade Leave a reply Your email address will not be published. Required fields are marker *
more_horiz
close

on 21st May 2013 / by Anoop John
Drupal 6 will be maintained till the release of Drupal 8. Drupal 8 release is expected to happen towards the end of 2013. The current stable branch Drupal 7 will be maintained till the release of Drupal 9 (probably 2015). If you are running a production site on Drupal 6 then you will probably have to start looking at upgrading the site by the end of this year. There are couple of different options open in front of you if you are looking to upgrade your Drupal 6 site soon. If the site does not use a lot of custom functionalities and uses minimal contributed module functionalities and you are not really interested in contributing towards migrating Drupal 7 modules to Drupal 8 then you could just go ahead and upgrade your Drupal 6 site to Drupal 7. This could be done anytime you have the budget to do this. If you are interested in contributing towards migrating Drupal 7 contrib modules to Drupal 8 then you could wait a bit and then migrate your Drupal 6 site into Drupal 8 by the time Drupal 8 is released. You could start on the work a few months before the release date of Drupal 8. If the site does have a lot of custom functionalities as opposed to contributed module functionalities then you should really be looking to migrate to Drupal 8. Work on this could be started as soon as we have an RC version of Drupal 8. You will however have to be prepared to contribute towards migrating some of the Drupal 7 modules to Drupal 8 as it would take a while before top 100 contributed modules have Drupal 8 versions. If you are not sure about which version of Drupal you should upgrade your site to do get in touch with us and we can help you make that decision for you. Do note that this is a time sensitive article written in May 2013 and the opinions cited in this article may not be relevant after a few months from writing this article. The concepts would still hold though. Contact us to get our recommendation on what version of Drupal should you be upgrading your site to. Drupal Drupal 6 Drupal Upgrade Drupal 7 Drupal 8 Leave a reply Your email address will not be published. Required fields are marker *
more_horiz
close

on 21st May 2013 / by Anoop John
Upgrading Drupal 6 to Drupal 7 is supposed to be a straightforward process but there are certain things you have to be careful about when you upgrade Drupal. The following list outlines the different steps you will have to follow to upgrade your non-mission-critical small Drupal site. The instructions assume that the site is a small site and that you do not want to spend time running trial upgrades on a dev site and that you do not mind taking the site offline for a few hours. If the site is a mission critical site and cannot afford broken functionalities on the upgraded site then this is definitely not the way for you. You should follow the fully safe Drupal upgrade instructions List out all the modules used on the site in a spreadsheet Identify whether each of these modules have their Drupal 7 equivalents Read the upgrade instructions of each of these modules to identify special upgrade paths if any For each module that do not have a Drupal 7 equivalent identify if there is a recommended alternative module and identify if there is an upgrade/migrate path for the module For those modules that do not have a Drupal 7 equivalent and an alternative manually upgrade the module code Upgrade the theme code to Drupal 7 if you are not using a free theme. Take a full backup of the site Create a backup of the webroot Take the site offline Create a copy of the database and change settings.php to point to the new database Overwrite the core with the latest version of Drupal 6 (if it is not already so) Run update.php and bring core updates up-to-date Overwrite all the contributed modules to the latest version of Drupal 6 Run update.php and bring all module updates up-to-date Disable all non-core modules after documenting the list of enabled modules Overwrite the core with the latest version of Drupal 7 Run update.php and bring core updates up-to-date Overwrite contributed modules with the latest versions of the modules in Drupal 7 (also include the modules that were custom migrated). Run update.php and bring all module updates up-to-date If there are issues in the update process, copy over the backed up webroot and replace the new webroot. The settings.php in the restored webroot should be pointing to the original database and the old site should be back up again. If there are issues then the process will have to be run on a separate development and the issues sorted out before trying the process out again on the live site. If you are looking to get help in upgrading your Drupal 6 site to Drupal 7 we will be happy to help. Get in touch with us to know more. Drupal Drupal 6 Drupal Upgrade Drupal 7 Leave a reply Your email address will not be published. Required fields are marker *
more_horiz
close

on 16th May 2013 / by Anoop John
With Drupal 8 in the works a lot of Drupal 6 sites are currently upgrading to Drupal 7. We get quite a few queries on Drupal upgrades and almost everybody asks for a fixed price estimate for the process. In theory Drupal 6 to Drupal 7 upgrade process is an automated process (except for the upgrade of theme and custom modules) and all you have to do is to take the site through a set of standard steps for the upgrade. However upgrades don't always work like that. There are quite a few factors that affect the duration of a Drupal upgrade process. Most of the factors are the same as those that affect Drupal updates as well. Here are some of the key factors. Whether safe practices are followed - backups, trial, testing Whether upgrade is done right on the production server or on a development server Whether there is a development server for the site Whether code is already under revision control Whether SSH access is available on the servers Whether there are a lot of custom patches applied in core or contributed modules Whether there is documentation of the patches applied Whether there is a lot of custom code that uses functionalities from contributed modules directly (not via an API) Whether there is documentation about critical functionalities that should be tested after each update Whether there are a lot of custom modules Whether there are a lot of contributed modules Whether all the contributed modules have D7 versions Whether all the contributed modules have upgrade paths from D6 versions to D7 versions Whether there are a lot of template files / theme functions Whether custom code is heavily API driven or whether they are more or less standalone systems To commit to a fixed price estimate for the update process each of these aspects will have to be evaluated in detail and this might actually take longer than the full upgrade if the upgrade did not run into any issues. So our general practice is to give a ballpark figure of 80 hours and then bill on the actuals based on an Time & Materials (T&M) billing model. Also note that all custom code including modules and themes that were created for D6 will have to be manually converted to the D7 API and this would take additional time as well. The time for this will have to be custom estimated for based on the number of template files and the lines of code in the custom modules. Get in touch with us if you are looking to upgrade your Drupal 6 site to Drupal 7. Drupal Drupal 6 Drupal Upgrade Drupal 7 Leave a reply Your email address will not be published. Required fields are marker *
more_horiz
close

on 16th May 2013 / by Anoop John
A lot of clients come to us asking for running Drupal updates on their sites. However almost everybody asks for a fixed price estimate for the process. There is however a challenge in this because updates would mostly run without problems but you might run into a problem or two once in a while. We have a standard and safe process of running Drupal updates but the safe practices followed in the process would take considerably longer time than blindly running updates on the live site. Depending on whether one would like to avoid all risks while running the updates or whether one would like to take some risk while running the updates the time required to run Drupal updates would take anywhere from 2 to 20 hours of work (or more if there are issues during the process). The factors affecting this variability are Whether safe practices are followed - backups, trial, testing Whether updates are done right on the production server or on a development server Whether there is a development server for the site Whether code is already under revision control Whether SSH access is available on the servers Whether there are a lot of custom patches applied in core or contributed modules Whether there is documentation of the patches applied Whether there is a lot of custom code that uses functionalities from contributed modules directly (not via an API) Whether there is documentation about critical functionalities that should be tested after each update To commit to a fixed price estimate for the update process each of these aspects will have to be evaluated in detail and this might actually take longer than the full update if the update did not run into any issues. So our general practice is to give a ballpark figure of 10 hours and then bill on the actuals based on an Time & Materials (T&M) billing model. Get in touch with us if you are looking to keep your Drupal site updated on a regular basis. Drupal Drupal Upgrade Drupal Updates Drupal Maintenance Leave a reply Your email address will not be published. Required fields are marker *
close

on 22nd August 2012 / by Anoop John
Ecommerce used to be the preferred ecommerce solution for Drupal before Ubercart came into the picture. We recently worked on upgrading a Drupal 5 site with Ecommerce to Drupal 7 with Ubercart. The challenge with this upgrade was that the source data existed only in the D5 database and the corresponding code to programmatically access the ecommerce data was in D5 as well while the destination tables existed only in the D7 database with the corresponding code existing only in the D7 database. The solution we went with was to go for a full SQL query based migration to copy over the Ecommerce data from its tables to the Ubercart tables. The full migration process was created as a re-executable sql script because we had to iteratively fix issues in the migration. The following set of sql queries were used in the migration. We hope this helps someone trying to Migrate Drupal Ecommerce module to Ubercart. Contact Us if you need help with migrating from Ecommerce to Ubercart or for that matter migrating from any system to Drupal + Ubercart. /* DROP table tmp_ec_migrate_products; DROP table tmp_ec_migrate_txnid_order_id; */ -- Temporary table to store the nid,vid pairs that are inserted into uc_products table CREATE TABLE IF NOT EXISTS tmp_ec_migrate_products ( id int(10) unsigned NOT NULL AUTO_INCREMENT, nid int(10), vid int(10), PRIMARY KEY (id), INDEX (nid), INDEX (vid) ); -- Temporary table to store the nid,vid pairs that are inserted into uc_products table CREATE TABLE IF NOT EXISTS tmp_ec_migrate_txnid_order_id ( id int(10) unsigned NOT NULL AUTO_INCREMENT, txnid int(10), order_id int(10), PRIMARY KEY (id), INDEX (txnid), INDEX (order_id) ); DELETE uop.* FROM uc_order_products uop JOIN tmp_ec_migrate_txnid_order_id tto ON uop.order_id = tto.order_id; DELETE upr.* FROM uc_payment_receipts upr JOIN tmp_ec_migrate_txnid_order_id tto ON upr.order_id = tto.order_id; DELETE uoc.* FROM uc_order_comments uoc JOIN tmp_ec_migrate_txnid_order_id tto ON uoc.order_id = tto.order_id; DELETE uol.* FROM uc_order_line_items uol JOIN tmp_ec_migrate_txnid_order_id tto ON uol.order_id = tto.order_id; DELETE uo.* FROM uc_orders uo JOIN tmp_ec_migrate_txnid_order_id tto ON uo.order_id = tto.order_id; DELETE up.* FROM uc_products up JOIN tmp_ec_migrate_products tp ON up.vid = tp.vid AND up.nid = tp.nid; DELETE tp.* FROM tmp_ec_migrate_products tp; DELETE tto.* FROM tmp_ec_migrate_txnid_order_id tto;/** * Migration of ec products */ -- Store the nids and vids to be deleted if the script is to be re-run INSERT INTO tmp_ec_migrate_products ( nid, vid ) SELECT ep.nid, ep.vid FROM ec_product ep LEFT JOIN ec_product_tangible ept ON ep.nid = ept.nid AND ep.vid = ept.vid LEFT JOIN uc_products up ON up.nid = ep.nid AND up.vid = ep.vid WHERE up.nid IS NULL; -- Load uc_products from ec_products tables INSERT INTO uc_products ( vid, nid, model, list_price, cost, sell_price, weight, weight_units, length, width, height, length_units, pkg_qty, default_qty, unique_hash, ordering, shippable ) SELECT ep.vid, ep.nid, ep.sku, 0, 0, ep.price, 0, '', 0, 0, 0, '', 1, 1, MD5(CONCAT(ep.vid, ep.nid, ep.sku, ep.price, NOW())) AS unique_hash, 0, CASE ept.nid WHEN NULL THEN 0 ELSE 1 END AS shippable FROM ec_product ep LEFT JOIN ec_product_tangible ept ON ep.nid = ept.nid AND ep.vid = ept.vid LEFT JOIN uc_products up ON up.nid = ep.nid AND up.vid = ep.vid WHERE up.nid IS NULL;/** * Migration of ec transactions */ SELECT @new_order_id := MAX(order_id)+1 FROM uc_orders; -- Create and store order_ids for new orders to be imported from the ec_transaction table INSERT INTO tmp_ec_migrate_txnid_order_id ( txnid, order_id ) SELECT txnid, @new_order_id := @new_order_id + 1 FROM ec_transaction; -- Load uc_orders from ec_transaction and ec_transaction_address tables INSERT INTO uc_orders ( order_id, uid, order_status, order_total, primary_email, delivery_first_name, delivery_last_name, delivery_phone, delivery_company, delivery_street1, delivery_street2, delivery_city, delivery_zone, delivery_postal_code, delivery_country, billing_first_name, billing_last_name, billing_phone, billing_company, billing_street1, billing_street2, billing_city, billing_zone, billing_postal_code, billing_country, payment_method, data, host, created, modified, product_count, currency ) SELECT tto.order_id, et.uid, CASE et.payment_status WHEN 1 THEN 'pending' WHEN 2 THEN 'completed' ELSE 'pending' END AS order_status, et.gross, et.mail, etas.firstname, etas.lastname, '' AS delivery_phone, '' AS delivery_company, etas.street1, etas.street2, etas.city, 0 AS delivery_zone, etas.zip, 0 AS delivery_country, etab.firstname, etab.lastname, '' AS billing_phone, '' AS billing_company, etab.street1, etab.street2, etab.city, 0 AS billing_zone, etab.zip, 0 AS billing_country, CASE et.payment_method WHEN 'authorize_net' THEN 'credit' WHEN 'manually_add' THEN 'other' ELSE 'other' END AS payment_method, 'a:0:{}' AS data, '127.0.0.1' AS host, et.created, et.changed, 0 AS product_count, 'USD' AS currency FROM ec_transaction et JOIN tmp_ec_migrate_txnid_order_id tto ON et.txnid = tto.txnid LEFT JOIN ec_transaction_address etab ON et.txnid = etab.txnid AND etab.type = 'billing' LEFT JOIN ec_transaction_address etas ON et.txnid = etas.txnid AND etas.type = 'shipping'; -- Create temporary table with indexed fields for handling country and state data CREATE TABLE IF NOT EXISTS tmp_ec_migrate_ect_address ( id int(10) unsigned NOT NULL AUTO_INCREMENT, txnid int(10), state varchar(100), country char(2), type char(1), PRIMARY KEY (id), INDEX (txnid), INDEX (state), INDEX (country), INDEX (type) ); -- Load temporary table with country and state data for billing address INSERT INTO tmp_ec_migrate_ect_address ( txnid, state, country, type ) SELECT txnid, UPPER(state), UPPER(CASE country WHEN 'an' THEN 'CW' WHEN 'uk' THEN 'GB' WHEN 'Un' THEN 'US' WHEN 'cs' THEN 'RS' WHEN '' THEN 'US' WHEN NULL THEN 'US' ELSE country END) AS country_corrected, 'b' FROM ec_transaction_address WHERE type = 'billing'; -- Load temporary table with country and state data for shipping address INSERT INTO tmp_ec_migrate_ect_address ( txnid, state, country, type ) SELECT txnid, UPPER(state), UPPER(CASE country WHEN 'an' THEN 'CW' WHEN 'uk' THEN 'GB' WHEN 'Un' THEN 'US' WHEN 'cs' THEN 'RS' WHEN '' THEN 'US' WHEN NULL THEN 'US' ELSE country END) AS country_corrected, 's' FROM ec_transaction_address WHERE type = 'shipping'; -- Update billing_zone for orders loaded from ec_transaction table UPDATE uc_orders uo JOIN tmp_ec_migrate_txnid_order_id tto ON uo.order_id = tto.order_id LEFT JOIN tmp_ec_migrate_ect_address etab ON tto.txnid = etab.txnid AND etab.type = 'b' LEFT JOIN uc_zones uczb ON etab.state = UPPER(uczb.zone_name) SET uo.billing_zone = uczb.zone_id WHERE uo.billing_zone = 0; -- Update delivery_zone for orders loaded from ec_transaction table UPDATE uc_orders uo JOIN tmp_ec_migrate_txnid_order_id tto ON uo.order_id = tto.order_id LEFT JOIN tmp_ec_migrate_ect_address etas ON tto.txnid = etas.txnid AND etas.type = 's' LEFT JOIN uc_zones uczs ON etas.state = UPPER(uczs.zone_name) SET uo.delivery_zone = uczs.zone_id WHERE uo.delivery_zone = 0; -- Update billing_country for orders loaded from ec_transaction table UPDATE uc_orders uo JOIN tmp_ec_migrate_txnid_order_id tto ON uo.order_id = tto.order_id LEFT JOIN tmp_ec_migrate_ect_address etab ON etab.txnid = tto.txnid LEFT JOIN uc_countries uccb ON etab.country = UPPER(uccb.country_iso_code_2) SET uo.billing_country = uccb.country_id WHERE uo.billing_country = 0; -- Update delivery_country for orders loaded from ec_transaction table UPDATE uc_orders uo JOIN tmp_ec_migrate_txnid_order_id tto ON uo.order_id = tto.order_id LEFT JOIN tmp_ec_migrate_ect_address etas ON etas.txnid = tto.txnid AND etas.type = 's' LEFT JOIN uc_countries uccs ON etas.country = UPPER(uccs.country_iso_code_2) SET uo.delivery_country = uccs.country_id WHERE uo.delivery_country = 0; -- Drop temporary table DROP TABLE tmp_ec_migrate_ect_address; -- Update product counts for orders loaded from ec_transaction table UPDATE uc_orders uo JOIN tmp_ec_migrate_txnid_order_id tto ON uo.order_id = tto.order_id LEFT JOIN (SELECT txnid, COUNT(txnid) AS product_count FROM ec_transaction_product GROUP BY txnid) tpc ON tto.txnid = tpc.txnid SET uo.product_count = tpc.product_count WHERE tpc.product_count IS NOT NULL;/** * Migration of transaction products */ -- Load uc_order_products from ec_transaction_product table INSERT INTO uc_order_products ( order_id, nid, title, model, qty, cost, price, weight, data, weight_units ) SELECT tto.order_id, etp.nid, etp.title, etp.title AS model, etp.qty, 0 AS cost, etp.price, ctp.field_weight_0_value, 'a:1:{s:6:"module";s:10:"uc_product";}' AS data, 'lb' AS weight_units FROM ec_transaction_product etp JOIN tmp_ec_migrate_txnid_order_id tto ON etp.txnid = tto.txnid LEFT JOIN content_type_physical_item ctp ON etp.nid = ctp.nid AND etp.vid = ctp.vid;/** * Migration of authorize.net payment transactions */ -- Load uc_payment_receipts from ec_authorize_net table INSERT INTO uc_payment_receipts ( order_id, method, amount, uid, data, comment, received ) SELECT tto.order_id, 'Credit Card' AS method, ea.amount, uo.uid, CONCAT('a:3:{s:6:"module";s:15:"uc_authorizenet";s:8:"txn_type";s:12:"auth_capture";s:6:"txn_id";s:10:"', ea.anid, '";}') AS data, CONCAT('Type: Authorization and captureID: ', ea.anid) AS comment, uo.modified FROM uc_orders uo JOIN tmp_ec_migrate_txnid_order_id tto ON uo.order_id = tto.order_id JOIN ec_authorize_net ea ON tto.txnid = ea.txnid;/** * Migration of manually recorded receipts */ -- Load uc_payment_receipts for manually added payments recorded in ec_transaction INSERT INTO uc_payment_receipts ( order_id, method, amount, uid, data, comment, received ) SELECT tto.order_id, 'Other' AS method, et.gross, et.uid, '' AS data, '' AS comment, et.changed FROM tmp_ec_migrate_txnid_order_id tto JOIN ec_transaction et ON tto.txnid = et.txnid WHERE et.payment_status = 2 AND et.payment_method = 'manually_add';/** * Migration of transaction notes */ -- Load uc_order_comments from ec_transaction_note table INSERT INTO uc_order_comments ( order_id, uid, order_status, notified, message, created ) SELECT tto.order_id, et.uid, CASE et.payment_status WHEN 1 THEN 'pending' WHEN 2 THEN 'completed' ELSE 'pending' END AS order_status, 1 AS notified, etn.note, et.created FROM ec_transaction et JOIN tmp_ec_migrate_txnid_order_id tto ON et.txnid = tto.txnid JOIN ec_transaction_note etn ON et.txnid = etn.txnid;/** * Migration of transaction tax */ -- Load uc_order_line_items from ec_transaction_misc table INSERT INTO uc_order_line_items ( order_id, type, title, amount, weight, data ) SELECT tto.order_id, 'tax' AS type, 'California State Tax' AS title, etm.price, etm.weight, CONCAT('{s:8:"tax_rate";s:5:"0.095";s:14:"taxable_amount";d:', et.gross, ';s:16:"tax_jurisdiction";s:20:"California State Tax";}') AS data FROM ec_transaction_misc etm JOIN tmp_ec_migrate_txnid_order_id tto ON etm.txnid = tto.txnid JOIN ec_transaction et ON tto.txnid = et.txnid; Drupal 5 Drupal Upgrade Drupal 7 Ubercart Data Migration Drupal Migration Leave a reply Your email address will not be published. Required fields are marker *
more_horiz
close

on 19th September 2011 / by webmaster
Upgrading a Drupal site refers to moving it’s database and files from one major version of Drupal to a later one, to take advantage of the newer features and bug fixes that might not be available for the older version. Upgrading a Drupal site is a pretty effective way to make sure that your Drupal site is currently up to date with all the latest security updates and bug fixes. Old versions of Drupal will naturally be unsupported with the arrival of the new releases. The Drupal community has currently stopped supporting the older versions of Drupal like version 4 and 5 and has moved to Drupal 7. However Drupal 6 is more widely supported. Have a look at the steps required to upgrade your Drupal site from an older version to      Drupal 6.      Keeping your Drupal site up-to-date is necessary to make sure that you’re not left behind with a chunk of unsupported code as time passes. Updates and upgrades are necessary to ensure the smooth functioning of your Drupal site. Upgrading a Drupal site refers to moving it’s DB and files from one major version to a later one, to take advantage of newer features and fixes that might not be available for the older one. (On the other hand, updating refers to moving from one minor version to a later one). Many sites still use the 4.x and 5.x versions of Drupal, which the community has officially stopped supporting/maintaining. Drupal.org asks for all these sites to be upgraded to the latest 6.x version to ensure smooth updates and fixes. Here we show you how to upgrade your Drupal 4.x or 5.x based site to version 6.x. The general strategy that we follow would be to update through minor versions till we reach the last available minor version for that major version (that would be 4.7.11 for 4.x, 5.23 for 5.x), and then to upgrade to the next major version’s first minor version. We will continue this process till we reach the last minor version for 6.x. For example, if we are now on Drupal 4.7.1, we update through all 4.x minor versions till 4.7.11, and then upgrade to 5.0. Following that, we update through all 5.x minor versions till 5.23 and then upgrade to 6.0. Then, we move through the 6.x stream till we reach 6.22 which is the latest 6.x minor version as of the date of writing this HOWTO. HOWTO: It would be easier and safer to perform the following updates and upgrades on a local copy of the site. Make sure you have the local LAMP environment as similar as possible, to the production environment (especially PHP - version, extensions). After finishing and verifying locally, you can upload both the DB and files to the production server. Since such an upgrade is a time consuming and risky process, make sure you take backups all along the way. Things would be much saner if you use a VCS such as git. Login as the default admin user (user/1), so that you have permissions to run update.php. Check for all php/drupal function syntax changes/deprecation along the 4.x to 6.x path. Before each update/upgrade stage, check for code hacks and generate patches. Check in the documentation both on drupal.org and inside the module, for patches that might have gone in already, during the version change. After replacing the component core/module/theme, apply and verify those patches one by one, which have not already gone in. Before each update/upgrade, check the existing site components (core, contrib modules, themes) with their original drupal.org versions to find out whether there are any custom code hacks. If present, generate diff patches (diff is a good commandline utility for doing this on linux. MelDiff is a GUI version). Remember to document and maintain patches in a separate folder (patches). You can use the Hacked! and Diff modules for checking for code hacks. (Hacked is a Drupal module that helps you find custom code hacks in the site’s core, contrib modules/themes by comparing the existing code with original copies of their same versions freshly downloaded from Drupal.org. Hacked!, along with Diff, make things much easier). After replacing the code and applying patches (if any), run update.php, followed by cron.php. Check the ‘Recent Logs’ and ‘Status Report’ pages after each update.php run. To handle WSODs, add the following debug code in index.php: error_reporting(E_ALL); ini_set('display_errors', TRUE); ini_set('display_startup_errors', TRUE);  Fix all errors - do not skip. Warnings may be ignored till the final stage. Before each upgrade, disable all non-core stuff (modules and themes). Follow the same procedure as for updates (mentioned above), for the Drupal core. Then upgrade and enable non-core stuff one by one. Before upgrading the theme, make sure you have set the admin theme to a default available core one (such as Garland). Test extensively during each stage of your upgrade. As a general principle, move carefully, keep a descriptive log of your steps (would come automatically if you use a VCS properly), and test extensively. With these simple principles in mind, fill up a snack bowl next to your desk, take a deep breath, and upgrade! Dont have the time/patience to go through all of this, but want somebody knowledgeable to do this for you? We will be glad to take care of this and more! Contact Us Web Development Drupal Drupal 6 Drupal 4 Drupal 5 Drupal Upgrade Leave a reply Your email address will not be published. Required fields are marker *