WP-Cron თუ ნამდვილი cron: რატომ ტოვებს WordPress დაგეგმილ პოსტებს

WP-Cron დამგეგმავი არ არის. ეს არის შემოწმება, რომელიც გვერდების ჩატვირთვისას სრულდება: ყოველ ჯერზე, როცა ვინმე გვერდს ითხოვს, WordPress ათვალიერებს თავის დავალებების სიას და, თუ რომელიმეს ვადა გასულია, ფონურ მოთხოვნას აგზავნის wp-cron.php-ზე, რომ ის შეასრულოს. არ არიან ვიზიტორები - არ სრულდება დავალებები, ბევრი ვიზიტორი კი ნიშნავს უამრავ შემოწმებას. გამოსწორება, რომელიც საიტების უმეტესობას სჭირდება, სამი ნაბიჯია: დაამატე define( 'DISABLE_WP_CRON', true ); ფაილში wp-config.php, გამოიძახე wp-cron.php (ან wp cron event run --due-now) ნამდვილი cron-იდან ყოველ ხუთ წუთში და wp cron event list-ით დარწმუნდი, რომ რიგი იცლება. სტატიის დანარჩენი ნაწილი ხსნის, რატომ მუშაობს ეს, როდის არ ღირს ამის კეთება და როგორ გაარკვიო, რატომ დარჩა დაგეგმილი პოსტი წარწერით „Missed schedule“.

როგორ მუშაობს WP-Cron სინამდვილეში#

WordPress ყველა დაგეგმილ დავალებას მონაცემთა ბაზის ერთ ჩანაწერში ინახავს: ოფციაში cron, ცხრილში wp_options. ეს არის სერიალიზებული მასივი, რომლის გასაღებებიც Unix-დროის ნიშნულებია. თითოეული ჩანაწერი ასახელებს hook-ს (მოქმედების სახელს, მაგალითად wp_version_check ან publish_future_post), მის არგუმენტებს და, განმეორებადი დავალებებისთვის, ინტერვალს, მაგალითად hourly ან daily. პლაგინები საკუთარ ჩანაწერებს ამატებენ wp_schedule_event()-ით ან wp_schedule_single_event()-ით.

ყოველ მოთხოვნაზე, ჩატვირთვის დასაწყისში, WordPress იძახებს wp_cron()-ს. ეს ფუნქცია კითხულობს ოფციას cron და ერთ კითხვას სვამს: უადრესი დროის ნიშნული წარსულშია? თუ არა, არაფერი ხდება და დანახარჯი უმნიშვნელოა. თუ რამის დრო მოვიდა, ის იძახებს spawn_cron()-ს, რომელიც შემდეგს აკეთებს:

1. ამოწმებს ჩაკეტვას - transient-ს doing_cron. თუ სხვა გაშვება WP_CRON_LOCK_TIMEOUT წამზე ნაკლები ხნის წინ დაიწყო (ნაგულისხმევად 60), ის უარს ამბობს.
2. ჩაკეტვაში მიმდინარე დროს წერს.
3. სერვერიდან თავის თავს უგზავნის HTTP POST-ს - ე.წ. loopback მოთხოვნას - მისამართზე https://your-site/wp-cron.php?doing_wp_cron=<timestamp>, 0,01 წამის ლოდინის ლიმიტით და false-ზე დაყენებული blocking-ით, რომ ვიზიტორის გვერდმა მას არ დაუცადოს.
4. ახალი მოთხოვნა wp-cron.php-ზე ტვირთავს WordPress-ს, რიგრიგობით გადის ვადაგასულ დავალებებს, ასრულებს თითოეულ hook-ს, განმეორებადებს ხელახლა გეგმავს და ერთჯერადებს შლის.

იმისთვის, რისთვისაც შეიქმნა, ეს ჭკვიანური გადაწყვეტაა: 2000-იანების ვირტუალური ჰოსტინგი, სადაც მომხმარებლების უმეტესობას crontab-ის რედაქტირება საერთოდ არ შეეძლო. კონფიგურაცია არ სჭირდება და მუშაობს ნებისმიერ ჰოსტინგზე, სადაც PHP-ს საკუთარ დომენზე HTTP მოთხოვნის გაგზავნა შეუძლია. მისი ყველა სისუსტე იქიდან მოდის, რომ გამშვები ვიზიტორია.

