Как перезапустить сайт WordPress – сбросить WordPress (быстрый способ)

Недавно один из наших читателей спросил нас: «Как мне перезапустить свой сайт WordPress?».

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

В этом руководстве мы Я покажу вам, как быстро перезапустить или сбросить ваш сайт WordPress.

Зачем перезапускать сайт WordPress?

Перезапуск или сброс WordPress – это процесс, при котором вы восстанавливаете WordPress до настроек по умолчанию. Думайте об этом как о процессе, аналогичном восстановлению вашего телефона до заводских настроек по умолчанию.

Он удалит все ваши приложения и настройки, так что вы можете начать заново.

Есть несколько ситуаций, когда вы можете захотеть перезапустить или сбросить сайт WordPress:

1. Вы используете демонстрационный сайт на своем компьютере. Если вы установили WordPress на локальном хосте, возможно, вы захотите выполнить сброс после того, как создали сайт и переместили его с локального хоста на действующий сервер. Если вы разработчик и постоянно тестируете темы и плагины на своей локальной установке, то может помочь каждый квартал сбрасывать их, чтобы начать все заново.

2. Вы работали над новым сайтом и хотите начать все сначала. Возможно, вы были заняты созданием блога или веб-сайта, но вас не устраивают настройки. Вместо того, чтобы отменить все, вы можете просто сбросить WordPress и быстро начать с нового дизайна.

3. Вы собираетесь переделать веб-сайт клиента. Если они хотят чего-то очень отличного от того, что уже есть, вам может потребоваться сбросить WordPress на промежуточном сервере, чтобы он начал с нуля.

4. Вы изучаете WordPress на практике. Возможно, вы пытались разработать свои собственные плагины или темы, или вы экспериментировали со стартовой темой. Возможно, вы захотите начать заново с новой установки WordPress.

Видеоурок

Подпишитесь на WPBeginner

Если вы предпочитаете письменные инструкции, просто продолжайте читать.

Как перезапустить и сбросить сайт WordPress

Перезапуск вашего сайта WordPress может показаться трудным, но на самом деле это не так.

Мы проведем вас через весь процесс сброса, шаг за шагом.

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

Перезагрузите сайт WordPress с помощью WP Reset

Теперь вы готовы двигаться дальше и перезапускать сайт WordPress. Мы собираемся использовать для этого бесплатную версию плагина WP Reset.

Сначала вам нужно установить и активировать плагин WP Reset. Подробнее читайте в наших инструкциях по установке плагина WordPress..

После активации плагина вам нужно перейти в Инструменты »WP Reset на панели управления WordPress и прокрутить вниз до раздела страницы« Сброс сайта ».

Чтобы сбросить настройки вашего сайта, вам нужно ввести слово «сбросить» в поле подтверждения, прежде чем нажимать красную кнопку «Сбросить сайт».

WP Reset отобразит всплывающее сообщение с просьбой подтвердить, что вы хотите перезагрузить сайт. Нажмите «Сбросить WordPress», чтобы продолжить.

Вы увидеть сообщение «Выполняется сброс» в течение нескольких секунд. Затем ваш сайт будет перезапущен.

Затем вы увидите домашнюю страницу своей панели управления WordPress с сообщением об успешном завершении в верхней части WP Reset.

Вот и все. Вы перезапустили свой сайт WordPress.

Дополнительные функции сброса WP при перезапуске вашего сайта

Вышеупомянутый метод дает вам все необходимое для перезапуска вашего сайта.

Однако в WP Reset есть и другие параметры, которые вы, возможно, захотите использовать.

Создание снимка вашего сайта WordPress перед перезапуском

Вы можете использовать WP Reset, чтобы сделать снимок вашего сайта. Снимок – это точка восстановления для вашей базы данных WordPress. Это позволяет увидеть, какие изменения были внесены с момента создания снимка. При необходимости вы можете использовать его для отката изменений.

Важно: Снимок не является резервной копией WordPress. Вам все равно следует делать резервные копии, чтобы восстановить свой сайт.

Чтобы создать снимок, щелкните вкладку «Снимки». Затем прокрутите вниз и нажмите кнопку «Создать снимок»:

Вам будет предложено ввести имя или описание снимка. Введите все, что вы хотите использовать, затем нажмите кнопку «Создать снимок».

