คำเตือน PHP เมื่อติดตั้งใหม่ (หมดเวลาการเชื่อมต่อ)


10

ฉันได้รับคำเตือน PHP นี้เมื่อเข้าใช้งานการติดตั้ง WordPress 3.4.1 ใหม่ (ภาษานอร์เวย์)

คำเตือน: fopen (URL_TO_MY_WORDPRESS_PAGE / wp-cron.php? doing_wp_cron = 1341476616.760519027709960937500075000): การเชื่อมต่อหมดเวลาใน PATH_TO_MY_WP_FILES

แน่นอนว่านี่คือการWP_DEBUGตั้งค่าสถานะtrueเป็นมันทำงานบนเซิร์ฟเวอร์การพัฒนา

ป้อนคำอธิบายรูปภาพที่นี่

นี้เกิดขึ้นเป็นระยะ ๆ wp-cronเพื่อให้ดูเหมือนว่าจะมีปัญหากับ

นี่น่าจะเป็นข้อผิดพลาดใน WordPress หรือมีบางอย่างผิดปกติบนเซิร์ฟเวอร์ของฉันหรือไม่? ฉันควรกังวลไหม

เซิร์ฟเวอร์นั้นเป็นเซิร์ฟเวอร์ Ubuntu สด 12.04 VM พร้อมสแต็ก LAMP

การค้นหาโดย Google แสดงว่าฉันไม่ใช่คนเดียวที่ประสบปัญหานี้ (ดูหน้าที่แสดงรายการบัฟเฟอร์ / ดัชนีรุ่นเพื่อดูข้อผิดพลาดจริง)

แก้ไข: ฉันยังได้รับคำเตือน PHP เดียวกันนี้ในหน้าแรก มันอาจจะเกี่ยวข้องกับความจริงที่ว่าเว็บเซิร์ฟเวอร์กำลังถูก NAT? ขณะนี้ฉันได้ตั้งค่าไฟร์วอลล์เพื่อชี้พอร์ต 19235 ถึง 80 บนเซิร์ฟเวอร์การพัฒนา


ในไฟล์ php.ini ของคุณallow_url_fopenตั้งไว้ที่ ON หรือไม่
its_me

ใช่allow_url_fopen = On
ohaal

คำตอบ:


10

คำตอบคือเห็นได้ชัดว่าใช่ฉันควรกังวล หลังจากการวิจัยบางอย่างฉันพบว่าคำเตือนดูเหมือนว่าเกี่ยวข้องกับการกำหนดค่าผิดพลาดบนเซิร์ฟเวอร์ที่โฮสต์ WordPress (เช่นมีปัญหากับเซิร์ฟเวอร์ของฉันไม่ใช่ WordPress)

การกำหนดค่าผิดพลาดทั่วไป:

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