• დრო მიახლოებითია. დავალება, „დაგეგმილი 03:00-ზე“, შესრულდება 03:00-ის შემდეგ გვერდის პირველ ნახვაზე. მშვიდ საიტზე ეს შეიძლება 07:40 იყოს.
• მშვიდი საიტები ჩერდება. სავიზიტო საიტი დღეში ათი ვიზიტით თავის საათობრივ დავალებებს დღეში ათჯერ ასრულებს და არა ოცდაოთხჯერ.
• დატვირთული საიტები გამუდმებით ამოწმებენ. თავად შემოწმება იაფია, მაგრამ ყოველი გაშვებული loopback WordPress-ის სრული ჩატვირთვაა, გრძელი დავალებები კი ნამდვილ ვიზიტორებს PHP worker-ებისთვის ეჯიბრებიან.
• ქეშიდან მიცემული გვერდები არ ითვლება. ვიზიტი, რომელსაც სრული გვერდის ქეში ემსახურება, PHP-მდე არ აღწევს, ამიტომ WP-Cron-საც არ უშვებს. რაც უკეთესია ქეშირება, მით უფრო იშვიათად ეშვება cron.
• Loopback შეიძლება ჩუმად ჩავარდეს. თუ სერვერი საკუთარ საჯარო მისამართს ვერ წვდება, გვერდზე შეცდომა არ ჩანს - დავალებები უბრალოდ არასოდეს სრულდება.

ჩაშენებული ინტერვალები და რა სრულდება მათზე#

ბირთვი ოთხ ინტერვალს არეგისტრირებს: hourly, twicedaily, daily და weekly. პლაგინები ახლებს ამატებენ ფილტრით cron_schedules, ამიტომაც ხედავ დატვირთული საიტის სიაში სახელებს, როგორიცაა every_minute ან five_minutes. ახალი ინსტალაცია ბირთვის რამდენიმე დავალებას გეგმავს:

ზუსტი სახელები და რაოდენობა WordPress-ის ვერსიებს შორის იცვლება, ამიტომ ცხრილი ტიპურად მიიჩნიე და არა ამომწურავად, საკუთარი სია კი wp cron event list-ით შეამოწმე. ავტომატური ფონური განახლებებიც cron-ით მიდის, ისევე როგორც დაგეგმილი პოსტები: როცა პოსტს გეგმავ, WordPress ამატებს ერთჯერად მოვლენას publish_future_post პოსტის დროზე, არგუმენტად კი პოსტის ID-ს.

შემდეგ მოდიან პლაგინები. სარეზერვო ასლების პლაგინები თავიანთ გაშვებებს გეგმავენ, SEO პლაგინები საიტის რუკებს ხელახლა აგებენ, უსაფრთხოების პლაგინები სკანირებას უშვებენ, WooCommerce კი მოაქვს Action Scheduler - საკუთარი რიგი, რომელიც WP-Cron-ს ერთ-ერთ გამშვებად იყენებს და მაღაზიაში ათასობით მომლოდინე მოქმედებას შეიძლება ატარებდეს. ოცდაათპლაგინიან საიტზე ნორმალურია სამოცი ან მეტი მოვლენის პოვნა, ზოგჯერ კი რამდენიმესი, რომელიც წაშლილმა პლაგინებმა დატოვეს, თავის შემდეგ რომ არ დაალაგეს.

საკუთარი დავალების რეგისტრაცია ასე გამოიყურება. შემოწმება wp_next_scheduled() მნიშვნელოვანია - მის გარეშე გვერდის ყოველი ჩატვირთვა მოვლენის კიდევ ერთ ასლს დაამატებდა.

