WP-CLI روی هاست اشتراکی: نصب و ۱۲ دستوری که کار روزمره را نصف می‌کند

بیست افزونه دارید که هر کدام آپدیت جدیدی گرفته‌اند. از پیشخوان، هر آپدیت دو کلیک است به‌علاوهٔ یک صفحهٔ انتظار و یک ری‌لود؛ بیست افزونه می‌شود چهل کلیک و نیم ساعت. بعد از آپدیت هم باید تک‌تک بروید ببینید سایت بالا می‌آید یا نه. اگر همان کار را با یک خط فرمان انجام دهید، سه دقیقه است و خروجی‌اش می‌گوید کدام افزونه آپدیت شد و کدام نشد. پیش از هر به‌روزرسانی گروهی، پلاگین‌های رهاشده را جدا کن. پیش از هر به‌روزرسانی گروهی، پلاگین‌های رهاشده را جدا کن.

همین‌جاست که اکثر مدیرهای سایت فارسی متوقف می‌شوند: شنیده‌اند WP-CLI مال سرور اختصاصی است. این تصور از جایی می‌آید که تقریباً همهٔ راهنماهای فارسی با sudo mv wp-cli.phar /usr/local/bin/wp شروع می‌شوند — دو دستوری که روی هاست اشتراکی اصلاً وجود ندارند. حقیقت این است که WP-CLI روی هاست اشتراکی کار می‌کند، به شرط اینکه بدانید کدام دو چیز را ندارید و چطور دورشان بزنید.

WP-CLI چیست و چرا از پیشخوان سریع‌تر است

WP-CLI یک برنامهٔ PHP است که در یک فایل بسته‌بندی شده (فرمت .phar) روی همان سروری اجرا می‌شود که وردپرس شما هست. کاری که می‌کند این است: فایل wp-load.php سایت شما را بارگذاری می‌کند و بعد دستور را با همان توابع خود وردپرس اجرا می‌کند. این نکته مهم است، چون یعنی WP-CLI یک ابزار بیرونی نیست که از کنار وردپرس رد شود؛ از داخل وردپرس کار می‌کند و همان قلاب‌ها (hooks) و همان قواعد دسترسی اعمال می‌شوند.

سرعتش از کجا می‌آید؟ هر کاری که در پیشخوان انجام می‌دهید، یک درخواست HTTP است: مرورگر می‌فرستد، وردپرس بوت می‌شود، ادمین لود می‌شود، پاسخ برمی‌گردد، مرورگر رندر می‌کند. برای بیست افزونه، این چرخه بیست بار تکرار می‌شود. WP-CLI یک بار بوت می‌شود و بیست کار را پشت سر هم انجام می‌دهد؛ هیچ HTML‌ای ساخته نمی‌شود و هیچ صفحه‌ای رندر نمی‌شود.

مزیت دومش از سرعت مهم‌تر است: تکرارپذیری. کاری که در پیشخوان انجام می‌دهید در هیچ‌جا ثبت نمی‌شود. دستوری که در خط فرمان می‌زنید، خودش سند است؛ می‌توانید در فایل ذخیره کنید، فردا دوباره اجرا کنید، یا به میزبان بدهید تا برایتان اجرا کند.

آیا WP-CLI روی هاست اشتراکی اجرا می‌شود

بله، و محدودیتش جایی نیست که تصور می‌شود. WP-CLI به دسترسی روت نیاز ندارد؛ به یک پوستهٔ SSH، PHP خط فرمان، و اجازهٔ نوشتن در پوشهٔ خانگی خودتان نیاز دارد. هر سه مورد در اکثر پلن‌های اشتراکی cPanel و DirectAdmin هست.

چیزهایی که لازم دارید

• دسترسی SSH یا Terminal. در cPanel معمولاً بخشی به نام SSH Access یا Terminal در دستهٔ Advanced وجود دارد. اگر هیچ‌کدام را نمی‌بینید، از میزبان بپرسید؛ بعضی پلن‌های ارزان آن را بسته‌اند.
• PHP خط فرمان با نسخهٔ ۷.۲.۲۴ یا بالاتر. این حداقل رسمی WP-CLI است. برای وردپرس امروز، ۸.۱ به بالا منطقی‌تر است.
• وردپرس ۴.۹ یا بالاتر. نسخه‌های قدیمی‌تر ممکن است بخشی از دستورها را ناقص اجرا کنند.
• اجازهٔ نوشتن در پوشهٔ خانگی. فایل wp-cli.phar باید جایی بنشیند که مالکش خودتان باشید.

چیزهایی که لازم ندارید

• روت یا sudo. هیچ‌کدام. و بهتر است هیچ‌وقت سراغشان نروید.
• نوشتن در /usr/local/bin. این پوشه مال روت است و روی هاست اشتراکی برای شما قابل نوشتن نیست.
• نصب افزونه. WP-CLI افزونهٔ وردپرس نیست؛ برنامه‌ای جدا در سطح سیستم است.

آزمون سی‌ثانیه‌ای قبل از شروع

وارد SSH شوید — یا در cPanel دکمهٔ Terminal را بزنید — و این چهار خط را بزنید:

pwd
php -v
php -m | grep -i phar
php -m | grep -i mysqli

خروجی سالم چیزی شبیه این است. خط اول مسیر پوشهٔ خانگی شماست، خط دوم نسخهٔ PHP خط فرمان، و دو خط آخر باید نام Phar و mysqli را برگردانند:

/home/example
PHP 8.2.27 (cli) (built: Nov 21 2025 09:02:31) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.2.27, Copyright (c) Zend Technologies
    with Zend OPcache v8.2.27, Copyright (c), by Zend Technologies
Phar
mysqli

اگر خروجی php -m | grep -i phar چیزی برنگرداند، WP-CLI اجرا نمی‌شود مگر میزبان Phar را باز کند؛ ادامه دادن بی‌فایده است. اگر pwd چیزی مثل /home/example برگرداند، شما در حالت درست هستید.

وقتی SSH از نوع JAILSHELL است

بعضی میزبان‌ها پوسته را در محیط بسته (jailshell) اجرا می‌کنند. در این حالت هم همه‌چیز کار می‌کند، به جز دو چیز: نمی‌توانید به بیرون از پوشهٔ خانگی خودتان بنویسید، و بعضی دستورهای سیستمی مثل crontab شاید در دسترس نباشند. آن‌ها را از پنل تنظیم می‌کنید، نه از خط فرمان.

