فهرست مقاله
دو روز پیش، منوردپرسوبسایت هنگام ارتقاء برنامه خود ناگهان از کار افتاد.
بخش مدیریت (backend) کاملاً خالی است، و بخش مدیریت (frontend) خطای ۵۰۰ را گزارش میدهد، و گزارشها (logs) پر از خطاهای مهلک PHP هستند.
در آن لحظه، فقط یک فکر در ذهنم بود: وای نه، فایلهای اصلی خراب شدهاند.
راستش را بخواهید، اولین واکنش اکثر مردم به این موضوع وحشت است. مخصوصاً برای وبلاگهایی که سالهاست فعالیت میکنند، بیش از دوازده افزونه نصب کردهاند و قالبهای بهشدت سفارشیسازیشده دارند، ممکن است فکر کنید: «اگر همه چیز را دوباره نصب کنم، آیا همه مطالبم هنوز سر جایشان هستند؟»
نگران نباشید. تا زمانی که هنوز بتوانید از طریق SSH وارد سیستم شوید، این مشکل میتواند در عرض پنج دقیقه حل شود.
دلایل خراب شدن فایلهای اصلی وردپرس
اول، کمی پیشزمینه: مکانیزم ارتقاء وردپرس در واقع بسیار شکننده است. در طول ارتقاء آنلاین، فایلهای اصلی را یکی یکی جایگزین میکند. اگر مجوزها نادرست باشند، دیسک پر باشد یا فرآیند قطع شود، فایلها خراب میشوند. نتیجه این خرابی این است که سایت شما از کار میافتد و شما قادر به دسترسی به front-end یا back-end نخواهید بود.
با این حال، یک نکتهی حیاتی برای درک وجود دارد: فایلهای اصلی وردپرس و محتوای شما کاملاً از هم جدا هستند. قالب، افزونهها و تصاویر آپلود شدهی شما، همگی در پوشهی `wp-content` قرار دارند و اطلاعات پیکربندی در `wp-config.php` قرار دارد. از سوی دیگر، فایلهای اصلی، پوشههایی مانند `wp-admin` و `wp-includes` هستند که اساساً مجموعهای از برنامههای PHP هستند.
بنابراین، جایگزینی فایلهای اصلی با SSH اساساً یک کار انجام میدهد: قرار دادن یک کپی جدید از برنامهی خراب. مثل زمانی است که کامپیوتر شما با یک صفحه آبی از کار میافتد؛ اگر سیستم را دوباره نصب کنید، آیا فایلهای موجود در درایو D شما هنوز سر جای خود هستند؟ این همان اصل است.