Удаление тем и плагинов с помощью WP Reset

По умолчанию WP Reset не удаляет файлы тем и плагинов. Он их просто деактивирует. Однако вы можете использовать его и для удаления этих файлов.

Сначала вам нужно перейти в Инструменты »WP Reset и щелкнуть вкладку« Инструменты » . Оказавшись там, просто нажмите ссылку «Удалить темы» или «Удалить плагины», чтобы перейти прямо к этим инструментам.

Щелкнув любую ссылку, вы переместитесь вниз по странице к нужному инструменту:

Вы можете нажать кнопку «Удалить все темы» или «Удалить плагины», чтобы удалить их.

Важно: WP Reset никоим образом не выполняет резервное копирование ваших файлов. Удаление тем и плагинов нельзя отменить.

После того, как вы нажмете кнопку, вам будет предложено подтвердить. Нажмите кнопку Удалить во всплывающем окне, чтобы продолжить..

Затем вы увидите сообщение о том, сколько темы или плагины были удалены.

Если вы удалите все темы, вам нужно будет установить и активировать тему вручную. Без него ваш сайт не будет работать. Если вы перейдете в Внешний вид »Темы , вы увидите такой экран:

Продолжайте, нажмите кнопку« Добавить »и выберите или загрузите тему по вашему выбору. Если вам нужна помощь, узнайте, как установить тему WordPress.

Восстановление ваших данных после перезапуска вашего сайта WordPress

После перезапуска вашего сайта WordPress любые сообщения и страницы тебя не будет. Вместо этого вы увидите страницы по умолчанию и сообщение «Hello, world»:

Чтобы восстановить старые данные, вам необходимо переустановить и активировать плагин резервного копирования, который вы использовали для создания резервной копии.

Затем вы можете следовать его инструкциям, чтобы восстановить свой сайт из резервной копии.

Просмотр восстановленного содержимого

После того, как вы восстановили свой сайт из резервной копии, ваш контент должен вернуться на Вашем сайте.

Все свои сообщения вы найдете в разделе Сообщения »Все сообщения . У них будут правильные отметки времени, категории, теги и комментарии.

Мы надеемся, что это руководство помогло вам узнать, как быстро сбросить настройки сайта WordPress. Вам также может понравиться наше полное руководство по ускорению WordPress и наш список обязательных плагинов WordPress для всех сайтов.

Если вам понравилась эта статья, подпишитесь на наш канал YouTube для видеоуроков по WordPress. Вы также можете найти нас в Twitter и Facebook.



Apache не работает на AWS Linux после перезагрузки – код ответа 301

Я установил экземпляр EC2 с Amazon Linux image и установлены LAMP и WordPress в соответствии с документами Amazon.

Он работает нормально, обслуживает страницу WordPress по умолчанию, но как только экземпляр перезагружается, веб-сервер перестает работать. Индексная страница больше не обслуживается. Curling localhost возвращает пустой.

Я не уверен, какая конфигурация теряется при перезагрузке. Apache и MYSQL запущены и настроены для запуска при загрузке.

Когда я пытаюсь curl http://localhost и смотрю журнал доступа к apache, я см .:

  :: 1 - - [17/июн/2017: 00: 56: 26 +0000] "GET/HTTP/1.1" 301 350 "-" "curl /7.35.0"::1 - - [17/июн/2017: 00: 59: 19 +0000] "GET/HTTP/1.1" 301 350 "-" "curl/7.35.0" :: 1 - - [  17/июн/2017: 00: 59: 21 +0000] "GET/HTTP/1.1" 301 350 "-" "curl/7.35.0"  