<?phpadd_action( 'mysite_nightly_cleanup', 'mysite_do_cleanup' );function mysite_do_cleanup() {    // Delete drafts older than 90 days, prune a log table, and so on.}if ( ! wp_next_scheduled( 'mysite_nightly_cleanup' ) ) {    wp_schedule_event( strtotime( 'tomorrow 03:15' ), 'daily', 'mysite_nightly_cleanup' );}

WP-Cron დროს UTC ნიშნულებად ინახავს. დაგეგმილი პოსტის დრო რედაქტორში საიტის სასაათო სარტყელში ჩანს, რომელიც Settings, General-შია მითითებული, და WordPress მათ შორის თავად გარდაქმნის, ამიტომ სერვერის სასაათო სარტყელს მნიშვნელობა არ აქვს - სერვერის საათს, რომელიც უბრალოდ არასწორად მიდის, კი აქვს.

DISABLE_WP_CRON: გვერდის ჩატვირთვის გამშვების გამორთვა#

ამ კონსტანტას ვიწრო და ხშირად არასწორად გაგებული მოქმედება აქვს. ის უკრძალავს wp_cron()-ს გვერდების ჩატვირთვისას გაშვებას. ის არ თიშავს დაგეგმილ დავალებებს, ოფციიდან cron არაფერს შლის, და wp-cron.php კვლავ ასრულებს ყველა ვადაგასულ დავალებას, როცა ვინმე მას ითხოვს. შენ გამშვებს აშორებ და არა დამგეგმავს, ამიტომაც არის კონსტანტა ცვლილების მხოლოდ ნახევარი - მეორე ნახევარი WordPress-ისთვის ახალი გამშვების მიცემაა.

define( 'DISABLE_WP_CRON', true );/* That's all, stop editing! Happy publishing. */

ჩასვი ის სტრიქონის „stop editing“ ზემოთ. ყველაფერს, რაც wp-settings.php-ის ჩატვირთვის შემდეგ დგას, ეფექტი არ აქვს, და ეს ყველაზე ხშირი მიზეზია, რის გამოც ამბობენ, რომ კონსტანტა „არ მუშაობს“.

როდის სჯობს WP-Cron-ს თავი დაანებო

ეს ყველა საიტს არ სჭირდება. პატარა ბლოგი სტაბილური ტრაფიკით, PHP-ის წინ სრული გვერდის ქეშის გარეშე და დროზე მგრძნობიარე დავალებების გარეშე ნაგულისხმევ პარამეტრებზე მშვენივრად მუშაობს, სისტემური cron კი კიდევ ერთი რამაა, რაც ჰოსტინგის შეცვლისას გაფუჭდება. ცვლილება ღირს, თუ რომელიმე ეს მართებულია:

• დაგეგმილი პოსტები ან წერილები დროულად უნდა გავიდეს და არა „სადღაც მერე“.
• ტრაფიკი დაბალი ან არათანაბარია, ამიტომ დავალებები საათობით აგვიანებს.
• მოთხოვნების უმეტესობას სრული გვერდის ქეში ან CDN ემსახურება, ამიტომ PHP ვიზიტორს იშვიათად ხედავს.
• საიტი დატვირთულია და გინდა cron-ის სამუშაო მოთხოვნის გზიდან გაიტანო, ნამდვილი ვიზიტორებისგან შორს.
• დაყენებულია WooCommerce, წევრობის პლაგინი ან რამე, რაც Action Scheduler-ზეა აგებული - მათი რიგები გვერდის ჩატვირთვით გაშვებისას სწრაფად ჩამორჩება.

ნამდვილი cron-ით ჩანაცვლება#

ნამდვილი გამშვები არის ყველაფერი, რაც საათით მუშაობს და შეუძლია ან HTTP მოთხოვნა გაუგზავნოს wp-cron.php-ს, ან PHP გაუშვას WordPress-ის საქაღალდეში. cron-ის ხუთველიანი სინტაქსი ყველგან ერთნაირია; თუ */5 * * * * გასაშიფრია, სტატია cron გამოსახულებები ახსნილი მას ველ-ველ შლის.

ვარიანტი 1: wp-cron.php-ის გამოძახება HTTP-ით

ეს ნებისმიერი ადგილიდან მუშაობს - იმავე სერვერიდან, სხვა სერვერიდან, პატარა VDS-იდან, რომელიც უკვე გაქვს, ან ჰოსტირებული cron სერვისიდან - რადგან ეს ჩვეულებრივი ვებ-მოთხოვნაა. ეს ერთადერთი ვარიანტია, როცა ჰოსტინგი shell-ს არ გაძლევს.

*/5 * * * * curl -fsS -o /dev/null --max-time 120 "https://example.com/wp-cron.php?doing_wp_cron"

ან wget-ით, რომელიც ზოგ მინიმალურ სისტემაზე მის ნაცვლადაა:

*/5 * * * * wget -q -O /dev/null --timeout=120 "https://example.com/wp-cron.php?doing_wp_cron"

--max-time მნიშვნელოვანია. მის გარეშე გაჭედილი მოთხოვნა შეიძლება უსასრულოდ ღია დარჩეს, სანამ cron ხუთი წუთის შემდეგ შემდეგს უშვებს. დავალებები მაინც ჩვეულებრივი ვებ-მოთხოვნის შიგნით სრულდება, ამიტომ მათ ვებ-სერვერისა და თავად PHP-ის დროის ლიმიტები ზღუდავს - სარეზერვო ასლების პლაგინი, რომელსაც ათი წუთი სჭირდება, შეიძლება max_execution_time-მა ან პროქსის ლიმიტმა შეაწყვეტინოს. რომელი ლიმიტი რაზე პასუხობს, სტატიაშია PHP ini პარამეტრები, რომლებსაც მნიშვნელობა აქვს.

ვარიანტი 2: გაშვება WP-CLI-ით

თუ იმ მანქანაზე, სადაც WordPress ცხოვრობს, shell გაქვს, WP-CLI უკეთესი გამშვებია. ის ბრძანების სტრიქონის PHP-ით მუშაობს, რომელსაც შესრულების დროის ლიმიტი ჩვეულებრივ არ აქვს, არაფერი გადის ვებ-სერვერზე და არ არსებობს loopback, რომელიც ჩავარდებოდა.

*/5 * * * * cd /var/www/example.com && /usr/local/bin/wp cron event run --due-now --quiet

გაუშვი ის იმავე მომხმარებლით, ვისაც WordPress-ის ფაილები ეკუთვნის, და არა root-ით. WP-CLI root-ით მუშაობაზე --allow-root-ის გარეშე უარს საფუძვლიანად ამბობს: ფაილები, რომლებსაც დავალება შექმნის (ქეში, ატვირთვები, სარეზერვო არქივები), root-ს ეკუთვნოდა და ვებ-სერვერი მათ ვეღარ შეცვლიდა. თუ ერთი გაშვება ინტერვალზე დიდხანს შეიძლება გაგრძელდეს, ბრძანება შეფუთე flock -n /tmp/wp-cron-example.lock-ში, რომ მეორე ასლი პირველს თავზე არ დაეწყოს.

php wp-cron.php-ის პირდაპირ გამოძახება WordPress-ის საქაღალდიდან ასევე მუშაობს და WP-CLI-ს არ საჭიროებს, თუმცა WP-CLI გაცილებით უკეთეს ხელსაწყოებს გაძლევს იმის სანახავად, რა მოხდა.

რა სიხშირით გაუშვა

ყოველ წუთში გაშვება იაფია, როცა არაფერია ვადაგასული - მოთხოვნა დროის ნიშნულს ამოწმებს და გადის. დანახარჯი მხოლოდ მაშინ ჩნდება, როცა ბევრი სამუშაო დაგროვდა, და მაშინ ისედაც გინდა, რომ დაუყოვნებლივ შესრულდეს. Multisite-ზე გახსოვდეს, რომ თითოეულ საიტს საკუთარი რიგი აქვს: ციკლით გაიარე wp site list --field=url და თითოეულისთვის გაუშვი wp cron event run --due-now --url=<site>, ან თითოეული საიტის wp-cron.php გამოიძახე.

WP-CLI: რიგის ნახვა და გაშვება#

WP-CLI ყველაზე სწრაფი გზაა კითხვაზე პასუხის გასაცემად - „მუშაობს თუ არა cron“. პირველი ბრძანება ყველაფერს აჩვენებს, რაც ელოდება:

$ wp cron event list --fields=hook,next_run_relative,recurrence+------------------------------------+------------------------+---------------+| hook                               | next_run_relative      | recurrence    |+------------------------------------+------------------------+---------------+| publish_future_post                | 3 hours 20 minutes ago | Non-repeating || wp_privacy_delete_old_export_files | 2 hours 1 minute ago   | 1 hour        || wp_version_check                   | 5 hours 12 minutes     | 12 hours      || wp_scheduled_delete                | 17 hours 4 minutes     | 1 day         |+------------------------------------+------------------------+---------------+

ყველაფერი, სადაც „ago“ წერია, ვადაგასულია. ერთი-ორი მოვლენა დაახლოებით წუთით დაგვიანებული ნორმაა; მოვლენების მთელი სვეტი, რომლებიც საათობით წარსულშია, ნიშნავს, რომ cron-ს საერთოდ არავინ უშვებს. სასარგებლო ბრძანებები:

ერთი hook-ის გაშვება wp cron event run <hook>-ით პლაგინის დავალების გამართვის საუკეთესო გზაა: შეცდომებსა და გაფრთხილებებს ტერმინალში ხედავ და არ იკარგება ფონურ მოთხოვნაში, რომელსაც არავინ უყურებს. დაამატე --debug, რომ ნახო WP-CLI-ის საკუთარი კვალი იმისა, რა ჩაიტვირთა.

wp cron test ამოწმებს გვერდის ჩატვირთვის გზას - ის აგზავნის იმავე loopback-ს, რასაც spawn_cron() გაგზავნიდა, და ამასთან გეუბნება, დაყენებულია თუ არა DISABLE_WP_CRON. ჩართული კონსტანტით გაფრთხილება მოსალოდნელია; მაშინ მთავარია, ცლის თუ არა სიას შენი სისტემური cron.

თუ shell არ გაქვს, პლაგინი WP Crontrol იმავე სიას ადმინკაშივე აჩვენებს, საშუალებას გაძლევს მოვლენა მაშინვე გაუშვა და მონიშნავს მოვლენებს, რომელთა hook-ის უკან კოდი აღარ დგას. ღირს მისი დაყენება დიაგნოსტიკისთვის და შემდეგ წაშლა.

გამოტოვებული დაგეგმილი პოსტები#

„Missed schedule“ პოსტების სიაში ნიშნავს, რომ ამ პოსტის მოვლენის publish_future_post დრო მოვიდა, მაგრამ არ შესრულდა. WordPress ამ წარწერას აჩვენებს, როცა დაგეგმილი დრო გავიდა, პოსტი კი ისევ სტატუსშია future. თითქმის ყოველთვის მიზეზი ერთ-ერთი ამათგანია:

1. გამშვები არ არის. დაგეგმილ დროსა და ახლას შორის არავინ შემოსულა, ყველაფერი ქეშიდან გაიცა, ან დაყენებულია DISABLE_WP_CRON შემცვლელის გარეშე. მოვლენა ისევ რიგშია; cron-ის შემდეგი გაშვება პოსტს გამოაქვეყნებს.
2. Loopback ვერ გადის. სერვერი საკუთარ დომენს ვერ წვდება. ხშირი მიზეზები: საიტის DNS მიუთითებს CDN-ზე ან პროქსიზე, რომელიც შიგნიდან მიუწვდომელია; hairpin NAT, რომელიც სერვერის საკუთარ საჯარო მისამართთან კავშირებს აგდებს; HTTP basic auth სატესტო საიტზე; უსაფრთხოების პლაგინი ან firewall, რომელიც wp-cron.php-ზე მოთხოვნებს ბლოკავს; თვითხელმოწერილი სერტიფიკატი ლოკალურ ასლზე.
3. დავალება ჩავარდა. იმავე გაშვებაში უფრო ადრეულმა დავალებამ ფატალური შეცდომა მიიღო ან მეხსიერება ამოიწურა, და რიგის დანარჩენი ნაწილი აღარ შესრულდა. პლაგინის ერთ გაფუჭებულ hook-ს შეუძლია ყველაფერი შეაჩეროს, რაც მის უკანაა.
4. მოვლენა გაქრა. პოსტი დაგეგმილია, მაგრამ wp cron event list მისთვის publish_future_post-ს არ აჩვენებს. ეს უფრო იშვიათია - ჩვეულებრივ პოულობენ რბოლას, როცა ორი მოთხოვნა ოფციას cron ერთდროულად წერს, ან მუდმივ ობიექტურ ქეშს, რომელიც ოფციების მოძველებულ ასლს აბრუნებს.

პირველ სამ შემთხვევაში გამშვების გამოსწორება პოსტსაც ასწორებს: გაუშვი wp cron event run --due-now და ის გამოქვეყნდება. მეოთხეში გახსენი პოსტი და ხელით გამოაქვეყნე, ან ახალი დრო მიუთითე და ხელახლა დაგეგმე, რაც ახალ მოვლენას შექმნის. არსებობს პლაგინები, რომლებიც „გამოტოვებულ დაგეგმილ პოსტებს აქვეყნებენ“, და ერთადერთი, რასაც აკეთებენ, არის ის, რომ გვერდების ჩატვირთვისას ვადაგასულ მომავალ პოსტებს ეძებენ და აქვეყნებენ. ეს გამშვების პრობლემის შემოვლაა და არა გამოსწორება, ნამდვილი cron-ით კი ზედმეტია.

ALTERNATE_WP_CRON და სხვა შემოვლითი გზები#

define( 'ALTERNATE_WP_CRON', true );

ALTERNATE_WP_CRON არსებობს სერვერებისთვის, სადაც loopback ვერ იმუშავებს და ნამდვილი cron-ის დამატება შეუძლებელია. იმის ნაცვლად, რომ WordPress თავის თავს მიმართოს, ის ვიზიტორის ბრაუზერს გადაამისამართებს იმავე URL-ზე მიწერილი ?doing_wp_cron=-ით და ვადაგასულ დავალებებს ამ მოთხოვნაში ასრულებს გვერდის გაგზავნის შემდეგ. დავალებები მართლაც სრულდება, მაგრამ ფასად: მისამართის ზოლში ხილული query string, დამატებითი გადამისამართება გვერდის იმ ნახვაზე, რომელმაც ის გამოიწვია, URL-ის ვარიანტი, რომელიც შეიძლება ბმულებში ან ქეშში მოხვდეს, და cron-ის სამუშაო ისევ ტრაფიკზეა მიბმული. ეს დროებით ზომად მიიჩნიე. თუ სადმე მაინც შეგიძლია wp-cron.php-ზე HTTP მოთხოვნის დაგეგმვა, ის გააკეთე და ეს კონსტანტა გამორთული დატოვე.

ღირს კიდევ ორი დაკავშირებული კონსტანტის ცოდნა. WP_CRON_LOCK_TIMEOUT ჩაკეტვის ფანჯარას წამებში აყენებს; საიტების უმეტესობისთვის მისი გაზრდა არაფერს სასარგებლოს არ იძლევა, მაგრამ ზოგი ამცირებს, როცა cron გვერდის ჩატვირთვაზე დატოვებულია და დავალებებმა უფრო ხშირად უნდა დაიწყოს. DISABLE_WP_CRON და ALTERNATE_WP_CRON ერთდროულად არ უნდა იყოს დაყენებული - როცა პირველი ჩართულია, მეორეს მოქმედების შანსი არ ეძლევა.

wp-cron.php, ქეშირება და უსაფრთხოება#

დაყენებული DISABLE_WP_CRON-ის შემთხვევაშიც wp-cron.php პასუხობს ყველას, ვინც მას ითხოვს, და ასრულებს ყველაფერს, რისი დროც მოვიდა. ჩვეულებრივ ეს უვნებელია - თუ არაფერია ვადაგასული, მოთხოვნა სწრაფად სრულდება - მაგრამ თავდამსხმელი ან გაფუჭებული ბოტი, რომელიც მას ციკლში ურტყამს, PHP-ს აიძულებს ყოველ მოთხოვნაზე WordPress ჩატვირთოს. სტატია WordPress-ის უსაფრთხოების გაძლიერება მას xmlrpc.php-ის გვერდით განიხილავს, როგორც წერტილს, რომლის შეზღუდვაც ღირს. თუ შენი cron იმავე მანქანაზე WP-CLI-ით მუშაობს, wp-cron.php-ს HTTP-ით არავის სჭირდება მიმართვა და ვებ-სერვერზე შეგიძლია აკრძალო:

location = /wp-cron.php {    allow 127.0.0.1;    deny all;}

თუ მას გარე მანქანა HTTP-ით იძახებს, 127.0.0.1-ის ნაცვლად ამ მანქანის მისამართი დაუშვი, ან ეს location სიხშირით შეზღუდე და არა მთლიანად დაბლოკე. არ დაბლოკო, სანამ შემცვლელი გამშვები არ ამუშავდება, თორემ ისევ გამოტოვებულ გეგმებს დაუბრუნდები.

როცა cron საათით მუშაობს, ქეშირება შენ სასარგებლოდ მუშაობს. სრული გვერდის ქეში WordPress-ის წინ, რომელიც სტატიაშია აღწერილი WordPress-ის სიჩქარე და ქეშირება, ნიშნავს, რომ PHP-მდე ნაკლები მოთხოვნა აღწევს, რაც გვერდის ჩატვირთვით cron-ის დროს დავალებების გაშვების ნაკლებ შანსს ნიშნავდა. ნამდვილი გამშვებით ისინი ერთმანეთს აღარ უშლიან: ქეში ვიზიტორებს ემსახურება, cron კი რიგს. გამორიცხე wp-cron.php ქეშირების ყველა წესიდან - კონფიგურაციების უმეტესობა ამას თავისით აკეთებს, რადგან მოთხოვნას query string აქვს, მაგრამ CDN-ის წესმა „ყველაფრის ქეშირება“ შეიძლება ის გადაყლაპოს.

მეხსიერების მხარეც მნიშვნელოვანია. cron-ის მოთხოვნები მუშაობს WP_MAX_MEMORY_LIMIT-ის ქვეშ (ნაგულისხმევად 256M) და არა ფრონტენდის უფრო დაბალი ლიმიტით, ამიტომ მძიმე დავალებამ შეიძლება ხანმოკლედ გვერდის ნებისმიერ ნახვაზე მეტი მოიხმაროს. თუ საიტი ყოველ ღამე დაახლოებით ერთსა და იმავე დროს ვარდება, სანამ ტრაფიკს დააბრალებ, ნახე, რას უშვებს cron ამ საათზე - სტატია რამდენი RAM სჭირდება WordPress-ს აჩვენებს, როგორ გაზომო.

WordPress-ის cron RE:NODE-ზე#

WordPress-ის ხაზი RE:NODE-ის ვებ-ჰოსტინგში WordPress-ს პირველივე გაშვებისას აყენებს უკვე დაწერილი wp-config.php-ით საკუთარი MySQL ბაზისთვის, ამიტომ DISABLE_WP_CRON ემატება ფაილში, რომელსაც მაშინვე გახსნი ბრაუზერის ფაილ-მენეჯერში ან SFTP-ით. თავიდან არაფერი იცვლება: WP-Cron გვერდების ჩატვირთვაზე ზუსტად ისე მუშაობს, როგორც ყველგან.

პანელს აქვს ჩანართი Schedules, რომელიც სტანდარტულ cron გამოსახულებას იღებს და მიმდევრობით ასრულებს დავალებებს მათ შორის დაყოვნებებით - კონსოლის ბრძანებას, სარეზერვო ასლს ან კვების მოქმედებას (Schedules-ის სახელმძღვანელო მას ნაბიჯ-ნაბიჯ გადის). WordPress-ის საიტისთვის ეს ბუნებრივი ადგილია იმ დავალებებისთვის, რომლებიც WordPress-ის გარშემოა და არა მის შიგნით: ღამის backup იმ საათში, როცა რედაქტორებიდან არავინ მუშაობს, და backup დაგეგმილ მასობრივ ცვლილებამდე რამდენიმე წუთით ადრე. როგორც URL-ის გამოძახების უნივერსალური გზა ის აღწერილი არ არის, ამიტომ თავად wp-cron.php-ის გამშვებისთვის გამოიყენე გარე HTTP cron - შენი სხვა სერვერი ან ნებისმიერი ჰოსტირებული cron სერვისი - ზემოთ მოცემული curl სტრიქონით, რომელიც შენს დომენზე მიუთითებს. საიტი თავის დომენზე HTTPS-ს უკვე გასცემს ტარიფის პროქსი-სლოტის მეშვეობით, ამიტომ მოთხოვნა სრულიად ჩვეულებრივია.

cron-ის დავალებებისთვის პლატფორმის ორი დეტალი მნიშვნელოვანია. CPU მკაცრად შეზღუდულია ტარიფში შემავალი წილით, ამიტომ მძიმე დავალება პატარა ტარიფზე ნელა სრულდება, მაგრამ არ ვარდება; ხოლო თუ დავალება სერვერს მეხსიერების ლიმიტს გადააცილებს, კონტეინერი ჩერდება და სუფთად გადაიტვირთება swap-ის ნაცვლად, რაც cron-ის ამ გაშვებას შუაში წყვეტს. თუ ღამის დავალება იმდენად დიდია, რომ რომელიმეს ეჯახება, დროში გაანაწილე ან უფრო მაღალ ტარიფზე გადადი - ზოგადი მიდგომა აღწერილია სტატიაში ფონური დავალებები პატარა სერვერზე.

პრობლემების მოგვარების სია#

`wp cron event list`-ში მოვლენები საათობით აგვიანებს. cron-ს არაფერი უშვებს. თუ დაყენებულია DISABLE_WP_CRON, შენი სისტემური cron არ მუშაობს ან საიტამდე ვერ აღწევს - ზუსტად იგივე curl სტრიქონი ხელით გაუშვი და პასუხის კოდს დახედე. თუ დაყენებული არ არის, საიტს ქეშის გარეშე ძალიან ცოტა ტრაფიკი აქვს ან loopback ვერ გადის; wp cron test გეტყვის, რომელია.

curl სტრიქონი აბრუნებს 403-ს ან შესვლის გვერდს. მოთხოვნას ბლოკავს უსაფრთხოების პლაგინი, ვებ-აპლიკაციის firewall ან basic auth. დაუშვი გამომძახებლის მისამართი, ან გადადი WP-CLI გამშვებზე იმავე მანქანაზე.

curl სტრიქონი აბრუნებს 200-ს, მაგრამ არაფერი სრულდება. შეამოწმე, რომ URL საიტის ნამდვილი მისამართია და არა გადამისამართება www-ზე ან HTTPS-ზე - დაამატე -L, რომ მას გაჰყვეს, ან უკეთესი, პირდაპირ საბოლოო URL გამოიყენე. Multisite-ზე შეამოწმე, რომ სწორ საიტს იძახებ.

ერთი დავალება არასოდეს სრულდება და ყველაფერი მის უკან აგვიანებს. ეს hook ცალკე გაუშვი wp cron event run <hook>-ით და შეცდომა წაიკითხე. ფონური მოთხოვნების ფატალური შეცდომები PHP-ის შეცდომების ჟურნალში ხვდება და არა ეკრანზე, ამიტომ ძიების დროს ჩართე WP_DEBUG_LOG და მერე ისევ გამორთე.

ერთი და იგივე დავალება ორჯერ სრულდება. აქტიურია ორი გამშვები - cron გვერდის ჩატვირთვაზე და სისტემური cron, ან crontab-ის ორი სტრიქონი ძველი კონფიგურაციიდან. დააყენე DISABLE_WP_CRON და ზუსტად ერთი განრიგი დატოვე.

ასობით მოვლენა პლაგინიდან, რომელიც წაშალე. პლაგინმა თავისი hook-ები დატოვა. წაშალე ისინი wp cron event delete <hook>-ით ან პლაგინით WP Crontrol. ზიანი არ მოაქვთ, მაგრამ სიას ანაგვიანებენ და ნამდვილი პრობლემების შემჩნევას აძნელებენ.

FAQ#

აჩერებს თუ არა DISABLE_WP_CRON დაგეგმილი პოსტების გამოქვეყნებას?

მხოლოდ მაშინ, თუ cron-ს სხვა არაფერი უშვებს. კონსტანტა გვერდის ჩატვირთვის გამშვებს აშორებს; დაგეგმილი მოვლენები რიგში რჩება და სრულდება, როგორც კი რამე wp-cron.php-ს გამოიძახებს ან WP-CLI გაუშვებს. ნამდვილ cron-თან ერთად დაგეგმილი პოსტები უფრო ზუსტად გამოდის და არა პირიქით.

რა სიხშირით უნდა იძახებდეს ნამდვილი cron wp-cron.php-ს?

საიტების უმეტესობას ყოველი ხუთი წუთი უხდება. მაღაზიებს და ყველაფერს, რაც Action Scheduler-ს იყენებს, ყოველი წუთი სჯობს, საიტს კი დროზე მგრძნობიარე სამუშაოს გარეშე თხუთმეტიც ეყოფა. გაშვება, როცა არაფერია ვადაგასული, ერთი მოკლე PHP მოთხოვნა ჯდება.

შეიძლება თუ არა WP-Cron-ის გაშვება shell-ზე წვდომის გარეშე?

კი. გამშვებს მხოლოდ შენს საიტზე HTTPS მოთხოვნის გაგზავნა სჭირდება, ამიტომ ის ნებისმიერ ადგილას შეიძლება იცხოვროს: ჰოსტირებულ cron სერვისში, VPS-ზე, რომელიც უკვე გაქვს, ან მეგობრის სახლის სერვერზე. გამოიყენე curl სტრიქონი ლოდინის ლიმიტით და საიტის საბოლოო URL-ზე მიუთითე.

უსაფრთხოა თუ არა ALTERNATE_WP_CRON-ის გამოყენება?

მუშაობს და საშიში არ არის, მაგრამ ვიზიტორებს query string-ს აჩვენებს, გადამისამართებას ამატებს და ისევ ტრაფიკზეა დამოკიდებული. გამოიყენე მხოლოდ მაშინ, როცა loopback ვერ გადის და გარე მოთხოვნის დაგეგმვის არანაირი საშუალება არ არის.

რატომ წერს Site Health, რომ დაგეგმილი მოვლენა აგვიანებს?

Site Health თითოეული მოვლენის დროს მიმდინარეს ადარებს და ვადაგასულებს მონიშნავს. ერთი დაგვიანებული მოვლენა ჩვეულებრივ ნელ გამშვებს ნიშნავს; მთელი სია კი - რომ cron არ მუშაობს. შეამოწმე wp cron event list-ით და გამშვები გაასწორე და არა გაფრთხილება.

აფუჭებს თუ არა გვერდის ქეში WP-Cron-ს?

ასუსტებს. ქეშიდან მიცემული პასუხები PHP-მდე არ აღწევს და cron-ს არ უშვებს. კარგად ქეშირებულ საიტზე, სადაც cron გვერდის ჩატვირთვაზეა, დავალებებმა შეიძლება დიდხანს ელოდონ ქეშის გარეშე მოთხოვნას. ნამდვილ cron-ზე გადასვლა ამას სრულად წყვეტს.