Home » Blogs » sugree's blog

Smooth procedure to upgrade Drupal 4.7.0 beta 3 to beta 4

Posted January 27th, 2006 by sugree

Since Drupal 4.7.0 beta 4 is available last night, I have just upgraded howforge.com to see the better version. There are many patches was applied to this release. I recommend all you to upgrade as soon as possible. Since I installed lots of modules and themes as well as hot patches during beta 3, the upgrade is not as easily as expect. The most critical problem is I didn"t want to interrupt user by making site off-line for so long. According to the upgrade guide, I have to remove all existing files and extract the new ones. This action is unacceptable for me. That means user might not see the proper message about off-line maintenance or upgrading. Below procedure is what I done today.

  1. Make a copy of all files
  2. Extract Drupal 4.7.0 beta 3
  3. Find differences between the original beta 3 and the copy
  4. Extract Drupal 4.7.0 beta 4
  5. Copy .htaccess, additional modules and themes from the copy to beta 4
  6. Find differences between beta 3 and beta 4
  7. Look for conflict
  8. Apply manual customized to beta 4
  9. Make a patch of the copy and beta 4
  10. Apply the patch to the running code
  11. Run update.php

That"s all! Only 1 minute downtime during run update.php. As a result, I have 5 patches to apply in this release as follows.

  1. blogapi.module
  2. path.module
  3. ping.module
  4. profile.module
  5. taxonomy.module

Problem with Thai font after upgrading to beta 4

On January 27th, 2006 Anonymous says:
Sorry for posting in Thai, I think it can describe my situation better. วันนี้ผมลอง upgrade จาก 4.7.0 beta 3 เป็น beta 4 เหมือนกันครับ ทำตาม procedure มันเด๊ะๆ ไม่มี error ด้วย แต่พอกลับมาหน้า home ปรากฏว่าข้อความภาษาไทย มันกลายเป็นตัวยึกยือหมดเลย ไม่รู้ว่าตัว update.php มันไปทำอะไรกับ collation ของ MySQL !? อย่างที่นี่ ใช้ MySQL version อะไรครับ แล้ว set collation เป็นอะไร ผมลองพวก tis620_bin กับ tis620_thai_ci แล้ว เวลาโพสต์ข้อความ มันไม่เป็นภาษาไทย ตอนนี้ใช้ utf8_general_ci อยู่ แต่พออัพเกรดแล้ว กลับใช้ไม่ได้ซะดื้อๆ =.=
  • reply
  • th

Character set problem

On January 27th, 2006 sugree says:
You are correct. Drupal 4.7.0 beta 4 has changed to UTF-8 to support multilingual better in update number 169. This update will be applied to MySQL 4.1+ only. The upgrade procedure is as follows. 1. Alter columns to binary types 2. Alter columns back to original types with utf character set This upgrade procedure will be applied only if the database was created as UTF-8. This host has been installed MySQL 3.23.58 which doesn't support UTF-8. I think you should export the backup database and then import back later. Otherwise, I could help you to reverse above procedure to recover data. You should find out what the current character set is by now. According to http://drupal.org/node/40515, you can update again after upgrading to PHP 5.0.
  • reply
  • th

Too bad...

On January 28th, 2006 kong says:
It's me again (just created an account here). I exported the 4.7.0 beta 3 database and tried to re-import after upgrading to 4.7.0 beta 4 but I still get unreadable characters :( I think beta 3 stores the data in other format than UTF-8 even though I set the collation of MySQL to utf8_general_ci. Because after I tried a clean install of beta 3, added some Thai content and exported the database, I found the data in the exported database file (.sql) is unreadable. But when I tried a clean install of beta 4, added some Thai content and exported the database, it's readable... So there are 2 questions:
  • What is the collation that beta 3 actually use when it writes the data?
  • How to convert that collation into UTF-8 format?
Obviously, the update.php method doesn't do the trick. I would be very appreciate for any suggestions you guys might have.
  • reply
  • th

Collation is not charset

On January 28th, 2006 sugree says:
I think you are misunderstanding some terms. Character set and collation are different things. Your problem is character set mismatch. * Drupal has been used UTF-8 for long time even the database didn't support UTF-8 * You can use "alter" to convert character set as follow. ALTER TABLE my_table CONVERT TO CHARACTER SET 'utf8' Anyway, it seems there is some bug in update.php so the conversion will not be performed if PHP version is older than 5.0. You might try to convert it manually one by one. Could you let me see some sample data in database? I just want to see how it look like to find out how to convert it correctly.
  • reply
  • th

Yeah, I did misunderstood the meaning of the terms =.=

On January 28th, 2006 kong says:
So we're talking about charset, not collation, right? Here's the configuration of MySQL on my machine: Please take a look at the attached MySQL exports, one is from beta 3 and another is from beta 4, both containing the same text which reads "นี่คือข้อความภาษาไทย" but only the one from beta 4 is readable. Thank you very much for your help so far :)
  • reply
  • th

double utf-8 encoding

On January 28th, 2006 sugree says:
The data in beta3 clearly shows that update.php didn't know that charset was utf-8. The result was double utf-8 encoding. It is possible to fix this problem by decoding in utf-8.
  • reply
  • th

utf8_decode() ?

On January 28th, 2006 kong says:
Thanks, I guess what I have to do is writing a script to decode the data from [double-encoded utf-8] --> [utf-8] and put the data back into MySQL, right? I was looking at utf8_decode() function but in PHP manual it says that the output of the function is iso-8859-1. How can I convert it to utf-8 again?
  • reply
  • th

utf8_decode()

On January 29th, 2006 sugree says:
iso-8859-1 means 8-bit characters that should work fine.
  • reply
  • th

^^

On January 29th, 2006 kong says:
Thanks again for your help :)
  • reply
  • th

Post new comment