Извините, возникла проблема, которую мы не смогли устранить.

Сервер вернул ответ «500 — Упс, похоже, что-то пошло не так».

Это перевод с английского с https://magazine.joomla.org/.

Ого, спасибо, Joomla! Я это вижу. Мой сайт не работает. Хотите дать мне дополнительную информацию, чтобы я мог исправить эту чёртову штуку?

Всё это просто ужасно бесполезно. Мало того, ещё и этот большой уродливый красный экран. Он даже не оформлен в стиле моего сайта. Что я сделал? Я все потерял? Вся моя работа пропала? Меня взломали? Возможно, я не должен был нажимать ту кнопку?

И у меня даже нет зацепки, как это исправить или что не так.

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

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

Возможно, вы могли бы попробовать всё, что только сможете придумать. Очистку кэша. Перезагрузку компьютера. Обычные вещи, которые помогают. Всё ещё не работает, верно?

Потому что это проблема сервера. Раздражающая проблема сервера.

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

И возможно, они проверят журнал ошибок. «Извините, логи не показывают каких‑либо ошибок, это, должно быть, проблема конфигурации вашей CMS». Ну... возможно, они будут правы. Возможно, это не ошибка PHP. Возможно, им нужно поискать что-нибудь другое. Или вам следует поискать.

Автор оригинальной статьи записал видео, которое проведёт вас по этим шагам, это может прояснить ситуацию.

Эта статья по устранению ошибок изначально была создана на сайте Square Balloon, экспертами по Joomla с уже более чем 16-летним опытом.

Итак, как это исправить?

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

Шаг 1. Включите отладку Joomla.

Позвольте мне внести ясность. Это решит вашу проблему в 99% случаев. Или даст вам больше понимания. Это всегда первый шаг, и так будет всегда.

Но как я могу сделать это? Я слышу, как вы раздражённо кричите в экран.

Итак. вы правы. Вы не можете войти в систему. Администратор тоже видит экран ошибки 500!

Нет проблем. Эта настройка устанавливается с помощью конфигурационного файла. Вы можете войти с помощью ФТП-клиента или с помощью своего хостинга, на котором есть файловый менеджер.

Выберите способ и перейдите на свой сайт Joomla. У меня он обычно находится в папке public_html. Но это будет зависеть от вашего сервера.

Найдите и откройте файл configuration.php и проскрольте, пока не найдёте строку:

public $debug = false;

Вы должны будете изменить это значение на true:

public $debug = true;

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

Теперь откройте ещё раз файл configuration.php и убедитесь, что ваши изменения применились. Я сталкивался со случаями, когда изменения не сохранялись. А на некоторых серверах создаётся впечатление, что это защищённый файл. Вероятно, дело в разрешениях файла, в которых следует включить права на запись.

К вашему сведению, Joomla.org рекомендует установить разрешения 755 для каталогов и 644 для файлов.

После завершения настройки файл configuration.php должен иметь права 444.

Если ФТП не работает, вам следует воспользоваться файловым менеджером на вашем хостинге, например, в cPanel есть такой. Там вам следует отредактировать файл configuration.php. Установите параметр отладки Joomla на true, следуя инструкциям выше, и нажмите «Сохранить».

Обновите страницу.

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

Первое, что нужно сделать, — просмотреть всю страницу на предмет сообщения об ошибке.

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

Некоторые распространённые ошибки:

Невозможно создать экземпляр MySQL

Если вы посмотрите на нижнюю часть экрана, там будет написано что-то вроде «невозможно получить доступ к базе данных MySQL». Это явный признак того, что один или все параметры подключения неверны.

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

Вот три параметра, которые вам нужны:

База данных:

public $db = 'yourdatabase_name;

Пользователь базы данных:

public $user = yourdatabaseuser_name';

Пароль к базе данных:

public $password = 'YOURPASSWORD;

Если в сообщении об ошибке упоминается имя файла

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

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

Так как же решить эту проблему, если вы не знаете PHP? Ну, вы это не сделаете. Вы просто отключаете этот плагин. Зачем? Я слышу, вы восклицаете: «Мне нужен этот плагин!»

Ну, конечно! Но то, что мы делаем здесь, — это убеждаемся, что проблема именно в данном плагине, а не в чём-то другом. Давайте отключим его (или включим), и таким образом выясним, является ли он проблемой.

Есть два способа это проверить.

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

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

Компоненты, как и следовало ожидать, находятся в папке «components».

