Peringatan PHP pada pemasangan baru (waktu koneksi habis)

10

Saya mendapatkan Peringatan PHP ini ketika mengakses pemasangan WordPress 3.4.1 yang baru (bahasa Norwegia).

Peringatan: fopen (URL_TO_MY_WORDPRESS_PAGE / wp-cron.php? Doing_wp_cron = 1341476616.7605190277099609375000): gagal membuka arus: Sambungan habis waktu di PATH_TO_MY_WP_FILES / wp-termasuk / kelas-92 pada http :php

Ini tentu saja dengan WP_DEBUGflag yang ditetapkan true, karena berjalan pada server pengembangan.

masukkan deskripsi gambar di sini

Ini terjadi sesekali, jadi sepertinya menjadi masalah dengan wp-cron.

Apakah ini kemungkinan kesalahan di WordPress atau ada yang salah di server saya? Haruskah saya khawatir?

Server adalah Ubuntu Server 12,04 VM segar dengan tumpukan LAMP.

Pencarian Google menunjukkan saya bukan satu-satunya yang mengalami ini. (Lihat versi buffered / indexed dari halaman yang terdaftar untuk melihat kesalahan yang sebenarnya.)

EDIT: Saya juga mendapatkan Peringatan PHP yang sama di halaman depan. Mungkinkah itu terkait dengan fakta bahwa server web sedang NATed? Saat ini saya sudah menyiapkan firewall untuk mengarahkan port 19235 ke 80 di server pengembangan.

ohaal
sumber
Di file php.ini Anda, allow_url_fopendiatur ke ON?
its_me
Ya,allow_url_fopen = On
ohaal

Jawaban:

10

Jawabannya rupanya YA, saya harus khawatir . Setelah beberapa penelitian, saya menemukan bahwa peringatan itu tampaknya terkait dengan kesalahan konfigurasi pada server tempat WordPress di-host (mis. Masalah dengan server saya, bukan WordPress).

Kesalahan konfigurasi umum:

  1. Server tidak memiliki DNS, sehingga tidak dapat mengetahui siapa "example.com", meskipun itu sendiri.
  2. Administrator server, dalam upaya keamanan yang salah arah, telah memblokir permintaan "loopback", sehingga tidak dapat benar-benar melakukan panggilan balik ke dirinya sendiri.
  3. Server menjalankan sesuatu yang disebut "mod_security" atau serupa, yang secara aktif memblokir panggilan karena konfigurasi mati otak.

