Drupal 5
more_horiz
close

on 03rd June 2013 / by naveen.pl
We had recently faced an issue in one of our client's website running on Drupal 5. The site had crashed and we were unable to continue development. We began analyzing the problem by checking the free space on the site and came to the conclusion that the now deprecated PHP Ereg function was causing the site to crash. If you are facing the same issue in one of your Drupal sites, read on to know how we successfully fixed the bug. First let us explain how we found the bug. We began by checking the free space on the website and found that more than 50% space was still available. Then we checked the database and we found that the watchdog table had become corrupted. We truncated the table and it actually started working! We may not have actually gone for truncating the table, since it was a watchdog table. But the issue was due to the corrupted table. We also realized that a few pages that were working, no longer worked. They were all showing WSOD and we found around 20 pages of warning messages recorded in a short duration of time. Interestingly, they were all generated around a PHP ereg function. elseif ($depth >= $min_depth && ereg($mask, $file)) { We have also noticed that the server was upgraded recently from 5.1 to 5.3. Then we had a look into the PHP manual for ereg and noticed the following warning about function. "This function has been DEPRECATED as of PHP 5.3.0. Relying on this feature is highly discouraged." We realized that the solution to this problem was to replace it with preg_match which is somewhat similar to ereg and supported by PHP. Here is how we did it. example code // Original code elseif ($depth >= $min_depth && ereg($mask, $file)) { // Replaced code. elseif ($depth >= $min_depth && mb_ereg($mask, $file)) { // Original code if(!ereg("^[A-Za-z0-9\-|_]*$", $name)) // Replaced code. if(!preg_match("/[^A-z0-9_\-]/", $name)) This fixed the issue caused by ereg function which is deprecated after php 5.3. Hope this article was helpful to you too. Drupal Drupal 5 Debugging 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 13th December 2012 / by webmaster
Many Drupal programmers, Drupal site admins and Drupal site users have encountered the "Notice: Undefined variable" error message in their Drupal site. If you are facing the same situation in your Drupal site then read on to find out more. This is a warning from PHP indicating that the code is taking some shortcuts and it does not mean, there is an error in your Drupal installation. This message means that there is a very verbose level of logging enabled on your server. Here is the workaround for that. The setting for such a verbose level of logging is usually not enabled on a production server but your PHP settings may have it turned on It is considered safe to turn off these notice messages by editing your php.in .error_reporting = E_ALL & ~E_NOTICE Hope that helps. The easiest way to solve a Drupal issue is to hand it to the Drupal experts. We can provide a wide range of Drupal services to help you maintain and manage your Drupal websites. Get in touch with us to know more. Reference: http://drupal.org/node/303492 Drupal Drupal 6 Drupal 5 Drupal Issues Drupal Errors Leave a reply Your email address will not be published. Required fields are marker * cam8001 (not verified) access_time 24 May 2019 - 02:07 Rather than change your php.ini, you can disable the display of these errors to the user at admin/config/development/logging. The errors will still be logged to dblog or syslog (depending on what you have set up). It is better to log notices rather than disabling them, as they can provide valuable insight when debugging. I will go ahead and update the handbook page on Drupal.org to reflect this. Add new comment
more_horiz
close

on 13th December 2012 / by webmaster
Many Drupal programmers, Drupal site admins and Drupal site users have encountered 403, 404, 406, 500 or "Page not found" errors when submitting content with specific phrases. If you are facing the same situation in your Drupal site then read on to find out more. This error is usually caused by the filter settings in the Apache module mod_security. The module scans for phrases like lynx, perl, mother, select from, table, cc: etc. Here are the steps to fix the error. Request your host to decrease the security level You can also add the following lines of code to .htaccess if your hosting provider allows that.# Turn off mod_security filtering. <IfModule mod_security.c> SecFilterEngine Off </IfModule> Hope that helps. The easiest way to solve a Drupal issue is to hand it to the Drupal experts. We can provide a wide range of Drupal services to help you maintain and manage your Drupal websites. Get in touch with us to know more. Reference: http://drupal.org/node/110219 Drupal Drupal 6 Drupal 5 Drupal 7 Drupal Issues Drupal Errors Leave a reply Your email address will not be published. Required fields are marker * Sheba Maniar (not verified) access_time 24 May 2019 - 02:07 i uncomment RewriteBase / in .htaccess file still it shows me same error . So another way to solve this issues. Add new comment
more_horiz
close