Вот мой httpd .conf

  ServerRoot "/etc/httpd" Listen 80Include conf.modules.d/*. confUser apacheGroup apacheServerAdmin root @ localhost  AllowOverride none Требовать все отклонено  DocumentRoot "/var/www/html"  AllowOverride None # Разрешить открытый доступ: требовать все разрешено  # Дальнейшее ослабление доступа к корню документа по умолчанию:  Параметры Индексы FollowSymLinks AllowOverride All Требовать все разрешено   DirectoryIndex index.html   Требовать все отклоненные  ErrorLog" журналы/error_log "LogLevel warn  LogFormat"% h% l% u% t  "% r "%> s% b  "% {Referer}  i  ""% {User-Agent} i  "" комбинированный формат журнала "% h% l% u% t "% r  "%> s% b" common  # Вам необходимо включить mod_logio.  c использовать% I и% O LogFormat "% h% l% u% t "% r  "%> s% b "% {Referer} i  ""% {User-Agent} i  "%  I% O "комбинированный  CustomLog" журналы/access_log "объединены   ScriptAlias ​​/cgi-bin/"/var/www/cgi-bin/"  AllowOverride Нет Параметры Нет Требовать предоставления всех разрешений   TypesConfig/etc/mime.types Приложение AddType/x-compress .Z Приложение AddType/x-gzip .gz.  tgz AddType text/html .shtml AddOutputFilter ВКЛЮЧАЕТ .shtml  AddDefaultCharset UTF-8  MIMEMagicFile conf/magic  EnableSendfile onInclude *.    p> Заголовки ответа от  curl -v   
  [ec2-user @ ip-xxxx ~] $ curl -v localhost * Восстановленный URL  to: localhost/* Попытка 127.0.0.1 ... * TCP_NODELAY set * Подключен к localhost (127.0.0.1) порт 80 (# 0)> GET/HTTP/1.1> Хост: localhost> User-Agent: curl/7.51.0  > Принять: */*>  

Я понял проблему. При перезагрузке экземпляра AWS адрес DNS изменяется. Поскольку я использую WordPress, мне нужно обновить URL-адреса siteurl и home в базе данных MySQL для сайта wordpress на новый адрес DNS.

Например, на рисунках ниже localhost следует заменить DNS-адресом экземпляра. Когда экземпляр перезагружается, его нужно будет снова заменить новым адресом DNS и т. Д. Каждый раз при перезагрузке экземпляра.. На самом деле мне следовало использовать статический DNS-адрес, чтобы избавить меня от этой проблемы 🙂


1

У меня возникла точно такая же проблема при развертывании HA WordPress на веб-сервере EC2 Apache в группе автоматического масштабирования при запуске нового веб-сервера EC2 Apache.

1. Сначала я думаю, что есть проблема с веб-сервером apache:

  sudo vim/var/log/httpd/error_log [вторник, 05 ноября] [core: notice]  [pid 2914] AH00094: Командная строка: '/usr/sbin/httpd' [Вт, 05 ноября] [mpm_prefork: notice] [pid 2914] AH00169: поймал SIGTERM, завершение работы [Вт, 05 ноября] [suexec: notice] [pid  3012] AH01232: механизм suEXEC включен (оболочка:/usr/sbin/suexec) [Вт, 05 ноября] [http2: warn] [pid 3013] AH10034: Модуль mpm (prefork.c) не поддерживается mod_http2.  MPM определяет, как вещи обрабатываются на вашем сервере.  HTTP/2 предъявляет больше требований в этом отношении, и текущий выбранный mpm просто не подходит.  Это рекомендательное предупреждение.  Ваш сервер продолжит работу, но протокол HTTP/2 будет неактивен. [Вт, 05 ноября] [http2: warn] [pid 3013] AH02951: mod_ssl не включен [Вт, 05 ноября, 14: 52: 14.233364 2019  ] [lbmethod_heartbeat: notice] [pid 3013] AH02282: Нет slotmem от mod_heartmonitor [Вт, 05 ноября] [mpm_prefork: notice] [pid 3013] AH00163: Apache/2.4.41 (Amazon) PHP/7.2.24 настроен - возобновление работы в обычном режиме  операции [Вт, 05 ноября] [core: notice] [pid 3013] AH00094: Командная строка: '/usr/sbin/httpd'  

Сначала мне показалось, что веб-сервер apache не работает но при проверке с помощью curl он показывает, что слишком много перенаправлений:

  [ec2-user @ ip-ec2 ~] $ curl -v localhost: 80 * Перестроен URL-адрес на: localhost  : 80/* Попытка 127.0.0.1 ... * TCP_NODELAY set * Подключен к localhost (127.0.0.1) порт 80 (# 0)> GET/HTTP/1.1> Хост: localhost> User-Agent: curl/7.61.1>  Принять: */*>  
  1. Затем 301 wordpress, ec2 привели меня сюда после почти 9 часов отладки