Masalah dalam kasus saya sebenarnya disebabkan oleh firewall saya (pfSense), yang memiliki "Nonaktifkan refleksi NAT" secara default (tercantum sebagai alasan umum # 2).

Di server itu sendiri, saya mencoba menjangkau diri menggunakan telnet, dan hasilnya adalah sebagai berikut:

$ telnet external.server.hostname.com 19235
Mencoba XXX.XXX.XXX.XXX ...
telnet: Tidak dapat terhubung ke host jarak jauh: Koneksi habis

Untuk memperbaiki ini, saya harus menghapus centang Nonaktifkan refleksi NAT pada firewall saya. Dalam kasus saya, ini ada di antarmuka web pfSense di bawah System-> Advanced-> Firewall / NAT.
Sumber: http://forum.pfsense.org/index.php?topic=3473.0

masukkan deskripsi gambar di sini

Sekarang saya dapat terhubung ke diri saya sendiri (di server itu sendiri) melalui firewall:

$ telnet external.server.hostname.com 19235
Mencoba XXX.XXX.XXX.XXX ...
Terhubung ke external.server.hostname.com.
Karakter melarikan diri adalah '^]'.

dan saya tidak lagi mendapatkan peringatan PHP tentang wp-cron.


Saya menemukan jawabannya setelah membaca jawaban terperinci ini wp_cron, menjelaskan cara kerjanya.

Jawaban singkat: Tambahkan ini ke definisi dalam file wp-config.php Anda: define ('ALTERNATE_WP_CRON', true);

Jawaban yang sangat panjang, untuk masokis: posting terjadwal tidak sekarang, dan belum pernah, "rusak". Pengembang WordPress tidak dapat memperbaikinya karena tidak ada yang diperbaiki.

Masalahnya terletak pada kenyataan bahwa server Anda, karena alasan tertentu, tidak dapat menjalankan proses wp-cron dengan benar. Proses ini adalah mekanisme pengaturan waktu WordPress, ia menangani semuanya, mulai dari posting terjadwal hingga mengirim pingback ke ping XMLRPC, dll.

Cara kerjanya cukup sederhana. Setiap kali halaman WordPress dimuat, secara internal WordPress memeriksa untuk melihat apakah perlu mematikan wp-cron (dengan membandingkan waktu saat ini dengan waktu terakhir wp-cron berlari). Jika memang perlu menjalankan wp-cron, maka ia mencoba membuat koneksi HTTP kembali ke dirinya sendiri, memanggil file wp-cron.php.

Koneksi ini kembali ke dirinya sendiri ada karena suatu alasan. wp-cron memiliki banyak pekerjaan yang harus dilakukan, dan pekerjaan itu membutuhkan waktu. Menunda pengguna melihat halaman web-nya ketika melakukan banyak hal adalah ide yang buruk, jadi dengan membuat koneksi itu kembali ke dirinya sendiri, ia dapat menjalankan program wp-cron dalam proses terpisah. Karena WordPress sendiri tidak peduli dengan hasil dari wp-cron, ia hanya menunggu sebentar, lalu kembali membuat laman web untuk pengguna. Sementara itu, wp-cron, yang diluncurkan, melakukan tugasnya sampai selesai atau kehabisan waktu eksekusi.

Koneksi HTTP itu adalah tempat beberapa sistem yang dikonfigurasi dengan buruk gagal. Pada dasarnya, WordPress bertindak seperti browser web. Jika situs Anda adalah http://example.com/blog , maka WP akan memanggil http://example.com/blog/wp-cron.php untuk memulai prosesnya. Namun, beberapa server tidak dapat melakukan itu karena suatu alasan. Di antara alasan yang mungkin:

  1. Server tidak memiliki DNS, sehingga tidak dapat mengetahui siapa "example.com", meskipun itu sendiri .
  2. Administrator server, dalam upaya keamanan yang salah arah, telah memblokir permintaan "loopback", sehingga tidak dapat benar-benar melakukan panggilan balik ke dirinya sendiri.
  3. Server menjalankan sesuatu yang disebut "mod_security" atau serupa, yang secara aktif memblokir panggilan karena konfigurasi mati otak.
  4. Sesuatu yang lain

Intinya adalah bahwa untuk alasan apa pun, server web Anda dikonfigurasi dalam beberapa cara non-standar yang mencegah WordPress melakukan tugasnya. WordPress tidak bisa memperbaikinya.

Namun, jika Anda memiliki kondisi ini, ada solusinya. Tambahkan ini ke untuk mendefinisikan dalam file wp-config.php Anda:

define ('ALTERNATE_WP_CRON', true);

Metode alternatif ini menggunakan pendekatan pengalihan, yang membuat browser pengguna mendapatkan pengalihan ketika cron perlu dijalankan, sehingga mereka segera kembali ke situs sementara cron terus berjalan di koneksi yang baru saja mereka jatuhkan. Metode ini kadang-kadang agak rapuh, itulah sebabnya itu bukan default.

Sumber: http://wordpress.org/support/topic/scheduled-posts-still-not-working-in-282#post-1175405

Sebagaimana dinyatakan dalam posting yang luar biasa dan terperinci ini, jika Anda tidak memiliki kendali atas konfigurasi server Anda atau, jika berlaku, lingkungan - solusinya adalah dengan menempatkan

define ('ALTERNATE_WP_CRON', true);

dalam file wp-config.php Anda.

ohaal
sumber
3
Laporan yang sangat bagus!
brasofilo
2
Sangat menyenangkan ketika orang memecahkan masalah mereka sendiri, tetapi luar biasa ketika mereka kembali untuk menjatuhkan solusi. @ohaal Jadi, apakah semuanya baik-baik saja sekarang?
its_me
1
@ AahanKrish: Ternyata, saya agak cepat di jari pemicu. Masalahnya sedikit lebih berbelit-belit dari yang diperkirakan - pelakunya tidak, seperti yang diperkirakan sebelumnya, kesalahan apache2. Saya telah memperbarui jawaban saya dengan detailnya.
ohaal