Drupal 7 Upgrade Story

ช่วงน้ำท่วมเหมือนได้ปิดเทอม เลยนั่งทยอยสะสางงานที่อยากทำแต่ไม่ได้ทำเพราะไม่มีเวลามากพอ หนึ่งในนั้นคือการอัพเกรด isriya.com เป็น Drupal 7

ผลลัพธ์ออกมาอย่างที่เห็นคือ อัพได้ (ยังไม่ได้แก้ธีมเก่า + หาธีมใหม่ เลยใช้ default ไปพลางๆ ก่อน) แต่กว่าจะผ่านมาได้ก็เหนื่อยยากแสนเข็ญ มาแชร์ประสบการณ์ไว้หน่อย

แบ็คกราวด์

  • isriya.com รัน D6 ที่อัพมาจาก D5 อีกที
  • ใช้ module ไม่เยอะเท่าไร และไม่มีความสำคัญกับชีวิตมากนัก ปิดทิ้งได้หมด ยกเว้น markdown ที่ต้องใช้เป็น input format (ซึ่งก็มีเวอร์ชัน D7 อยู่แล้ว)
  • isriya.com อยู่บนเซิร์ฟเวอร์ของ CLNOX

วางแผน

  • แนะนำอย่างยิ่งว่า ควรจะซ้อมอัพเกรดบนเครื่องจำลองก่อน เพราะมีรายละเอียดจุกจิกเยอะมาก
  • ขั้นตอนการซ้อมอัพเกรดก็ตามปกติของเว็บทั่วไป มีเทคนิคนิดหน่อยคือ empty table หลายๆ อันที่ไม่จำเป็นต้องใช้ พวกแคชและ log ต่างๆ เพื่อให้ตัวฐานข้อมูลมีขนาดเล็กลงให้มากที่สุด
  • เทคนิคอีกประการคือ ลง D7 แบบ fresh install ไว้เทียบดูด้วย ว่าการตั้งค่าอะไรต่างกันบ้าง

ขั้นตอน

ทำตาม upgrade.txt ทุกประการ ขั้นตอนแบบย่อๆ มีดังนี้

  • แรกสุดคือปิด module กลุ่ม non-core ทิ้งให้หมด อันไหนคิดว่าไม่ใช้ในอนาคตแล้วก็ uninstall ทิ้งไปเลย
  • เปลี่ยนธีมเป็น Garland
  • จากนั้นล็อกอินด้วย user 1 แล้วเข้า maintenance mode ดังเช่นการอัพเกรดปกติ
  • ลบไฟล์ sites/default/default.settings.php
  • เปลี่ยน permission ของ sites/default/settings.php ให้เป็น 666 (หรือ 644 แล้วแต่คอนฟิกของเซิร์ฟเวอร์)
  • ลบทุกอย่างที่อยู่นอก sites ถ้ามีของอื่นที่ไม่ใช่ไฟล์จาก Drupal ก็แบ็คอัพกันเอง
  • ก็อปไฟล์จาก D7 มาทับ
  • แก้ไฟล์ .htaccess ถ้าจำเป็น (กรณีของผมคือ แก้ RewriteBase บนเครื่องจำลอง)
  • เข้าไปที่ update.php เพื่อรันการอัพเกรด ที่เหลือก็ภาวนาให้มันรอด

อุปสรรคของการอัพเกรด

Table Schema

ปัญหาของ isriya.com คืออัพมาจาก D5 > D6 > D7 มันทำให้ table schema บางอันยังใช้ของ D5 อยู่ (ที่ดันไม่มีปัญหากับ D6 แต่มีปัญหากับ D7)

ผมดูข้อมูลใน Drupal.org แล้วพบว่ามีคนเป็นบ้างประปราย ส่วน table ที่มีปัญหาก็แตกต่างกันไป

กรณีของผมคือ table ชื่อ block มีฟิลด์ชื่อ theme ตั้งชนิดของข้อมูลเป็น varchar(255) ซึ่งเป็นค่าเดิมของ D5 แต่พอมาเป็น D6/D7 มันกลายเป็น varchar(64) ไปแทน ทำให้การรันสคริปต์อัพเดตไม่สมบูรณ์

ทางแก้ก็ไม่ยากคือเข้าไปเปลี่ยนค่าของ table structure ใน MySQL ได้เลย (ไม่มีผลกระทบต่อข้อมูล เพราะข้อมูลที่เก็บจริงคือชื่อธีมซึ่งสั้นมาก) จะแก้ผ่าน phpMyAdmin หรือแก้จาก MySQL console โดยตรงก็แล้วแต่ชอบ

Taxonomy as Field

อันนี้ไม่รู้มีใครเป็นหรือเปล่า แต่กรณีของ isriya.com มีลักษณะเฉพาะคือใช้แท็กเยอะมาก และ D7 ได้เปลี่ยนสถาปัตยกรรมการเก็บข้อมูลของแท็กใหม่ ให้เป็น Field แทน (ตาม Field API)

Field API improvements: Taxonomy terms are now fields, comments and taxonomy terms are fieldable, and fields are also now translatable.

