system cron ব্যবহার করে WP-Cron বন্ধ করার নিয়ম

WP-Cron কী এবং কেন system cron এটি প্রতিস্থাপন করে

WP-Cron হলো WordPress-এ অন্তর্নির্মিত task scheduler। এটি কেবল কেউ কোনো page request করলে চলে। WordPress-এর ভেতরে নিজে থেকে কোনো প্রক্রিয়া শুরু হয় না। Cache থেকে পরিবেশন করা হয়নি এমন প্রতিটি request-এ WordPress scheduled job-এর তালিকা পড়ে। কোনো job চালানোর সময় হয়ে গেলে কাজটি সম্পন্ন করতে এটি /wp-cron.php-এ নিজের কাছেই দ্বিতীয় HTTP request পাঠায়। এই কাজটি system cron-এ স্থানান্তর করলে নির্দিষ্ট schedule অনুযায়ী একটি পূর্বানুমেয় সময়ে job চলে, সেই মিনিটে site-এ এক হাজার visitor থাকুক বা কেউ না থাকুক।

দুটি line প্রকৃত কাজটি করে: wp-config.php-এ একটি constant এবং একটি crontab entry। এই guide-এর বাকি অংশে ওই দুটি line থেকে জানা যায় না এমন বিষয়গুলো ব্যাখ্যা করা হয়েছে। Job-টি কোন user হিসেবে চালাতে হবে, scheduled event সত্যিই চালু হয়েছে কি না তা কীভাবে নিশ্চিত করবেন, এবং site-এ কোনো বার্তা না দেখিয়ে setup ব্যর্থ হওয়ার তিনটি উপায়—এসবই এখানে রয়েছে।

উদাহরণগুলোতে WordPress directory হিসেবে /srv/www/example.com এবং web server user হিসেবে www-data ব্যবহার করা হয়েছে। সব জায়গায় আপনার নিজস্ব path ও user বসান।

ব্যস্ত সাইটে cron-এর খরচ কোন visitor ঘটিয়েছিল

প্রতিটি uncached request-এর জন্য এই check-এর খরচ হয়। WordPress `cron option লোড করে, timestamp তুলনা করে এবং কোনো কাজের সময় হলে spawn_cron() কল করে। এটি /wp-cron.php-এ একটি non-blocking loopback request পাঠায়। Visitor ফলাফলের জন্য অপেক্ষা করে না। কিন্তু একটি PHP worker অপেক্ষা করে। pm.max_children = 5`-সহ PHP-FPM চালানো একটি ছোট VPS-এ ধীরগতির একটি scheduled job যতক্ষণ চলে, ততক্ষণ আপনার PHP capacity-এর এক-পঞ্চমাংশ ধরে রাখে। এটি সবচেয়ে ব্যস্ত মিনিটে trigger হওয়ার সম্ভাবনাই বেশি, কারণ তখন সবচেয়ে বেশি page load হয়।

WordPress duplicate run সীমিত করে। এটি `WP_CRON_LOCK_TIMEOUT` lifetime-এর একটি lock নেয়, যার default মান 60 seconds। তাই একই সময়ের visitor-রা প্রত্যেকে আলাদা run শুরু করে না। এই lock duplicate run-এর সংখ্যা সীমিত করে। তবে কাজটিকে request path-এর বাইরে সরায় না।

এটি গুরুত্বপূর্ণ কি না সিদ্ধান্ত নেওয়ার আগে আপনার নিজের server-এ কত ঘন ঘন এটি fire হয় তা গণনা করুন। প্রতিটি loopback web server access log-এ দেখা যায়:

sudo grep -c 'wp-cron.php' /var/log/nginx/access.log

Apache পরিবর্তে `/var/log/apache2/access.log`-এ লেখে। প্রতিদিন হাজারের ঘরে count হলে সেটি বাস্তব খরচ। এই সংখ্যা কোনো article-এ পড়ার পরিবর্তে নিজের server-এ মাপা উচিত। অন্য কোনো পরিবর্তনের আগে ও পরে যেমন আপনি VPS benchmark করেন, একইভাবে এটি যাচাই করুন।

Caching হলে পরিস্থিতি বদলে যায়। কোনো page cache যদি অধিকাংশ request static HTML হিসেবে serve করে, তাহলে সেই request-গুলোর জন্য PHP চলে না। ফলে cron check-ও হয় না। ভালোভাবে cached একটি ব্যস্ত site নিচের quiet site-এর মতো আচরণ করতে শুরু করে।