Название каждого начинается с com_. Таким образом, все статьи Joomla находятся в компоненте com_content. Маловероятно, что проблема в этом компоненте. Существуют тысячи установленных Joomla по всему миру. Можно предположить, что любая проблема, связанная с Joomla, будет быстро устранена, если она достаточно серьёзна и может вызвать ошибку 500.

Это говорит о том, что, если вы найдёте проблему, которая является подлинным багом, вы можете сообщить о ней на Joomla GitHub или на Joomla Issues Tracker. Эти сервисы взаимосвязаны, поэтому не имеет значения, на какой из них вы сообщите.

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

Предположим, вы что-то установили или изменили. Вы только что установили какой-либо компонент? Возможно, он не совместим с вашей версией PHP? Вы можете спросить разработчика о минимальных требованиях PHP. Возможно, он не совместим с вашей версией Joomla, но как-то установился.

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

Найдите компонент и переименуйте папку. Я обычно добавляю два дефиса в начале.

Так, например, если вы видите сообщение об ошибке и оно выглядит так, как будто относится к com_akeebabackup, я бы переименовал папку компонента в--com_akeebabackup. Таким образом, папка больше не будет доступна коду, поскольку он будет искать её в неправильном месте.

После этого обновите страницу.

Если это сработает, значит, с компонентом происходит что-то странное.

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

Одним из ключевых моментов при выполнении этих проверок является то, что мы проверяем только одно расширение за раз.

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

Папки модулей находятся в папке modules, их имена начинаются с mod_. Правила в любом случае остаются теми же.

Последнее место, где вы можете увидеть ошибку, — это переопределения. Они находятся в templates/YourTemplateName/html/ и затем в подпапке.

Вы должны, по крайней мере, найти достаточно информации, чтобы определить ошибку, а затем либо исправить её, либо грамотно сформулировать вопрос, когда просите других о помощи. Я перечислю все места, где вы можете найти помощь, в конце этой статьи.

Шаг 2: Проблема с .htaccess?

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

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

В cPanel моего хостинга справа вверху есть кнопка «настройки», в них есть опция «показать скрытые файлы».

Как только вы увидите файл .htaccess, переименуйте его (не удаляйте). Я обычно называю свой --.htaccess

После переименования обновите страницу.

Если страница откроется, значит причина ошибки в .htaccess, если нет, — то в чём-то другом. Измените имя файла обратно на .htaccess и переходите к следующему шагу.

Если проблема в этом, то проблема в файле .htaccess.

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

В корневой папке Joomla с помощью FTP-клиента или файлового менеджера вашего хостинга вы найдете файл с именем htaccess.txt.

Это копия оригинального файла Joomla .htaccess. Она ДЕЙСТВИТЕЛЬНО полезна, потому что оригинальный файл обычно рабочий.

Переименуйте его в .htaccess. Не забудьте удалить .txt в конце.

Обновите страницу. Сайт загружается? Обязательно проверьте внутренние страницы, а не только главную.

Если сайт заработал, то очевидно, что ошибку вызвало что-то, что вы изменили в файле .htaccess.

Шаг 3: Задайте вопрос техподдержке своего хостинга

Почему бы и нет? Они администрируют сервер; возможно, они изменили настройки или какой-то параметр конфигурации, к которому у вас нет доступа. Стоит спросить их. Некоторые из них не являются экспертами Joomla, поэтому вы можете обнаружить, что они не так уж полезны, но встречаются и те, кто быстро решает проблему.

Шаг 4: Отчет об ошибках PHP

Часто ошибка 500 не отображается в отчётах об ошибках PHP. Ошибка может произойти до возникновения ошибок PHP.

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

Ищите параметр:

public $error_reporting = 'none';

Измените его на:

public $error_reporting = maximum';

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

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

Шаг 5: Проверьте журналы ошибок PHP

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

Техподдержка хостинга расскажет вам, как получить доступ к журналам ошибок PHP. Вам стоит знать их расположение, чтобы иметь возможность устранять неполадки самостоятельно, поскольку это часто быстрее, чем создавать тикет. Они могут быть доступны с помощью панели вашего хостинга или ФТП-клиента.

Главный совет:

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

Шаг 6: Переименуйте error.php вашего шаблона

Я сталкивался с ситуациями, когда страница error.php вызывала ошибку. Иронично.

Не забудьте также проверить error.php вашего дочернего шаблона.

Переименуйте их, например, –error.php, и ваша страница ошибок по умолчанию будет страницей ошибок Joomla.

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

Шаг 7: Проблемы с Gzip?

