หลายๆคนมักจะโพสท์ถามกันให้เห็นบ่อยๆตามฟอรั่ม php ทั่วไป ว่าทำไมสิ่งที่พวกเขาทำได้บน localhost กลับทำไม่ได้บน server จริง นั่นเป็นเพราะนักพัฒนาเหล่านั้นขาดความเข้าใจในการปรับแต่งให้เหมาะสมสำหรับสภาพแวดล้อมของการพัฒนา (development).
เมื่อนำไปใช้บน server จริงแล้ว ทำให้ใช้งานไม่ได้เหมือนเคย เป็นเพราะ server จริงแต่ละที่จะมีการปรับแต่ง php.ini สำหรับการใช้จริงเท่านั้น ซึ่ง server เหล่านั้นต้องเพิ่มความปลอดภัยอีกมาก ทำให้ต้องปรับลดส่วนต่างๆที่ไม่จำเป็นออกไป หรือปรับค่าต่างๆให้มีเงื่อนไขที่จำกัด.
การปรับแต่ง php.ini สำหรับการพัฒนาเท่านั้น เป็นสิ่งที่สำคัญมาก. มันเป็นการสร้างสภาพแวดล้อมบนเครื่องที่พัฒนาให้มีขีดจำกัดขั้นต่ำชนิดที่ server จริงทั่วไปน่าจะให้มากกว่าหรือแตกต่างออกไป แต่เมื่อรันผ่านบน localhost สำเร็จแล้ว การนำงานไปวางบน server จริง ไม่ว่าที่ใด** ก็จะใช้งานได้เป็นปกติ. นอกจากนี้ การปรับแต่ง php.ini สำหรับพัฒนาเท่านั้นยังมีความสำคัญอีก คือมีความละเอียดอ่อน แจ้งทุกอย่างที่บกพร่อง ซึ่งอาจเป็นเหตุให้โค้ดของเราถูกแฮ็คได้ และยังเพิ่มความรอบคอบในการทำงานให้ตัวเราเอง.
ก่อนการปรับแต่ง, การทับค่า php.ini
ในบทความนี้จะเน้นไปที่การปรับแต่งภายใน php.ini เป็นหลัก เพื่อกำหนดสภาพแวดล้อมของ server ในขั้นตอนการพัฒนาให้มีความรัดกุมหรือน้อยกว่าปกติ และในระหว่างการพัฒนา ความต้องการใช้ทรัพยากรอาจมากขึ้น ถึงตอนนี้ให้ใช้การทับค่า php.ini เช่นใช้ .user.ini หรือ .htaccess เป็นต้น. ตัวอย่างเช่น php.ini จะขอแนะนำให้กำหนด memory_limit ไว้ที่แค่ 64M เป็นขั้นต้น เพราะ shared hosting ส่วนใหญ่จะไม่ให้น้อยกว่านี้ แต่ในเมื่องานที่พัฒนามีขนาดใหญ่ขึ้น การใช้ memory จะต้องมากขึ้น ก็ให้ใช้การทับค่าด้วยวิธีใดวิธีหนึ่งตามที่บอก เขียนค่าลงไปใหม่ให้มากขึ้น เช่น ขยาย memory_limit เป็น 128M เพื่อให้เพียงพอกับระบบที่ใหญ่ขึ้นนั่นเอง. ทั้งนี้หากค่าที่แนะนำใน php.ini เพียงพออยู่แล้วก็ไม่จำเป็นต้องทับค่าลงไปในที่ใดๆ.
ด้วยวิธีการแบบนี้จะทำให้การ publish/upload งานไปบน server จริงจะทำงานต่อเนื่องได้เลย และแทบจะไม่มีปัญหาอีก. ในบทความนี้จะใช้คำอธิบายวิธีการทับค่า php.ini เสียใหม่ว่า การทับค่าสำหรับ production.
การติดตั้ง PHP จะมีแบบที่เป็นที่นิยมกันคือ Apache module, CGI/FastCGI, และอื่นๆ. สำหรับแบบ Apache module การสั่งทำงานทับค่าของ php.ini ให้ใช้วิธี .htaccess, แบบ CGI/FastCGI ให้ใช้วิธี .user.ini ดังตัวอย่างต่อไปนี้.
| php.ini | .htaccess | .user.ini |
|---|---|---|
| memory_limit = 64M | php_value memory_limit 128M | memory_limit = 128M |
จะเห็นได้ว่าวิธี .user.ini คือใช้ค่าเดียวกันกับ php.ini ได้เลย. สำหรับ PHP บน web server อื่นๆโปรดหาข้อมูลเพิ่มเติมจากผู้ให้บริการนั้นๆ.
การปรับแต่งต่อไปนี้ ไม่ใช่ทั้งหมดของ php.ini แต่จะแนะนำสิ่งที่ควรปรับเป็นบางส่วนไปเท่านั้น
php.ini
short_open_tag = Off ปิดการใช้งานการเขียนแบบสั้นๆ ( <? ... ?> ) server จริงหลายแห่งปิดการใช้งานนี้ ดังนั้นเราควรปิดมันด้วย และให้เปลี่ยนไปใช้ <?php ... ?> แทน. PHP ตั้งแต่รุ่น 5.4 ขึ้นไปจะไม่แนะนำให้ใช้ (discouraged), รุ่น 7.4 ขึ้นไปจะขึ้นเตือนว่าเลิกใช้ (deprecated), รุ่น 8.0 ขึ้นไปจะเอาออกและไม่มีให้ใช้อีกต่อไป (removed).
ตัวอย่างการทับค่าสำหรับ production โดยใช้ .htaccess: php_value short_open_tag 1
asp_tags = Off เราเขียน php ครับ ไม่ได้เขียน asp ( <% ... %> ) ทั้งนี้ใน PHP ตั้งแต่รุ่น 7.0 ขึ้นไปจะเอาค่าตัวนี้ออก.
output_buffering = Off เราไม่ควรเปิด output buffer โดย server เพราะหากไปใช้งานบาง server ที่ไม่ได้เปิดไว้ผลคือโค้ดอาจจะทำงานไม่ได้เลย. เมื่อต้องใช้มัน เราควรเปิดใช้ด้วยตัวเองในโค้ด คือ ใส่ ob_start(); ที่บรรทัดแรกสุดของโค้ด และ ob_end_flush(); ที่บรรทัดล่างสุด. ถ้าต้องใช้เพราะมี error เช่น Headers already sent ก็ให้ออกแบบการทำงานของสคริปเสียใหม่ ให้มีการประมวลผลเป็นส่วนแรกสุด ตามด้วยการแสดงผลเป็นส่วนสุดท้าย ก็จะช่วยได้.
ตัวอย่างการทับค่าสำหรับ production โดยใช้ .htaccess: php_flag output_buffering On หรือ php_value output_buffering 4096
max_execution_time = 30 ให้เวลาการทำงานไม่ควรเกิน 30 วินาที.
ตัวอย่างการทับค่าสำหรับ production โดยใช้ .htaccess: php_value max_execution_time 300 หมายเหตุ: 300 วินาทีคือ 5 นาที.
หาก server ที่ผู้อ่านใช้มีการใช้ mod_fcgid บน Apache ผู้อ่านควรไปกำหนดค่า FcgidIOTimeout ให้เหมาะสมกับการพัฒนาและพอดีกับค่า max_execution_time ด้วย เพื่อป้องกันปัญหา Internal server error, The connection was reset
memory_limit = 64M กำหนดลิมิตของหน่วยความจำไว้เท่านี้ ใช้งานใน shared hosting ได้สบายๆ. กรณีที่บางโปรเจ็คจำเป็นต้องใช้หน่วยความจำมาก ให้ใช้การทับค่า php.ini แทน.
ตัวอย่างการทับค่าสำหรับ production โดยใช้ .htaccess: php_value memory_limit 128M
error_reporting = E_ALL | E_STRICT รายงานทุกอย่าง ทั้ง Error, Warning, Notice เพื่อที่เราจะได้เห็นทุกอย่างว่ามีความผิดพลาดอะไรบ้าง แล้วตามแก้ให้หมดครับ. ส่วน E_STRICT คือให้ PHP แจ้งเตือนว่าโค้ดส่วนใดของคุณควรได้รับการเปลี่ยนแปลงเพื่อความเข้ากันได้กับรุ่นต่อๆไปของ PHP ครับ. ควรกำหนดข้อนี้ให้แสดงทั้งหมดทุกอย่างในขั้นตอนการเขียนงาน เพื่อลดความผิดพลาดลงบน server จริง.
ตัวอย่างการทับค่าสำหรับ production โดยใช้ .htaccess: php_value error_reporting 1
display_errors = On แสดงรายการที่ error ต่างๆ อย่างที่บอกด้านบน เพื่อที่เราจะได้ตามแก้ครับ error ไม่ใช่สิ่งที่น่ากลัวและน่าอายที่จะปิดมัน แต่เราต้องแก้มัน.
ตัวอย่างการทับค่าสำหรับ production โดยใช้ .htaccess: php_flag display_errors off
display_startup_errors = On แสดง error แม้กระทั่งตอนเริ่มต้น.
ตัวอย่างการทับค่าสำหรับ production โดยใช้ .htaccess: php_flag display_startup_errors off
log_errors = On บันทึก error ต่างๆลงบนไฟล์. ทางเว็บไซต์ php.net แนะนำให้ใช้แม้กระทั่งบนเว็บไซต์ที่ทำงานจริง (production websites).
ตัวอย่างการทับค่าสำหรับ production โดยใช้ .htaccess: php_flag log_errors on
error_log = "your/path/to/file.log" กำหนดตำแหน่งไฟล์ log ให้ถูกต้อง เพื่อเขียนบันทึก error ต่างๆ ใช้ในการตรวจสอบย้อนหลังได้.
ตัวอย่างการทับค่าสำหรับ production โดยใช้ .htaccess: php_value error_log "your/path/to/file.log"
register_globals = Off ต้องปิดไว้เพื่อความปลอดภัย นอกจากนี้ทำให้เราต้องประกาศตัวแปรให้ชัดเจนว่าเป็นอะไรมาจากไหน (เลิกวิธีเขียนแบบโบราณๆ ชนิดที่จู่ๆจะเรียก $input_name ก็เรียก กันได้แล้วครับ) เช่น การรับค่าจาก form method post ก็ให้ใช้ $name = $_POST['name']; แทนการเรียก $name เฉยๆโดยไม่บอกว่ามันคืออะไรมาจากไหน. PHP ตั้งแต่รุ่น 5.4 ขึ้นไปจะเอาค่าตัวนี้ออก.
post_max_size = 8M ไม่ควรเกินจากนี้ เพราะ server จริงส่วนใหญ่ก็ประมาณนี้ การกำหนดมากเกินไปอาจมีปัญหาเมื่อต้องย้ายไปบน server จริง.
ตัวอย่างการทับค่าสำหรับ production โดยใช้ .htaccess: php_value post_max_size 20M
magic_quotes_gpc = Off ใน php รุ่นใหม่ๆต่อๆไปจะเลิกการใช้งานส่วนนี้แล้ว ดังนั้นเราก็ควรปิดมัน แต่หาก server จริงที่ไหนยังใช้อยู่ แล้วเราต้องเผชิญกับการแปลง " เป็น \" ก็ให้ใช้ไฟล์ .htaccess หรือ .user.ini ปิดมันเสีย แล้วใช้วิธีการ escape stringแทน. PHP ตั้งแต่รุ่น 5.4 ขึ้นไปจะเอาค่าตัวนี้ออก.
ตัวอย่างการทับค่าสำหรับ production โดยใช้ .htaccess: php_flag magic_quotes_gpc Off
upload_max_filesize = 2M กำหนดค่าอัพโหลดไฟล์ไม่ควรให้มากเกินไป แม้จะต้องการอัพโหลดไฟล์ใหญ่ๆก็ควรสำรวจจาก server จริงว่าจะรองรับได้เพียงใด แล้วจึงค่อยทำการทับค่านี้ต่อไป. การกำหนดค่านี้ไม่ควรมากกว่า post_max_size หากมากกว่าควรไปปรับ post_max_size ให้มากขึ้นไปด้วยเพื่อจะได้รองรับกัน.
หาก server ที่ผู้อ่านใช้มีการใช้ mod_fcgid บน Apache ผู้อ่านควรไปกำหนดค่า FcgidMaxRequestLen ให้เหมาะสมกับการพัฒนาและพอดีกับค่า upload_max_filesize ด้วย เพื่อป้องกันปัญหา Internal server error, The connection was reset
ตัวอย่างการทับค่าสำหรับ production โดยใช้ .htaccess: php_value upload_max_filesize 10M
date.timezone = "Asia/Bangkok" อย่าลืมกำหนดค่า timezone ให้ระบบ โดยอิงค่าอื่นๆได้จาก http://php.net/manual/en/timezones.php. กรณีที่ต้องการให้มั่นใจว่าบน server จริงก็จะมี timezone ถูกต้องด้วย ให้กำหนดซ้ำอีกครั้งในไฟล์ .htaccess หรือ .user.ini.
ตัวอย่างการทับค่าสำหรับ production โดยใช้ .htaccess: php_value date.timezone 'Asia/Bangkok'
เมื่อ ทำการปรับแต่งได้ดังนี้แล้ว ให้ลอง restart web server แล้วเรียกเว็บเพจดูใหม่ จะพบได้ทันทีเลยว่า ที่ผ่านมาเราทำงานละเอียดแค่ไหน ซึ่งก็ต้องตามแก้ไขกันไป.
การแก้ไขที่ดีที่สุดก็คือแก้ไปตามวิธีการที่ถูก ไม่ใช่อุดปากมันด้วยการเติม @ ลงไปข้างหน้าในที่ๆไม่จำเป็น.
หมายเหตุ
** ยกเว้นพวก free hosting หลายแห่ง ที่มีการปรับแต่งเพื่อความปลอดภัยมากเกินธรรมดาทำให้ใช้งานแบบปกติแทบไม่ได้
