อวสานอภิมหากาพย์ run cron ก็ คิดว่าปัญหาได้ถูกเคลียร์แล้ว (หวังว่า) ปัจจุบัจจุบันยังคงเจอหน้า error บ้าง แต่น้อยลงมาก

เหตุที่แก้ได้คือ หลังจากที่ลองรันใน beta.ubuntuclub แล้ว cron ผ่านเรียบร้อยดี ก็เลยลองรันซ้ำดูอีกสักที ปรากฏว่า มันขึ้น error ของ cron มาว่า fail ในตอนที่ feed ข้อมูลในส่อนของ aggregator module ก็เลยจับได้ละว่า ใครเป็นตัวการ แต่ก็ยังงงอยู่ว่า ตอนแรกที่ทดสอบ run โดยปิด module ทั้งหมดไปทำไมมันไม่ผ่าน

ก็เลยแก้ด้วยการ ไล่ลบข้อมูล feed ของทั้งหมดทิ้งไปก่อน แล้วลบโมดูล aggregator ทิ้ง (uninstall เลย) ก็พอรันแล้วก็พบว่า cron ผ่านเรียบร้อยดี โล่งอกเลย

ในส่วนของ feed aggregator ก็ปรับมาเหลือแค่ ubuntuclub forum กับ twitter #ubuntu
ส่วน feed aggregator เดิมก็ขยับมาใช้โมดูล planet แทน

ดูเหมือนจะเรียบร้อยดี

ผ่านสงครามครั้งนี้ได้ค่า EXP มาอีกเยอะ

• drupal รัน cron ของ feed aggregator ก่อน database logging และ update module (เพื่ออะไร หรือแค่เรียงตามอักษร)
• ถ้า cron fail มันจะเสียทั้งกระบวนการเลย แทนที่จะข้ามไป
• drupal จะพยายามทำงานให้ได้ แม้ว่าบางส่วนจะเสียหาย มันจะทำงานให้ดีที่สุดเท่าที่สังขารจะอำนวย แต่นั่นก็เลยเป็นว่าเราจะไม่รู้เลยว่ามันมีปัญหาจนกว่าอาการจะสาหัส

ยิ่งใช้ยิ่งประทับใจ drupal จะติดก็บางเรื่องที่ยังปรับไม่ค่อยได้ดั่งใจ

เช้าวันเสาร์ มหากาพย์ อภิมหาสงคราม cron ยังไม่จบ โซโล่มื้อเช้าในเวลาใกล้เที่ยง กลับมากด Zelda: Spirit Track สักชั่วโมง แล้วก็ ลุกมาขัดการมหากาพย์ต่อ

ก็วันนี้ลองวิธี เอา site เดิมไปวางที่อื่น บนเซิร์ฟเวอร์เดียวกัน ก็ตะก่อนนี้นานมาแล้ว เคยตั้ง beta.ubuntuclub ไว้ เอาไว้ test web ก็เลยพอดี ใช้อันนี้ซะเลย

วิธีการก็ไม่มีไร ย้ายไฟล์ทั้งหมดไป ส่วน db ก็เปลี่ยนก้อน ข้อมูลเหมือนเดิมหมด

รอบแรก รัน manually ผ่านหน้า status report โช๊ะ ไม่ผ่าน
ถัดมาลองใหม่ โหลด drupal 6.15 มาแตกทับ รันอีกรอบ โช๊ะ ผ่านวุ๊ย
เจดดดด เสร็จล่ะกู เรียบร้อย ปิดฉายสงครามยืดเยื้อกันเถิด
ก็ทำที่ site จริง ด้วยวิธีการดังกล่าว run cron โช๊ะ ไม่ผ่าน เข็ดม่อนนน ไรเนี่ย

จบ episode 3 ไว้เท่านี้ก่อน เดี๋ยวกลับไปหาทางใหม่

ยกที่2 ของการพยายามแก้ cron จากครั้งก่อนก็ยังคงหาวิธีไม่ได้ เลยกะว่า จะเคลียร์ table ของ module ต่างๆออกให้หมด แล้วลอง run cron ดู เพื่อจะดูว่ามันเป็นที่ตัว drupal หรือเป็นที่ module ก็เลยย้ายข้อมูลทั้งหมดมาทำที่ localhost

ก็พอวางเสร็จ ก่อนจะจัดการอะไรต่อ ก็เลยลอง run cron ซะรอบนึง โอ้วพี่น้อง มันดัน run ผ่านหว่ะ ไม่ได้ปรับแต่งอะไรเลย

ก็เลย เอาล่ะ ลองติดต่อไปที่ dreamhost ดู ก็คุยไปคุยมา มาจบที่คำตอบสุดท้าย

Thank you for following up. Unfortunately we can not troubleshoot custom
Drupal installations as we only support Drupal installation made using
the DreamHost one-click installer. We can only recommend that you contact
Drupal for support for their product:

ก็ก่อนหน้านั้นผมถามไปยาวๆ โดยมีประโยคป้องกันคำตอบแบบนี้ไว้แล้ว หนึ่งชุดว่า