В моем случае siteurl и home указывают на старый экземпляр веб-сервера ec2, мы можем проверить это следующим образом:

  SELECT * FROM wp_options WHERE option_name = 'siteurl'; SELECT * FROM wp_options WHERE option_name = 'home';  

Затем следуйте @ Брайен Крин, чтобы обновить siteurl и home на URL-адрес ELB, тогда он заработает

  ОБНОВЛЕНИЕ wp_options SET option_value =  replace (option_value, 'old-ec2-url', 'fixed-elb-url') WHERE option_name = 'home' OR option_name = 'siteurl';  

Ссылка: Apache не работа в AWS Linux после перезагрузки - код ответа 301

https://wordpress.stackexchange.com/questions/245716/site-address-and-wordpress-address-settings-when-using-a -load-balancer

Получение перенаправления на уродливый URL-адрес beanstalk вместо просмотра моего доменного имени в моем WordP ress, несмотря на установку записи псевдонима Route53

Улучшите этот ответ
ответил 5 ноя '19 в 20:35
добавить комментарий |

У меня возникла точно такая же проблема при развертывании HA WordPress на веб-сервере EC2 Apache в группе автоматического масштабирования при запуске нового веб-сервера EC2 Apache.

1. Сначала я думаю, что есть проблема с веб-сервером apache:

  sudo vim/var/log/httpd/error_log [вторник, 05 ноября] [core: notice]  [pid 2914] AH00094: Командная строка: '/usr/sbin/httpd' [Вт, 05 ноября] [mpm_prefork: notice] [pid 2914] AH00169: поймал SIGTERM, завершение работы [Вт, 05 ноября] [suexec: notice] [pid  3012] AH01232: механизм suEXEC включен (оболочка:/usr/sbin/suexec) [Вт, 05 ноября] [http2: warn] [pid 3013] AH10034: Модуль mpm (prefork.c) не поддерживается mod_http2.  MPM определяет, как вещи обрабатываются на вашем сервере.  HTTP/2 предъявляет больше требований в этом отношении, и текущий выбранный mpm просто не подходит.  Это рекомендательное предупреждение.  Ваш сервер продолжит работу, но протокол HTTP/2 будет неактивен. [Вт, 05 ноября] [http2: warn] [pid 3013] AH02951: mod_ssl не включен [Вт, 05 ноября, 14: 52: 14.233364 2019  ] [lbmethod_heartbeat: notice] [pid 3013] AH02282: Нет файла slotmem от mod_heartmonitor [Вт, 05 ноября] [mpm_prefork: notice] [pid 3013] AH00163: Apache/2.4.41 (Amazon) PHP/7.2. 24 настроено - возобновление нормальной работы [Вт, 05 ноября] [core: notice] [pid 3013] AH00094: Командная строка: '/usr/sbin/httpd'  

Сначала я думаю, что веб-сервер apache не работает, но при проверке с помощью curl он показывает, что слишком много перенаправлений:

  [ec2-user @ ip-ec2 ~] $ curl -v localhost: 80  * URL перестроен на: localhost: 80/* Попытка 127.0.0.1 ... * TCP_NODELAY установлен * Подключен к localhost (127.0.0.1) порт 80 (# 0)> GET/HTTP/1.1> Хост: localhost> User-Agent:  curl/7.61.1> Принять: */*>  
  1. Затем 301 wordpress, ec2 привели меня сюда после почти 9 часов отладки

В моем случае siteurl и home указывают на старый экземпляр веб-сервера ec2, мы можем проверить это следующим образом:

  SELECT * FROM wp_options WHERE option_name = 'siteurl'; SELECT * FROM wp_options WHERE option_name = 'home';  

Затем следуйте @ Брайен Крин, чтобы обновить siteurl и home на URL-адрес ELB, тогда он заработает

  ОБНОВЛЕНИЕ wp_options SET option_value =  replace (option_value, 'old-ec2-url', 'fixed-elb-url') WHERE option_name = 'home' OR option_name = 'siteurl';  

Ссылка: Apache не работа в AWS Linux после перезагрузки - код ответа 301

https://wordpress.stackexchange.com/questions/245716/site-address-and-wordpress-address-settings-when-using-a -load-balancer

Получение перенаправления на уродливый URL-адрес beanstalk вместо просмотра моего доменного имени в моем WordP ress, несмотря на установку записи псевдонима Route53

Оцените статью
futurei.ru
Добавить комментарий