নিরিবিলি সাইটে কোন visitor cron চালু করে?

কোনো visitor না থাকলে cron-ও চলে না। দিনে অল্প কয়েকবার visitor আসা কোনো সাইটে scheduled job-গুলোও দিনে অল্প কয়েকবার চলে, visitor আসার সেই অনির্দিষ্ট সময়গুলোতেই।

লক্ষণগুলো সব একই ধরনের। 09:00-এ প্রকাশের জন্য নির্ধারিত কোনো post, কেউ একটি page load না করা পর্যন্ত posts list-এ Missed schedule অবস্থায় থাকে। Backup plugin-গুলো রাতের backup বাদ দেয়। Update check দেরিতে হয়। ফলে dashboard-এ update করার মতো কিছু দেখা যায় না, যদিও security release ইতিমধ্যে প্রকাশিত হয়েছে। Order email, renewal notice এবং expiry warning দেরিতে পাঠানো হয়।

এসবের কোনোটি error log-এ দেখা যায় না। WordPress-এর দৃষ্টিতে job-টি দেরি করেনি, কারণ job-টি শুরুই হয়নি।

ধাপ 1: wp-config.php-এ visitor trigger বন্ধ করুন

/srv/www/example.com/wp-config.php খুলে এই constant যোগ করুন:

define( 'DISABLE_WP_CRON', true );

এটি /* That's all, stop editing! Happy publishing. */ লেখা লাইনের উপরে রাখুন, কারণ ওই comment-এর ঠিক পরের লাইনে wp-settings.php প্রয়োজন হয় এবং wp-settings.php-এর মাধ্যমে WordPress cron check-টি init-এর সঙ্গে যুক্ত করে। ওই require-এর পরে constant সংজ্ঞায়িত করলে সেটি পরিবর্তন কার্যকর করার জন্য অনেক দেরিতে সেট হয়। ফলে ফাইলটি সঠিক দেখালেও trigger চলতে থাকে।

লাইনটি প্রত্যাশিত স্থানে আছে কি না নিশ্চিত করুন:

grep -n "DISABLE_WP_CRON\|stop editing" /srv/www/example.com/wp-config.php

এই constant scheduled event বন্ধ করে না। Plugins আগের মতোই queue-তে job যোগ করতে থাকে। এটি শুধু page load-এর সময় ওই queue চালানো বন্ধ করে। ফলে ধাপ 3 শেষ না করা পর্যন্ত queue আর কখনও চলে না।

এটি /wp-cron.php-এ direct request-ও বন্ধ করে না। যে কেউ এখনও ওই URL request করতে পারে। সাধারণত এতে সমস্যা হয় না, কারণ ফাইলটি শুধু due job চালায়। Web server config-এ এটি block করা ঐচ্ছিক। তবে block করলে এই guide-এর শেষের কাছে থাকা curl fallback-ও কাজ করবে না।

ধাপ 2: WP-CLI ইনস্টল করুন

WP-CLI হলো WordPress-এর অফিসিয়াল কমান্ড-line tool। এটি PHP command-line binary ব্যবহার করে। এই binary web server-এর PHP module থেকে আলাদা package।

php -v
sudo apt install -y php-cli

phar build থেকে WP-CLI ইনস্টল করুন। অফিসিয়াল install guide-এও এটি সুপারিশ করা হয়েছে:

cd /tmp
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
php wp-cli.phar --info
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp
wp --info

php wp-cli.phar --info PHP binary-এর path, PHP version এবং WP-CLI version দেখায়। তিনটিই দেখালে phar কাজ করছে। August 2026 অনুযায়ী install guide-এ PHP 7.2.24-কে minimum version বলা হয়েছে। Ubuntu 24.04-এ PHP 8.3 ship করে, তাই বর্তমান server এই minimum-এর চেয়ে যথেষ্ট এগিয়ে। পরে sudo wp cli update দিয়ে update করুন।

সাইটের user হিসেবে WP-CLI চালান। কখনো root হিসেবে চালাবেন না:

sudo -u www-data /usr/local/bin/wp --path=/srv/www/example.com core version

root হিসেবে চালালে WP-CLI start হতে অস্বীকার করে:

Error: YIKES! It looks like you're running this as root.