نصب WP-CLI از طریق SSH بدون دسترسی روت

روش رسمی WP-CLI برای نصب، دانلود فایل .phar و گذاشتنش روی PATH است. بخش sudo آن راهنما برای سرور اختصاصی است. اینجا همان مسیر را بدون روت می‌رویم.

گام ۱ — دانلود فایل

اول مطمئن شوید در پوشهٔ خانگی خودتان هستید، بعد فایل را بگیرید:

cd ~
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
ls -lh wp-cli.phar

خروجی باید فایلی چند مگابایتی نشان بدهد:

-rw-r--r--  1 example example  7.4M Nov  1 10:12 wp-cli.phar

اگر حجم فایل چند کیلوبایت است، دانلود ناقص بوده یا شبکه بسته شده؛ دوباره بگیرید. اگر خطای curl: (60) SSL certificate problem گرفتید، به‌جای -k (که تأیید گواهی را خاموش می‌کند و کار درستی نیست) با میزبان تماس بگیرید تا گواهی میانی سرور را درست کند.

گام ۲ — اجرایی کردن و آزمون

chmod +x wp-cli.phar
php wp-cli.phar --info

خروجی --info همهٔ چیزی است که برای عیب‌یابی لازم دارید: نسخهٔ PHP، فایل php.iniای که واقعاً استفاده می‌شود، و نسخهٔ WP-CLI.

OS:     Linux 4.18.0-513.5.1.el8_9.x86_64 #1 SMP x86_64
Shell:  /bin/bash
PHP binary:     /usr/bin/php
PHP version:    8.2.27
php.ini used:   /opt/cpanel/ea-php82/root/etc/php.ini
MySQL binary:   /usr/bin/mysql
MySQL version:  mysql  Ver 15.1 Distrib 10.6.17-MariaDB
WP-CLI root dir:        phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI phar path:       /home/example
WP-CLI cache dir:       /home/example/.wp-cli/cache
WP-CLI version: 2.12.0

دو خط از این خروجی را یادداشت کنید: PHP binary و PHP version. دو بخش بعدی به همین دو خط وصل‌اند.

گام ۳ — گذاشتن در PATH بدون روت

در پوشهٔ خانگی یک پوشهٔ bin بسازید و فایل را با نام wp آنجا بگذارید. چون این پوشه مال خودتان است، هیچ مجوزی لازم ندارد:

mkdir -p ~/bin
mv wp-cli.phar ~/bin/wp
chmod +x ~/bin/wp
echo 'export PATH="$HOME/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc
wp cli version

خروجی:

WP-CLI 2.12.0

اگر wp: command not found گرفتید، یعنی source ~/.bashrc اجرا نشده یا نشست SSH شما پوستهٔ دیگری (sh) دارد. یک بار از SSH خارج و دوباره وارد شوید. اگر باز هم نبود، فایل پیکربندی پوستهٔ خود را پیدا کنید؛ روی بعضی پوسته‌ها ~/.profile خوانده می‌شود نه ~/.bashrc.

چرا sudo mv /usr/local/bin/wp را اجرا نکنید

چون روی هاست اشتراکی این کار یا خطای Permission denied می‌دهد، یا اگر بدهید و به‌نحوی انجام شود، فایل را با مالکیت روت در مسیر مشترک می‌گذارید که هم مسئلهٔ امنیتی است و هم در آپدیت‌های بعدی به مشکل می‌خورد. روش ~/bin همان نتیجه را می‌دهد، بدون هیچ ریسکی، و به میزبان هم وابسته نیست.

اگر wp --info از قبل روی هاست کار می‌کرد، یعنی میزبان WP-CLI نصب کرده است. اول wp cli version بزنید؛ اگر نسخه قدیمی بود و wp cli update اجازهٔ نوشتن نداشت، همان فایل شخصی خودتان را در ~/bin بگذارید و در PATH مقدمش کنید تا نسخهٔ خودتان اجرا شود.

تنظیم alias و اتصال به دیتابیس

WP-CLI به دیتابیس وصل نمی‌شود مگر از فایل wp-config.php بخواند. یعنی هیچ زمان رمز دیتابیس را در دستور نمی‌نویسید و هیچ اتصال جداگانه‌ای تنظیم نمی‌کنید: کافی است WP-CLI بداند پوشهٔ وردپرس کجاست.

پوشهٔ وردپرس را به WP-CLI معرفی کنید

ساده‌ترین راه، رفتن به پوشهٔ سایت است:

cd ~/public_html
wp core version

خروجی:

6.8.2

راه دوم، ماندن در هر جای دیگر و دادن مسیر است. این برای زمانی است که روی یک اکانت چند سایت دارید:

wp --path=/home/example/public_html/shop core version
wp --path=/home/example/public_html/blog core version

alias دائمی

اگر روی هاست چند نسخهٔ PHP دارید و می‌خواهید همیشه همان نسخهٔ درست اجرا شود، alias را با مسیر صریح باینری PHP بسازید. مسیر باینری را از خروجی wp --info یا از پنل بردارید:

echo "alias wp='/opt/cpanel/ea-php82/root/usr/bin/php $HOME/bin/wp'" >> ~/.bashrc
source ~/.bashrc
wp --info | grep -E 'PHP (binary|version)'

خروجی:

PHP binary:     /opt/cpanel/ea-php82/root/usr/bin/php
PHP version:    8.2.27

مسیر /opt/cpanel/ea-phpXX/root/usr/bin/php الگوی استاندارد cPanel است؛ عدد نسخه در آن فرق می‌کند. اگر پنل شما cPanel نیست، مسیر را از بخش تنظیمات PHP یا از خروجی php -i بردارید. اعداد را از مقالهٔ دیگر کپی نکنید؛ از پنل خودتان بردارید.

فایل wp-cli.yml برای تنظیم ثابت

به‌جای تکرار --path در هر دستور، یک فایل wp-cli.yml در پوشهٔ وردپرس بگذارید. WP-CLI هر بار از پوشهٔ جاری به بالا می‌گردد و اولین فایل را می‌خواند:

path: /home/example/public_html/shop
url: https://example.com
color: false
disabled_commands:
  - db reset
  - db drop

