WordPress میں WP-Cron بند کر کے system cron کیسے لگائیں

WP-Cron کیا ہے، اور system cron اسے کیوں بدلتا ہے

WP-Cron، WordPress میں شامل task scheduler ہے، اور یہ صرف اس وقت چلتا ہے جب کوئی page request کرے۔ WordPress کے اندر خود سے کوئی عمل اسے بیدار نہیں کرتا۔ ہر ایسی request پر جو cache سے serve نہ ہو، WordPress scheduled jobs کی فہرست پڑھتا ہے۔ اگر کوئی job واجب ہو چکی ہو تو یہ کام مکمل کرنے کے لیے /wp-cron.php پر خود کو دوسری HTTP request بھیجتا ہے۔ اس job کو system cron میں منتقل کرنے سے مقررہ schedule کے مطابق ایک قابل پیش گوئی run ہوتا ہے، چاہے اس منٹ site پر ایک ہزار visitors آئے ہوں یا کوئی بھی نہ آیا ہو۔

اصل کام دو lines کرتی ہیں: wp-config.php میں ایک constant، اور crontab entry۔ اس guide کا باقی تمام حصہ ان دو lines سے پوشیدہ تفصیلات بیان کرتا ہے۔ Job کس user کے طور پر چلنی چاہیے، یہ کیسے ثابت کریں کہ scheduled events واقعی run ہوئے، اور setup کن تین طریقوں سے site پر کچھ ظاہر کیے بغیر fail ہوتا ہے۔

مثالوں میں /srv/www/example.com کو WordPress directory اور www-data کو web server user کے طور پر استعمال کیا گیا ہے۔ ہر جگہ اپنی paths اور user استعمال کریں۔

کون سے visitor نے مصروف site پر cron کے اخراجات کو متحرک کیا

ہر uncached request کے لیے یہ check چلانے کی لاگت ادا ہوتی ہے۔ WordPress، cron option لوڈ کرتا ہے، timestamps کا موازنہ کرتا ہے، اور جب کوئی کام due ہو تو spawn_cron() کو call کرتا ہے۔ یہ /wp-cron.php کو non-blocking loopback request بھیجتا ہے۔ visitor نتیجے کا انتظار نہیں کرتا۔ PHP worker انتظار کرتا ہے۔ pm.max_children = 5 کے ساتھ PHP-FPM چلانے والے چھوٹے VPS پر ایک سست scheduled job آپ کی PHP capacity کا پانچواں حصہ اتنی دیر تک روکے رکھتی ہے جتنی دیر اسے مکمل ہونے میں لگتی ہے۔ اس کے trigger ہونے کا سب سے زیادہ امکان آپ کے مصروف ترین minute میں ہوتا ہے، کیونکہ اسی وقت سب سے زیادہ page loads ہوتے ہیں۔

WordPress duplicates کو محدود کرتا ہے۔ یہ ایک lock لیتا ہے جس کی lifetime WP_CRON_LOCK_TIMEOUT ہے، اور default طور پر 60 seconds ہوتی ہے۔ اس لیے بیک وقت آنے والے visitors میں سے ہر ایک الگ run شروع نہیں کرتا۔ یہ lock duplication کو محدود کرتا ہے۔ یہ کام کو 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 پر measure کرنی چاہیے، بالکل اسی طرح جیسے آپ کسی دوسری تبدیلی سے پہلے اور بعد میں VPS کا benchmark لیتے ہیں۔

Caching سے صورتِ حال بدل جاتی ہے۔ اگر page cache زیادہ تر requests کو static HTML کے طور پر serve کرے تو ان requests کے لیے PHP نہیں چلتا، اس لیے cron check بھی نہیں ہوتا۔ زیادہ cache شدہ busy site نیچے دی گئی quiet site جیسا برتاؤ کرنے لگتی ہے۔

خاموش ویب سائٹ پر کس وزیٹر نے cron چلایا؟

وزیٹر نہ ہوں تو cron بھی نہیں چلتا۔ جو ویب سائٹ روزانہ چند وزٹس حاصل کرتی ہے، اس کے scheduled jobs بھی روزانہ صرف اتنی ہی بار چلتے ہیں، اور وہ بھی وزٹس کے بے ترتیب اوقات میں۔