এটি --allow-root ব্যবহারের পরামর্শ দেয়। এখানে এটি ব্যবহার করবেন না। কারণটি নিচের প্রথম failure mode-এ ব্যাখ্যা করা হয়েছে।

আরও মনে রাখুন, sudo -u www-data -i কাজ করে না। কারণ ওই account-এর login shell হলো /usr/sbin/nologin, ফলে This account is currently not available. পাওয়া যায়। command সরাসরি sudo -u-এ পাঠালে login shell এড়িয়ে যায়, তাই এটি ঠিকভাবে চলে।

এখন নিশ্চিত করুন, WordPress নিজেই step 1-এ যোগ করা constant দেখতে পাচ্ছে:

sudo -u www-data /usr/local/bin/wp --path=/srv/www/example.com eval 'var_dump( DISABLE_WP_CRON );'

এটি bool(true) দেখায়। undefined constant নিয়ে fatal error দেখা গেলে বুঝতে হবে define() line-এ execution পৌঁছাচ্ছে না। সাধারণত এর অর্থ হলো line-টি require-এর নিচে চলে গেছে।

ধাপ 3: সঠিক user হিসেবে cron entry যোগ করুন

সঠিক user হলো সেই user, যে PHP যে ফাইলগুলোতে লিখে, সেগুলোর owner। দুই দিকই পরীক্ষা করুন:

stat -c '%U %G' /srv/www/example.com/wp-content/uploads
grep -E '^(user|group) = ' /etc/php/8.3/fpm/pool.d/www.conf

ডিফল্ট Ubuntu install-এ দুটির উত্তরই www-data। সাইটের জন্য আলাদা user-সহ নিজস্ব PHP-FPM pool তৈরি করে থাকলে, Ubuntu 24.04-এ একটি LAMP stack-এর per-site setup-এ সাধারণত যেমন হয়, নিচের সব কাজের জন্য সেই user ব্যবহার করুন।

সেই user যেন লিখতে পারে, এমন একটি log directory তৈরি করুন:

sudo install -d -o www-data -g www-data -m 750 /var/log/wp-cron

সেই user-এর crontab সম্পাদনা করুন:

sudo crontab -u www-data -e

একটি line যোগ করুন:

*/5 * * * * /usr/bin/flock -n /run/lock/wp-cron-example.lock /usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now >> /var/log/wp-cron/example.log 2>&1

অংশগুলো আলাদা করে দেখলে। */5 এটি প্রতি পাঁচ মিনিটে চালায়। flock -n একটি lock file নেয় এবং আগের run এখনও lock ধরে রাখলে সঙ্গে সঙ্গে বন্ধ হয়ে যায়। /usr/local/bin/wp হলো absolute path, যা cron-এর প্রয়োজন। --path command-টিকে যেকোনো working directory থেকে চালাতে দেয়। --due-now queue-তে থাকা প্রতিটি event চালানোর বদলে শুধু যেসব event-এর সময় হয়েছে, সেগুলো চালায়। redirect সাধারণ output এবং error একটি file-এ পাঠায়, যা আপনি পড়তে পারবেন।

বাস্তবে এই redirect বাদ দেওয়া যায় না। Cron job-এর output তার user-কে mail করে। অধিকাংশ VPS image-এ mail transfer agent ইনস্টল করা থাকে না। ফলে cron (CRON) info (No MTA installed, discarding output) log করে এবং output ফেলে দেয়। একটি file evidence সংরক্ষণ করে।

সংরক্ষিত file পরীক্ষা করুন:

sudo crontab -u www-data -l

একাধিক site থাকলে প্রতিটির জন্য একটি করে line ব্যবহার করুন এবং minute আলাদা করে দিন, যাতে সবগুলো একসঙ্গে শুরু না হয়:

*/5 * * * * /usr/bin/flock -n /run/lock/wp-cron-one.lock /usr/local/bin/wp --path=/srv/www/one.example.com cron event run --due-now >> /var/log/wp-cron/one.log 2>&1
2-59/5 * * * * /usr/bin/flock -n /run/lock/wp-cron-two.lock /usr/local/bin/wp --path=/srv/www/two.example.com cron event run --due-now >> /var/log/wp-cron/two.log 2>&1

rotate না করলে log অনির্দিষ্টকাল বড় হতে থাকবে। /etc/logrotate.d/wp-cron লিখুন:

/var/log/wp-cron/*.log {
    weekly
    rotate 4
    missingok
    notifempty
    compress
    create 640 www-data www-data
}

কোনো কিছু পরিবর্তন না করে এটি parse হচ্ছে কি না পরীক্ষা করুন: sudo logrotate --debug /etc/logrotate.d/wp-cron।

ধাপ 4: নির্ধারিত event সত্যিই চালু হয়েছে কি না নিশ্চিত করুন

কোনো crontab line সফলভাবে সংরক্ষিত হয়েছে—এতে কিছুই প্রমাণ হয় না। সবচেয়ে সহজ পরীক্ষা থেকে শুরু করে যে পরীক্ষা বিষয়টি নিশ্চিত করে, সেভাবে এগিয়ে যান।

প্রথমত, cron কি command শুরু করেছিল? cron নিজের unit-এর অধীনে journal-এ log লেখে:

journalctl -u cron.service --since "15 min ago" | grep wp

সুস্থ entry দেখতে এমন হয়। শুরুতে থাকা timestamp এবং host name বাদ দেওয়া হয়েছে:

CRON[24913]: (www-data) CMD (/usr/bin/flock -n /run/lock/wp-cron-example.lock /usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now >> /var/log/wp-cron/example.log 2>&1)

এই line-এর অর্থ হলো cron আপনার command-টি www-data হিসেবে শুরু করেছে। command সফল হয়েছে কি না, তা এতে জানা যায় না।

দ্বিতীয়ত, WordPress কি কিছু execute করেছিল? log file পড়ুন:

sudo tail -n 20 /var/log/wp-cron/example.log

WP-CLI প্রতিটি event-এর জন্য একটি করে line এবং শেষে মোট সংখ্যা দেখায়:

Executed the cron event 'wp_version_check' in 0.418s.
Success: Executed a total of 2 cron events.

Error একই file-এ লেখা হয়। এটাই 2>&1 ব্যবহারের মূল উদ্দেশ্য। অধিকাংশ run-এ কোনো event due থাকবে না এবং খুব অল্প output লেখা হবে। তাই কাজ অপেক্ষমাণ ছিল এমন একটি run-এর পরে file পড়ুন।

তৃতীয়ত, শুরু থেকে শেষ পর্যন্ত প্রমাণ করুন। একটি marker event schedule করুন এবং সেটি অদৃশ্য হওয়া দেখুন:

sudo -u www-data /usr/local/bin/wp --path=/srv/www/example.com cron event schedule wp_cli_cron_check now
sudo -u www-data /usr/local/bin/wp --path=/srv/www/example.com cron event list --fields=hook,next_run_relative --format=csv | grep wp_cli_cron_check

একটি interval অপেক্ষা করুন। তারপর আবার list command চালান। hook-টি আর থাকবে না, কারণ one-off event চলার সময় queue থেকে সরিয়ে দেওয়া হয়। কোনো plugin ওই hook name-এ callback register করে না। তাই এটি চালালে site-এ আর কিছু হয় না। দুইটি interval পার হওয়ার পরও hook তালিকায় থাকলে queue run হচ্ছে না। প্রথম দুইটি পরীক্ষা থেকে বোঝা যাবে সমস্যাটি cron-এ, নাকি WP-CLI-এ।

এ কাজের জন্য wp cron test ব্যবহার করবেন না। ওই command visitor-triggered spawning কাজ করছে কি না পরীক্ষা করে। DISABLE_WP_CRON true হলে এটি error দেখায়। সঠিকভাবে configured server-এ ওই error-ই প্রত্যাশিত output; এটি কোনো fault নয়।

systemd timer-এর বিকল্প

সার্ভারের নির্ধারিত কাজগুলো যদি ইতিমধ্যে systemd service ও timer হিসেবে চলে, তাহলে WordPress-কেও একই ব্যবস্থায় রাখুন। প্রতিটি run তখন systemctl list-timers-এ দেখা যাবে, এবং output এমন একটি file-এর বদলে journal-এ যাবে যেটি আপনাকে rotate করতে হবে।

/etc/systemd/system/wp-cron-example.service লিখুন:

[Unit]
Description=Run due WordPress cron events for example.com

[Service]
Type=oneshot
User=www-data
Group=www-data
ExecStart=/usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now

এরপর /etc/systemd/system/wp-cron-example.timer লিখুন:

[Unit]
Description=Run WordPress cron for example.com every 5 minutes

[Timer]
OnCalendar=*:0/5
AccuracySec=30s
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now wp-cron-example.timer
systemctl list-timers wp-cron-example.timer
journalctl -u wp-cron-example.service -n 20

systemd একই service-এর দুটি copy একসঙ্গে চালাবে না। তাই এই সংস্করণে flock প্রয়োজন নেই। Persistent=true মেশিন বন্ধ থাকার সময় বাদ পড়া run পরে চালিয়ে দেয়। crontab entry এটি করতে পারে না।

crontab অথবা timer—একটি বেছে নিন। একই site-এর জন্য দুটিই চালালে queue দুইবার process হবে, এবং email বা order job একাধিকবার চললে আপনার customer-রা তা দেখতে পাবেন।

cron job root হিসেবে চালানো যাবে না

এটি setup ব্যর্থ হওয়ার তিনটি উপায়ের প্রথমটি। Job-টি root-এর crontab-এ রাখলে WP-CLI কোনো কাজ করার আগেই থেমে যায়:

Error: YIKES! It looks like you're running this as root.

Queue কখনো চালু হয় না। Output redirect না করলে আপনি বার্তাটিও দেখতে পাবেন না। বিপজ্জনক সমাধান হলো --allow-root যোগ করা। কারণ এতে ওই run চলাকালে plugin যে প্রতিটি file লেখে, সেগুলোর মালিক root হয়ে যায়। পরবর্তী web request www-data হিসেবে চলে এবং ওই directory-গুলোতে লিখতে পারে না। তখন site সাধারণত এই ধরনের বার্তা দেখাতে শুরু করে:

Unable to create directory wp-content/uploads/2026/08. Is its parent directory writable by the server?

Ownership ঠিক করুন। এরপর job-টি সরিয়ে দিন:

sudo chown -R www-data:www-data /srv/www/example.com/wp-content

Root-এর crontab এবং www-data-এর crontab আলাদা file। তাই একটির line মুছে ফেললে অন্যটির line মুছে যায় না। দুটিই পরীক্ষা করুন:

sudo crontab -u root -l
sudo crontab -u www-data -l

cron কেন wp: not found জানায়

এটি দ্বিতীয় ব্যর্থতা। Cron ব্যবহারকারীর job-এর জন্য খুব সংক্ষিপ্ত PATH দেয়: /usr/bin:/bin। WP-CLI ইনস্টল হয় /usr/local/bin-এ, যা ওই তালিকায় নেই। Job শুরু হয়, এক সেকেন্ডের ভগ্নাংশের মধ্যে ব্যর্থ হয়, এবং log-এ একটি মাত্র লাইন থাকে:

/bin/sh: 1: wp: not found

অনুমান না করে নিজেই cron-এর environment দেখুন। একটি সাময়িক line যোগ করুন:

*/5 * * * * env > /tmp/cron-env.txt 2>&1

