500 ошибка при переносе modx

Зачастую при необдуманном выборе хостинг-провайдера, в последующем, при возникновении каких-то ограничений или дискомфорта в использовании хостинга – многие решаются перенести свой сайт в другую хостинг-компанию, например, в Beget.

Но при, казалось бы, простом и успешном переносе сайта, находящегося на CMS MODX Revolution, можно столкнуться с рядом ошибок. Одна из них – «500 Error Site temporarily unavailable».

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

1. Итак, первое, что вам необходимо сделать – это подключиться к вашему сайту по FTP.

2. Затем перейдите в папку /core/ и удалите в ней папку cache.

3. Третьим шагом будет проверка корректности указанных данных для подключения к базе данных. Для этого откройте файл config.inc.php в папке /core/config/.

Здесь нас интересуют эти строки:

$database_type = 'mysql'; // Тип базы данных 
$database_server = 'localhost'; // Сервер базы данных 
$database_user = ''; // Пользователь базы данных 
$database_password = ''; // Пароль базы данных 
$dbase = ''; // Название базы данных 
$database_dsn = 'mysql:host=localhost;dbname=название базы данных;charset=utf8'; 

Тип и сервер базы данных уточните у своего хостинг-провайдера, но чаще всего они именно такие, какие по умолчанию указаны в файле.

Пользователь и название базы данных чаще всего одинаковые, но этот момент так же уточните у своего хостинг-провайдера.

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

4. И завершающим шагом будет прописывание корректного пути к папкам от корня сервера в файлах:

config.core.php (корневая папка /);
config.inc.php (папка /core/config/);
config.core.php (папка /connectors/);
config.core.php (папка /manager/).

Во всех файлах, вы ищите что то типа:

/home/s/pandogecom/www.pandoge.com/core/

Здесь вам необходимо изменить часть «/home/s/pandogecom/www.pandoge.com» на правильную.

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

В некоторых файлах замену нужно произвести в нескольких местах. Не торопитесь, будьте внимательны – и все у вас получится!

Постоянный вопрос у обладателей движка modx revo — как перенести его на другой хостинг — для многих это прям как ком в горле, не хочу…зачем…оказывается это не так сложно…

Да, возникают ошибки при переносе, но их можно решить…

Перенос сайта на modx revo на другой хостинг или на локальный компьютер по шагам:

1. «На старом» — хостинге запаковываем все: все файлы(можно предварительно очистить папку /core/cache/ — но можно и потом, без разницы) и базу данных. То есть получаем 2 архива.
2. Копируем все файлы на новый хостинг;
3. Загружаем (импортируем БД).
4. На новом хостинге или на домашнем компе меняем пути вот у этих файлов:
   /config.core.php
   /core/config/config.inc.php
   /connectors/config.core.php
   /manager/config.core.php             Большая часть проблем с переносом именно в прописании этих путей, не всегда удается их прописать правильно (если сомневаетесь спросите у поддержки хостинга) или, если у вас есть другие сайты на этом хостинге, то можно посмотреть у них пути. И следующий вариант, это прогнать сверху установщиком (загружаете папку setup в корень сайта и делаете «новую установку»). Я на локалку на open sever сегодня ставил и пути поменять у меня оказалось не проблемой, так как у меня рядом был другой тестовый домен с modx revo тоже и я там просто подглядел пути и все, но потом была другая проблема, о ней ниже…
5. Папку кэш /core/cache/ очищаем.

Все! — должно заработать.

Какие ошибки при установке modx Revo могут быть и как их решать?

500 error site temporarily unavailable modx revo

Наверное самая распространенная ошибка — это «500 error site temporarily unavailable» — это типа проблемы с сервером «Сайт временно недоступен». Происходит она по разным причинам — и всегда это настройки сервера и сайта. Для диагностики находим логи по адресу core/cache/logs/error.log — тут вы увидите примерные ошибки и они расшифрованы и примерно понять можно. При переносе сайта клиента на modx на локалку — я там нашел свою причину и удивился, оказалось, что у меня БД перенеслась не полностью, как такое произошло я до конца не понял, может ограничение какое-то, она была около 300 мб, в общем штук 10 таблиц не поместилось в архив, потом взял их отдельно запаковал и залил и все заработало. То есть всегда нужно смотреть в этот log файл — если есть какая-то ошибка.

Решения ошибки 500 error site temporarily unavailable на modx revo:

1. Смотрим целостность БД (ошибку смотрим в логах — как написано выше). Часть базы данных может не скопироваться, если она слишком большая!!!
2. смотрим файл .htaccess — пробуем его временно скопировать в другую папку и посмотреть как отреагирует.
3. версия php — она должна быть от 5.3 — все что ниже — тоже свалит в ошибку.

Смотрите также: как загрузить сайт на хостинг

Содержание статьи:

Платформа MODX — популярная и довольно удобная для пользователей CMS с открытым кодом. Перенос сайта на MODX имеет ряд нюансов, которые лучше учесть заранее.

Перенос MODX на другой хостинг — инструкция

Переезд сайта на новый хостинг правильно будет разбить на два этапа: этап подготовки и непосредственно переезд.

Подготовка сайта к переносу

Без правильной подготовки вы не сможете восстановить сайт на новом хостинге так, чтобы он работал корректно. Поэтому мы составили алгоритм из трёх пунктов, которые необходимо реализовать перед началом переезда сайта.

1. Удаление кэша

Удалить кэш можно несколькими способами:

1. Через админку самого сайта. Зайдите в системные настройки, а затем последовательно выберите пункты “Сайт” и “Статус сайта: нет”. Теперь в верхнем меню кликните на выпадающий список в пункте “Управление” и выберите “Очистить кэш”.