تمام علامات ایک جیسی ہوتی ہیں۔ 09:00 کے لیے scheduled کی گئی پوسٹ posts list میں Missed schedule حالت کے ساتھ موجود رہتی ہے، یہاں تک کہ کوئی شخص صفحہ لوڈ کرے۔ Backup plugins رات کا backup چھوڑ دیتے ہیں۔ Update checks تاخیر سے چلتے ہیں، اس لیے dashboard میں update کے لیے کچھ نظر نہیں آتا، حالانکہ security release پہلے ہی جاری ہو چکی ہوتی ہے۔ Order emails، renewal notices اور expiry warnings تاخیر سے بھیجے جاتے ہیں۔

ان میں سے کسی معاملے میں بھی کوئی error log نہیں ہوتا۔ WordPress کے نقطۂ نظر سے job کبھی late نہیں ہوئی، کیونکہ وہ شروع ہی نہیں ہوئی تھی۔

مرحلہ 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 define کرنے سے تبدیلی بہت دیر سے لاگو ہوتی ہے۔ فائل درست دکھائی دیتی رہتی ہے، لیکن trigger چلتا رہتا ہے۔

تصدیق کریں کہ سطر اسی جگہ موجود ہے جہاں آپ سمجھتے ہیں:

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

یہ constant scheduled events کو نہیں روکتا۔ Plugins پہلے کی طرح queue میں jobs شامل کرتے رہتے ہیں۔ یہ صرف page loads کو اس queue کو چلانے سے روکتا ہے۔ اس کا مطلب ہے کہ step 3 مکمل ہونے تک queue بالکل نہیں چلے گی۔

یہ /wp-cron.php کو براہ راست بھیجی جانے والی requests کو بھی block نہیں کرتا۔ کوئی بھی اب بھی اس URL کی request کر سکتا ہے، اور عموماً یہ بے ضرر ہوتا ہے کیونکہ فائل صرف due jobs چلاتی ہے۔ اپنے web server config میں اسے block کرنا اختیاری ہے۔ اگر آپ اسے block کرتے ہیں تو اس guide کے آخر کے قریب موجود curl fallback بھی کام نہیں کرے گا۔

مرحلہ 2: WP-CLI انسٹال کریں

WP-CLI، WordPress کے لیے سرکاری command line tool ہے۔ اسے PHP command line binary درکار ہوتی ہے، جو web server کے PHP module سے الگ package ہے۔

php -v
sudo apt install -y php-cli

WP-CLI کو phar build سے انسٹال کریں۔ سرکاری 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 bypass ہو جاتا ہے، اس لیے command درست طور پر چلتی ہے۔

اب تصدیق کریں کہ 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: درست صارف کے طور پر cron اندراج شامل کریں

درست صارف وہ ہے جو ان فائلوں کا مالک ہو جن میں 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 انسٹالیشن میں دونوں کا جواب www-data ہوتا ہے۔ اگر آپ نے site کے لیے الگ PHP-FPM pool بنایا ہے اور اس میں الگ صارف مقرر کیا ہے، جو عموماً Ubuntu 24.04 پر LAMP stack میں per-site setup کا نتیجہ ہوتا ہے، تو نیچے دیے گئے تمام مراحل کے لیے وہی صارف استعمال کریں۔

ایسی log directory بنائیں جس میں وہ صارف لکھ سکے:

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

اس صارف کا crontab ایڈٹ کریں:

sudo crontab -u www-data -e

ایک سطر شامل کریں:

*/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 کمانڈ کو کسی بھی working directory سے چلنے دیتا ہے۔ --due-now صرف ان events کو چلاتا ہے جن کا وقت آ چکا ہو، queue میں موجود ہر event کو نہیں۔ redirect عام output اور errors کو ایک ایسی file میں بھیجتا ہے جسے آپ پڑھ سکتے ہیں۔

عملی طور پر یہ redirect اختیاری نہیں ہے۔ cron job کا output اس کے صارف کو mail کرتا ہے، زیادہ تر VPS images میں mail transfer agent انسٹال نہیں ہوتا، اور پھر cron (CRON) info (No MTA installed, discarding output) log کرتا ہے اور output ضائع کر دیتا ہے۔ file رکھنے سے ثبوت محفوظ رہتا ہے۔

محفوظ کی گئی file کی جانچ کریں:

sudo crontab -u www-data -l

متعدد sites کے لیے ہر site کے لیے ایک سطر استعمال کریں اور minutes مختلف رکھیں، تاکہ وہ سب ایک ساتھ شروع نہ ہوں:

*/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: تصدیق کریں کہ مقررہ events واقعی چل گئے ہیں

کامیابی سے محفوظ ہونے والی crontab لائن کسی بات کا ثبوت نہیں ہوتی۔ سب سے کم خرچ جانچ سے شروع کریں اور پھر اس جانچ تک جائیں جو نتیجہ حتمی طور پر ثابت کرتی ہے۔

پہلے یہ دیکھیں کہ کیا cron نے command شروع کی؟ cron اپنے unit کے تحت journal میں logs لکھتا ہے:

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)

اس لائن کا مطلب ہے کہ cron نے آپ کی command کو www-data کے طور پر شروع کیا۔ اس سے یہ معلوم نہیں ہوتا کہ command کامیاب ہوئی یا نہیں۔

دوسرا، کیا WordPress نے کوئی action انجام دیا؟ log file پڑھیں:

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

WP-CLI ہر event کے لیے ایک لائن لکھتا ہے، پھر total دکھاتا ہے:

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

Errors اسی file میں لکھی جاتی ہیں، اور 2>&1 کا مقصد بھی یہی ہے۔ زیادہ تر runs میں کوئی event due نہیں ہوگا اور file میں بہت کم مواد لکھا جائے گا، اس لیے file کو ایسے run کے بعد پڑھیں جس میں آپ کو معلوم ہو کہ کام زیرِ انتظار تھا۔

تیسرا، عمل کو end to end ثابت کریں۔ ایک 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 پر کوئی دوسرا action نہیں ہوگا۔ اگر hook دو intervals کے بعد بھی درج ہو، تو queue run نہیں ہو رہی۔ پہلی دو جانچ سے معلوم ہو جائے گا کہ مسئلہ cron میں ہے یا WP-CLI میں۔

اس کام کے لیے wp cron test استعمال نہ کریں۔ یہ command جانچتی ہے کہ visitor-triggered spawning کام کرتی ہے یا نہیں، اور جب DISABLE_WP_CRON درست ہو تو error دیتی ہے۔ درست طور پر configured server پر یہ error متوقع output ہے، خرابی نہیں۔

systemd timer کا متبادل

اگر سرور کے دیگر scheduled کام پہلے ہی systemd services اور timers کے ذریعے چلتے ہیں تو 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 کی دو copies بیک وقت نہیں چلاتا، اس لیے اس version کو flock کی ضرورت نہیں ہے۔ Persistent=true اس وقت چھوٹی ہوئی run کو بعد میں چلا دیتا ہے جب مشین بند ہونے کی وجہ سے وہ run نہ ہو سکی ہو۔ crontab entry یہ کام نہیں کر سکتی۔

crontab یا timer میں سے ایک منتخب کریں۔ ایک ہی site کے لیے دونوں چلانے کا مطلب ہے کہ queue کو دو مرتبہ process کیا جا رہا ہے، اور email یا order job کی duplicate runs آپ کے customers کو نظر آئیں گی۔

cron job کو root کے طور پر کیوں نہیں چلنا چاہیے

یہ ان تین طریقوں میں سے پہلا ہے جن سے setup ناکام ہوتا ہے۔ job کو root کی crontab میں شامل کرنے پر WP-CLI کوئی کارروائی کرنے سے پہلے ہی رک جاتا ہے:

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

queue کبھی نہیں چلتی، اور اگر آپ نے output کو redirect نہیں کیا تو یہ message دکھائی نہیں دیتا۔ خطرناک حل --allow-root شامل کرنا ہے، کیونکہ اس کے بعد اس run کے دوران plugin جو بھی file لکھتا ہے، اس کی ملکیت root کی ہو جاتی ہے۔ اگلی web request www-data کے طور پر چلتی ہے، ان directories میں write نہیں کر سکتی، اور site اس طرح کے messages دکھانا شروع کر دیتی ہے:

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 الگ files ہیں، اس لیے ایک سے line حذف کرنے سے دوسری متاثر نہیں ہوتی۔ دونوں کو check کریں:

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

Cron wp: not found کی اطلاع کیوں دیتا ہے