مراحل کامل جایگزینی فایلهای اصلی وردپرس با استفاده از SSH
داستان از این قرار است: من از طریق SSH وارد سیستم شدم، وارد دایرکتوری سایت شدم و اولین کاری که کردم بررسی وضعیت فعلی بود.
cd /var/www/html # 根据你的实际路径سپس، آخرین نسخه وردپرس را دانلود کنید.
wget https://wordpress.org/latest.tar.gz
tar -xf latest.tar.gzاین مرحله شامل دانلود آخرین نسخه فایل فشرده وردپرس و سپس استخراج آن است. سپس یک پوشه جدید با نام "wordpress" در دایرکتوری فعلی مشاهده خواهید کرد.
مرحله بعدی، مهمترین مرحله است: پوشش فایلهای اصلی.
cp -rf wordpress/* .این دستور به معنای کپی اجباری هر آنچه در پوشه وردپرس است به دایرکتوری فعلی است.
نکتهای که باید بدانید این است: این عملیات فایلهای wp-content و wp-config.php شما را حذف نمیکند. این فایلها در پوشه وردپرس وجود ندارند؛ آنها مختص سایت شما هستند. بنابراین، این مرحله ایمن است؛ فقط فایلهای اصلی برنامه را بازنویسی میکند.
بعد از اجرای آن دستور، هنوز کمی نگران بودم. اگر چیزی را اشتباه نوشته باشم چه؟
بعدش رفتم سراغ پاک کردن بسته نصبی.
rm -rf wordpress latest.tar.gzتمیز و کارآمد، بدون هیچ ردی.
پس از انجام این مراحل، باید وارد پنل مدیریت شوید و ارتقاء پایگاه داده را انجام دهید. مسیر /wp-admin/upgrade.php است. این مرحله ضروری است زیرا نسخههای جدیدتر وردپرس ممکن است ساختار پایگاه داده را بهروزرسانی کنند.
راستش را بخواهید، کل این فرآیند کمتر از پنج دقیقه طول کشید. با خودم فکر کردم، اگر روی دکمهی ارتقا در پسزمینه کلیک کرده بودم، چه کسی میداند چقدر باید منتظر میماندم، و ممکن بود دوباره از کار بیفتد.
قبل از عملیات، پشتیبان گیری ضروری است
اما باید به شما یادآوری کنم که ابتدا از اطلاعات خود نسخه پشتیبان تهیه کنید. حداقل از فایل wp-config.php و پایگاه داده خود نسخه پشتیبان تهیه کنید. این عادتی است که باید در خود پرورش دهید، مهم نیست که چقدر فکر میکنید عملیات شما امن است. من خودم از دست دادن دادهها را تجربه کردهام و این درد چیزی است که فقط یک بار باید آن را تجربه کنید.
نحوه رفع مجوزهای دایرکتوری پس از جایگزینی SSH
یک نکته دیگر هم وجود دارد: بعد از اینکه جایگزینی را انجام دادید، ممکن است با مشکل جدیدی روبرو شوید - مجوزهای دایرکتوری.
بعد از اینکه جایگزینی را تمام کردم، برای نصب افزونه به بخش مدیریت رفتم، اما خطا داد زیرا نمیتوانستیم برخی از فایلها را کپی کنیم و ارتقا نصب نشد.
این به چه معناست؟ یعنی وقتی برای جایگزینی یک فایل از طریق SSH وارد میشوید، ممکن است مالک فایل، کاربر root یا کاربر دیگری شده باشد و وب سرور شما، مانند آپاچی، از کاربر www-data استفاده میکند که مجوزهای نوشتن ندارد. بنابراین، مکانیزم ارتقاء بکاند وردپرس خطایی را گزارش میدهد.
راه حل پیچیده نیست.
cd /home/你的用户名/web/你的域名文件夹/public_html/wp-content/
chmod -R 755 plugins/
chmod -R 755 themes/
chmod -R 755 uploads/
chmod -R 755 upgrade/تنظیم این دایرکتوریها روی مجوز ۷۵۵ به این معنی است که فقط مالک حق نوشتن دارد و دیگران فقط میتوانند بخوانند.
اگر استفاده می کنیدHestiaCPیک روش سادهتر هم برای استفاده از این پنل وجود دارد.
chown -R 你的用户名:你的用户名 /home/你的用户名/web/你的域名文件夹/public_html/*میشه با یه جمله تمومش کرد.
برگردیم به مبحث مجوزها، اگر تمام مجوزهای فایل در سایت شما نادرست است، میتوانید از دستور find برای اصلاح آنها به صورت دستهای استفاده کنید.
find /home/你的用户名/web/你的域名文件夹/public_html -type d -print0 | xargs -0 chmod 755
find /home/你的用户名/web/你的域名文件夹/public_html -type f -print0 | xargs -0 chmod 644به دایرکتوری عدد ۷۵۵ و به فایل عدد ۶۴۴ اختصاص داده شده است.لینـوکــسپیکربندی استاندارد مجوزها برای سرویسهای وب در این محیط.
بهروزرسانی دستهای افزونهها و قالبها با استفاده از WP-CLI
علاوه بر این، اگر به استفاده از WP-CLI عادت دارید، میتوانید افزونهها و قالبها را همزمان بهروزرسانی کنید.
wp plugin update --all
wp theme update --allراستش را بخواهید، من خودم هنوز در حال بررسی راهحلهای خودکارسازی بهتر هستم. برای مثال، آیا میتوانم اسکریپتی بنویسم که کل فرآیند پشتیبانگیری، جایگزینی، تغییر مجوزها و ارتقای پایگاه داده را تنها با یک کلیک انجام دهد؟ از لحاظ تئوری، این امکان وجود دارد، اما من هنوز آن را به طور کامل آزمایش نکردهام، بنابراین در اینجا در مورد آن گمانهزنی نمیکنم.
بعد از انجام همه این کارها، به سایتی که از کار افتاده بود برگشتم، صفحه را رفرش کردم و همه چیز درست شد. بخش مدیریت به طور عادی بارگذاری شد، بخش مدیریت اجازه ورود داد و هیچ یک از قالبها یا افزونهها از بین نرفتند.
چطور بگویم؟ مثل این است که صرف پنج دقیقه وقت برای استفاده از SSH، شما را از یک روز کامل دردسر نجات دهد.
فکر میکنم بسیاری از صاحبان وبسایت احتمالاً اضطرابهای مشابهی دارند: وقتی بهروزرسانیهای وردپرس با مشکل مواجه میشوند، وحشت میکنند و از خود میپرسند که آیا باید همه چیز را دوباره نصب کنند یا خیر. در واقع، وقتی ساختار فایلهای وردپرس را درک کنید، فایلهای اصلی فقط بستههایی هستند؛ میتوانید به سادگی آنها را جایگزین کنید. هر چیزی که واقعاً متعلق به شماست در wp-content قرار دارد.
نکته آخر: به پشتیبانگیری منظم عادت کنید. چه از افزونهای برای پشتیبانگیری خودکار استفاده کنید و چه از پشتیبانگیری دستی از طریق SSH، فرقی نمیکند. فقط منتظر نمانید تا مشکلی پیش بیاید و بعد پشتیبانگیری را فراموش کنید.
گذشته از همه اینها، وقتی دادهها از بین بروند، دیگر رفتهاند؛ اما اگر برنامه خراب شود، میتوان آن را جایگزین کرد.
از آنجایی که تا اینجا را خواندهاید، اگر برایتان مفید بود، لطفاً آن را لایک کنید و به اشتراک بگذارید. اگر میخواهید زودتر از بقیه از بهروزرسانیها مطلع شوید، میتوانید من را دنبال کنید!
ممنون که مقاله من را خواندید. دفعه بعد میبینمتان.
وبلاگ امید چن ویلیانگ ( https://www.chenweiliang.com/ مقاله «جایگزینی کامل فایلهای هسته وردپرس با SSH (۱۰ برابر سریعتر از FTP)» که در اینجا به اشتراک گذاشته شده است، ممکن است برای شما مفید باشد.
به اشتراک گذاری لینک این مقاله خوش آمدید:https://www.chenweiliang.com/cwl-34329.html