on 13th December 2012 / by webmaster
Many Drupal programmers, Drupal site admins and Drupal site users have encountered the error message - "MySQL: "Warning: MySQL server has gone away" on their Drupal site. If you are facing the same situation in your Drupal site then read on to know the fix. The error is usually caused by a lack of insufficient resources available to MySQL for supporting Drupal. The error can be solved by allocating more resources to MySQL by changing the settings in the configuration file. Follow the steps below to do so. The MySQl configuration file in Windows is situated in C:\Program Files\MySQL\MySQL Server X.Y\my.ini Linux users can find the global settings file in /etc/mysql/my.cnf Create a backup of the file Edit the file and add or modify the following details to the files if you are using MyISAM database tables[mysqld] port = 3306 socket = /tmp/mysql.sock skip-locking key_buffer = 384M max_allowed_packet = 64M table_cache = 4096 sort_buffer_size = 2M read_buffer_size = 2M read_rnd_buffer_size = 64M myisam_sort_buffer_size = 64M thread_cache_size = 8 query_cache_size = 32M Try changing from MyISAM database tables to InnoDB as the former is more resource intensive if you are not presently using it. Here are the specifications for InnoDB database tables For InnoDB specificationsinnodb_buffer_pool_size = 384M innodb_additional_mem_pool_size = 20M innodb_log_file_size = 10M innodb_log_buffer_size = 64M innodb_flush_log_at_trx_commit = 1 innodb_lock_wait_timeout = 180 You must modify the above resource specifications or add them there if they are not present there as some configurations do not have them by default. Hope that helps. The easiest way to solve a Drupal issue is to hand it to the Drupal experts. We can provide a wide range of Drupal services to help you maintain and manage your Drupal websites. Get in touch with us to know more. Reference: http://drupal.org/node/259580 Drupal Drupal 6 Drupal 5 Drupal 7 Drupal Issues Drupal Errors 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 *
close

on 22nd August 2012 / by Anto
When migrating from Drupal 5, the normal path would be to migrate everything (core/modules/themes) to the latest Drupal 5 versions, and then to the latest Drupal 6 versions, and then over to the Drupal 7 versions. How fortunate would have been the developers assigned the job if everything was as simple as that! Unfortunately, everything is not as simple as that. There are modules that have fallen over time, those whose maintainers found it no longer as entertaining as before to keep releasing compatible versions for Drupal 7. There are custom modules for which there have been no history of updates. All these are just the tip of the iceberg when you set out to get your good Drupal 5 site upgraded. You might not be able to get everything migrated over a simple update.php run. And when the site has quite some data to be brought over to the new land (Drupal 7) after the migration, CCK is one of your biggest concerns, being one of the most data-intensive modules in Drupal. You should first try using the Content Migrate module. That should help you bring over most of the data. What you should set out next is to get a set of SQL queries to safely and reliably bring the data not brought over by Content Migrate. Drupal 7 uses two tables each to hold each field's data:field_data_field_fieldname and field_revision_field_fieldname. In Drupal 5, fields used by a single content type would have the data in the content_type_ table. For fields used by multiple content types, the data would be presented in content_field_ tables. The surest way to go would be to dig into the code and find out how the module stores the data. But that could be quite time consuming when compared to the method mentioned below: A quick and simple strategy to identify table mappings would be to try adding a new content of the type under which the field appears. Make sure you enter some easily searchable and recognizable value that might be unique. For eg., for string fields, a value like 'testing-data-mapping-0001', and for numeric fields, a value like 1234567, should be somewhat unique enough. Now using something like phpMyAdmin, search the entire database for those values to identify where Drupal 7 stores those data. This shouldnt take much time (usually a matter of 1-5 minutes for a less-than-30GB DB). As simple as that! Do the same thing on the Drupal 5 version of the site. Now that you know where to put the data into, and from where to get the data, just write some SQL to bring the data over. Here's something to start with that: INSERT INTO d7_table_name ( column1, column2, column3, ... ) SELECT d5table1.column00x as column1, d5table1.column00y as column2, d5table2.column001 as column3, ... ) FROM d5table1 LEFT JOIN d5table2 ON ... WHERE ...;This should help you get going. (Let us know if you still need help with this, or if you would like to get us to migrate your Drupal 5.x / 6.x site over to Drupal 7). Happy migrating! Drupal 5 Drupal Development Drupal 7 Data Migration Drupal Updates CCK Content Construction Kit Field Migration Site Administration 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 *