یہ دوسری خرابی ہے۔ Cron صارف کی jobs کے لیے بہت مختصر PATH فراہم کرتا ہے، /usr/bin:/bin۔ WP-CLI، /usr/local/bin میں install ہوتا ہے، جو اس فہرست میں شامل نہیں ہے۔ Job شروع ہوتی ہے، ایک سیکنڈ کے معمولی حصے میں fail ہو جاتی ہے، اور log میں صرف ایک سطر رہ جاتی ہے:

/bin/sh: 1: wp: not found

اندازہ لگانے کے بجائے خود cron کا environment دیکھیں۔ عارضی طور پر یہ سطر شامل کریں:

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

ایک interval کے بعد /tmp/cron-env.txt پڑھیں، پھر یہ سطر حذف کر دیں۔ اس file میں موجود PATH= کی value عین وہی ہوتی ہے جو آپ کی job کو ملتی ہے۔

اس کے دو حل ہیں۔ absolute path /usr/local/bin/wp استعمال کریں، جیسا کہ step 3 میں بتایا گیا ہے۔ یا crontab کے آغاز میں، ہر job line سے پہلے، PATH ایک بار set کریں:

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 builds اور control panel builds میں ہوتا ہے، تو یہ error ملتا ہے:

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

ایسی صورت میں interpreter کو صراحت کے ساتھ call کریں، مثلاً /usr/local/bin/php /usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now۔

ایک منٹ کا وقفہ اصل مسئلے کو دوبارہ کیوں پیدا کرتا ہے

یہ تیسری خرابی ہے۔ * * * * * پانچ منٹ کے مقابلے میں زیادہ محفوظ محسوس ہوتا ہے، لیکن مصروف site پر یہ آپ کو دوبارہ اسی حالت میں پہنچا دیتا ہے جہاں سے آغاز کیا تھا۔ اگر ایک run وقفے سے زیادہ وقت لے، تو پہلا run جاری رہتے ہوئے اگلا run شروع ہو جاتا ہے۔ دس منٹ بعد دس PHP processes موجود ہوتی ہیں، اور ہر process اپنی memory اور اپنی database connection برقرار رکھتی ہے۔

براہِ راست معلوم کریں کہ processes جمع تو نہیں ہو رہیں:

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

etimes process کی عمر seconds میں دکھاتا ہے۔ ایک line معمول کے مطابق ہے۔ اگر کئی lines میں عمر آپ کے وقفے سے کہیں زیادہ ہو، تو اس کا مطلب ہے کہ runs ایک دوسرے پر جمع ہو رہے ہیں۔ چھوٹے VPS پر اس کا نتیجہ MySQL Too many connections error یا kernel کی جانب سے memory واپس حاصل کرنے کے لیے PHP کو ختم کرنے کی صورت میں نکل سکتا ہے۔ اس کی تصدیق sudo dmesg -T | grep -i 'killed process' سے کی جا سکتی ہے۔

WP-CLI event callbacks کو براہِ راست چلاتا ہے، wp-cron.php کی درخواست نہیں کرتا۔ اس لیے duplicate spawns کے خلاف WordPress کا 60 second lock یہاں لاگو نہیں ہوتا۔ step 3 entry میں موجود flock -n اب overlap کو روکتا ہے۔ جو run skip ہو، وہ ڈیزائن کے مطابق فوراً اور خاموشی سے exit ہو جاتا ہے۔

وقفہ اس مختصر ترین schedule کے مطابق منتخب کریں جس پر آپ واقعی انحصار کرتے ہیں، اور پہلے ایک run کا وقت ناپیں:

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

پانچ منٹ ایک مناسب default ہے: 09:00 پر schedule کی گئی post زیادہ سے زیادہ 09:05 تک publish ہو جائے گی۔ ایسی site کے لیے پندرہ منٹ کافی ہیں جہاں کوئی کام وقت کے لحاظ سے اہم نہ ہو۔ ایک منٹ صرف ان stores اور queue-driven plugins کے لیے مناسب ہے جنہیں واقعی اس کی ضرورت ہو، اور وہ بھی تب جب آپ جانتے ہوں کہ ایک run چند seconds میں مکمل ہو جاتا ہے۔

اگر آپ WP-CLI انسٹال نہیں کر سکتے

