Повністю замініть основні файли WordPress на SSH (у 10 разів швидше, ніж FTP)

Два дні тому, мійWordPressВебсайт раптово завис під час оновлення програми.

Бекенд повністю порожній, а фронтенд повідомляє про помилку 500, причому журнали заповнені фатальними помилками PHP.

У той момент у мене в голові була лише одна думка: О ні, основні файли пошкоджені.

Чесно кажучи, перша реакція більшості людей на це — паніка. Особливо для тих блогів, які ведуться роками, мають понад десяток плагінів та сильно налаштовані теми, ви можете подумати: «Якщо я перевстановлю все, чи всі мої речі залишаться там?»

Не панікуйте. Поки ви все ще можете підключитися через SSH, це можна вирішити за п'ять хвилин.

Причини пошкодження основних файлів WordPress

Спочатку трохи передісторії: механізм оновлення WordPress насправді досить крихкий. Під час онлайн-оновлень він замінює основні файли один за одним. Якщо дозволи неправильні, диск переповнений або процес перервано, файли будуть пошкоджені. Результатом цього пошкодження є збій вашого сайту, і ви не зможете отримати доступ ні до фронтенду, ні до бекенду.

Однак, є важливий момент, який слід розуміти: основні файли WordPress та ваш контент повністю окремі. Ваша тема, плагіни та завантажені зображення знаходяться в каталозі `wp-content`, а інформація про конфігурацію знаходиться у `wp-config.php`. Основні файли, з іншого боку, – це папки типу `wp-admin` та `wp-includes`, які по суті є просто набором PHP-програм.

Таким чином, заміна основних файлів за допомогою SSH по суті робить одне: повертає нову копію пошкодженої програми. Це як коли ваш комп'ютер зависає з синім екраном; якщо ви перевстановите систему, чи файли на вашому диску D все ще там? Це той самий принцип.

Виконайте кроки для заміни основних файлів WordPress за допомогою SSH

Історія така: я увійшов через SSH, зайшов до каталогу сайту і перше, що зробив, це перевірив поточний стан.

cd /var/www/html   # 根据你的实际路径

Потім завантажте останню версію WordPress.

wget https://wordpress.org/latest.tar.gz
tar -xf latest.tar.gz

Цей крок включає завантаження останньої версії стиснутого файлу WordPress та його розпакування. Після цього ви побачите нову папку з назвою "wordpress" у поточному каталозі.

Наступний крок є найважливішим: охоплення основних файлів.

cp -rf wordpress/* .

Ця команда означає примусове копіювання всього вмісту папки WordPress до поточного каталогу.

Ось що вам потрібно зрозуміти: ця операція не видалить ваші файли wp-content та wp-config.php. Цих файлів немає в папці WordPress; вони унікальні для вашого сайту. Тому цей крок безпечний; він лише перезапише основні файли програми.

Після виконання цієї команди я все ще відчував деяке занепокоєння. Що, як я щось неправильно перезаписав?

Потім я пішов очищати інсталяційний пакет.

rm -rf wordpress latest.tar.gz

Чисто та ефективно, не залишаючи слідів.

Після виконання цих кроків вам потрібно увійти до панелі адміністратора та виконати оновлення бази даних. Шлях: /wp-admin/upgrade.php. Цей крок є важливим, оскільки новіші версії WordPress можуть оновлювати структуру бази даних.

Чесно кажучи, весь процес зайняв менше п'яти хвилин. Я подумав, що якби я натиснув кнопку оновлення у фоновому режимі, хто знає, скільки б мені довелося чекати, і можливо, він знову завис.

Перед початком роботи обов'язкове резервне копіювання

Але я мушу нагадати вам про необхідність спочатку створити резервну копію. Принаймні, зробіть резервну копію вашого wp-config.php та бази даних. Це звичка, яку ви повинні виробити, незалежно від того, наскільки безпечною, на вашу думку, є ваша операція. Я сам стикався з втратою даних, і цей біль потрібно пережити лише один раз.

Як виправити дозволи каталогу після заміни SSH

Є ще одне: після заміни ви можете зіткнутися з новою проблемою — правами доступу до каталогу.

Після завершення заміни я перейшов до бекенду, щоб встановити плагін, але виникла помилка, оскільки ми не можемо скопіювати деякі файли, а оновлення не було встановлено.

Що це означає? Це означає, що коли ви використовуєте SSH для заміни файлу, власником файлу може стати root або інший користувач, а ваш веб-сервер, такий як Apache, використовує користувача www-data, який не має прав на запис. Тому механізм оновлення бекенду WordPress повідомляє про помилку.

Рішення не складне.

cd /home/你的用户名/web/你的域名文件夹/public_html/wp-content/
chmod -R 755 plugins/
chmod -R 755 themes/
chmod -R 755 uploads/
chmod -R 755 upgrade/

Встановлення прав доступу 755 для цих каталогів означає, що лише власник має право запису, а інші можуть лише читати.

Якщо ви використовуєте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

Директорію присвоюється номер 755, а файлу — 644.LinuxСтандартна конфігурація дозволів для веб-сервісів у цьому середовищі.

Пакетне оновлення плагінів та тем за допомогою WP-CLI

Крім того, якщо ви звикли використовувати WP-CLI, ви також можете одночасно оновлювати плагіни та теми пакетами.

wp plugin update --all
wp theme update --all

Чесно кажучи, я все ще сам досліджую кращі рішення для автоматизації. Наприклад, чи можу я написати скрипт, який би завершував весь процес резервного копіювання, заміни, зміни дозволів та оновлення бази даних одним клацанням миші? Теоретично це можливо, але я ще не повністю це протестував, тому не буду тут робити припущення на цю тему.

Повернувшись на сайт, який не працював, після всіх цих дій я оновив сторінку, і вона запрацювала. Фронтенд завантажився нормально, бекенд дозволяв вхід, і жодна з тем чи плагінів не була втрачена.

Як би це сказати? Це як витратити п'ять хвилин на SSH, щоб позбавити себе цілого дня клопоту.

Я думаю, що багато власників веб-сайтів, ймовірно, поділяють схожі тривоги: вони панікують, коли під час оновлення WordPress виникають проблеми, задаючись питанням, чи потрібно їм перевстановлювати все. Насправді, як тільки ви зрозумієте структуру файлів WordPress, основні файли – це просто пакети; ви можете просто замінити їх. Все, що справді належить вам, знаходиться в wp-content.

І останнє: візьміть за звичку регулярно створювати резервні копії. Неважливо, чи використовуєте ви плагін для автоматичного резервного копіювання, чи ручне резервне копіювання через SSH. Просто не чекайте, поки щось піде не так, щоб згадати про резервне копіювання.

Зрештою, як тільки дані зникнуть, вони зникнуть; але якщо програма зламається, її можна замінити.

Оскільки ви дочитали до цього місця, якщо це було корисно, будь ласка, поставте лайк та поділіться цим. Якщо ви хочете отримувати оновлення першими, ви також можете підписатися на мене!

Дякую, що прочитали мою статтю. До зустрічі наступного разу.