นอกจากมันจะเป็น Field แล้ว มันยังได้คุณสมบัติของ Field ติดมาด้วยคือ Revision ผลก็คือการอัพเกรดฐานข้อมูล จะต้องสร้างตารางใหม่ที่เอา node x tag x revision ซึ่งกินเวลาเป็นชั่วโมงได้

บนเครื่องจำลอง การอัพเกรดฐานข้อมูลสามารถทำได้โดยไม่มีปัญหาอะไร (แค่รอนาน) แต่บนเครื่องจริง กลับรันไม่รอดจนจบ ทางแก้ก็ไม่ยากคือ dump ฐานข้อมูลจากเครื่องจำลองมาใส่เครื่องจริง ก็เป็นอันเสร็จ

Temp Directory

สิ่งที่เพิ่มเข้ามาใน D7 คือเราต้องระบุ path สำหรับ temp/tmp directory ด้วย จากเดิมที่ระบุแค่ path ของ files directory

ตั้งค่าได้ใน Admin/Config/File Systems ส่วนจะตั้งเป็นอะไรก็ขึ้นกับคอนฟิกของเซิร์ฟเวอร์ที่ใช้ครับ

File Compression

อันนี้เป็นปัญหาที่ยังแก้ไม่ได้ คือ คอนฟิกของ D7 กับเซิร์ฟเวอร์ของ CLNOX มีปัญหาเรื่องการบีบไฟล์ CSS/JS ทำให้เวลาเราเลือก Aggregate CSS/JS ในหน้า Performance แล้ว ธีมไม่ขึ้น

ปัญหานี้ไม่เกิดบนเครื่องจำลอง (Ubuntu LAMP) อันนี้กำลังหาทางแก้กับ CLNOX อยู่ว่าเป็นอย่างไรบ้าง แต่ workaround เบื้องต้นคือใช้ D7 แบบไม่บีบ CSS/JS ไปก่อน

Admin Toolbar

ของใหม่ของ D7 ที่เห็นได้ชัดเจนที่สุดคือ Admin Toolbar ที่ปรากฏขึ้นมาเป็น overlay ทับหน้าจอปกติ ช่วยให้การเข้าถึงฟังก์ชันต่างๆ ในหน้า Admin ทำได้สะดวกขึ้น

แต่กรณีของ isriya.com ที่ไม่ได้ลงแบบ fresh install แต่อัพเกรดแทน ปรากฏว่า Admin Toolbar ไม่โผล่ (ไม่ทราบสาเหตุ คาดว่าเป็นเรื่องของคอนฟิก)

ทางแก้คือเปิด Module ชื่อ Toolbar, Overlay, Shortcut แล้วแต่งานที่ใช้ (ถ้าเปิดครบ 3 อันจะเท่ากับ D7 default)

Module

เนื่องจากไม่ต้องใช้ module อะไรที่จำเป็นมาก เบื้องต้นเลยลงไว้เฉพาะ markdown ก่อน ซึ่งก็ไม่มีปัญหาอะไร สามารถทำงานได้ดี

module บางตัวก็ไม่จำเป็นต้องใช้อีกแล้ว เช่น vertical_tab ที่เข้ามาอยู่ใน D7 Core แล้ว

โอกาสนี้ก็ควรลอง module ใหม่ๆ บ้างเช่นกัน ตัวอย่างเช่น Mollom ที่ระยะหลังไม่น่าประทับใจนัก (ทำสแปมหลุดบ่อย) ก็อาจจะไปลองใช้ AntiSpam/Akismet แทน

สรุป

การอัพเกรดจาก D6 > D7 โหดร้ายทารุณมาก เหตุผลเพราะสถาปัตยกรรมข้างล่างเปลี่ยนเยอะ (ระยะห่างระหว่างรุ่น 3 ปี) นี่ยังไม่รวมเรื่อง module ที่ยังเปลี่ยนตามกันไม่ทันอีก

ถ้าทำเว็บใหม่ตอนนี้ก็ควรเริ่มที่ D7 เลย แต่คนที่รัน D6 อยู่แล้วและยังไม่มีเหตุจำเป็นต้องอัพเกรด ก็ควรอยู่กับ D6 นั่นแหละครับ

Comments

จะมีเกรียนเวิร์ดเพรสมาเกรียนมั้ยเนี่ย

ไม่นะ ไม่นะ ไม่นะ :P

ตอบคุณ @iMenn ผมขายวิญญาณให้ @Warong เอ้ย @WordPress ไปแล้วครับ

ประสพการณ์คล้ายๆ กัน เว็บส่วนตัวใช้ไม่กี่ module ยังเกือบตาย (แต่ไม่ได้จดบันทึกปัญาหาไว้)

เว็บที่ใช้งานของบริษัท ก็มีความอยากจะ upgrade เพราะอยากใช้ module ใหม่ๆ บางตัว แต่ยังไม่จำเป็นขนาดนั้น

สุดท้ายคงจะย้ายเอาตอน D8 ออก และ D6 ไม่มี official support น่าจะได้อีกอย่างน้อยปีนึง

Add new comment