2. Через административную панель текущего хостинга. Для этого нужно очистить содержимое папки “core/cache”. Только не удаляйте саму папку, нужно удалить только файлы, содержащиеся в ней.

   Очистить папку с  кэшем  MODX из SSH или терминала можно так (на примере панели управления cPanel)

   

   cd public_html/  <- путь к папке сайта
   rm -rf core/cache/*  <- очистка папки с кэшем

   

3. Через FTP. Здесь также очищаем папку “core/cache”.

Некоторые специалисты рекомендуют выполнять сразу два первых пункта из этого списка: сначала удалять кэш на уровне сайта, а затем на уровне хостинга.

2. Выход из административной панели

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

Для этого в административной панели сайта кликните на вкладку “Управление” и выберите пункт “Перезагрузить права доступа”. А затем снова кликните на “Управление” в верхнем меню, но на этот раз выберите пункт “Завершить все сеансы”.

3. Бэкапы

Перед переносом нужно сделать два вида резервного копирования: бэкап базы данных и бэкап файлов.

Бэкап файлов

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

Выберите папку сайта MODX на сервере, например public_html, и скачайте её на свой компьютер. Предварительно можно заархивировать папку — тогда процесс скачивания будет быстрее. 

Бэкап базы данных

Сделать бэкапы базы данных можно в административной панели вашего текущего хостинга. Сперва нужно создать архив файлов, а затем экспортировать и сохранить. Для этой задачи подойдёт приложение phpMyAdmin, оно есть в панелях большей части популярных хостинг-провайдеров. 

В phpMyAdmin выбрать пункт “Экспорт”, выбрать базу данных (имя базы данных можно посмотреть в файле /core/config/config.inc.php), а также формат скачивания — SQL, — и нажать кнопку “Вперёд”.

Если опции экспорта оставить по умолчанию, то размер базы данных в таком случае будет не сжат, но и не создаст  нагрузку на сервер по время создания дампа (копии). 

Если место на сервере ограничено, а размер дампа большой,  то следует создать дамп в сжатом виде: во втором пункте выбирается формат сжатия, подойдёт gzip/zip.

Процесс переноса сайта на ModX

Когда предварительные этапы будут выполнены, можно будет приступить к переносу сайта на новый хостинг.

1. Перенос базы данных

Здесь нам снова пригодится приложение phpMyAdmin. На новом хостинге создайте новую базу данных и пользователя для этой базы данных. Затем выберите пункт “Импорт” и загрузите в неё копию базы данных вашего сайта. 

2. Копирование файлов

После сохранения базы данных закачайте на хостинг сохранённые файлы. Если вы скачивали их в виде архива — то заливайте прямо так, а затем уже там распакуйте на хостинге.

3. Исправление путей к файлам и директориям

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

Вот список конфигурационных файлов, которые следует исправить:

• /core/config/config.inc.php

• /config.core.php

• /manager/config.core.php

• /connectors/config.core.php

Самый важный из этих файлов — /core/config/config.inc.php. Это главный конфигурационный файл MODX. В нём вам нужно будет изменить пути к файлам — заменить их на актуальные. Актуальные пути к файлам вы можете узнать сами, просто посмотрев, в каких папках и подпапках они теперь находятся. 

Обратите внимание, в файле будет указано несколько путей — и в каждый из них нужно будет внести корректировки. Если этого не сделать — ваш сайт не будет работать.

Кроме того, в этом файле нужно изменить информацию об имени вашей базы данных, пользователе и пароле. 

Удобнее всего вносить изменения, открыв файл в программе Notepad++ — редакторе, который устанавливается на ваш компьютер. Скачать его можно здесь. 

Аналогичное действие нужно проделать и с остальными файлами, перечисленными выше.

4. Обновление файла .htaccess

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

Важно не забыть в этом случае внести изменения в файл .htaccess, чтобы там был указан актуальный адрес сайта.

5. Очистка кэша

Завершить переезд сайта нужно повторной очисткой кэша в админке сайта: “Управление” — “Очистить кэш”.

6. Перенос задач из Cron

Чтобы перенести задачи, проставленные в Cron на текущем хостинге, на новом их нужно будет пересоздать. Это делается в админке хостинга. В разных панелях управления хостингом раздел с планировщиком задач называется по-разному. Например, в панели cPanel он называется “Планировщик заданий”, а в ISPmanager — “Планировщик Cron”.

7. Проверка работоспособности сайта

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

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

Ошибки и проблемы, связанные с переносом MODX на хостинг

• Ошибка 403 при переносе сайта MODX

Похоже, что-то не то с корневой папкой сайта. Возможно, в ней отсутствуют файлы или назначены некорректные права на папки и файлы в ней.

Кроме того, проблема может быть с файлом .htaccess — проверьте корректность прописанных в нём данных.

• Ошибка 404 на внутренних страницах

Проблема с файлом .htaccess. Скорее всего, он вообще отсутствует. Скопируйте его заново и загрузите в корень вашего сайта. Также можно загрузить оригинальный .htaccess из чистой установки — скачать её можно по ссылке.

• Ошибки 500 и 503 при переносе сайта 

Скорее всего, вы внесли изменения не во все пути к файлам на новом хостинге. 

1. В первую очередь, следует очистить кэш (вы делали это уже два раза, повторяться не будем). Затем проверьте корректность путей к файлам и директориям. 

2. Также обратите внимание, верно ли указано имя вашей базы данных в файле core/config/config.inc.php,  а также доступы к ней.

3. Ещё один момент, связанный с базой данных: она могла быть загружена в неверной кодировке. Проверьте, совпадают ли кодировки БД на старом и новом сервере.

4. Менее вероятная, но возможная причина ошибок: некорректная версия PHP. Возможно, её стоит обновить. Но имейте в виду, что это может повлечь за собой другие ошибки и проблемы с отображением контента.

5. Также решить проблему может увеличение доступной памяти в PHP. Попробуйте увеличить memory_limit до 256М — 512М.

6. Наконец, если всё перечисленное выше в порядке, проблема может оказаться в знаках препинания или лишних символах в коде. 

• Не открывается админка сайта

Если после захода в админку вы не видите ничего, кроме белого экрана, скорее всего, дело в кэше. Найдите папку core/cache и очистите её содержимое (саму папку не удаляйте).

• Переадресация на админку хостинга вместо админки сайта

Это происходит, если адрес админки сайта совпадает с адресом панели управления хостингом. Такое в редких случаях, но бывает. Чтобы исправить этот недочёт, нужно изменить адрес административной панели сайта. Найдите файл config.inc.php на хостинге, откройте его, и в пунктах  $modx_manager_url и $modx_manager_path измените слово manager на content. 

Затем найдите системный каталог manager и также переименуйте его в content.

Теперь адрес админки вашего сайта: vashdomen.by/content.

• Все буквы кириллицы заменились знаками вопроса или другими символами

Проверьте, всё ли хорошо с базой данных: корректный ли прописан к ней путь, верная ли кодировка. Если вы исправили недочёты, но ничего не изменилось — удалите загруженный файл и залейте файл с базой данных заново.

Как перенести сайт на хостинг HostFly.by — видео

Что думают эксперты о CMS MODX?

Мы взяли комментарии у специалистов из области разработки и SEO-продвижения:

Егор Дорофеев, СЕО агентства v90.team:

“Мы работаем с CMS MODX Revolution при разработке сайтов.

Из минусов, которые я бы выделил:

•  Мало готовых MODX-шаблонов (если рассматриваем для клиента разработку сайта на шаблоне).

•  Для сложных доработок в данной CMS нужны знания html, css + желательно js (но это уже минус больше не для клиента, а для программиста, который работает с данной CMS).

А основные плюсы CMS такие:

•  Сама по себе админка бесплатная.

•  Простая, интуитивно понятная панель администратора.

•  Большой выбор готовых модулей (плагинов) для внедрения и простота их установки.

•  Админка ориентирована на SEO-продвижение.

•  Кроссбраузерность и кроссплатформенность. Поддерживаются все основные браузеры, в т. ч. мобильные.

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

Евгений Лабков, founder агентства Starpointup:

“Работаю с MODX Revo около четырех лет. Почему? Очень удобная CMS для оптимизации под SEO, если надо, большинство доработок можно сделать без привлечения разработчиков, шаблонизировать любые меты, тексты. 

Ещё из плюсов: не обязательно знать PHP, большое RU-язычное комьюнити, простота в использовании для пользователя и при разработке. 

Минусы: очень маленькая популярность по сравнению с WP и Битриксом, из-за этого чаще клиенты ищут разработку на других CMS. 

Мы разрабатывали на MODX как лендинги, так и интернет-магазины с подвязкой к CRM, а также интернет-магазины с возможностью динамичного обновления контента на всём сайте при обновлении информации в Google-таблицах”.

Hi Guys,
This is a project I have been working on for some time. I’m slowly getting over each hump as I come to it.
Sorry this is so long winded but I reckon more is better and may save a lot of questions.

My Goal is to move a copy of my Production Web page onto a private Development server.
The production page was written by an external company and is still hosted on their web server.
They have given me ftp access to the files and a backup of mySql in a dump.sql

I plan to develop / update some content on my development server and then move it into production once tested.

Development Machine
===================
I’m have installed Modx Revo version 2.2.6-PL which is the same version production. I copied the setup folder off the production server and ran it. Setup connected to my local My local MYSQL db no problem. This was restored from a dump.sql file.

The server is running Debian Wheezy. Apache is version 2.2.22 and PHP is Version 5.4.4-14+deb7u3.

All the static files that make up my web pages were copied off production into development using FTP.
I have done a file compare of the contents of all files and nothing seems to be corrupted.

OK
The Problem
=============
when I load http://myIPaddress/index.php I received the following error
Error 503
Site temporarily unavailable

Almost the same thing when I try and load http:/myIPaddress/manager
It just says
Site temporarily unavailable

When I look into index.php it appears that the error comes from this section. (I edited the title text to be sure)
(both the index.php and /manager page show my edited title)

My model/modx folder is actually not of the web server root folder.
It is located here core/model/modx

This folder structure is matching on both production and development.
The mysteries of htaccess still allude me at the moment but havn’t had much time to figure it out so far.
From what I can tell all my htaccess files are named ht.access so should not have any effect.

Does anyone know what is going on here?

forums.modx.com

Установка MODX Revolution на новый хостинг

Все дело в том что при установке на старом хостинге создались несколько файлов конфигурации MODX Revo которые нужно подправить. В моем случае я установил для демонстрации modx revo на локальную машину и соответственно домен и пути у вас будут отличаться чем прописываемые в моей статье

  C:/OpenServer/domains/modxrevo.ru/  

Файлы которые нужно подредактировать при установке CMS MODX Revolution на новый хостинг:
1) config.core.php в корне сайта нужно подправить следующую строку:

  define('MODX_CORE_PATH', 'C:/OpenServer/domains/modxrevo.ru/core/');  

2) /manager/config.core.php

  define('MODX_CORE_PATH', 'C:/OpenServer/domains/modxrevo.ru/core/');  

3) /connectors/config.core.php

  define('MODX_CORE_PATH', 'C:/OpenServer/domains/modxrevo.ru/core/');  

4) /core/config/config.inc.php данный файл требует большого редактирования.

При таком количестве необходимого редактирования записи можно вполне что-то пропустить.

Самое видимо простое решение это установить чистый modx revo на новом хостинге. Затем скачать те самые 4 файла, после скачки затереть установленную чистую CMS и затереть соответственно бд. Необходимые файлы мы получили, теперь можно по обычному заливать резервную копию. И теперь заливаем в соответствующие папки те самые 4 файла. Для /core/config/config.inc.php проверяем корректность прописи подключения к БД.

Возможна следующая ошибка Fatal error: Call to a member function parseProperties() on null in coremodelmodxmodelement.class.php on line 536

  Очистить /core/cache/  

Следующая ошибка которая у вас наверняка возникнет это то что вы неправильно настроите в базе данных таблицы users и user_attributes.

В таблице users вы конечно поменяете пароль, но можем возникнуть ситуация когда вы просто добавите нового пользователя допустим admin и пропишете все как надо, но опять не сможете войти в админку, все дело в том что таблица user_attributes обязательно должна содержать профиль теперь уже пользователя admin. Если профиля для нового пользователя admin нет, то и войти под данным логином вам не удастся.

Вот вы вошли в админку первым дело вам нужно зайти в ваш профиль логина, можно ничего не менять, а просто сохранится, чтобы если что не создалось в бд по логину, то нужно чтобы создалось. Потом нужно почистить профиль, снять блокировки в общем пощелкать все что лежит в журнале управления. Обычно на восстановление сайта уходят мгновения и все проходит легко, но с modx revolution не так быстро.

Всё.

ligatime.ru

Зачастую при необдуманном выборе хостинг-провайдера, в последующем, при возникновении каких-то ограничений или дискомфорта в использовании хостинга – многие решаются перенести свой сайт в другую хостинг-компанию, например, в Beget.

Но при, казалось бы, простом и успешном переносе сайта, находящегося на CMS MODX Revolution, можно столкнуться с рядом ошибок. Одна из них – «500 Error Site temporarily unavailable».

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

1. Итак, первое, что вам необходимо сделать – это подключиться к вашему сайту по FTP.

2. Затем перейдите в папку /core/ и удалите в ней папку cache.

3. Третьим шагом будет проверка корректности указанных данных для подключения к базе данных. Для этого откройте файл config.inc.php в папке /core/config/.

Здесь нас интересуют эти строки:

$database_type = 'mysql'; // Тип базы данных   $database_server = 'localhost'; // Сервер базы данных   $database_user = ''; // Пользователь базы данных   $database_password = ''; // Пароль базы данных   $dbase = ''; // Название базы данных   $database_dsn = 'mysql:host=localhost;dbname=название базы данных;charset=utf8'; 

Тип и сервер базы данных уточните у своего хостинг-провайдера, но чаще всего они именно такие, какие по умолчанию указаны в файле.

Пользователь и название базы данных чаще всего одинаковые, но этот момент так же уточните у своего хостинг-провайдера.

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

4. И завершающим шагом будет прописывание корректного пути к папкам от корня сервера в файлах:

config.core.php (корневая папка /);
config.inc.php (папка /core/config/);
config.core.php (папка /connectors/);
config.core.php (папка /manager/).

Во всех файлах, вы ищите что то типа:

/home/s/pandogecom/www.pandoge.com/core/  

  
 

Здесь вам необходимо изменить часть «/home/s/pandogecom/www.pandoge.com» на правильную.

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

В некоторых файлах замену нужно произвести в нескольких местах. Не торопитесь, будьте внимательны – и все у вас получится!

www.pandoge.com

500 error site temporarily unavailable modx revo

Наверное самая распространенная ошибка — это «500 error site temporarily unavailable» — это типа проблемы с сервером «Сайт временно недоступен». Происходит она по разным причинам — и всегда это настройки сервера и сайта. Для диагностики находим логи по адресу core/cache/logs/error.log — тут вы увидите примерные ошибки и они расшифрованы и примерно понять можно. При переносе сайта клиента на modx на локалку — я там нашел свою причину и удивился, оказалось, что у меня БД перенеслась не полностью, как такое произошло я до конца не понял, может ограничение какое-то, она была около 300 мб, в общем штук 10 таблиц не поместилось в архив, потом взял их отдельно запаковал и залил и все заработало. То есть всегда нужно смотреть в этот log файл — если есть какая-то ошибка.

Решения ошибки 500 error site temporarily unavailable на modx revo:

1. Смотрим целостность БД (ошибку смотрим в логах — как написано выше). Часть базы данных может не скопироваться, если она слишком большая!!!
2. смотрим файл .htaccess — пробуем его временно скопировать в другую папку и посмотреть как отреагирует.
3. версия php — она должна быть от 5.3 — все что ниже — тоже свалит в ошибку.

saitsozdanie.ru

Fix «This Website Is Temporarily Unavailable» GoDaddy Error

Is the domain registered at GoDaddy and the domain status is active?

If the domain status is passive, or need renewal, then you need to renew the domain first and ensure the domain status is active.

Figure out the type of domain hosting package you have (cPanel, Managed WordPress, Website Builder, etc.)

You need to know what kind of hosting package you have and you have successfully generated domain records and added in the GoDaddy DNS manager.

Was the site working before and it changed to this, or was it never working?

The site may be having the error because you have done some recent changes in the DNS manager. It may take 4-8 hours for .com and .net domain names and 24-48 hours for other domain names. If you are hosting your domain in Word press, it may take 48 — 72 hours to complete the domain mapping.

Whether your domain name is pointing towards a Parked Page IP?

If the domain is pointing towards a parked page, change the name servers to the hosting provider’s.
For WordPress, the name servers are;

NS1.WORDPRESS.COM
NS2.WORDPRESS.COM
NS3.WORDPRESS.COM

Here is details of Google Open DNS and how to test it: Open DNS by Google.

Have you tried Cleared caches in the browser?

Sometimes the browser may have kept cache of the website with the error. Try clearing cache of your browser and reload it again.

How To Fix the this website is temporarily unavailable please try again later blogger error

First you should see whether your domain is visible in Internet. You can do that by visiting Whatsmydns website. Here is an easy way to do that. Copy the below URL and change shipmethis.com to your domain name. Paste the URL in the browser.

For Checking Active CNAME of Domain

https://www.whatsmydns.net/#CNAME/www.shipmethis.com

For Checking A Record of a Domain

https://www.whatsmydns.net/#A/www.shipmethis.com

For Checking AAAA Record of Domain

https://www.whatsmydns.net/#AAAA/www.shipmethis.com

Your domain is visible in internet if these CNAME, A Record and AAAA records are appearing fine with a green color. If not there may be errors in any of these domain records. You may need to change the DNS settings of your domain in this case. Login to GoDaddy DNS manager and check these domain records.

www.shipmethis.com

Причины ошибки 503 Service Unavailable в WordPress

Ошибка 503 service unavailable может быть вызвана рядом причин, включая (но не ограничиваясь):

• Ошибки в плагинах или темах
• Сбои в работе пользовательский PHP скриптов
• Недостаточно ресурсов сервера
• Ошибки сервера
• Злоумышленные атаки, такие как хорошо всем известные DDoS (Distributed Denial of Service)

Мы пройдёмся по всем этим причинам и предложим различные решения по устранению ошибки 503 service unavailable.

Ошибка в плагине

Некорректно работающий плагин может быть причиной большинства возникающих в WordPress ошибок. К слову, ошибка в плагине лидирующая причина возникновения ошибки 503 service unavailable в WordPress.

Если вы столкнулись с ошибкой 503 после установки или обновления конкретного плагина, скорее всего вы уже нашли виновника. Всё, что вам потребуется сделать, это удалить проблемный плагин и работа сделана.

Если, однако, у вас нет идей по поводу того, какой именно плагин мог вызвать ошибку 503, нужно начать диагностику путём деактивации всех плагинов.

Но как деактивировать все плагины WordPress, если у вас нет доступа к админ панели?

Деактивация всех плагинов WordPress

Зайдите в ваш каталог WordPress по FTP или используя Файловый менеджер. В этом руководстве будем использовать популярную программу подключения по FTP FileZilla:

Так выглядит наш тестовый каталог WordPress в Файловом менеджере на Hostinger:

Внутри нашего каталога WordPress, найдите и откройте каталог wp-content, который содержит ваши плагины, темы и медиа контент среди прочего.

Нажмите правой кнопкой мыши на каталоге plugins и переименуйте его в plugins-old:

Это приведёт к деактивации всех плагинов одновременно. Теперь переименуйте обратно plugins-old в plugins и перегрузите свой сайт. Если ошибка 503 исчезла, плагин является причиной вашего текущего затруднительного положения.

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

Теперь вы сможете зайти в свою админ консоль на сайте WordPress через браузер и активировать по очереди один за другим все плагины.

Каждый раз, когда вы активируете плагин, перезагружайте сайт, чтобы выявить неисправный плагин. Как только вы нашли хулиганистый плагин, зайдите свой каталог plugins по FTP и удалите его:

Если деактивация плагинов не помогла в устранении ошибки 503 service unavailable, читайте дальше другие решения. Теперь давайте проверим, не является ли причиной проблемы ваша тема.

Сомнительная тема WordPress

Порой, скрипт PHP с ошибками, который выдаёт ошибку 503 может быть частью темы. Для проверки этого, мы переключимся на тему по умолчанию Twenty Seventeen. Между прочим, рекомендуется оставлять темы по умолчанию даже после установки новой темы, поскольку она (тема по умолчанию) служить запасной темой в случае проблема с вашей.

Деактивация темы WordPress

Прежде, чем мы деактивируем вашу тему (или удалим, если это проблема) нужно создать бэкап. Подключитесь к своему сайту WordPress по FTP и перейдите в каталог wp-content -> themes.

Найдите вашу текущую тему и скачайте её, как показано ниже:

Далее удалите вашу текущую тему и перезагрузите сайт. Если ошибка 503 исчезла, вам нужно исправить/обновить вашу тему. Если это не вариант для вас, тогда возьмите новую копию или другую тему.

Если ошибка 503 service unavailable осталась, возможно, фрагмент кода PHP с ошибкой находится где-то в другом месте вашего сайта.

Сбой в работе пользовательского кода PHP

Порой, код от сторонних сервисов или фрагмент кода, который вы добавили на свой сайт может вызвать ошибку 503. Но как определить, что проблема в коде.

В обычном режиме, когда ваш сайт работает, можно использовать плагины для отладки, такие как Query Monitor и Debug Bar.

Включение WP_DEBUG

Но, так как 503 ошибка часто блокирует вам вход в админ панель вашего WordPress сайта, мы будем использовать константы  WP_DEBUGи WP_DEBUG_LOG, WP_DEBUG_DISPLAY и @ini_set доступные в WordPress.

Для включения режима отладки в WordPress и записи логов ошибок в файл, следуйте шагам:

1. Откройте каталог WordPress по FTP или в Файловом менеджере.
2. Откройте файл wp-config.php
3. Прокрутите до определения константы WP_DEBUG. Выглядит так: define ('WP_DEBUG', false);. Если она пропущена, мы добавим её сразу перед словами /*That's all, stop editing! Happy blogging.*/
4. Вставьте магический код отладки DEBUG. Только исправьте код define ('WP_DEBUG', false); на:
   define ('WP_DEBUG', true);