خط disabled_commands همان چیزی است که در بخش «چه کاری را نباید کرد» به آن برمی‌گردیم: دستورهایی که هرگز روی سایت زنده نباید اجرا شوند، از همان اول قفل می‌شوند. بعد از این فایل، دستور مسدودشده با پیام روشن رد می‌شود، نه با یک اشتباه تایپی که کار را انجام می‌دهد.

برای تنظیمات سراسری (همهٔ سایت‌های این اکانت) همان محتوا را در ~/.wp-cli/config.yml بگذارید.

اتصال دیتابیس را بسنجید، نه فرض کنید

wp db check
wp db size --tables

خروجی db check برای هر جدول یک خط می‌دهد و در انتها نتیجهٔ کلی:

wp_posts: OK
wp_postmeta: OK
wp_options: OK
wp_users: OK
Success: Database checked.

و db size --tables جدولی از حجم هر بخش می‌دهد؛ همین‌جا می‌فهمید کدام جدول بیش از اندازه رشد کرده:

+------------------+--------+-------+
| table            | size   | count |
+------------------+--------+-------+
| wp_posts         | 48.2MB | 12480 |
| wp_postmeta      | 96.5MB | 78210 |
| wp_options       | 12.1MB |  1842 |
| wp_term_relationships | 3.4MB | 19002 |
+------------------+--------+-------+

اگر db check پیام Error: Can't connect to the database داد، اول به بخش نسخهٔ PHP بروید؛ روی هاست اشتراکی شایع‌ترین علت، نه رمز اشتباه است و نه دیتابیس خراب.

چرا نسخهٔ PHP در خط فرمان با وب‌سایت فرق دارد

این مهم‌ترین بخش این مقاله است و در هیچ راهنمای فارسی دیگری دیده نمی‌شود. روی هاست اشتراکی cPanel، نسخهٔ PHP وب‌سایت را از بخش MultiPHP Manager انتخاب می‌کنید و وب‌سرور برای هر دامنه یک نسخهٔ مشخص اجرا می‌کند. اما دستور php در SSH یک برنامهٔ کاملاً جداست و آن تنظیم را نمی‌بیند. یعنی می‌شود سایت شما با PHP 8.3 اجرا شود و WP-CLI همان لحظه با PHP 7.4 کار کند، و هیچ‌کدام هم خطا ندهند.

نتیجه چه شکلی است؟ سه نشانهٔ رایج:

• افزونه‌ای که در سایت کار می‌کند، در خط فرمان خطای fatal می‌دهد. چون با نسخهٔ قدیمی‌تری بارگذاری شده و تابع یا سینتکسی که لازم دارد وجود ندارد.
• دستوری موفق می‌شود ولی اثرش را نمی‌بینید. مثلاً آپدیت افزونه در خط فرمان «Success» می‌دهد، ولی بعد از ورود به پیشخوان همان نسخهٔ قبلی را می‌بینید؛ چون کش یا OPcache همان نسخهٔ PHP وب را نگه داشته است.
• wp db check اتصال نمی‌گیرد در حالی که سایت بالا است. گاهی باینری MySQL خط فرمان جدا از وب است و گواهی یا سوکت متفاوتی می‌بیند.

اولین کاری که باید بکنید، مقایسهٔ دو عدد است. یک‌طرف:

wp --info | grep -E 'PHP (binary|version)|php.ini'
php -v | head -1

خروجی نمونه:

PHP binary:     /usr/bin/php
PHP version:    7.4.33
php.ini used:   /opt/cpanel/ea-php74/root/etc/php.ini
PHP 7.4.33 (cli) (built: Nov  8 2022 00:00:00) ( NTS )

طرف دیگر، در پیشخوان: Tools → Site Health → Info → Server و خط PHP version. اگر آنجا ۸.۳ نوشته و اینجا ۷.۴، همان مسئله را دارید. راه‌حل، تغییر نسخهٔ کل سرور نیست — که روی هاست اشتراکی نمی‌توانید — بلکه صدا زدن همان باینری درست است:

/opt/cpanel/ea-php83/root/usr/bin/php ~/bin/wp --info | grep 'PHP version'

خروجی:

PHP version:    8.3.14

حالا این مسیر کامل را در alias بگذارید تا هر بار خودکار انجام شود (همان خطی که در بخش قبل نوشتیم):

echo "alias wp='/opt/cpanel/ea-php83/root/usr/bin/php $HOME/bin/wp'" >> ~/.bashrc
source ~/.bashrc

یک تلهٔ دیگر هم همین‌جاست: memory_limit. روی خیلی از میزبان‌ها مقدار خط فرمان ۲۵۶ مگابایت است، در حالی که وب ۵۱۲ مگابایت دارد. برای آپدیت دسته‌ای یا search-replace روی دیتابیس بزرگ، ۲۵۶ مگابایت کافی نیست و کار با Allowed memory size ... exhausted وسط راه می‌میرد. راهش این است که به‌جای تغییر php.ini (که شاید اجازه‌اش را نداشته باشید) مقدار را در همان دستور بدهید:

php -d memory_limit=512M ~/bin/wp plugin update --all

۱۲ دستور پرکاربرد WP-CLI با نمونهٔ واقعی

این دوازده دستور، هستهٔ کار روزمره روی هاست اشتراکی است. بقیهٔ دستورها را وقتی لازم شدید با wp help <command> پیدا می‌کنید؛ هر دستور WP-CLI مستندات خودش را همراه دارد.

۱. نسخهٔ وردپرس — wp core version

قبل و بعد از هر کاری این را بزنید. تک عدد، بدون HTML، بدون ورود به پیشخوان:

wp core version

6.8.2

اگر نسخهٔ جدیدتر موجود باشد، همین دستور آن را نمی‌گوید؛ برای دیدن فاصله از آخرین نسخه، wp core check-update بزنید:

wp core check-update

+---------+-------------+-------------------------------------------------------------+
| version | update_type | package_url                                                 |
+---------+-------------+-------------------------------------------------------------+
| 6.8.3   | minor       | https://downloads.wordpress.org/release/wordpress-6.8.3.zip |
+---------+-------------+-------------------------------------------------------------+

۲. آپدیت هسته — wp core update

هستهٔ وردپرس را آپدیت می‌کند. قبل از آن بکاپ بگیرید؛ دستور بکاپ خودکار نمی‌گیرد. آپدیت هسته معمولاً کم‌ریسک است، ولی افزونه‌های قدیمی می‌توانند بعد از آن سایت را سفید کنند. قبل از هر دستور مخرب، روش‌های پشتیبان‌گیری در وردپرس را مرور کن. قبل از هر دستور مخرب، روش‌های پشتیبان‌گیری در وردپرس را مرور کن.