Иногда Gzip вызывает проблемы на определённых серверах. Я бы предположил, что это может быть из-за двойного gzip-сжатия или из-за того, что модуль PHP gzip не включен (или модуль Apache, как угодно, это проблема gzip).

Войдите в систему через FTP или через файловый менеджер на вашем хостинге и откройте configuration.php.

Найдите строку:

public $gzip = true;

измените на

public $gzip = false;

Не забывайте о других расширениях, таких как Admin Tools от Akeeba, которые также могут сжимать файлы с помощью Gzip в их настройках .htaccess. Если вы следуете этому руководству, то уже проверили .htaccess ранее, так что это не будет проблемой. Но если вы не следуете по порядку, это всё равно может быть проблемой, так что об стоит помнить. Также стоит знать, используете ли вы конструктор .htaccess в инструментах администрирования (или другой компонент), и не мешает ли это работе сайта. Один из параметров конфигурации несовместим с вашим сервером. Только методом проб и ошибок можно выяснить, какой именно. Отключайте их по одному, а затем так же поочерёдно включайте снова. Или, в качестве альтернативы, вы можете отключить половину и перезагрузить страницу. Если это сработает, вы поймете, что проблема в одном из отключённых расширений. Теперь включите половину из них. Делая это таким образом и уменьшая вдвое каждый раз, вы можете быстрее устранить неполадки.

Шаг 8: Отсутствующие модули PHP

Joomla имеет несколько основных PHP-модулей и несколько дополнительных технических требований.

Вот ссылка на них: https://docs.joomla.org/J4.x:Optional_Technical_Requirements

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

Если вы только что сменили версию PHP, возможно, вы не включили один из этих модулей, но в предыдущей версии PHP он был включен.

Я могу изменить эти модули в cPanel хостинга. Однако некоторые хостеры требуют, чтобы вы использовали php.ini для обновления этих настроек. Php.ini — это файл конфигурации для PHP. Он довольно прост, но выглядит как жаргон, если вы к нему не привыкли.

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

Вот пример строки, закомментированной с помощью точки с запятой ;

; How many GET/POST/COOKIE input variables may be accepted

;max_input_vars = 1000

Если я захочу, чтобы max_input_vars имел значение, я удалю точку с запятой в начале строки.

; How many GET/POST/COOKIE input variables may be accepted

max_input_vars = 1000

Первая строка — это просто комментарий/инструкция, поэтому вы должны оставить её закомментированной, т. е. оставить точку с запятой на месте.

Затем вы можете изменить значение 1000 на любое другое число (обычно в большую сторону), чтобы посмотреть, сработает ли это.

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

Шаг 9: Проблемы с кэшированием?

Чтобы было ясно, это почти наверняка НЕ проблема кэша браузера. Ошибка 500 — это проблема сервера. Однако в некоторых случаях я видел, как она кэшировалась в определённых компонентах. Так что вы можете очистить кэш браузера для проверки работоспособности.

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

Я, например, иногда использую Redis.

Просматривайте файлы с помощью FTP-клиента или файлового менеджера вашего хоста и ищите обработчик сессий. Вот как выглядит мой:

public $session_handler = 'redis';

Конкретно в моём случае ошибка заключалась в том, что изменилось расположение redis.sock.

public $session_redis_server_host = '/home/tpwcsquareballoo/redis.sock';

Убедитесь, что это точно. Возможно, вам придётся попросить вашего хостера предоставить вам эту информацию.

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

Измените строку следующим образом:

public $session_handler = ‘file’;

Обновите страницу.

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

Если это не сработает, возможно, стоит пока оставить кэш отключённым, пока вы не решите проблему.

Но не забудьте включить его снова в будущем, когда сайт заработает. Вы можете сделать это в админке Joomla:

System > Global Configuration > System > Session Handler (dropdown).

Шаг 10: Обработчик кэша?

Откройте файл configuration.php (используя FTP или файловый менеджер вашего хостинга).

Найдите эту строку:

public $cache_handler = 'file';

Если значение переменной не ‘file', то замените его на ‘file'.

Обновите страницу.

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

Шаг 11: Что изменилось?

Это довольно полное руководство, и если ничего не помогло, стоит спросить, что вы делали перед появлением ошибки. Вы что-то устанавливали на свой сервер? Вы делали что-то ещё?

Шаг 12: Попросите о помощи у сообщества!

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

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