define ('WP_DEBUG_LOG', true);
define ('WP_DEBUG_DISPLAY', false);
@ini_set ('display_errors', 0);
5. Сохраните изменения

Теперь перезагрузите свой сайт, чтобы вызвать появление ошибки. Далее, найдите файл под названием debug.log внутри вашего каталога wp-content в каталоге WordPress.

В этом файле содержаться записи по всем ошибкам на вашем сайте. Если ваша ошибка 503 service unavailable вызвана фрагментом пользовательского кода, это будет видно с указанием её подробностей.

Устраните/замените проблемный код и перезагрузите сайт. Если ошибка 503 осталась, проблема может быть в вашем веб-сервере.

Причины, связанные с сервером

Ряд причин, связанных с сервером тоже может вызывать ошибку 503 service unavailable. Обычно, ошибка 503 вызванная проблемами с сервером исчезает автоматически через несколько минут.

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

Повысить ресурсы сервера

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

Вы постоянно получаете ошибку 503 service unavailable? Если да, проверьте свои показатели в Google analytics. Если вы получаете больше трафика, чем обычно, вам определённо перестало хватать изначальных ресурсов сервера.

Однако, если у вас нету прироста в трафике, но всё равно возникает ошибка 503, ваша проблема не имеет отношение к недостаточному количеству RAM или памяти на сервере.