wp db export ~/backup-before-core.sql
wp core update

Updating to version 6.8.3 (from 6.8.2)...
Downloading update from https://downloads.wordpress.org/release/wordpress-6.8.3-no-content.zip...
Unpacking the update...
Success: WordPress updated successfully.

۳. آپدیت دیتابیس — wp core update-db

بعد از آپدیت هسته، بعضی جدول‌ها باید ساختارشان به‌روز شود. پیشخوان این کار را در صفحهٔ آپدیت انجام می‌دهد؛ در خط فرمان دستی می‌زنید:

wp core update-db

Success: WordPress database already at version 58975.

یا اگر لازم بود:

Success: WordPress database upgraded successfully from db version 57155 to 58975.

۴. بررسی سلامت دیتابیس — wp db check

هر بار که سایت کند شده یا خطای دیتابیس دیده‌اید، این را بزنید. جدولی که OK نگیرد، مشکل را نشان می‌دهد؛ تعمیرش با wp db repair است.

wp db check
wp db repair

wp_options: OK
Success: Database checked.

۵. حجم جدول‌ها — wp db size --tables

پاسخ کوتاه به «چرا دیتابیسم انقدر بزرگ شده». معمولاً wp_postmeta و wp_options متهم اصلی‌اند:

wp db size --tables --human-readable

+-----------------------+--------+-------+
| table                 | size   | count |
+-----------------------+--------+-------+
| wp_postmeta           | 96.5MB | 78210 |
| wp_posts              | 48.2MB | 12480 |
| wp_options            | 12.1MB |  1842 |
+-----------------------+--------+-------+

۶. فهرست نوشته‌ها — wp post list

فیلترها همان چیزهایی است که در پیشخوان در نوار بالای فهرست نوشته‌ها می‌بینید، ولی ترکیب‌پذیر و قابل‌ذخیره:

wp post list --post_type=post --post_status=draft --fields=ID,post_title,post_date --format=table

+-------+---------------------------+---------------------+
| ID    | post_title                | post_date           |
+-------+---------------------------+---------------------+
| 15431 | نقشهٔ راه هوش مصنوعی      | 2026-10-27 09:14:02 |
| 15402 | پیش‌نویس راهنمای سرعت     | 2026-10-26 18:40:11 |
+-------+---------------------------+---------------------+

برای پیدا کردن نوشته‌های بدون تصویر شاخص، فیلد featured_media را بگیرید و صفرها را ببینید:

wp post list --post_type=post --post_status=publish --fields=ID,post_title,featured_media --format=csv | awk -F, '$3==0'

۷. تغییر وضعیت یک نوشته — wp post update

شناسه (ID) را از دستور قبلی دارید. این دستور فقط فیلدی را که می‌دهید عوض می‌کند و بقیه را نگه می‌دارد:

wp post update 15402 --post_status=publish

Success: Updated post 15402.

برای تغییر تاریخ انتشار به گذشته، --post_date را بدهید. برای پاک‌کردن فیلد، مقدار خالی بدهید؛ اینجا هیچ «Undo» وجود ندارد، پس قبلش wp post get 15402 --field=post_status بزنید و مقدار فعلی را جایی بردارید.

۸. خواندن تنظیم سایت — wp option get

همان جدول wp_options، بدون رفتن به phpMyAdmin و بدون ریسک دست‌زدن به سلول اشتباه:

wp option get siteurl
wp option get home
wp option get blogname

https://example.com
https://example.com
فروشگاه نمونه

اگر مقدار ذخیره‌شده آرایه یا آبجکت باشد، wp option get آن را به شکل خوانا چاپ می‌کند؛ برای ماشین‌خوان کردنش --format=json بدهید.

۹. تغییر تنظیم سایت — wp option update

این دستور تنظیم را در دیتابیس می‌نویسد و کش مربوطه را پاک می‌کند. برای siteurl و home احتیاط کنید: اگر یکی را عوض کنید و دیگری را نه، سایت به حلقهٔ ریدایرکت می‌افتد. هر دو را با هم و در یک خط بزنید: اگر بعد از هر دستور کش را پاک می‌کنی، مقایسهٔ LiteSpeed و WP Rocket تنظیم درست را نشان می‌دهد. اگر بعد از هر دستور کش را پاک می‌کنی، مقایسهٔ LiteSpeed و WP Rocket تنظیم درست را نشان می‌دهد.

wp option update home 'https://example.com'
wp option update siteurl 'https://example.com'
wp cache flush

Success: Updated 'home' option.
Success: Updated 'siteurl' option.
Success: The cache was flushed.

توجه: این کار آدرس‌هایی را که در محتوا و متادیتا نوشته شده عوض نمی‌کند. برای آن‌ها بخش search-replace را ببینید.

۱۰. پاک‌کردن کش منقضی — wp transient delete --expired

وردپرس و افزونه‌ها هزاران ردیف موقت در wp_options می‌گذارند. ردیف‌هایی که تاریخشان گذشته ولی هنوز پاک نشده‌اند، حجم و کندی می‌سازند:

wp transient delete --expired

Success: Deleted 218 expired transients.

برای پاک‌کردن همهٔ کش شیء (اگر افزونهٔ کش شیء فعال دارید):

wp cache flush

Success: The cache was flushed.

۱۱. کارهای زمان‌بندی‌شده — wp cron event list

وردپرس برای انجام کارهای زمان‌بندی‌شده به بازدیدکننده نیاز دارد. روی سایت کم‌بازدید، این یعنی کارها دیر اجرا می‌شوند. این دستور نشان می‌دهد چه چیزی در انتظار است:

wp cron event list --fields=hook,next_run_relative,recurrence

+--------------------------+-------------------+------------+
| hook                     | next_run_relative | recurrence |
+--------------------------+-------------------+------------+
| wp_version_check         | now               | 12 hours   |
| wp_update_plugins        | 2 hours           | 12 hours   |
| action_scheduler_run_queue | 4 minutes       | 1 minute   |
| wp_scheduled_delete      | 23 hours          | 1 day      |
+--------------------------+-------------------+------------+

اجرای دستی کارهای سررسیده، برای وقتی که سایت تازه بیدار شده:

wp cron event run --due-now