একটি interval পরে /tmp/cron-env.txt পড়ুন, তারপর line-টি মুছে ফেলুন। ওই file-এ থাকা PATH= value-ই আপনার job যে value পায় তার সঙ্গে হুবহু মিলে যাবে।

এটির দুটি সমাধান আছে। ধাপ 3-এর মতো absolute path /usr/local/bin/wp ব্যবহার করুন। অথবা crontab-এর শুরুতে, প্রতিটি job line-এর আগে, একবার PATH সেট করুন:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

একই সমস্যা আরও এক স্তর নিচে থাকে। wp phar শুরু হয় #!/usr/bin/env php দিয়ে। তাই shell-কে php-ও খুঁজে পেতে সক্ষম হতে হবে। PHP যদি /usr/bin-এর বাইরে থাকে, যা custom build এবং control panel build-এ ঘটে, তাহলে আপনি দেখবেন:

/usr/bin/env: 'php': No such file or directory

সে ক্ষেত্রে interpreter-টি সরাসরি উল্লেখ করুন, যেমন /usr/local/bin/php /usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now।

এক মিনিটের interval কেন মূল সমস্যাটি আবার তৈরি করে

এটি তৃতীয় ব্যর্থতা। * * * * * পাঁচ মিনিটের চেয়ে নিরাপদ মনে হতে পারে, কিন্তু ব্যস্ত site-এ এটি আপনাকে আবার আগের অবস্থায় ফিরিয়ে দেয়। একটি run শেষ হতে interval-এর চেয়ে বেশি সময় লাগলে প্রথমটি চলতে থাকা অবস্থাতেই পরের run শুরু হয়। দশ মিনিট পরে দশটি PHP process থাকে, এবং প্রতিটি process নিজের memory ও নিজের database connection ধরে রাখে।