Ограничение частоты сканирования Google

Для индексирования вашего контента, Google использует специальные скрипты, известные как сканеры (crawlers). Они регулярно посещают сайт и собирают контент и определяют другие показатели ранжирования.

Хоть это и редкий случай, но сканирование может вызвать рост потребления ресурсов на вашем сервере и замедление работы сайта. Чтобы обойти это и избежать ошибки 503, вы можете ограничить частоту сканирования Google в Google Search Console.

Примечание: Изменения, внесенные вами, будут действовать в течение 3 месяцев. К тому же, если у вас есть версия сайта с WWW и без WWW, сделать настройки нужно для обоих.

Войдите в Google Search Console и выберите свой сайт. Далее нажмите на иконку шестерёнки, как показано ниже:

На следующей странице настройте частоту сканирования Google перемещением ползунка влево:

Ограничение WordPress Heartbeat

Согласно WordPress.org, “…Heartbeat API – это пример API приложения встроенного в WordPress и осуществляющего опрос сервера, позволяя в режиме почти реального времени видеть показатели.” Он отвечает за такие функции, как авто-сохранение и так далее.

Приложение WordPress Heartbeat API запускает файл admin-ajax.php среди других запросов с регулярным интервалом, когда вы заходите на свой сайт.

Это функциональность потребляет ресурсы вашего сервера, но вы можете её ограничить или вообще выключить. Когда вы восстанавливаете свой сайт, вы можете использовать плагин Heartbeat Control WordPress для ограничения этой функциональности, вместо того, чтобы выключить его вообще.

