WP-Cron বন্ধ করে system cron কীভাবে ব্যবহার করবেন

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

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

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

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

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

প্রতিটি 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-এর এক-পঞ্চমাংশ দখল করে রাখে। এটি সাধারণত আপনার সবচেয়ে ব্যস্ত minute-এ trigger হওয়ার সম্ভাবনাই বেশি, কারণ তখন সবচেয়ে বেশি page load হয়।

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

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

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

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

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

একটি নীরব সাইটে কোন visitor-এর কারণে cron চলে

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

লক্ষণগুলো একই ধরনের। 09:00-এ প্রকাশের জন্য নির্ধারিত post, কেউ একটি page load না করা পর্যন্ত posts list-এ Missed schedule অবস্থায় থাকে। Backup plugin-গুলো রাতে কাজ চালায় না। 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-এর সঙ্গে hook করে। ওই require-এর পরে constant সংজ্ঞায়িত করলে সেটি কোনো পরিবর্তন করার জন্য খুব দেরিতে সেট হয়। ফলে file-টি সঠিক দেখালেও trigger চলতে থাকে।

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

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

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

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

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

WP-CLI হলো WordPress-এর অফিসিয়াল কমান্ড-লাইন টুল। এটি PHP কমান্ড-লাইন 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-কে সর্বনিম্ন version বলা হয়েছে। Ubuntu 24.04-এ PHP 8.3 থাকে, তাই বর্তমান server এই সীমার চেয়ে যথেষ্ট এগিয়ে। পরে sudo wp cli update দিয়ে update করুন।

WP-CLI site-এর user হিসেবে চালান, কখনো root হিসেবে নয়:

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

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

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 যে ফাইলগুলোতে লিখে সেগুলোর মালিক। দুই দিকই পরীক্ষা করুন:

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। আপনি যদি site-এর জন্য নিজস্ব 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 install করা থাকে না। তখন 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 লেখা হবে। তাই কাজ pending ছিল এমন একটি 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 চালানো হচ্ছে না। প্রথম দুইটি পরীক্ষা থেকে বোঝা যাবে সমস্যাটি cron-এ, নাকি WP-CLI-তে।

এ কাজের জন্য wp cron test ব্যবহার করবেন না। ওই command visitor-triggered spawning কাজ করছে কি না পরীক্ষা করে। DISABLE_WP_CRON সত্য হলে এটি 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 বারবার run হলে আপনার customers তা দেখতে পাবেন।

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 শুরু হয়, এক সেকেন্ডের ভগ্নাংশের মধ্যে ব্যর্থ হয়, এবং লগে একটি লাইন থাকে:

/bin/sh: 1: wp: not found

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

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

একটি interval পরে /tmp/cron-env.txt পড়ুন, তারপর লাইনটি মুছে ফেলুন। ওই ফাইলের PATH= মানটি আপনার job ঠিক যে environment পায়, সেটিই দেখায়।

এটি ঠিক করার দুটি উপায় আছে। ধাপ 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 আবার মূল সমস্যাটি তৈরি করে

এটি তৃতীয় ব্যর্থতা। পাঁচ মিনিটের তুলনায় * * * * * বেশি নিরাপদ মনে হয়, কিন্তু ব্যস্ত সাইটে এটি আপনাকে আগের অবস্থায় ফিরিয়ে দেয়। একটি run শেষ হতে interval-এর চেয়ে বেশি সময় লাগলে, প্রথমটি চলমান থাকা অবস্থাতেই পরের run শুরু হয়। দশ মিনিট পরে 10টি 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 reclaim করার জন্য 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 এড়িয়ে গেলে সেটি নকশা অনুযায়ী সঙ্গে সঙ্গে এবং নীরবে শেষ হয়।

আপনি যে সবচেয়ে কম সময়ের 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-এর মধ্যে প্রকাশিত হবে। যেসব সাইটে সময়-নির্ভর কাজ নেই, সেগুলোর জন্য 15 মিনিট যথেষ্ট। এক মিনিটের 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-এর output নীরব রাখে, কিন্তু error দেখায়। cron job-এর জন্য এটিই প্রয়োজন।

সার্ভারের schedule-এ আর কী রাখা উচিত

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

WordPress cron job কোন user-এর অধীনে চালানো উচিত?

যে user-এর মালিকানাধীন file-এ PHP লিখে, সেই user-এর অধীনে চালানো উচিত। 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 তার চেয়ে যথেষ্ট বেশি রাখুন। WP-CLI command-এর সামনে time বসিয়ে এই সময় মাপতে পারেন। Busy 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 দেখায়। ফলে log থেকে ঠিক কোন event চলেছে এবং কত সময় লেগেছে তা জানা যায়।