Today I tried to fix it in localhost (My Computer). I copy everything from /home/ubuntuclub/ubuntuclub.com/* then put it to my computer and test to run Cron without any drupal configuration (Everything same as real site, except configuration of database name). It's pretty done

แต่ก็ยังมาจบที่คำตอบแบบนี้อยู่ ก็เลยไม่รู้ว่าจะยังไงต่อดี

แผนการณ์ถัดไป คิดว่าจะลองรันบนเครื่องเดิม แต่ไปไว้ใน sub domain แทนเพื่อ test ดูก่อน

จากที่เริ่มหันมาจัดการจัดระเบียบ ubuntuclub ชุดใหญ่ ก็ได้พบว่า cron มีปัญหา ไม่ยอมรัน เท่าที่เคยเจอปัญหาที่สัมผัสกะตัวเองก็มีของ pclinuxclub.com ที่เดียว ของขานั้นแก้อยู่นาน มาสรุปได้ว่า มีปัญหาที่ binary ของไฟล์ database ก็แก้ไขโดย dump ออกมาใส่ db ก้อนใหม่ ก็คือเปลี่ยน binary นั่นแหล่ะ นอกนั้นก็มีที่เคยเสริชเจอบ้างประปราย

ของ ubuntuclub ที่มีปัญหาคือ พอรัน manually ในหน้า status แล้ว มันบอกแค่ "cron run fail" ส่วนเรียกจาก cron.php ก็ขึ้นหน้าขาวตามปกติ

จากที่ดูใน aggregator แล้ว ครั้งสุดท้ายที่ได้ข้อมูลอัพเดทมาเป็นข้อมูลของช่วงเดือนธันวาที่ผ่านมา แสดงว่า มันพังช่วงประมาณที่อัพเดทจาก drupal 6.14 ไป 6.15 แต่จริงๆแล้ว drupal 6.14 ไป 6.15 นั้น db ไม่มีการอัพเดทอะไร ดังนั้นแปลว่า มันน่าจะพังเพราะการอัพเดท module ใดสักตัว

ลองตามคำแนะนำของ @manatsawin คือ ปิดโมดูลทีละตัวดู ว่าจะ run ได้ไม๊ ก็ลองปิดจนเหลือแค่ core มันก็ยังไม่ยอมรัน แต่ไม่ได้เคลียร์ table กับ data ก็คงไม่ได้ช่วยอะไร คิดว่าเดี๋ยวจะลองดูดมาใส่ localhost แล้วลอง เคลียร์ module แบบเกลี้ยงๆดู ว่าจะรันได้ไม๊

ระหว่างนี้ยังหาทางแก้ไม่ได้ ด้วยว่าอับจนซึ่งหนทาง ตอนนี้ก็เลยแก้ด้วยวิธี ช่างมัน (เรียกแก้เหรอนั่น) แล้วไปปิดตัว database logging ไปก่อน เพราะก่อนที่จะปิดโมดูลไปนี่ เฉพาะ table access log นี่ พวกล่อไปครึ่งกิ๊กละ

ไว้หาทางแก้ได้จะมาโน๊ตไว้อีกที

วันหยุด ยังอยู่ในอารมณ์ขยันจะแก้ ubuntuclub.com คิดอยู่ว่า ubuntuclub ค่อนข้างอาภัพ เพราะผมไม่ค่อยจะดูแลสักเท่าไหร่ จะดูแลทีก็ช่วงมีอารมณ์จะดู ถึงเวลาพักนึงพอเบื่อก็ช่างหัวมัน ปล่อยไปตามยถากรรม แต่อันนี้ก็พอเข้าใจตัวเองอยู่ ดังนนั้นช่วงนี้ไฟเริ่มโหม ต้องรีบโซโล่ก่อนไฟจะมอด

ก็ที่ปรับไปแล้วคือหน้าตา theme แล้วก็ จัดการเรื่อง markdown เป็นที่เรียบร้อย wusiwyg ขยะๆจงหายไปซะ

กลับมาถึงงานช้างคือเรื่องของ tag อันนี้ถือว่ามาใช้กรรมในอดีต เพราะ admin ที่ดี ก่อน approve ข่าวมีหน้าที่ที่ต้องทำคือ

• spam หรือไม่
• ตรวจสอบความถูกต้องของเนื้อหา
• ตรวจคำผิด
• เช็คลิงก์
• การจัดฟอร์แมท
• แก้ไข tag ให้เรียบร้อย

แต่สิ่งที่ผมทำโดยมากผมจะทำแค่ข้อแรก คือ เช็คดูว่า spam ป่าว แล้ว approve เลย ดังนั้น tag มันเลยเน่ามากๆ ก็ถึงเวลาต้องมาสางย้อนหลัง

จริงๆสิ่งที่เป็นปัญหาของ ubuntuclub เลย คือ เป้าที่ผมวางไว้แต่แรกว่า ให้มันเป็นเว็บที่เปิดกว้างมากๆ คือแค่สมัครสมาชิกก็เขียนข่าวได้เลย แต่การจะเป็นเว็บแบบนั้นได้ แปลว่าต้องใช้การดูแลสูง แต่ผมกลับทำตรงข้าม

ทีนี้กลับมาที่ tag ต่อ

tag เน่าคืออะไร

• tag ไม่ตรงกับเนื้อหา
• tag ในคำที่ไม่ต้องใส่ เช่น เว็บ ubuntuclub นี่ไม่จำเป้นต้องมี tag ubuntu เพราะถ้ามันไม่เกี่ยวกับ ubuntu ก็ไม่มีเหตุให้ต้องมาเขียนในนี้
• พิมพ์ผิด อันนี้เลวร้ายมาก เช่น ubutnu หรือที่เลวร้ายกว่านั้นคือแบบที่เขียนบนวินโดวส์ คือพอมีสระแทรกในภาษาอังกฤษมันจะมองไม่เห็น
• ไม่ดู autocomplete เราจะเจอ tag เช่น command, command-line, cmd อะไรเทือกๆนี้