Executed the cron event 'wp_version_check' in 0.03s.
Executed the cron event 'action_scheduler_run_queue' in 1.42s.
Success: Executed 2 of 2 scheduled events.

۱۲. حالت تعمیر — wp maintenance-mode

قبل از یک آپدیت سنگین یا مهاجرت، سایت را از دید بازدیدکننده ببندید بی‌آنکه فایلی را دستی بسازید:

wp maintenance-mode activate
wp maintenance-mode status
wp maintenance-mode deactivate

Success: Activated maintenance mode.
Maintenance mode is active.
Success: Deactivated maintenance mode.

اگر یادتان رفت خاموشش کنید، سایت برای همه صفحهٔ «چند لحظه صبر کنید» نشان می‌دهد. همان status جواب می‌دهد که گیر کجاست.

مدیریت افزونه‌ها و قالب از خط فرمان

این بخش همان جایی است که بیشترین وقت را برمی‌گرداند. اصل کار ساده است: هر کاری که در صفحهٔ افزونه‌ها با کلیک انجام می‌شود، اینجا با نام افزونه انجام می‌شود. نام همان اسلاگ پوشهٔ افزونه است، نه عنوان فارسی‌اش.

دیدن افزونه‌ها و آپدیت‌های موجود

wp plugin list

+---------------------+----------+--------+---------+----------------+-------------+
| name                | status   | update | version | update_version | auto_update |
+---------------------+----------+--------+---------+----------------+-------------+
| woocommerce         | active   | none   | 9.9.5   |                | off         |
| yoast               | active   | none   | 25.1    |                | off         |
| contact-form-7      | active   | none   | 6.1.1   |                | off         |
| litespeed-cache     | active   | none   | 6.5.0   |                | off         |
| akismet             | inactive | none   | 5.3.6   |                | off         |
+---------------------+----------+--------+---------+----------------+-------------+

وقتی آپدیتی موجود باشد، ستون update مقدار available می‌گیرد و update_version پر می‌شود. برای فهرست کوتاه‌تر فقط همین‌ها را بگیرید:

wp plugin list --update=available --fields=name,version,update_version

+----------------+---------+----------------+
| name           | version | update_version |
+----------------+---------+----------------+
| woocommerce    | 9.9.5   | 10.0.1         |
| contact-form-7 | 6.1.1   | 6.1.3          |
+----------------+---------+----------------+

آپدیت دسته‌ای

قبل از آپدیت، بکاپ. همیشه. ترتیب کار را عوض نکنید:

wp db export ~/backup-before-plugins-$(date +%F).sql
wp plugin update --all

Enabling Maintenance mode...
Downloading update from https://downloads.wordpress.org/plugin/contact-form-7.6.1.3.zip...
Unpacking the update...
Installing the latest version...
Removing the old version of the plugin...
Plugin updated successfully.
Disabling Maintenance mode...
+----------------+-------------+-------------+---------+
| name           | old_version | new_version | status  |
+----------------+-------------+-------------+---------+
| woocommerce    | 9.9.5       | 10.0.1      | Updated |
| contact-form-7 | 6.1.1       | 6.1.3       | Updated |
+----------------+-------------+-------------+---------+
Success: Updated 2 of 2 plugins.

اگر یکی از افزونه‌ها آپدیت نشد، همان جدول status را Error نشان می‌دهد و خط مربوطه علت را می‌نویسد. یک نکتهٔ عملی: Woocommerce را هیچ‌وقت در ساعتی آپدیت نکنید که سفارش می‌گیرید؛ آپدیت دیتابیس Woocommerce بعد از آپدیت افزونه و از پیشخوان انجام می‌شود، نه در همین دستور.

نصب، فعال‌سازی و حذف

wp plugin install wordfence --activate
wp plugin deactivate contact-form-7
wp plugin delete contact-form-7

Installing Wordfence Security (8.0.5)
Downloading installation package from https://downloads.wordpress.org/plugin/wordfence.8.0.5.zip...
Unpacking the package...
Installing the plugin...
Plugin installed successfully.
Activating 'wordfence'...
Plugin 'wordfence' activated.
Success: Installed 1 of 1 plugins.

دستور delete فایل‌های افزونه را حذف می‌کند ولی داده‌هایش را در دیتابیس نگه می‌دارد — همان کاری که «حذف» از پیشخوان می‌کند. حذف داده‌ها کار خود افزونه است یا دستی در دیتابیس.

قالب‌ها

wp theme list
wp theme activate theme-slug
wp theme update --all

+----------------+----------+--------+---------+
| name           | status   | update | version |
+----------------+----------+--------+---------+
| theme-slug     | active   | none   | 2.4.1   |
| twentytwentyfive | inactive | none | 1.2     |
+----------------+----------+--------+---------+

دستور theme activate فقط قالب را عوض می‌کند؛ ویجت‌ها و منوهای قالب قبلی سر جایشان می‌مانند و ممکن است در قالب جدید جایی نداشته باشند. قبل از تعویض قالب روی سایت زنده، یک بکاپ از دیتابیس بگیرید — برگشتن به قالب قبلی ساده است، ولی بازگرداندن چیدمان ویجت‌ها نه.

پشتیبان‌گیری و بازیابی با یک دستور

افزونهٔ بکاپ خوب است، ولی وقتی سایت خطای ۵۰۰ می‌دهد و پیشخوان باز نمی‌شود، افزونهٔ بکاپ هم باز نمی‌شود. خط فرمان در آن لحظه کار می‌کند، چون به پیشخوان کاری ندارد.

گرفتن بکاپ دیتابیس

cd ~/public_html
wp db export ~/backup-$(date +%F-%H%M).sql

Success: Exported to /home/example/backup-2026-11-01-1030.sql

فایل پشتیبان روی همان سرور ساخته می‌شود، نه روی سیستم شما. دو کار بعدی مهم است: حجمش را چک کنید و از سرور بیرونش ببرید. بکاپی که فقط روی همان هاست است، بکاپ نیست؛ اگر هاست از دست برود، بکاپ هم رفته.

ls -lh ~/backup-*.sql

-rw-r--r--  1 example example  142M Nov  1 10:30 /home/example/backup-2026-11-01-1030.sql

برای اینکه فایل کوچک‌تر شود و انتقالش سریع‌تر، خروجی را مستقیم فشرده کنید. علامت - یعنی به‌جای فایل، به خروجی استاندارد بنویس:

wp db export - | gzip > ~/backup-$(date +%F).sql.gz

برای بکاپ گرفتن از چند جدول خاص، یا کنار گذاشتن جدول‌های سنگین و کم‌ارزش مثل لاگ‌ها:

wp db export --tables=wp_posts,wp_postmeta,wp_options ~/backup-content.sql
wp db export --exclude_tables=wp_actionscheduler_logs ~/backup-no-logs.sql

بازگرداندن بکاپ

این دستور دیتابیس فعلی را با محتوای فایل جایگزین می‌کند. یعنی هر چیزی که بعد از گرفتن آن بکاپ نوشته شده، از دست می‌رود. اگر شک دارید، اول از وضعیت فعلی بکاپ بگیرید:

wp db export ~/backup-before-restore.sql
wp db import ~/backup-2026-11-01-1030.sql

Success: Imported from '/home/example/backup-2026-11-01-1030.sql'.

اگر فایل فشرده است، اول بازش کنید:

gunzip -c ~/backup-2026-11-01.sql.gz > ~/restore.sql
wp db import ~/restore.sql

بعد از بازیابی، همیشه این سه خط را بزنید؛ بدون این‌ها سایت با جدول‌های قدیمی و کش قدیمی بالا می‌آید و فکر می‌کنید بازیابی نشده:

wp cache flush
wp rewrite flush
wp core update-db

یک نکتهٔ مهم که در بکاپ دیتابیس جا می‌ماند: پوشهٔ wp-content/uploads داخل دیتابیس نیست. بکاپ دیتابیس + بکاپ فایل‌ها با هم بکاپ کامل است. فایل‌ها را از پنل (File Manager → Compress) یا با tar بگیرید، نه با WP-CLI.

و یک محدودیت واقعی هاست اشتراکی: wp db export به باینری mysql روی سرور نیاز دارد. روی اکثر میزبان‌ها هست؛ اگر نبود، خطای Error: Failed to get mysql binary path می‌گیرید و راه جایگزین، بکاپ از phpMyAdmin یا از پنل میزبان است.

جست‌وجوی جایگزینی انبوه در دیتابیس

این دستور قدرتمندترین و خطرناک‌ترین دستور WP-CLI است و باید با پروتکل اجرا شود، نه با حدس. کاربردهای واقعی‌اش: عوض کردن دامنه بعد از مهاجرت، تغییر پیشوند جدول‌ها، اصلاح آدرس‌های http به https، و پاک‌کردن نام یک افزونهٔ حذف‌شده از تمام محتوا.

چرا نمی‌شود این کار را با جست‌وجوی phpMyAdmin کرد؟ چون وردپرس بخشی از داده را به شکل سریالایزشدهٔ PHP ذخیره می‌کند و در آن شکل، طول رشته داخل خود داده نوشته شده است. اگر با SQL ساده یک آدرس کوتاه‌تر یا بلندتر شود، طول اعلام‌شده دیگر درست نیست و آن ردیف خراب می‌شود — گاهی بی‌صدا. wp search-replace داده سریالایز را می‌شناسد و طول را با هم اصلاح می‌کند.

گام ۱ — بکاپ

wp db export ~/before-replace-$(date +%F-%H%M).sql

گام ۲ — dry-run و خواندن گزارش

--dry-run تمام مراحل را انجام می‌دهد و گزارش می‌دهد، ولی چیزی نمی‌نویسد:

wp search-replace 'http://example.com' 'https://example.com' --dry-run

+---------------------+-----------------+-------+
| Table               | Column          | Count |
+---------------------+-----------------+-------+
| wp_posts            | post_content    |   214 |
| wp_posts            | guid            |  1248 |
| wp_postmeta        | meta_value      |   386 |
| wp_options          | option_value    |     7 |
+---------------------+-----------------+-------+
Success: 1855 replacements to be made.

سه چیز را در این گزارش بررسی کنید: تعداد کل با انتظار شما می‌خواند؟ جدولی هست که نباید در فهرست باشد؟ و مقدار guid چقدر است؟

گام ۳ — تصمیم دربارهٔ guid

ستون guid در wp_posts آدرس اصلی فید است و وردپرس از آن به‌عنوان شناسهٔ دائمی پست استفاده می‌کند. تغییرش پیشنهاد رسمی نیست و بعضی فیدخوان‌ها همان پست را دوباره پست‌شده می‌بینند. اگر می‌خواهید دست نزنید:

wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid --dry-run

اگر دیتابیس شما جدول‌هایی با پیشوند دیگر هم دارد (مثلاً از یک نصب قدیمی)، پیش‌فرض دستور فقط جدول‌های ثبت‌شدهٔ همین سایت را می‌گردد. برای پوشش همهٔ جدول‌های با همین پیشوند، --all-tables-with-prefix بدهید. دربارهٔ --all-tables در بخش «چه کاری را نباید کرد» توضیح می‌دهیم؛ روی دیتابیس مشترک، خطرناک است.

گام ۴ — اجرای واقعی

بعد از اینکه گزارش dry-run درست بود، همان دستور را بدون --dry-run بزنید:

wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid

+---------------------+-----------------+-------+
| Table               | Column          | Count |
+---------------------+-----------------+-------+
| wp_posts            | post_content    |   214 |
| wp_postmeta        | meta_value      |   386 |
| wp_options          | option_value    |     7 |
+---------------------+-----------------+-------+
Success: Made 607 replacements.

گام ۵ — پاک‌سازی بعد از جایگزینی

بدون این سه خط، سایت ممکن است آدرس قدیمی را از کش یا از قواعد بازنویسی بخواند و رفتار عجیب نشان بدهد:

wp cache flush
wp rewrite flush
wp option update home 'https://example.com'
wp option update siteurl 'https://example.com'

حالا سایت را در مرورگر باز کنید و سه چیز را ببینید: صفحهٔ اصلی، یک نوشتهٔ تصادفی، و یک صفحهٔ محصول یا برگه. اگر نوشته‌ها باز می‌شوند ولی صفحهٔ اصلی نه، معمولاً home و siteurl یکی نشده‌اند.

یک راه امن‌تر برای سایت‌های بزرگ: به‌جای نوشتن روی دیتابیس، خروجی SQL بگیرید و خودتان بازبینی و ایمپورت کنید. گزینهٔ --export همین کار را می‌کند:

wp search-replace 'http://example.com' 'https://example.com' --export=~/replaced.sql --skip-columns=guid