Комментарии (8)


  1. FanatPHP
    06.08.2024 16:50
    +7

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

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

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


    1. VitaliyNekrasov Автор
      06.08.2024 16:50
      +1

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


      1. FanatPHP
        06.08.2024 16:50
        +1

        С процессом всё ещё хуже. Если вы хотите заниматься переводами, то надо обязательно учить русский язык. Осваивать устойчивые обороты, развивать чувство стиля. Для этого надо много читать. Причем не мусора, а нормальных текстов. Чтобы набор слов, который вы выдаёте за перевод, у вас же самого вызывал оскомину. А предложения вида "прежде чем пытаться сделать что-либо из этого, вы можете легко проверить, проблема в этом или нет" - рвотные позывы.

        Вам нужно читать логичные тексты. Чтобы нелогичные места в переводе вас раздражали. Я понимаю, что автор статьи умышленно изображает идиота. Но стегать ремнем компьютер - это немного чересчур даже для него. У вас должно возникнуть подозрение - что-то здесь не так. Возможно, надо вбить в переводчик не одно слово strop, а целиком словосочетание, в котором оно используется. Там тоже будет тупая клоунада, но хотя бы градусом поменьше.

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


        1. ArtPlotnikov
          06.08.2024 16:50

          "можно, пожалуйста"


    1. sergeytolkachyov
      06.08.2024 16:50
      +1

      При работе Joomla проверка логов сервера точно так же, как и во всём мире является чаще всего первым шагом. Также в ней есть свой PSR3 логгер, но он уже настраивается из админки и кто-то может по неопытности его или отключить или сделать так, чтоб он ничего не показывал.

      Вообще здесь для перевода выбрана совершенно идиотская статья, предназначенная явно для тех, кто 20 минут назад узнал слово "Joomla". И сокрушаться больше нужно не о качестве перевода, но о том, что подобные статьи просачиваются на страницы официального журнала Joomla сообщества, международный уровень все-таки... Делать хороший качественный контент - это долго, дорого, и отнимает много сил. Пишешь ли ты о чем-либо впервые или уже есть источники - не так важно. В некоторых случаях статья - как диплом написать - рождается несколько месяцев, сначала в голове, а потом в тексте. А потом ещё защитить этот "диплом" в комментариях))

      Сейчас же времени, сил, желания концентрироваться на одной статье в целом у авторов как минимум мало. Им хочется быстрой мотивации, быстрого результата, видимых признаков одобрения. С другой стороны разговор с профессионалами постепенно заменяется на контент-маркетинг, где качество текста регулируется уже ценами на его создание, да и цели написания статей уже другие. Такие первопричины влияют на уровень текстов. Сколько публикаций было на тему "Хабр уже не торт"? Много. И появляются они регулярно.

      В защиту Виталия (автора перевода) хочу сказать, что он на самом деле большой молодец. Он собирался с духом сделать первую публикацию на Хабре года полтора, кабы не больше и решил для начала попробовать себя в переводах, а потом уже переходить на авторские статьи. Несколько раз за это время в Joomla-чатах он спрашивал совета у сообщества что взять на перевод, о чем написать. Поскольку статей о Joomla на русском мало, англоязычные неплохие статьи и книги существуют - в сообществе Joomla всегда с одобрением отзывались о подобных намерениях. За статьи и переводы никто не платит, это только добрая воля автора, его затраченные усилия.

      К сожалению, Виталий усомнился (на мой взгляд слишком) в своих силах и взял для работы текст "попроще", который действительно не несёт в себе новой информации. И оказывается может бросить тень на саму Joomla. О возможной негативной реакции на Хабре его предупреждали. Но свой собственный опыт - это только свои собственные ошибки))

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

      Ну и сама Joomla не плохая, как может показаться после прочтения этой статьи)))


  1. ArtPlotnikov
    06.08.2024 16:50

    "Как исправить ошибку 500 в Joomla":

    1. Снести Joomla

    2. Проверить логи

    3. ???????

    4. PROFIT


  1. xSVPx
    06.08.2024 16:50
    +1

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

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

    Результаты действий людей, которые решили "быстренько не парясь всё поправить" я иногда вижу. Обычно они успевают изгадить всё что можно, не делают никаких резервных копий и только после того как ничего не помогает приходят по сарафанке и оказывается что они просто забыли оплатить хостинг или что-либо подобное. А после оплаты ничего не работает т.к. они совершенно всё разворотили. И не всем удается помочь...


    1. FanatPHP
      06.08.2024 16:50

      Ну, в данном случае всё проще. Автор статьи хочет напугать потенциального клиента, чтобы тот не рыпался, а "сразу часы снимал", как в том одесском анекдоте.