کچھ hosts shell tools کو block کر دیتے ہیں۔ 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 timeouts سے محدود ہوتی ہے، اس لیے طویل job درمیان میں رک سکتی ہے۔
• Certificate کا valid ہونا ضروری ہے، ورنہ curl، SSL certificate problem کے ساتھ رک جاتا ہے۔ اس لیے nginx پر Certbot کے ذریعے renewals فعال رکھیں۔
• Page caching کو wp-cron.php cache نہیں کرنا چاہیے، ورنہ cron requests کو cached response ملتا ہے اور کچھ بھی نہیں چلتا۔
• آپ کو ہر event کا output نہیں ملتا، اس لیے کسی job کے چلنے کا واحد ثبوت اس کا پیدا کردہ اثر ہوتا ہے۔

-sS کامیابی کی صورت میں curl کو خاموش رکھتا ہے، لیکن errors پھر بھی دکھاتا ہے۔ cron job میں یہی مطلوب ہے۔

سرور کے شیڈول میں اور کیا شامل ہونا چاہیے

جب system cron، WordPress queue کی ذمہ داری سنبھال لے تو سرور کے باقی معمول کے کام بھی اسی جگہ رکھیں، جہاں آپ انہیں دیکھ سکیں۔ Operating system کے security patches کے لیے آپ کی دستی طور پر برقرار رکھی گئی cron لائن کے بجائے unattended upgrades استعمال ہونے چاہئیں۔ WordPress plugin اور theme updates ایک الگ فیصلہ ہیں: crontab میں wp plugin update --all کسی نگرانی کے بغیر رات 3 بجے live site کو باآسانی خراب کر سکتا ہے، اس لیے یہ کام سوچ سمجھ کر، یا staging step اور backup کے بعد کریں۔

FAQ

کیا WP-Cron کو غیر فعال کرنے سے مقررہ پوسٹس شائع ہونا رک جاتی ہیں؟

نہیں، بشرطیکہ کوئی اور چیز queue چلائے۔ DISABLE_WP_CRON صرف page loads کو queue trigger کرنے سے روکتا ہے۔ Events پہلے کی طرح schedule رہتے ہیں۔ 09:00 کے لیے مقرر پوسٹ 09:00 کے بعد پہلی cron run پر شائع ہوتی ہے، اس لیے پانچ منٹ کا interval اسے 09:05 تک شائع کر دیتا ہے۔ اگر آپ constant set کر دیں اور cron entry شامل نہ کریں، تو پوسٹ Missed schedule سے نشان زد فہرست میں اس وقت تک موجود رہتی ہے جب تک کوئی queue نہ چلائے۔

WordPress cron job کس user کو چلانی چاہیے؟

اس user کو جو PHP کی لکھی ہوئی files کا مالک ہو۔ Default Ubuntu install میں یہ www-data ہوتا ہے۔ stat -c '%U %G' /srv/www/example.com/wp-content/uploads سے اس کی تصدیق کریں اور اسے اپنی PHP-FPM pool config میں موجود user = line سے ملائیں۔ Job کو root کے طور پر چلانے سے WP-CLI YIKES error کے ساتھ رک جاتا ہے۔ اسے --allow-root کے ذریعے زبردستی چلانے سے wp-content کے اندر root-owned files بن جاتی ہیں، جن میں web server بعد میں لکھ نہیں سکتا۔

system cron کو WordPress cron کتنی بار چلانا چاہیے؟

زیادہ تر sites کے لیے ہر پانچ منٹ مناسب ہے۔ Interval کو اس مختصر ترین schedule کے مطابق رکھیں جس پر آپ واقعی انحصار کرتے ہیں، اور اسے ایک run کے مکمل ہونے میں لگنے والے وقت سے مناسب حد تک زیادہ رکھیں۔ اس وقت کو WP-CLI command کے آگے time لگا کر ناپا جا سکتا ہے۔ مصروف site پر ایک منٹ کے intervals runs کو ایک دوسرے پر جمع کر دیتے ہیں، جب تک flock انہیں محفوظ نہ کرے۔

WP-Cron کو غیر فعال کرنے کے بعد wp cron test کیوں fail ہوتا ہے؟

کیونکہ یہ command visitor-triggered spawning کی جانچ کرتی ہے، اور جب DISABLE_WP_CRON کو true پر set کیا جائے تو error report کرتی ہے۔ اس طرح 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 events کو command line PHP process میں، web timeout کے بغیر، چلاتا ہے اور ہر event کے لیے اس کی duration سمیت ایک line print کرتا ہے۔ اس طرح log سے واضح طور پر معلوم ہو جاتا ہے کہ کیا چلا اور اسے کتنا وقت لگا۔