اجرای خودکار WP-CLI با cron و wp-cli.yml

وقتی دستوری را دو بار پشت سر هم زدید و هر دو بار همان نتیجه را داد، وقت خودکار کردنش است. روی هاست اشتراکی این کار با cron پنل انجام می‌شود، ولی سه تله دارد که اکثر راهنماها نمی‌گویند.

تلهٔ اول: cron پوسته ندارد

cron با bash تعاملی اجرا نمی‌شود، پس alias شما وجود ندارد. یعنی در cron نمی‌توانید wp بنویسید؛ باید مسیر کامل باینری PHP و مسیر کامل فایل را بدهید:

/opt/cpanel/ea-php82/root/usr/bin/php /home/example/bin/wp --path=/home/example/public_html plugin update --all >> /home/example/wp-update.log 2>&1

تلهٔ دوم: پوشهٔ جاری مشخص نیست

cron از پوشهٔ خانگی شروع می‌کند، نه از پوشهٔ وردپرس. پس یا --path بدهید (که در خط بالا دادیم) یا اول cd کنید:

cd /home/example/public_html && /opt/cpanel/ea-php82/root/usr/bin/php /home/example/bin/wp maintenance-mode deactivate

تلهٔ سوم: دو اجرای هم‌زمان

اگر فاصلهٔ cron را ۵ دقیقه بگذارید و اجرا ۸ دقیقه طول بکشد، دو نسخه هم‌زمان روی یک دیتابیس کار می‌کنند. برای کارهای سنگین فاصله را بزرگ‌تر بگیرید یا از flock استفاده کنید:

flock -n /home/example/wp-update.lock /opt/cpanel/ea-php82/root/usr/bin/php /home/example/bin/wp --path=/home/example/public_html plugin update --all

-n یعنی اگر قفل گرفته شده، این اجرا بی‌صدا رد شود، نه اینکه صبر کند و دوتایی اجرا شوند.

الگوی مفید: جایگزینی wp-cron با cron واقعی

والدین این کار: وردپرس کارهای زمان‌بندی‌شده را با بازدید کاربر اجرا می‌کند. روی سایت کم‌بازدید این یعنی تأخیر. الگوی استاندارد دو خط است — اول در wp-config.php چرخهٔ داخلی را خاموش کنید، بعد cron واقعی هر پنج دقیقه کارهای سررسیده را اجرا کند:

wp config set DISABLE_WP_CRON true --raw

Success: Updated the constant 'DISABLE_WP_CRON' in the 'wp-config.php' file with the raw value true.

و خط cron در پنل:

/opt/cpanel/ea-php82/root/usr/bin/php /home/example/bin/wp --path=/home/example/public_html cron event run --due-now > /dev/null 2>&1

این تغییر را روی سایت زنده بی‌بکاپ انجام ندهید؛ wp config set فایل wp-config.php را بازنویسی می‌کند و اگر خطی در آن دستکاری شده باشد، ممکن است ترتیب یا کامنت‌ها جابه‌جا شوند. اول wp config get DISABLE_WP_CRON بزنید تا بدانید قبلاً چه بود.

اگر برنامه‌نویسی بلد نیستید ولی می‌خواهید خروجی این دستورها را کسی برایتان تحلیل کند، مسیر کم‌دردسرتری هم هست: لاگ را ذخیره کنید و بعد سراغ ابزارهای هوش مصنوعی بروید. در بخش هوش مصنوعی سئوپلاس روش‌های عملی برای همین کار هست.

خطاهای رایج WP-CLI و پیام‌هایشان

پیام خطای WP-CLI تقریباً همیشه دقیق است؛ مشکل این است که اغلب مردم پیام را با یک راهنمای سرور اختصاصی تطبیق می‌دهند و راه‌حل به دردشان نمی‌خورد. این‌ها رایج‌ترین‌ها روی هاست اشتراکی است. اگر خطای شما اینجا نبود، فهرست کامل خطاهای وردپرس و شبکه را ببینید.

وقتی بعد از تغییر آدرس، REST خطای 405 می‌دهد

یکی از پیامدهای ناخواستهٔ عوض کردن دامنه یا پیشوند جدول‌ها این است که درخواست‌های REST وردپرس با 405 Method Not Allowed برمی‌گردند. ۴۰۵ یعنی «این متد روی این مسیر مجاز نیست» و ربطی به نبودن فایل ندارد — به همین دلیل گشتن دنبال فایل گم‌شده وقت تلف کردن است. دو علت رایج: قواعد بازنویسی هنوز آدرس قدیمی را می‌شناسند، یا یک دیوار محافظ (WAF) در مسیر آدرس جدید، متد POST روی wp-json را بسته است. اول wp rewrite flush و بعد wp option get home را چک کنید؛ اگر درست بود، سراغ تنظیمات WAF بروید. توضیح کامل این خطا و راه‌های رفعش در مقالهٔ خطای 405 Method Not Allowed هست.

روش عیب‌یابی که همیشه جواب می‌دهد

سه دستور، به همین ترتیب. اول ببینید WP-CLI اصلاً چه چیزی می‌بیند:

wp --info
wp core is-installed && echo INSTALLED
wp eval 'echo get_option("home");'

اگر --info سالم بود ولی is-installed کد خطا داد، مسئله مسیر است. اگر is-installed سالم بود ولی eval خطای PHP داد، مسئله نسخه یا افزونه است. این تفکیک، جست‌وجوی شما را از یک ساعت به پنج دقیقه می‌رساند.

چه کاری را با WP-CLI نباید کرد

خط فرمان تأیید نمی‌خواهد. هیچ پنجره‌ای نمی‌پرسد «مطمئنید؟». همین ویژگی است که آن را سریع می‌کند و همین ویژگی است که آن را خطرناک. این فهرست را قبل از هر دستور ناشناخته یک بار بخوانید.

۱. wp db reset و wp db drop

این دو، جدول‌های دیتابیس را پاک می‌کنند. db reset جدول‌ها را خالی می‌کند و سایت را به حالت نصب‌نشده می‌برد؛ db drop خود دیتابیس را حذف می‌کند. یک اشتباه در نام دیتابیس، یعنی از دست رفتن همه‌چیز. اگر این دستورها را لازم ندارید — و روی سایت زنده معمولاً لازم ندارید — همان‌جا در wp-cli.yml مسدودشان کنید:

disabled_commands:
  - db reset
  - db drop
  - site empty

۲. search-replace بدون --dry-run

در بخش قبل کامل توضیح دادیم. خیلی کوتاه: بدون dry-run، دستور بدون هیچ پرسشی می‌نویسد و لغو ندارد. اگر عجله دارید، همان عجله دلیل انجام ندادنش است.

۳. --all-tables روی دیتابیس مشترک

روی هاست اشتراکی، یک دیتابیس ممکن است چند نصب وردپرس با پیشوندهای مختلف داشته باشد، یا جدول‌های یک اسکریپت دیگر کنارش باشد. --all-tables همهٔ جدول‌های دیتابیس را می‌گردد، حتی آن‌هایی که مال وردپرس شما نیستند. نتیجه: داده‌های یک برنامهٔ دیگر هم بازنویسی می‌شود. به‌جایش --all-tables-with-prefix بدهید که فقط جدول‌های با پیشوند همین سایت را می‌گیرد.

۴. --allow-root روی هاست اشتراکی

این سوئیچ برای دور زدن هشدار روت است، و روی هاست اشتراکی هیچ کاربردی ندارد چون شما از اول روت نیستید. اگر روزی دیدید --allow-root لازم شد، یعنی اشتباهی با کاربر روت وارد شده‌اید. و اگر واقعاً روت هستید، اجرای دستورهای وردپرس با روت باعث می‌شود فایل‌های تازه با مالکیت روت ساخته شوند و بعد از آن، خود وردپرس نتواند آپلود کند — همان خطای Unable to create directory که تعمیرش از خود مشکل سخت‌تر است.

۵. آپدیت دسته‌ای بدون بکاپ

نه فقط بکاپ دیتابیس؛ بکاپ فایل‌های افزونه‌ها هم مهم است. اگر آپدیت یک افزونه سایت را سفید کرد، برگشتن به نسخهٔ قبل یعنی داشتن فایل نسخهٔ قبل. اگر بکاپ ندارید، تنها راهتان بازگرداندن کل سایت است.

۶. حذف انبوه افزونه‌ها در ساعت کاری

حذف افزونه یعنی حذف فایل‌هایش. اگر افزونه‌ای در حال دریافت سفارش یا پردازش فرم است، حذفش در همان لحظه یعنی خطای کاربر. کارهای حذف را در کم‌ترین ترافیک روز بگذارید و بعدش یک wp cache flush بزنید.

۷. گذاشتن رمز در خط فرمان یا در cron

دستور wp user create ... --user_pass='...' رمز را در تاریخچهٔ پوسته و در فهرست فرایندها می‌گذارد. راه بهتر: wp user create بدون رمز، و بعد تغییر رمز از پیشخوان. و هیچ‌وقت رمزی را در یک فایل cron قابل خواندن نگذارید.

۸. اجرای دستور نویسنده با کاربر اشتباه

دستورهایی که فایل می‌سازند — مثل wp media regenerate یا wp plugin install — فایل‌ها را با همان کاربری می‌سازند که دستور را اجرا کرده است. اگر آن کاربر همان کاربر وب‌سرور نباشد، فایل‌هایی با مالکیت نادرست می‌مانند و بعداً آپلود یا آپدیت از پیشخوان خطا می‌دهد. همیشه با کاربر اصلی اکانت هاست وارد شوید.

۹. تغییر wp-config.php با wp config set روی سایت زنده

دستور کار می‌کند، ولی فایل را بازنویسی می‌کند. اگر افزونه‌ای خطی با ترتیب خاص در آن گذاشته باشد، ممکن است آن خط جابه‌جا شود. قبلش یک نسخهٔ کپی از فایل بگیرید؛ WP-CLI راه بکاپ خودکار برای این فایل ندارد.

بیشتر بخوانید

• مهاجرت از جوملا به وردپرس
• رفع خطای Updating Failed
• خطای حالت نگهداری وردپرس
• مشکل بارگذاری تصویر در وردپرس
• سایت وردپرس هک شد

پرسش‌های متداول WP-CLI روی هاست اشتراکی

آیا WP-CLI روی هاست اشتراکی بدون SSH اجرا می‌شود؟

نه. WP-CLI یک برنامهٔ خط فرمان است و برای اجرا به یک پوسته نیاز دارد. اگر پلن شما SSH ندارد، بعضی پنل‌ها (از جمله cPanel) یک Terminal تحت وب دارند که همان کار را می‌کند؛ اگر آن هم نبود، از میزبان بخواهید فعالش کند. روش دیگری وجود ندارد.

حداقل نسخهٔ PHP برای WP-CLI چقدر است؟

PHP نسخهٔ ۷.۲.۲۴ یا بالاتر، و وردپرس ۴.۹ یا بالاتر. برای وردپرس امروز بهتر است همان نسخه‌ای را اجرا کنید که سایت با آن کار می‌کند؛ وگرنه نتیجه‌های متفاوت می‌گیرید.

چرا wp --info به‌جای متن، یک خط HTML برمی‌گرداند؟

یعنی پشتیبانی Phar در php.ini غیرفعال است. فایل .phar بدون این قابلیت باز نمی‌شود و به‌جای خروجی، هدر Content-type چاپ می‌شود. راه‌حل: خط suhosin.executor.include.whitelist = phar در php.ini، یا درخواست فعال‌سازی از میزبان.

آیا wp search-replace قابل برگشت است؟

نه. لغو داخلی ندارد. تنها راه برگشت، همان بکاپی است که قبلش گرفتید. اگر دیتابیس بزرگ است، به‌جای نوشتن مستقیم از --export استفاده کنید تا فایل SQL بگیرید و قبل از ایمپورت بازبینی کنید.

آیا برای WP-CLI به روت یا --allow-root نیاز دارم؟

هیچ‌کدام. روی هاست اشتراکی شما کاربر اکانت خودتان هستید و همین کافی است: نصب در پوشهٔ خانگی، اجرا با همان کاربر، بدون sudo. اگر جایی --allow-root لازم شد، یعنی اشتباهی به کاربر روت وارد شده‌اید و باید از آن خارج شوید.

اگر بخواهید همین کارها را به‌جای دستور تایپ‌کردن، از داخل خود وردپرس یا با کمک ابزارهای هوشمند انجام دهید، پایهٔ کار همان است که در این مقاله آمد: بکاپ، dry-run، و بعد اجرا. ترتیب را عوض نکنید.