সরাসরি জমে থাকা process পরীক্ষা করুন:

ps -eo etimes,user,args | grep '[c]ron event run'

etimes হলো process-এর বয়স, seconds-এ। একটি line স্বাভাবিক। আপনার interval-এর তুলনায় অনেক বেশি age-সহ একাধিক line থাকলে বুঝবেন run-গুলো একটির ওপর আরেকটি জমছে। ছোট VPS-এ এর ফলে MySQL Too many connections error হতে পারে, অথবা memory পুনরুদ্ধারের জন্য kernel PHP process বন্ধ করে দিতে পারে। এটি sudo dmesg -T | grep -i 'killed process' দিয়ে নিশ্চিত করতে পারেন।

WP-CLI wp-cron.php-এর কাছে অনুরোধ না করে সরাসরি event callback চালায়। তাই duplicate spawn ঠেকাতে WordPress যে 60 second lock ব্যবহার করে, এখানে তা প্রযোজ্য নয়। step 3 entry-তে থাকা flock -n এখন overlap প্রতিরোধ করে। কোনো run এড়িয়ে গেলে সেটি নকশা অনুযায়ী সঙ্গে সঙ্গে এবং নীরবে exit করে। Overlap-এর সমাধান crontab-এই করতে হবে; host kernel আপনার হয়ে এটি সমাধান করে না। এমনকি Linux kernel 7.2-এ যোগ হওয়া cache-aware task placement কেবল কোন core-এ একটি process চলবে তা নির্ধারণ করে, আপনি মোট কতটি process শুরু করেছেন তা নয়।

আপনি যে সবচেয়ে ছোট schedule-এর ওপর সত্যিই নির্ভর করেন, সেই অনুযায়ী interval নির্বাচন করুন। আগে একটি run-এর সময় মাপুন:

time sudo -u www-data /usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now

পাঁচ মিনিট একটি যুক্তিসংগত default: 09:00-এ নির্ধারিত post 09:05-এর মধ্যে publish হবে। Site-এ time-critical কিছু না থাকলে পনেরো মিনিট যথেষ্ট। এক মিনিটের interval কেবল store এবং queue-driven plugin-এর জন্য উপযুক্ত, যাদের সত্যিই এটি প্রয়োজন এবং যাদের run শেষ হতে কয়েক seconds লাগে।

WP-CLI ইনস্টল করতে না পারলে

কিছু host shell tool ব্লক করে। wp-cron.php-এ একটি সাধারণ HTTP request একই queue চালায়, তবে পুরো web stack-এর মাধ্যমে:

*/5 * * * * /usr/bin/curl -sS --max-time 120 "https://example.com/wp-cron.php?doing_wp_cron" > /dev/null

আপনি যা হারাবেন, তা স্পষ্টভাবে:

• Run-এর সময় web server এবং PHP-FPM request timeout দ্বারা সীমাবদ্ধ থাকে। তাই দীর্ঘ job মাঝপথে বন্ধ হয়ে যেতে পারে।
• Certificate বৈধ হতে হবে। তা না হলে curl, SSL certificate problem দিয়ে বন্ধ হয়ে যায়। তাই nginx-এ Certbot ব্যবহার করে renewal সচল রাখুন।
• Page caching-এ wp-cron.php cache করা যাবে না। তা হলে cron request cached response পায় এবং কিছুই চালানো হয় না।
• প্রতি event-এর কোনো output পাবেন না। তাই কোনো job চলেছে কি না বোঝার একমাত্র প্রমাণ হলো সেটির প্রভাব।

সফল হলে -sS curl-কে নীরব রাখে, তবে error দেখায়। cron job-এ এটিই প্রয়োজন।

সার্ভারের সময়সূচিতে আর কী রাখা উচিত

