- config จากไฟล์
- config จากฐานข้อมูล
- มีค่า default
- สามารถ เพิ่ม/เปลี่ยนค่า/ลบ config จาก index.php ได้
วันก่อนไปอ่านเว็บไซท์ของคุณพี่ไท้ เรื่องการตั้งโจทย์ให้กับการทำงาน เห็นว่ามันน่าจะเรียบเรียงวิธีคิดของผมในการออกแบบ CMS ตัวใหม่ ก็เลยลองมาตั้งคำถามกับตัวเองถึงความต้องการพัฒนา CMS สักหน่อย
คุณสมบัติที่ต้องการในการเขียน package
- สามารถนำกลับมาใช้ใหม่หรือพัฒนาต่อยอดได้
- สามารถเปลี่ยนฐานข้อมูลได้
- เปลี่ยนตารางข้อมูลได้
- เรียกใช้ในชื่อใหม่ได้
- เพิ่ม package folder ได้
- เปลี่ยนแบบฟอร์มการป้อนข้อมูลได้
- เปลี่ยนรูปแบบการแสดงผลได้
บทความขนาดยาวที่จะนำมาแสดงหน้าแรก ถ้ายาวเกินก็น่าจะแทรกคำสั่ง break เพื่อให้การแสดงในหน้าแรกนั้นแสดงเฉพาะส่วนสำคัญ
กำลังคิดว่า คำสั่ง break ควรจะเป็นอย่างไร บางแห่งใช้ <_!--break-->
คิดว่าน่าจะเป็น <!--break--> เลย จะดีหรือเปล่า
ว่างเว้นไปหลายวัน (คิดอะไรไม่ออก นั่งหน้าเครื่องปุ๊บก็คิดอะไรไม่ออกปั๊บเลย)
อาทิตย์นี้เลยลองเขียน member signin / signout โดยเปลี่ยนการใช้ Session ของ PHP มาเป็น ใช้ Cookie และ เก็บ user session data ไว้ใน database แทน เคยอ่านเจอจากบทความ บอกว่า ทำให้เราสามารถยืดหยุ่นในการพัฒนาโปรแกรมในอนาคตได้ง่ายขึ้น โดยเฉพาะการเขียนโปรแกรมหลายภาษาร่วมกันในเว็บเดียวกัน
clean url หมายถึงการอ้างถึง url โดยมีลักษณะเหมือนเป็น folder ซึ่ง folder ดังกล่าวไม่ได้มีอยู่จริงใน host ก็จะเกิด error 404
ให้กำหนดชื่อไฟล์ที่ server จะทำการ redirect เมื่อเกิด error 404 มาที่โปรแกรมหลัก ทุกครั้งที่มีการอ้างอิงถึง clean url ก็จะมาที่โปรแกรมหลักของเราเสมอ ในโปรแกรมหลักก็จะตรวจสอบเจ้า folder ที่ส่งมา แล้วทำงานตามที่ได้ตั้งข้อกำหนดเอาไว้
การกำหนด error 404 ได้ในไฟล .htaccess ดังนี้
## Apache/PHP/CMS settings
Customized error messages.
ErrorDocument 404 /index.php
หรือการกำหนดให้ Apache redirect page เมื่อหา page นั้นไม่เจอ
you must enable mod_rewrite module by remove # before this line in httpd.conf
# Enable mod_rewrite
LoadModule rewrite_module modules/mod_rewrite.so
- set apache to allow .htaccess file by change value AllowOverride to All
# AllowOverride controls what directives may be placed in .htaccess files. AllowOverride All
- and restart Apache
ดังนั้นทุกครั้งที่เรียกมา ก็จะถูกย้ายไปสู่ index.php
ลองเขียน oop บน php ได้หลายปีแล้ว รู้สึกว่าสะดวกดี ครั้งนี้ก็จะใช้ oop ทั้งหมดอีกเหมือนเดิม
โดยแยก program กับ template ออกจากกัน รุ่นก่อนใช้วิธีการแปล template (interpret) ซึ่งทำให้การทำงานช้า (โดยเฉพาะการวน loop) คราวนี้เลยตัดสินใจยกเลิก โดยให้ template เป็น php ไปเลย คงช่วยเรื่องความเร็วได้เยอะ
ให้มี theme object เป็นตัวควบคุบหน้าตาของเว็บ โดยเป็น object ตัวหนึ่ง
ใช้ style sheet เป็นตัวควบคุมการแสดงผล
ก่อนอื่นก็ต้องมีตัวแก่นของระบบ เพื่อจัดการเรื่องการโหลดไฟล์ต่างๆ เป็นการเพิ่มความสะดวกในการโหลดไฟล์ ทั้ง include , theme , template ตั้งชื่อให้ว่าเป็น core
ก่อนอื่นก็ต้องกำหนดรูปแบบในการติดต่อผ่าน url parameter ก่อน ว่าจะส่ง parameter กันอย่างไร
หลาย cms ใช้รูปแบบ clean url จากที่อ่านมาหลายแห่ง นับเป็นวิธีการที่ดี ที่สุดคือการจำง่าย แต่มีข้อเสียอย่างหนึ่งที่คิดได้ คือ ทุกครั้งมีมีคนคลิกเว็บ จะมี error log ของ apache 1 รายการ เพราะเป็นการเข้าถึงไฟล์หรือโฟลเดอร์ที่ไม่มีอยู่จริง ซึ่งไม่รู้ว่าจะมีผลกระทบแค่ไหน (แต่คงไม่มากนัก ถ้ากลัวก็ยกเลิกการ log เสียก็สิ้นเรื่อง)
cms ก็จะมีหลาย module เช่น member , blog , topic , news ฯลฯ ก็จะใช้ตัว module นี่แหละเป็น parameter หนึ่งในการระบุงานที่ต้องการทำ เช่น
/topic/150 -> view topic id 150
/blog/bloggang/3 -> view blog name bloggang topic id=3
/member/6 or /member/username -> view member detail id=6 or username
ตัดสินใจออกแบบ CMS รุ่นใหม่ หลังจากรุ่นแรกใช้งานมานาน และมีปัญหากับเว็บไซท์ที่มีคนดูจำนวนมาก
ครั้งนี้เลยใช้เวลาวางแผนนาน (ที่นานเพราะคิดอะไรไม่ออกนั่นแหละ) ค่อยๆ คิดทีละนิด บันทึกการทำงานทุกขั้นตอน
เริ่มกันเลย...
เจอบทความในเว็บ http://www.biolawcom.de เรื่อง เพิ่มความปลอดภัยให้เวบไซท์ง่ายๆด้วย SHA1 คิดว่าจะนำมาใช้ประโยชน์ได้ เลยลิงค์ไว้ก่อน กันลืมครับ
เจ้าของเวบไซท์ทุกท่านคงไม่มีใครอยากให้เวบไซท์ของตัวเองโดนโจมตี โดยเหล่าแครกเกอร์ทั้งหลาย (อย่าสับสนนะครับระหว่างแครกเกอร์และแฮกเกอร์) การโจมตีของเหล่าแครกเกอร์นั้นมีมากมายหลายอย่างด้วยกันครับ แล้วแต่ว่าจุดประสงค์ของผู้โจมตี แต่ส่วนมากแล้วตามหน้าเวบไซท์ต่างๆนั้นมักจะไม่ถูกโจมตีเพื่อแอบดูข้อมูล เนื่องจากเวบไซท์ส่วนมากมักเปิดเผยข้อมูลของตนอยู่แล้ว แต่การโจมตีที่เวบไซท์ต่างๆโดนกันบ่อยๆ เป็นประเภทการโจมตีเพื่อเปลี่ยนแปลงหรือทำลายข้อมูลของเวบไซท์
รายละเอียดแบบเต็มๆ อ่านได้ที่ http://www.biolawcom.de/?/blog/238