ปัญหาในกรณีของฉันเกิดขึ้นจริงจากไฟร์วอลล์ของฉัน (pfSense) ซึ่งมี "ปิดใช้งานการสะท้อน NAT" โดยค่าเริ่มต้น (แสดงเป็นเหตุผลทั่วไป # 2)

บนเซิร์ฟเวอร์ตัวเองฉันพยายามเข้าถึงตัวเองโดยใช้ telnet และผลลัพธ์ก็คือ:

$ telnet external.server.hostname.com 19235
กำลังลอง XXX.XXX.XXX.XXX ...
telnet: ไม่สามารถเชื่อมต่อกับโฮสต์ระยะไกล: หมดเวลาการเชื่อมต่อ

ในการแก้ไขปัญหานี้ฉันต้องยกเลิกการเลือกปิดใช้งานการสะท้อน NATบนไฟร์วอลล์ของฉัน ในกรณีของฉันนี่คือในเว็บอินเตอร์เฟสของ pfSense ภายใต้ระบบ -> ขั้นสูง -> ไฟร์วอลล์ / NAT
ที่มา: http://forum.pfsense.org/index.php?topic=3473.0

ป้อนคำอธิบายรูปภาพที่นี่

ตอนนี้ฉันสามารถเชื่อมต่อกับตัวเอง (บนเซิร์ฟเวอร์เอง) ผ่านไฟร์วอลล์ได้:

$ telnet external.server.hostname.com 19235
กำลังลอง XXX.XXX.XXX.XXX ...
เชื่อมต่อกับ external.server.hostname.com
ตัวละคร Escape คือ '^]'

และฉันไม่ได้รับคำเตือน PHP เกี่ยวกับ wp-cron อีกต่อไป


ฉันคิดออกหลังจากอ่านคำตอบโดยละเอียดเกี่ยวกับการwp_cronอธิบายวิธีการทำงาน

คำตอบสั้น ๆ :เพิ่มส่วนนี้ลงในไฟล์ wp-config.php ของคุณ: define ('ALTERNATE_WP_CRON', จริง);

คำตอบที่ยาวมากสำหรับผู้ทำโทษตนเอง:โพสต์ตามกำหนดการไม่ได้ตอนนี้และไม่เคยมี "เสีย" นักพัฒนาของ WordPress ไม่สามารถแก้ไขได้เพราะไม่มีอะไรให้แก้ไข

ปัญหาอยู่ที่เซิร์ฟเวอร์ของคุณด้วยเหตุผลบางอย่างไม่สามารถดำเนินการกระบวนการ wp-cron ได้อย่างถูกต้อง กระบวนการนี้เป็นกลไกการกำหนดเวลาของ WordPress มันจัดการทุกอย่างตั้งแต่โพสต์ตามกำหนดเวลาไปจนถึงส่ง pingbacks ไปยังปิง XMLRPC เป็นต้น

วิธีการทำงานค่อนข้างง่าย เมื่อใดก็ตามที่หน้า WordPress โหลด WordPress ภายในจะตรวจสอบเพื่อดูว่ามันจำเป็นต้องดับ wp-cron หรือไม่ (โดยการเปรียบเทียบเวลาปัจจุบันกับ wp-cron ครั้งล่าสุด) หากไม่จำเป็นต้องเรียกใช้ wp-cron ก็จะพยายามเชื่อมต่อ HTTP กลับไปยังตัวเองโดยเรียกไฟล์ wp-cron.php

การเชื่อมต่อนี้กลับไปยังตัวเองมีเหตุผล wp-cron มีงานต้องทำมากมายและงานนั้นต้องใช้เวลา การทำให้ผู้ใช้เห็นเว็บเพจของเขาในขณะที่ทำสิ่งต่าง ๆ เป็นความคิดที่ไม่ดีดังนั้นด้วยการทำให้การเชื่อมต่อนั้นกลับมาสู่ตัวมันเองก็สามารถเรียกใช้โปรแกรม wp-cron ในกระบวนการแยกต่างหาก เนื่องจาก WordPress เองไม่สนใจเกี่ยวกับผลลัพธ์ของ wp-cron จึงรอเพียงวินาทีเดียวจากนั้นกลับไปที่การแสดงผลหน้าเว็บสำหรับผู้ใช้ ในขณะเดียวกัน wp-cron ซึ่งเปิดตัวแล้วจะทำงานจนกว่าจะเสร็จสิ้นหรือหมดเวลาในการดำเนินการ

การเชื่อมต่อ HTTP นั้นเป็นที่ที่ระบบบางระบบไม่ทำงาน โดยทั่วไป WordPress ทำหน้าที่เหมือนเว็บเบราว์เซอร์ หากไซต์ของคุณคือ http://example.com/blogดังนั้น WP จะโทร ไปที่http://example.com/blog/wp-cron.phpเพื่อเริ่มต้นกระบวนการ อย่างไรก็ตามบางเซิร์ฟเวอร์ก็ไม่สามารถทำได้ด้วยเหตุผลบางประการ ท่ามกลางเหตุผลที่เป็นไปได้:

  1. เซิร์ฟเวอร์ไม่มี DNS ดังนั้นจึงไม่สามารถระบุได้ว่า "example.com" คือใครแม้ว่าจะเป็นตัวของมันเองก็ตาม
  2. ผู้ดูแลเซิร์ฟเวอร์ในความพยายามผิดด้านความปลอดภัยได้บล็อกคำขอ "loopback" ดังนั้นจึงไม่สามารถโทรกลับไปที่ตัวเองได้
  3. เซิร์ฟเวอร์กำลังเรียกใช้บางสิ่งที่เรียกว่า "mod_security" หรือคล้ายกันซึ่งบล็อกการโทรอย่างแข็งขันเนื่องจากการกำหนดค่าที่ไม่ทำงาน
  4. อื่น ๆ อีก.

ประเด็นก็คือไม่ว่าจะด้วยเหตุผลใดก็ตามเว็บเซิร์ฟเวอร์ของคุณได้รับการกำหนดค่าด้วยวิธีที่ไม่ได้มาตรฐานซึ่งทำให้ WordPress ไม่สามารถทำงานได้ WordPress ไม่สามารถแก้ไขได้

อย่างไรก็ตามหากคุณมีเงื่อนไขนี้จะมีวิธีแก้ไขเฉพาะหน้า เพิ่มสิ่งนี้ลงในเพื่อกำหนดในไฟล์ wp-config.php ของคุณ:

define ('ALTERNATE_WP_CRON', จริง);

วิธีสำรองนี้ใช้วิธีการเปลี่ยนเส้นทางซึ่งทำให้ผู้ใช้เบราว์เซอร์ได้รับการเปลี่ยนเส้นทางเมื่อ cron จำเป็นต้องเรียกใช้เพื่อให้พวกเขากลับมาที่เว็บไซต์ทันทีในขณะที่ cron ยังคงทำงานในการเชื่อมต่อที่พวกเขาเพิ่งลดลง บางครั้งวิธีนี้อาจจะเล็กน้อยหากเป็นเช่นนั้นซึ่งเป็นสาเหตุที่ไม่ใช่ค่าเริ่มต้น

ที่มา: http://wordpress.org/support/topic/scheduled-posts-still-not-working-in-282#post-1175405

ตามที่ระบุไว้ในโพสต์ที่ยอดเยี่ยมและมีรายละเอียดนี้หากคุณไม่สามารถควบคุมการกำหนดค่าเซิร์ฟเวอร์ของคุณหรือถ้ามีสภาพแวดล้อม - วิธีแก้ปัญหาคือการวาง

define ('ALTERNATE_WP_CRON', จริง);

ในไฟล์ wp-config.php ของคุณ


3
รายงานดีมาก!
brasofilo

2
เป็นเรื่องที่ดีเมื่อผู้คนแก้ไขปัญหาของตัวเอง แต่ยอดเยี่ยมเมื่อพวกเขากลับมาวางวิธีแก้ปัญหา @ohaal ดังนั้นตอนนี้ทุกอย่างโอเคใช่ไหม
its_me

1
@AahanKrish: ตามที่ปรากฎฉันก็รวดเร็วในการเรียกนิ้ว ปัญหานี้ซับซ้อนกว่าที่คาดไว้เล็กน้อย - ผู้กระทำผิดไม่ได้รับข้อผิดพลาด apache2 อย่างที่คาดไว้ในตอนแรก ฉันได้อัปเดตคำตอบพร้อมรายละเอียดแล้ว
ohaal
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.