WordPress queue-এর দায়িত্ব system cron নেওয়ার পর সার্ভারের অন্যান্য নিয়মিত কাজও একই জায়গায় রাখুন, যাতে সেগুলো পর্যবেক্ষণ করা যায়। অপারেটিং সিস্টেমের security patch নিজে হাতে রক্ষণাবেক্ষণ করা cron line-এ না রেখে unattended upgrades-এর মাধ্যমে প্রয়োগ করা উচিত। WordPress plugin ও theme update আলাদা সিদ্ধান্তের বিষয়: crontab-এ wp plugin update --all রাখলে কোনো পর্যবেক্ষণ ছাড়াই রাত 3টায় চলমান site নষ্ট হয়ে যেতে পারে। তাই এটি ইচ্ছাকৃতভাবে চালান, অথবা staging step ও backup-এর পরে চালান।

FAQ

নির্ধারিত পোস্ট প্রকাশ বন্ধ হয়ে যাবে কি, যদি WP-Cron নিষ্ক্রিয় করি?

না, যদি অন্য কোনো ব্যবস্থা queue চালায়। DISABLE_WP_CRON শুধু page load-এর মাধ্যমে queue trigger হওয়া বন্ধ করে। Event আগের মতোই নির্ধারিত থাকে। 09:00-এর জন্য নির্ধারিত পোস্ট 09:00-এর পর প্রথম cron run-এ প্রকাশিত হবে। তাই পাঁচ মিনিটের interval থাকলে এটি 09:05-এর মধ্যে প্রকাশিত হবে। Constant সেট করে cron entry যোগ না করলে পোস্টটি Missed schedule চিহ্নিত অবস্থায় তালিকায় থেকে যাবে, যতক্ষণ না কোনো ব্যবস্থা queue চালায়।

WordPress cron job কোন user হিসেবে চালানো উচিত?

যে user-এর মালিকানাধীন ফাইলে PHP লিখে। Default Ubuntu install-এ সেটি www-data। stat -c '%U %G' /srv/www/example.com/wp-content/uploads দিয়ে পরীক্ষা করুন এবং PHP-FPM pool config-এর user = line-এর সঙ্গে মিলিয়ে দেখুন। root হিসেবে job চালালে WP-CLI YIKES error দিয়ে থেমে যায়। --allow-root ব্যবহার করে জোরপূর্বক চালালে wp-content-এর ভিতরে root মালিকানাধীন file তৈরি হয়, যেগুলো web server পরে লিখতে পারে না।

System cron কত ঘন ঘন WordPress cron চালাবে?

বেশিরভাগ site-এর জন্য প্রতি পাঁচ মিনিট উপযুক্ত। আপনি যে সবচেয়ে কম schedule-এর ওপর সত্যিই নির্ভর করেন, interval সেটির সঙ্গে মিলিয়ে নিন। একটি run সম্পন্ন হতে যত সময় লাগে, interval তা থেকে যথেষ্ট বেশি রাখুন। time WP-CLI command-এর আগে বসিয়ে এই সময় মাপতে পারেন। ব্যস্ত site-এ এক মিনিটের interval থাকলে run একটির ওপর আরেকটি জমা হতে পারে, যদি না flock এগুলো নিয়ন্ত্রণ করে।

WP-Cron নিষ্ক্রিয় করার পরে wp cron test কেন ব্যর্থ হয়?

কারণ ওই command visitor triggered spawning পরীক্ষা করে। DISABLE_WP_CRON true হিসেবে সেট থাকলে এটি error দেখায়। এভাবে configured server-এ এটিই সঠিক ফলাফল। এর বদলে system cron path পরীক্ষা করুন। /var/log/wp-cron/example.log পড়ুন, অথবা wp cron event schedule দিয়ে একটি marker event schedule করুন এবং পরবর্তী run-এর পরে wp cron event list থেকে সেটি সরে গেছে কি না নিশ্চিত করুন।

আমার কি WP-CLI দরকার, নাকি wp-cron.php-এ curl করলেই হবে?

curl কাজ করে। WP-CLI install করা না গেলে এটিই উপযুক্ত পদ্ধতি। এটি ধীর, কারণ web server-এর মাধ্যমে WordPress load করে। এটি request timeout-এর দ্বারাও সীমাবদ্ধ। WP-CLI কোনো web timeout ছাড়াই command line PHP process-এ event চালায়। এটি প্রতিটি event-এর জন্য duration-সহ একটি করে line print করে। ফলে log থেকে ঠিক কোন event চলেছে এবং কত সময় লেগেছে তা জানা যায়।