Чтобы определить вызывает ли WordPress Heartbeat ошибку 503 service unavailable на своём WordPress сайте, добавьте следующий код в свой файл темы functions.php сразу после открытия тэга <?php:

add_action( 'init', 'stop_heartbeat', 1 ); function stop_heartbeat() { wp_deregister_script('heartbeat'); }

Сохраните изменения и перезагрузите сайт. Если ошибка 503 пропала, вздохните с облегчением. Но если ошибка 503 service unavailable всё ещё осталась, это значит WordPress Heartbeat API является наименьшей из ваших проблем.

Если код выше не помог устранить ошибку 503, не забудьте удалить этот код из своего файла functions.php.

Заключительные заметки

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

Надо отметить, что ошибка 503 service unavailable, это преимущественно результат выполнения некорректного кода PHP, такого как ошибка в плагине или теме.

Также важно отметить, что 503 ошибка вызванная недостатком ресурсов сервера чаще всего проходит сама собой, поэтому всегда перезагружайте свой сайт немного погодя для проверки того, осталась ли ещё ошибка.

Независимо от того, что происходит, помните вы всегда можете исправить ошибку 503 service unavailable совершенно не утруждая себя. А поэтому, нет повода для паники, так как это не постоянная ситуация.

Сталкивались ли вы с ошибкой 503 service unavailable? Как вы её устраняли? У вас есть вопросы или предложения? Пожалуйста, делитесь ими в комментариях ниже. Заранее благодарим!

www.hostinger.ru

Я имел ввиду вот что делать.

/* check for correct version of php */    $php_ver_comp = version_compare(phpversion(),'5.1.0');    if ($php_ver_comp < 0) {   die('Wrong php version! You're using PHP version "'.phpversion().'", and MODX Revolution only works on 5.1.0 or higher.');  }  exit();//Добавили exit();  /* set the document_root */  /*if(!isset($_SERVER['DOCUMENT_ROOT']) || empty($_SERVER['DOCUMENT_ROOT'])) {   $_SERVER['DOCUMENT_ROOT'] = str_replace($_SERVER['PATH_INFO'], '', str_replace('\', '/', $_SERVER['PATH_TRANSLATED'])) . '/';  }*/    /* include the modX class */  /*if (!(include_once MODX_CORE_PATH . 'model/modx/modx.class.php')) {   include MODX_CORE_PATH . 'error/unavailable.include.php';   die('Site temporarily unavailable!');  }*/    /* @var modX $modx create the modX object */  /*$modx= new modX('', array(xPDO::OPT_CONN_INIT => array(xPDO::OPT_CONN_MUTABLE => true)));  if (!is_object($modx) || !($modx instanceof modX)) {   $errorMessage = '<a href="../setup/">MODX not installed. Install now?</a>';   include MODX_CORE_PATH . 'error/unavailable.include.php';   header('HTTP/1.1 503 Service Unavailable');   echo "<html><title>Error 503: Site temporarily unavailable</title><body><h1>Error 503</h1><p>{$errorMessage}</p></body></html>";   exit();  }    $modx->initialize('mgr');    $modx->getRequest();  $modx->getParser();    if (isset($modx) && is_object($modx) && $modx instanceof modX) {   if (!$modx->getRequest()) {   $modx->log(modX::LOG_LEVEL_FATAL,"Could not load the MODX manager request object.");   }   if (!MODX_API_MODE) {   $modx->request->handleRequest();   }  }  @session_write_close();  exit();*/

Всё остальное закомментировали, потом опять то же самое, но на более позднем участке. И так пока не найдёте в каком месте у вас вылазит ошибка. Нашли, если это во время подключения класса, то просто возмите и залейте заново все классы с заменой файлов

modx.im

Серверные ошибки

• Ошибка 403 — 403 Access denied
• Ошибка 404 — 404 File not found
• Ошибка 500 — 500 Internal server error
• Ошибка 502 — 502 Bad Gataway
• Ошибка 503 — 503 Service temporarily unavailable
• Ошибка 504 — 504 Gateway time-out

Ошибка 403 — 403 Access denied (Доступ к ресурсу запрещен)

Ошибка 403 означает, что доступ к ресурсу, папке или файлу запрещен (получен код 403 Forbidden). Возможно, что доступ был закрыт через файл .htaccess.

Так же ошибка может быть вызвана тем, что в папке нет index файла.

Ошибка 404 — 404 File not found

Документ по указанному URL не существует. Возможно, такой файл удален, либо вы ошиблись при наборе URL в браузере или пошли по неверной ссылке.

Ошибка 500 — 500 Internal server error

Появление 500 ошибки, может быть связано с неправильно указанными параметрами в файле .htaccess, который находится в папке с вашим сайтом.

Также, если файл сохранён в кодировке UTF-8, он должен быть без метки BOM. Если же файл сохранён в UTF-8 с меткой BOM, откройте файл и сохраните его без метки BOM.

Ошибка 500 у CGI скриптов, может быть вызвана из-за неправильных прав у файла-скрипта CGI (должны быть 755).

Также, это может быть ошибка непосредственно в сценарии скрипта. Точную причину можно установить, просматривая лог ошибок.

Ошибка 502 — 502 Bad Gataway

Данная ошибка означает, что сервер (или proxy-сервер) получил недопустимые ответы другого сервера (или proxy-сервера).
Причиной может быть некорректная работа скриптов, либо ошибка ответа шлюза веб-сервера.

Одна из наиболее частых причин ошибки 502:
скрипт сайта отправляет cookie или другие данные множество раз при каких-то определённых действиях, в результате чего объём заголовков (header) растёт больше допустимого лимита веб-сервера.

При достижении порогового значения, веб-сервер отклоняет запрос с слишком большим заголовком, отбрасывая соединение с ошибкой 502 Bad Gateway. Такое бывает, когда скрипты написаны разработчиками без должной оптимизации.

На хостинге используется связка веб-серверов nginx (front-end) + apache (back-end)
У nginx указаны оптимальные параметры для заголовков:

proxy_buffer_size 32k; proxy_buffers 16 32k; 

Прочие причины:
иногда пользователи невнимательны в выборе опций, и не читают их описание.
В хостинг-панели зайдите в раздел Домены → Настройки, если там включены все опции прдряд (стоят галочки), то отключите их. Это может убрать ошибку 502.

Ошибка 503 — 503 Service temporarily unavailable

Ошибка 503 (Service Temporarily Unavailable) – обслуживание временно недоступно.

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

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

Информация для более детального понимая проблемы.

Что же такое хостинг? Хостинг — некоторое количество аккаунтов на одном сервере, в каждом аккаунте может быть не один сайт и основное ограничение на нашем хостинге — это ограничение по нагрузке аккаунта пользователя, причем ограничение от одного потока процессора (CPU), а мы используем мощные многопроцессорные сервера.
Приведем пример на основе нашего сервера с минимальной частотой CPU 3.2GHz — это частота одного потока (ядра) процессора, а их 8 (на некоторых — больше), но как написано выше, ограничение для одного аккаунта считается от одного ядра. Теперь возьмем минимальный тариф SSD1, где ограничение по нагрузки составляет 20% CPU. 20% от 3.2GHz это640MHz, причем всего за 100 рублей/месяц. Много это или мало — решать вам, но для минимального тарифа этого более чем достаточно. Поэтому для каждого аккаунта на сервере выделяется определенное количество рабочих процессов, которые обрабатывают запросы пользователей ваших сайтов. Эти запросы поступают на сервер в порядке очереди. Если этих запросов несколько, то сервер их легко обработает, но если их достаточно много — очередь будет расти, а если процессы еще в добавок и тяжелые, то очередь будет продвигаться медленнее.
Сервер ограничен в вычислительных мощностях, поэтому есть ограничения по нагрузке для каждого аккаунта. Если серьезная нагрузка длится слишком долго — может «рухнуть» весь сервер, все аккаунты пользователей и все сайты — вот тут и возникает ошибика 503 (Service Temporarily Unavailable) говорящая о том, что веб-сервер не может обрабатывать больше запросов и необходимо подождать пока очередь уменьшиться и можно будет дальше обрабатывать запросы.
Мы рассмотрели, как устроен хостинг и теперь постараемся описать основные причины, при которых может расти очередь, и, по возможности, пути решений этой проблемы. Иногда это может быть очень сложной задачей и собственных знаний может не хватить, но тем не менее, рассмотрим варианты:

— Зависание скриптов при передаче больших статичных файлов через PHP.

Такие большие файлы лучше всего передавать напрямую, не используя скрипты. Почему? Скрипты работают определенное время, а не постоянно и при окончании времени работы скрипта прерывается передача файла, соответственно файл не будет передан полностью, а запрос оставит процесс веб-сервера работать ещё длительное время. Также, каждая передача файлов через PHP — это отдельный рабочий процесс веб-сервера apache, а для передачи статичных файлов напрямую будет использоваться отдельный многопоточный процесс веб-сервера nginx, который может обрабатывать множество потоков, а значит не будет влияния передачи файла на загрузку.
Хранение и отдачу файлов можно также реализовать через правила mod_rewrite и файл .htaccess, в этом случае можно использовать решение антилич. Антилич — это система, которая не позволит скачать ваш файл по ссылке на странице с другого сайта. Часто, если ваш файл популярен, недобросовестные web-мастера могут поставить у себя прямую ссылку на него, не упоминая о вашем сайте. Естественно, если сайт, на котором подгружается изображение от вашего сайта, посещаемый — это так же может создавать дополнительную нагрузку.

— Удаленное соединение с другим сервером (сайтом и т.д.).

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

Также часто используют вставки отдельных функций, кодов и т.д. (include) и если эти функции располагаются в одном аккаунте — используйте только локальные пути, а не в виде вставки url-адреса (http://site.ru/file.php). Лучше вставить конструкцию, например, такого вида: include 'file.php';. Это не будет делать дополнительный внешний запрос на сервер и тем самым вы снизите нагрузку, уменьшите количество создаваемых процессов.

— Очень тяжелые или испорченные дополнения систем управления сайтами (при использовании CMS и прочих скриптов).

Для нахождения таковых можно отключать дополнения (плагины, хаки, модули и т.д.) по отдельности. Возможно при включении/отключении вы заметите, что сайт станет быстрее/медленнее загружаться. Далее вы сможете найти более легкую замену или исправить поврежденные дополнения. Также в дистрибутив многих CMS включены дополнения, которые лично вам могут быть не нужны, поэтому лучше их удалить.

— Задания выполняющиеся долгое время.

Иногда в самих скриптах пишут задания на выполнение чего-либо по расписанию (например в тех же mambot’ах в joomla). Если их можно перенести в планировщик (cron), то лучше это сделать через cron, так как такие задания в joomla выполняются вместе с запросами пользователей и тем самым замедляют загрузку сайта и увеличивают нагрузку, а в некоторых случаях сайт вовсе перестает загружаться.

— Почтовые рассылки.

Рассылки писем могут влиять на загрузку сайта, тем не менее они часто бывают необходимы и их так же лучше оптимизировать. Скрипт запуска рассылки можно добавить в планировщик (cron), как и в случае с mambot’ами в joomla. Управление планировщиком находится в панели управления хостингом и доступно при соответствующем тарифе. Запускать такие скрипты лучше во время наименьшей нагрузки, например ночное, когда на сайте меньше всего посетителей.

— Медленные или не оптимизированные запросы sql к базе данных.

Пути решения в этом случае – использование кеширования, оптимизация запросов и индексация таблицы базы данных по столбцам (сортировка, упорядочивание). Также, если все это не помогает, стоит подумать о смене скрипта на более оптимизированный.

— Большое количество запросов к серверу.

Старайтесь избегать лишних запросов. Запросы могут исходить не только от посетителей ваших сайтов, но и, например, от индексирующих ботов с поисковиков, sape и т.д, также увеличивается количество запросов при использовании большого количества url на файлы (изображения, js-скрипты, css-стили), которые загружаются через отдельные запросы (при включенном apache вместо nginx). По возможности, объединяйте их в один файл.

Также запросы могут исходить, например, от чата или какого-то участка, блока на сайте, который посылает ajax-запросы на сервер. Многие из нас любят открывать несколько вкладок в браузере — нужно учитывать, что от этого так же может увеличиваться количество запросов и соответственно процессов веб-сервера.

Вставка iframe-кодов на сайте тоже может быть причиной ошибки 503.
Еще один пример увеличения запросов — использование другими сайтами ваших ресурсов (ссылки на файлы, картинки, различные информеры). Используйте антилич системы в борьбе с этим.

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

Если у вас все оптимизировано, используется кеширование, минимум запросов и просто не хватает ресурсов на используемом тарифе, тогда остается задуматься о переходе на другие тарифные планы.

Конечно, все хотят недорогие тарифы, при этом про оптимальное расходование ресурсов многие просто забывают.
На WebHOST1 разработаны оптимальные тарифы и нужно просто подобрать необходимый для вас тариф, что можно осуществить самостоятельно в биллинге.

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

Ошибка 504 — 504 Gateway time-out

Этот код ответа означает, что клиентский запрос nginx передал apache, а apache не смог в установленный лимит времени вернуть HTTP-ответ?, в рузультате сервер разрывает сетевое соединение по таймауту. Причиной может быть долгая работа процесса — сценария, запущенного скриптом веб-сайта.

Можно попробовать увеличить выделенное время для php, прописав в корне сайта в файл .htaccess код:

# время выполнения скрипта - сценария php_value max_execution_time 60 # время загрузки данных  php_value max_input_time 60

Однако это не избавит от таймаута веб-сервера с 504 ошибкой. Таймаут веб-сервера в рамках виртуального хостинга изменить не представляется возможным.

webhost1.ru