Ошибка при создание сайта joomla

Fatal error: Call to a member function merge() on a non-object in /home/…/public_html/
administrator/components/com_menus/models/item.php on line …
Критическая ошибка при создании и/или редактировании пунктов меню.
Решение: проверить целостность файла administrator/components/com_menus/models/item.php, при необходимости перезалить из установочного архива. Для гарантии — перезалить всю папку administrator из установочного архива Joomla!

Delete failed: ‘0a54a1212e802cc1ada1597885f9a59e.php’
Некритическая ошибка при сохранении материалов.

Комментарий: невозможно удалить файл кэша статьи.
Решение: проверить права записи (CHMOD) в папку /tmp (должны стоять 755 или 777). Проверить абсолютный путь к папке /tmp в конфиге сайта (configuration.php)

Database Error: Unable to connect to the database:Could not connect to database
Критическая ошибка соединения с базой данных.
Комментарий: нет подключения к базе данных.

Решение: проверить наличие базы данных сайта (в configuration.php в параметре var $db, имя базы данных должно соответствовать имени базы в phpMyAdmin). Проверить имя пользователя базы данных (var $user) и пароль доступа к базе данных (var $password). Если с этими параметрами все нормально — скорее всего упал MySQL, для устранения ошибки обратится к хостеру.

jtablesession::Store Failed
DB function failed with error number 1146
Table
‘database_name.jos_session’ doesn’t exist SQL=INSERT INTO `jos_session` (
`session_id`,`time`,`username`,`gid`,`guest`,`client_id` ) VALUES (
‘eb894feb5ff2dcc5f12cfc43f071fd8d’,’1270548439′,»,’0′,’1′,’0′ )
Критическая ошибка доступа к таблице сессий базы данных.
Комментарий: отсутствует таблица _session в базе данных.

Решение: проверить наличие таблицы _session в базе данных сайта. Проверить правильность префикса используемой базы данных (параметр var $dbprefix в configuration.php должен совпадать с префиксом таблиц базы данных, причем следует помнить, что таблицы в базе данных могут быть с разными префиксами, по умолчанию Joomla! использует префикс «jos_»).

JAuthentication::__construct: Could not load authentication libraries.
Имя пользователя и пароль не совпадают
Критическая ошибка авторизации в административной части сайта.
Комментарий: причиной ошибки является отключение (снятие с публикации) плагина Authentication — Joomla и/или плагина User — Joomla!
Решение: необходимо в phpMyAdmin включить два плагина (либо через интерфейс phpMyAdmin, либо выполнить два следующих SQL-запроса):

Активирование плагина Authentication — Joomla:
UPDATE `jos_plugins` SET `name` = ‘Authentication — Joomla’, `element` = ‘joomla’, `folder` = 
‘authentication’, `access` = ‘0’, `ordering` = ‘1’, `published` = ‘1’, `iscore` = ‘1’, 
`client_id` = ‘0’, `checked_out` = ‘0’, `checked_out_time` = ‘0000-00-00 00:00:00’, 
`params` = » WHERE `id` = ‘1’;
Активирование плагина User — Joomla:
UPDATE `jos_plugins` SET `name` = », `element` = ‘joomla’, `folder` = ‘user’, `access` = ‘0’, 
`ordering` = ‘0’, `published` = ‘1’, `iscore` = ‘0’, `client_id` = ‘0’, `checked_out` = ‘0’, 
`checked_out_time` = ‘0000-00-00 00:00:00’, `params` = ‘autoregister=1rnrn’ 
WHERE `id` = ‘5’;

JAuthentication::__construct: Невозможно загрузить библиотеки аутентификации.
Имя пользователя и пароль не совпадают или учетная запись отсутствует

Критическая ошибка авторизации в фронтальной части сайта.
Комментарий: причиной ошибки является отключение (снятие с публикации) плагина Authentication — Joomla и/или плагина User — Joomla!
Решение: необходимо в phpMyAdmin включить два плагина (либо через интерфейс phpMyAdmin, либо выполнить два следующих SQL-запроса):
UPDATE `jos_plugins` SET `name` = ‘Authentication — Joomla’, `element` = ‘joomla’, `folder` = 
‘authentication’, `access` = ‘0’, `ordering` = ‘1’, `published` = ‘1’, `iscore` = ‘1’, 
`client_id` = ‘0’, `checked_out` = ‘0’, `checked_out_time` = ‘0000-00-00 00:00:00’, 
`params` = » WHERE `id` = ‘1’;

Активирование плагина User — Joomla!
UPDATE `jos_plugins` SET `name` = », `element` = ‘joomla’, `folder` = ‘user’, `access` = ‘0’, 
`ordering` = ‘0’, `published` = ‘1’, `iscore` = ‘0’, `client_id` = ‘0’, `checked_out` = ‘0’, 
`checked_out_time` = ‘0000-00-00 00:00:00’, `params` = ‘autoregister=1rnrn’ 
WHERE `id` = ‘5’;

Warning: main(/путь/includes/phpInputFilter/class.inputfilter.php):failed to open stream: 
No such file or directory in /путь/includes/joomla.php on line 81 
Fatal error: main(): 
Failed opening required ‘/путь/includes/phpInputFilter/class.inputfilter.php’ 
(include_path=’.:/usr/lib/php:/usr/local/lib/php’) in /путь/includes/joomla.php on line 81
Критическая ошибка во время установки либо после установки Joomla!

Комментарий: папка /includes/phpInputFilter залилась не полностью либо в неправильном регистре.
Решение: проверить и/или заменить папку /includes/phpInputFilter из оригинального дистрибутива и проверить регистр имени папки — при необходимости переименовать (вместо phpinputfilter в phpInputFilter)

cURL extension is not available on your server

Некритическая ошибка появляется при публикации некоторых модулей на форнте сайта (в местах вывода модулей).
Комментарий: отсутствует расширение php_curl на хостинге.
Решение: Необходимо подключить расширение PHP cURL — либо в php.ini добавить extension=php_curl.dll, либо, если нет доступа к php.ini, обратится к хостеру.

Warning: session_start() [function.session-start]: Cannot send session cache limiter — 
headers already sent (output started at /путь/configuration.php:1) in
/путь/libraries/joomla/session/session.php on line 423

Warning: Cannot modify header information — headers already sent by (output started at
/путь/configuration.php:1) in /путь/libraries/joomla/session/session.php on line 426

Критическая ошибка при загрузке сайта.
Решение: проверить кодировку файла конфигурации (configuration.php). Кодировка файла должна быть в utf-8 без BOM. Содержимое файла configuration.php должно начинаться с <?php. Если впереди имеются какие либо другие символы — удалите их.

ERROR LOADING FEED DATA
Ошибка при загрузке канала данных.
Ошибка: запрашиваемая лента не загружена
Некритическая ошибка, появляется в админке и в лицевой части сайта соответственно.

Комментарий: по какой-то причине не возможно загрузить ленту новостей.
Решение: Необходимо снять с публикации административный модуль mod_feed (либо удалить его).

Fatal error: Allowed memory size of XXX bytes exhausted (tried to allocate YYY bytes)…
Критическая ошибка появляется при выполнении определенных операций.
Комментарий: Для выполнения скриптов недостаточно отведенной хостером оперативной памяти.

Решение: Существует несколько способов решить эту ошибку:
1. Пробуем самостоятельно увеличить память для выполнения скрипта
1.1. В файл index.php (в корне сайта) добавляем строку (при необходимости значение 32М можно увеличить, но сильно увеличивать не стоит):

1.2. В файл .htaccess (в корне сайта) добавлем строку:
php_value memory_limit 32M
1.3. В php.ini (если есть к нему доступ) увеличиваем параметр memory_limit:
memory_limit = 32M

1.4. В своем скрипте добавляем:
ini_set(‘memory_limit’, ’32M’)
1.5. Для Joomla! 1.5 существует плагин Memory Limit Plugin, который добавляет память для выполнения скриптов без ручного вмешательства в файлы сайта.
2. Если все вышеперечисленные способы не помогли — обращаемся к хостеру с просьбой об увеличении оперативной памяти для выполнения скриптов.

JFolder::create: Path not in open_basedir paths
Unable to create destination
Критическая ошибка при установке расширений.
Комментарий: ошибка связанная с open_basedir.

Решение: Для начала проверяем правильность пути к папке tmp (в файле сonfiguration.php). Если там все верно, то открываем файл /libraries/joomla/filesystem/folder.php и находим $obd = ini_get(‘open_basedir’) (примерно 194 стр.) и комментируем её, т.е. ставим впереди этой строки //

DB function failed with error number 1030
Критическая ошибка при сохранении и/или редактировании материалов или модулей.
Комментарий: повреждены таблицы базы данных.
Решение: необходимо проверить таблицы базы данных и восстановить их (в phpMyAdmin есть соответствующие функции). Если не помогло — обратится к хостеру с сообщением об ошибке MySQL — 1030 SQLSTATE: HY000 (ER_GET_ERRNO)

Вступление

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

Основные языки программирования, на которых написана CMS Joomla это два сценарных языка PHP и JavaScript. При этом сценарный язык (анг.scripting language) PHP является основным языком Joomla и, как правило, ошибки, возникающие при работе с Joomla это результат его неправильной (некорректной) работы.

В этой статье я сформулирую первые действия, что сделать сначала, чтобы осуществить правильный поиск ошибок и после найти отладку (способ исправления) «неправильного» скрипта вашей Joomla.

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

Видимость ошибок в браузере

Первое место, где вы видите сообщение о возникшей серьезной ошибке, это ваш рабочий браузер. Вы наверняка встречали при открытии сайтов, вместо страниц сайта пустое окно браузера и в нем цифровая (кодовая) ошибка. И речь не идет об ошибках класса 4×× (Ошибки со стороны клиента), например, ошибка 403-Ничего не найдено. Речь о более серьезных ошибок, начинающихся с цифры «5». Это класса ошибок 5×× (Ошибки со стороны сервера).

Ошибка 500

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

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

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

Настройка вывода ошибок зависит от вашего хостинга.

Вывод ошибок на рабочем сервере

На рабочем сервере (коммерческом хостинге) включение вывода ошибок ищите в настройках хостинга. Как правило, вывод ошибок по-умолчанию включен, и вывод ошибок настроен как вывод сообщений в журнал ошибок. Убедитесь, что эта функция сервера включена. Опять-таки, по — умолчанию, не имеет смысла включать на рабочем сервере вывод ошибок на экран. Эти ошибки будут видеть все гости сайта и это лишнее. Однако в критических, аварийных ситуациях, можно воспользоваться временно, выводом ошибок на экран. Об этом чуть ниже.

Вывод ошибок на локальном сервере

На локальном (домашнем) сервере, у вас есть все права на любые настройки сервера и вывод ошибок вы можете настроить сами. Наверное, все готовые платформы локального сервера (OpenServers, Денвер, Xmapp и т.д.) уже настроены на вывод ошибок в журнал и/или на экран. Но в том, то и прелесть локального сервера, вы всегда можете изменить любые его настройки.

Настроить вывод ошибок на локальном сервере нужно в файле php.ini.

Для разрешения вывода ошибок в файле php.ini должна быть строка:

error_reporting(E_ALL ^ E_NOTICE);// Добавлять сообщения обо всех ошибках, кроме ошибок NOTICE 
// Это значение включено по умолчанию в php.ini

Примечание: NOTICE ошибки это возможные, но не явные ошибки. Например, опечатка, предупреждение о плохом стиле, и.т.п.

error_reporting = E_ALL //Вывод всех ошибок//

Для вывода ошибок в журнал, должна быть строка:

log_errors = On

Для вывода ошибок на экран в файле php.ini должна быть строка:

display_errors = On

Вывод ошибок на экран, во время старта PHP

display_startup_errors=On

Понятно, что замена «on» на «off» все это отключит.

Повторюсь, интерпретатор PHP сам выводит сообщения об ошибках, нужно только разрешить и дать ему возможность (настроить) эти сообщения выводить в журнал на сервере, а при необходимости показывать их на экране.

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

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

Вывод ошибок, режим отладка Joomla 2,5

Административная панель сайта ->Меню ->Сайт->Общие настройки->Система

Вывод ошибок, режим отладка Joomla 3,x

Административная панель сайта-> Меню ->Сайт->Общие настройки->Система

В обоих версиях можно настроить, какой режим вывода ошибок во время отладки должен быть.

 

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

Но и из этой ситуации, есть выход. Есть плагин Joomla, который выводит ошибки системы во всплывающем окне и с видимостью только для вас. Это плагин j!Dump.

Плагин j!Dump Joomla

Это плагин для отладки системы Joomla в реальном времени, с выводом ошибок на экран только для вас. Плагин работает на версиях Joomla 2.5 и 3.х. Устанавливается плагин стандартным способом. В настройках понятен и, по отзывам, вполне работоспособен. На сайте extensions.jоomla.com этот плагин есть.

Итоги статьи

• Итак, при работе с Joomla у вас «выскакивают» ошибки на стороне сервера приводящие к некорректной работе системы или ее отключении (Error). Что делать?
• Если вы не программист и не находитесь в процессе разработки и к этому у вас рабочий (не локальный сервер), то прямиком «идете» на сервер и смотрите журнал ошибок (лог ошибок);
• Если журнал ошибок отсутствует, то в настройках сервера ищите и включаете запись ошибок в журнал;
• Если из журнала не удалось понять причину ошибки, включаете режим «Отладка системы» в административной панели сайта;
• Если режим отладки не включается, обращаетесь в support сервера с просьбой такой режим временно включить. Включается он в файле php.ini;
• Если вы работаете на локальном (домашнем) сервере, то самостоятельно проверьте настройки возможности интерпретатора PHP для вывода, показа и записи PHP ошибок, возникающих при работе. Опять таки, файл php.ini.

Это все, что хотелось сказать про Поиск и вывод PHP ошибок Joomla!

©Joomla-abc.ru

Другие статьи 

От автора: приветствую Вас дорогой друг. При посещении Вашего сайта, так или иначе, пользователи будут обращаться к несуществующим страницам. И причины могут быть самыми различными: ошибка в написании адреса, удален материал, который ранее был проиндексирован поисковой системой и т.д. Поэтому в данной статье мы с Вами поговорим о том, что такое ошибка 404 Joomla, так же кратко рассмотрим компонент sh404sef joomla 3 и посмотрим какие инструменты он предоставляет по обработке вышеуказанной ошибки.

Что такое ошибка 404?

Ошибка 404, или 404 Not Found – это стандартный код ответа протокола HTTP, который указывает на то, что запрашиваемый ресурс (страница) не найден. Но Вы должны понимать, что если возникает данная ошибка – доступ к серверу есть, но при этом, не возможно найти данные, соответствующие запросу пользователя. Общаясь с сервером по протоколу HTTP, так или иначе мы получаем различные трехзначные коды состояния запроса, и если ресурс успешно найден, то в качестве ответа, Вы получите, следующий результат — 200 Оk (Ok – пояснение к коду ошибки). Если же ресурс не доступен – то, как мы уже знаем — ошибка 404.

При этом в коде 404, первая цифра 4, указывает ошибку на клиентской стороне, то есть программного обеспечения пользователя (к примеру, в браузере указан не верный адрес страницы). Так же данная цифра, как бы формирует группу ошибок 4х.х. Вторая цифра 0, указывает на общую ошибку синтаксиса для протокола HTTP. И наконец, последняя – 4, конкретно указывает, на то, что ресурс не найден.

Поэтому, мы как разработчики, должны понимать, что данная ошибка может возникнуть, а значит, ее нужно как то обрабатывать. Вы можете спросить, как же обработать данную ошибку, если она возвращается в виде кода статуса запроса? И это действительно так, но если мы работаем с Joomla, мы должны знать, что абсолютно все запросы, на отображение страниц или выполнение каких либо действий, сводятся к единой точке входа в CMS, и это файл index.php. Данная точка входа, практически всегда доступна (сейчас мы не говорим о случаях когда его нет, так как это уже проблемы с целостностью самой CMS), а значит в соответствии с запросом пользователя, именно она решает, какой элемент CMS должен выполнить поставленную задачу. Таким образом, если запрашиваемый ресурс, не может быть найден, CMS самостоятельно формирует, вышеуказанную ошибку, то есть в качестве ответа на поставленный запрос, возвращается специальная страница Joomla, указывающая, что ресурс не найден и в качестве заголовка отправляется код статуса запроса 404 Not Found.

Как сделать 404 страницу Joomla 3

Теперь давайте поговорим о том, как сделать 404 страницу Joomla 3. Как я говорил Выше данная страница формируется непосредственно движком, а значит дизайн и оформление формируется в шаблоне. То есть если мы перейдем в каталог templates исходников Joomla, а затем в папку активного шаблона, в моем случае это beez3, мы увидим файл error.php, который как раз и отвечает за вывод содержимого страницы 404. Кстати по умолчанию, данная страница выглядит следующим образом!

Таким образом, если Вам необходимо изменить дизайн данной страницы, нужно править код файла error.php. При этом текстовое содержимое, которое Вы видите на странице 404, отображается из текущей локализации Joomla, то есть в коде файла Вы можете увидеть языковые константы, к примеру JERROR_LAYOUT_PAGE_NOT_FOUND, значения которых описаны в файлах “словарях” соответствующей локализации. Для шаблона Beez3, значения языковых констант, используемых на странице 404, содержатся в файле en-GB.ini, который располагается по адресу languageen-GB (то есть для английской локализации). Соответственно Вы можете, в файле error.php, изменить структуру HTML разметки, подключить собственные стили, изменить содержимое языковых констант, или вообще их не используя, прописать необходимый текст, страницы 404 – то есть абсолютно все, что Вам нужно.

Так же для создания собственной страницы 404, Вы можете использовать произвольный материал, на который впоследствии в файле error.php, организуете простое перенаправление. Поэтому давайте создадим необходимую статью в менеджере материалов Joomla.

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

Теперь давайте посмотрим, как настроить перенаправление на страницу 404 joomla 3. Для этого в файл error.php добавим следующий код (заменим его код).

Для использования кода, необходимо знать идентификатор и псевдоним созданного материала, а так же идентификатор категории, к которой привязан используемый материал (даные параметры можно узнать в соответствующих менеджерах). Обратите внимание, что метод _(), класса JRoute, формирует человеко-понятную ссылку из обычного URL. Синтаксис используемого URL следующий.

Теперь страница 404 выглядит следующим образом.

Хотел бы отметить, что используя расширение sh404sef joomla 3, Вы можете создать собственную страницу 404, без правок файла error.php, так как данная возможность предусмотрена функционалом. То есть, установив вышеуказанный компонент, необходимо перейти в настройки и включить оптимизацию ссылок.

Затем на вкладке “Страница ошибок”, в разделе интересующей локализации, используя визуальный редактор, Вы можете оформить собственную страницу 404.

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

Более подробно работа с ссылками и механизмом формирования ЧПУ, показана в курсе Joomla-Профессионал: создание расширений для Joomla. Вот и все о чем я хотел рассказать в данной статье. Всего Вам доброго и удачного кодирования!!!

Перевод статьи профессионального PHP-разработчика, руководителя Akeeba Ltd и ведущего разработчика Akeeba Backup для WordPress, Joomla! и standalone Николаса Дионисопулоса.

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

---

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

Вы можете задаться вопросом, сознательно ли разработчики публикуют неработающий код? Отнюдь нет, они это проверили… но они сделали это только в очень узком случае использования, в котором они ожидают, что их плагины будут использоваться. Это называется “тестированием счастливого пути” («happy path testing») и почти так же плохо, как отсутствие тестирования вообще. Проблема заключается в том, что когда плагин используется в любом другом контексте — приложение CLI, вывод не в формате HTML, в случаях, когда формат вывода может быть определен только после завершения выполнения компонента для страницы, — они приведут к непреднамеренным оказиям, т.е. сайт сломается.

Что еще хуже, клиенты начинают обвинять только невиновные стороны — саму Joomla и сторонних разработчиков, чье программное обеспечение написано правильно и работает отлично. Я должен сказать, что мы получаем по крайней мере два тикета каждую неделю в Akeeba Ltd по поводу такого рода проблемных плагинов.

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

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

Симфония ошибок

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

class plgSystemFoobar extends JoomlaCMSPluginCMSPlugin
{
	public function __construct(&$subject, $config)
	{
		parent::__construct($subject, $config);

		if (JoomlaCMSFactory::getApplication()->isClient('administrator')) return;

		$document = JoomlaCMSFactory::getDocument();
		$document->addScript(JoomlaCMSUriUri::root(true) . 'plugins/system/foobar/js/foobar.js');
	}
}

Этот код обманчиво выглядит как простой системный плагин. Он добавляет файл JavaScript к каждой загружаемой странице во внешнем интерфейсе. Верно?

Что ж, это то, что он хочет делать, но не то, что он делает на самом деле. Он также нарушает CLI и API-приложения Joomla 4, ломает страницы с выводом, отличным от HTML, запрещает компонентам использовать вывод, отличный от HTML, и пытается загрузить файл JavaScript из неправильного места. Четыре ошибки в пяти строках кода.

Не выполняйте логику в конструкторе класса плагина

Давайте подумаем о цикле Joomla. В общих чертах, запрос в конечном итоге обрабатывается в Joomla файлом index.php. Он заводит Joomla! приложение, например JoomlaCMSApplicationSiteApplication для фронтенда. Основной точкой входа для объекта приложения является метод doExecute. Этот метод выполняет большую часть инициализации перед маршрутизацией и диспетчеризацией приложения, что означает, что эта инициализация выполняется до того, как Joomla проанализирует SEF URL-адреса или создаст объект документа. Фактически, Joomla загрузит все включенные системные плагины до того, как выяснит что либо о самой себе.

Разработчик этого плагина поместил свою бизнес-логику в конструктор плагина, который выполняется на этой ранней стадии инициализации приложения Joomla. В то время как isClient() будет работать, остальная часть кода, которая пытается получить объект документа, является неправильным кодом, который нарушает работу сайта.

Плагин ошибочно использует метод JoomlaCMSFactory::getDocument(), чтобы получить документ. Это устарело в Joomla 4 и будет удалено в Joomla 5 (В статье на Хабре «Опубликован скорректированный план выпуска релизов Joomla 4 и Joomla 5» уточнаяется принятая на момент сентябрь 2022 года система удаления устаревшего кода в Joomla. В Joomla 5 метод Factory не будет удалён. — прим. переводчика). Предполагается, что вы будете использовать метод getDocument() объекта приложения. Если бы разработчик сделал это, он бы получил значение null, потому что документ еще не создан.

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

Не используйте JoomlaCMSFactory

Вторая проблема этого плагина — ещё одна веская причина, по которой метод Factory::getDocument() устарел.

Вызов Factory::getDocument() принудительно создаст объект документа, который затем будет использоваться объектом приложения. Объект документа создается на основе информации, содержащейся в запросе. Однако, как вы, возможно, помните, в этот момент выполнения приложения Joomla еще не проанализировала SEF url! Тот же эффект был бы достигнут, если бы этот код был вызывался при событии onAfterInitialise — самом раннем событии для системных плагинов, инициируемом Joomla.

Поскольку SEF URL-адрес не был проанализирован, Joomla не может достоверно знать тип используемого документа. Подумайте, например, о таком URL-адресе, как https://www.example.com/foobar.json который при прохождении через маршрутизатор URL-адреса SEF, помимо прочего, установит format=json в запросе. Это означает, что этот запрос ожидает, что Joomla создаст объект документа JoomlaCMSDocumentJsonDocument.

Однако, поскольку format=json еще не задан, Joomla примет format=html при вызове getDocument(), поэтому будет создан объект документа JoomlaCMSDocumentHTMLDocument, который также будет использоваться приложением. Это, конечно, приведет к поломке компонента, который обрабатывает запрос, причем вина лежит исключительно на авторе косячного плагина.

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

Вы должны использовать ТОЛЬКО ДВА метода JoomlaCMSFactory в Joomla 4:

• getContainer() — возвращает контейнер внедрения зависимостей Joomla (DI Container, иногда сокращенно DIC).

• getApplication() — возвращает текущий объект приложения Joomla, обрабатывающий запрос.

Всё. Больше ничего другого использовать не нужно! Всё остальное предоставляется либо через DI-контейнер, либо через сам объект приложения.

Чтобы получить документ приложения используйте JoomlaCMSFactory::getApplication()->getDocument().

В Joomla есть вывод не только HTML

Это до неприличия распространённая ошибка. Разработчики, похоже, предполагают, что Joomla всегда будет генерировать только HTML-вывод. ТАКОГО НЕ БЫЛО С ТЕХ ПОР, КАК JOOMLA 1.0 БЫЛА ВЫПУЩЕНА В 2005 ГОДУ, ЗАПОМНИТЕ ЭТО, ХРИСТА РАДИ! Серьезно, люди! Это касалось даже Mambo, предшественницы Joomla. Joomla — это не WordPress, она вполне способна генерировать выходные данные, отличные от HTML, такие как XML, JSON, RSS-каналы, Atom-каналы, необработанные raw binary (например, изображения) и так далее.

Разработчик этого плагина сделал необоснованное предположение, что этот $document всегда будет содержать HTMLDocument.

URL-адрес, подобный https://www.example.com/index.php?option=com_whatever&format=json — несмотря на две упомянутые выше проблемы — все равно будет заполнять $document объектом JSONDocument. Однако в JSONDocument нет метода addScript. Поэтому этот плагин сразу же вызывает фатальную ошибку PHP.

Правильным подходом будет сделать “feature detection”:

$document = JoomlaCMSFactory::getApplication()->getDocument();

if (!($document instanceof JoomlaCMSDocumentHtmlDocument))
{
	return;
}

Если документ, который возвращает наше приложение, не является HTMLDocument — валим отсюда. Просто, не правда ли?

В Joomla есть не только frontend и backend

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

Эта строка неверна:

if (JoomlaCMSFactory::getApplication()->isClient('administrator')) return;

Очевидно, разработчик хотел сказать: “Если это не фронт сайта, ничего не делаем”. Вместо этого они на самом деле сказал: “Если это админка сайта — следовательно, это фронт сайта или API-приложения, или CLI-приложения, или любого пользовательского приложения, расширяющего класс WebApplication Joomla — ничего не делайте”. Упс…

Видите ли, Joomla 4 имеет несколько типов приложения из коробки:

• installation — это веб-установщик при создании нового сайта. Сторонний код, такой как наш системный плагин symphony-of-mistakes, в нем не загружается и не касается сторонних разработчиков. Он существует со времен Joomla 1.0.

• site — фронтенд сайта. Существует со времен Joomla 1.0

• administrator — бэкенд сайта. Существует со времен Joomla 1.0

• api — директория /api в корне сайта на Joomla 4. Появилось в Joomla 4.

• cli —  cli/joomla.php CLI-приложение. Появилось в Joomla 4.

Кроме того, начиная с Joomla 1.5, существуют приложения, отличные от site и administrator.

Начиная с версии Joomla 1.5, появилась возможность создавать собственное пользовательское приложение, расширив JApplicationWeb. Эти пользовательские приложения загружают системные плагины по умолчанию. Они использовались для создания пользовательских точек входа для обратных вызовов, например, в платежных плагинах для компонентов электронной коммерции. Сейчас их использование не имеет смысла, с момента появления com_ajax в Joomla 2.5.

Начиная с Joomla 1.6 и вплоть до выхода Joomla 5.0 разработчик может создавать собственные приложения CLI, расширяя JApplicationCli. Эти приложения не загружают системные плагины по умолчанию, поэтому они вряд ли сломались.

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

Правильный способ сделать это — это, конечно, явно проверить тип приложения, с которым вы работаете:

if (!JoomlaCMSFactory::getApplication()->isClient('site')) return;

Не загружайте статические ресурсы напрямую и/или из папки вашего плагина

Это не ошибка, которая приведёт к поломке сайтов сегодня. Но она приведет к поломке сайтов с Joomla 5.0 и небольшой проблеме безопасности 😀

Разработчик расширения решил загрузить свой статический файл JavaScript, используя устаревший метод addScript() документа, и разместил файл в файловой структуре плагина. Это проблема «два в одном».

Прежде всего нужно помнить, что с тех пор, как Joomla 1.5 (выпущена в 2007 году — 15 лет назад на момент написания этой статьи), в Joomla появилась папка media, в которой расширения должны размещать все общедоступные статические файлы, будь то статические файлы или пользовательский контент, управляемый вне медиа-менеджера Joomla.

Разработчик расширения должен был поместить свой файл JavaScript в папку media/plg_system_foobar/js, используя следующий раздел в XML-манифесте своего плагина:

<media folder="media" destination="plg_system_foobar">
    <folder>js</folder>
    <file>joomla.asset.json</file>
</media>

(Мы сейчас увидим, что представляет собой файл joomla.asset.json).

Это плохая практика с точки зрения безопасности сайта, когда смешивается исполняемый серверный код (файлы .php) с исполняемым кодом интерфейса (файлы .js, .es6 и т.д.) и статическими медиафайлами (CSS, изображения, видео и т.д.). Joomla движется к размещению всего доступного для фронтенда материала в папке media — даже для шаблонов, начиная с версии Joomla 4.1 — и, скорее всего, начнет применять средства контроля безопасности для предотвращения веб-доступа к папкам плагинов, компонентов, модулей и т.д.

Будем считать, что теперь Вы предупреждены.

Следующая проблема заключается в том, что метод addScript() в HTMLDocument устарел и отмечен как deprecated. Joomla 4 перешла на использование зависимостей веб-ассетов и Web Asset Manager для управления зависимостями ассетов!

От переводчика: в предыдущих статьях упоминал замечательную статью Как правильно подключать JavaScript и CSS в Joomla 4, а также дополнение к ней — статья на хабре Использование WebAssetsManager Joomla 4 и добавление собственных пресетов с помощью плагина — Т.С.

Веб-ассеты и их зависимости объявлены в файле joomla.asset.json, расположенном в подпапке расширения в каталоге media. Итак, разработчик должен был создать файл media/plg_system_foobar/joomla.asset.json со следующим содержимым:

{
	"$schema": "https://developer.joomla.org/schemas/json-schema/web_assets.json",
	"name": "plg_system_foobar",
	"version": "1.0.0",
	"description": "Foobar plugin",
	"license": "GPL-3.0-or-later",
	"assets": [
		{
			"name": "plg_system_foobar.foobar",
			"description": "Foobar JavaScript",
			"type": "script",
			"uri": "plg_system_foobar/foobar.js",
			"dependencies": [
				"core"
			],
			"attributes": {
				"defer": true
			}
		}
	]
} 

Это позволяет разработчику указать Joomla использовать свой скрипт с помощью простой строчки кода:

$document->getWebAssetManager()->useScript('plg_system_foobar.foobar');

В чем загвоздка. Это безопасно, даже если вы не проверяете тип объекта документа. Да, если $document — это JSONDocument, в котором нет понятия веб-ресурсов, этот код все равно будет работать. Но, по-прежнему рекомендуется проверять тип документа так, как я вам сказал, чтобы избежать бессмысленной работы или появления ошибок в будущем.

Собираем всё воедино

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

<?php
class plgSystemFoobar extends JoomlaCMSPluginCMSPlugin
{
  // 1-е изменение - onAfterDispatch
   public function onAfterDispatch()
   {
     // 2-е изменение - изменение условия на правильное
      if (!JoomlaCMSFactory::getApplication()->isClient('site')) return;
     // 3-е изменение - получаем Document из приложения
      $document = JoomlaCMSFactory::getApplication()->getDocument();
     // 4-е изменение - проверяем тип документа
      if (!($document instanceof JoomlaCMSDocumentHtmlDocument))
      {
         return;
      }
     // Добавляем js-скрипт с помощью Web Assets Manager
      $document->getWebAssetManager()->useScript('plg_system_foobar.foobar');
   }
}

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

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

Вступление

Вы создаёте сайт Joomla ради развлечения? Наверное нет. Несмотря на локальные задачи, стоящие перед вами (продажа товаров, раскрутка бренда, распространение информации и т.д.) перед вами должны стоять глобальные задачи продвижения и раскрутка сайтов в поисковой выдачи Яндекс и/или Google. Удачному продвижения сайта мешают ошибки продвижения, о которых поговорим в этой статье.

Почему Яндекс?

Сконцентрируемся на Яндекс продвижении и на ляпах, которые Яндекс считает ошибками. Почему? Всё просто. Яндекс даёт ответы на вопросы, которые, априори задаёт ваша аудитория. Значит продвижение сайта в Яндекс для вас важнее. Если ваш клиент «сидит» в Google, значит двигаете сайт в Google.    

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

Базовые ошибки Яндекс продвижения

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

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

Итак, переходим к базовым ошибкам оптимизации создания сайтов, которые Яндекс считает распространёнными.

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

Ошибка №1

Основной поисковой робот Яндекс обходит сайт по ссылкам. Он отлично читает классические ссылки в теге <a href…>, но категорически не видит ссылки:

• JavaScript;
• Flash;
• Документы iframe.

Ошибка №2

Повторюсь, Яндекс не любит когда ему мешают, в данном случае усложняют обход вашего сайта. Поэтому он категорически не любит перенаправления (redirect).

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

На Joomla, для этих целей есть системный компонент «Перенаправление». Разберитесь в его работе.

Ошибка №3

Яндекс считает ошибкой, если одна и та же информация доступна по разным адресам сайта. В рекомендациях он пишет:

Каждая страница должна быть доступна по единственному и постоянному адресу.

Это особенно актуально для сайтов Joomla. Joomla «любитель» делать дубли страниц, и с дублями на сайте Joomla нужно постоянно бороться.

Ошибка №4

Ошибка «грязных» URL. Актуальна для Joomla, если вы сидите на старых версиях и не убрали из URL идентификаторы сессий и другие параметры, делающие URL не ЧПУ.

На практике, такой URL http: //joomla.ru/index.php?option=com_content&view=article&id=266, гораздо хуже воспринимается Яндекс, чем такой http ://joomla-site.ru/category/article.

Как настроить ЧПУ ссылок на Joomla читать в статье Как оптимизировать Joomla 3 без дополнительных расширений.

Ошибка №5

Есть в SEO такое понятие, как «клоакинг». Яндекс санкционно не любит когда он индексирует одну страницу, а по этому адресу пользователю показывают другое содержание. Однако к белому клоакингу, когда вы правильно используете геотаргетинг для региональной индексации, Яндекс лоялен.

Ошибка №6

Яндекс не умеет читать текст на картинках и страницу, на которой есть только картинки, даже инфографика, он чаще не индексирует. Картинки должны дополнять текст, а не заменять его. В картинки вставляйте тег alt.

Ошибка №7

Боты Яндекс любят правильно оформленную страницу ошибок 404. По мнению Яндекс правильно оформленная страница ошибок 404, должна давать ответ с кодом 200 (ОК).

У Joomla есть своя системная страница ошибок. У большинства шаблонов Joomla оформлены свои страницы ошибок. Их нужно включить в настройках шаблона. Как создать свою страницу ошибок читать в статье 4 шага создания страницы 404 Not found на Joomla.

Ошибка №8

Следите за корректной работой CMS. Обновляете её вовремя и не допускайте размещения вредоносных кодов злоумышленниками. О шагах безопасности сайта читать в статье Безопасность Joomla сайта и почему она важна.

Пользовательские ошибки

Кроме распространённых ошибок, есть более банальные пользовательские ошибки, которые будут ошибками продвижения в Яндекс Joomla сайта.

Не игнорируйте работу с инструментом вебмастеров «Яндекс Вебмастер». Зарегистрируйте сайт системе и работайте с ней. Там есть вся необходимая информация и инструменты для удачного Яндекс продвижения.

Системные ошибки

К системным отнесём ошибки характерные для Joomla, как специфической СMS.

Грязный URL

В первичный настройках сайта включите функционал ЧПУ на странице общих настроек и современную маршрутизацию на вкладке «Настройки менеджера материалов»>>>Интеграция. Это уберёт из URL indeх.php и идентификаторы сессий, то есть сделать URL сайта человеку понятными ЧПУ (SEF). 

Дубли страниц

Отчасти проблему дублей страниц на сайте Joomla решит включение ЧПУ, включение перенаправления и включение современной маршрутизации. Для более серьёзного избавления от дублей страниц придётся работать со сторонними SEO расширениями «ArtioJomSEF» или «SH404».    

Навигация

Joomla даёт вам в руки все возможности, чтобы навигацию по сайту сделать удобной и полезной для пользователя. Не игнорируйте эту возможность. Читать статью: Меню Joomla 3.

Фавикон

По всем официальным публикациям Яндекс обращает внимание на наличие Иконки сайта (фавикона). Он должен быть виден в любом браузере Интернет, а главное виден в выдаче Яндекс.

Технические страницы

Повторюсь, Яндекс не любит, когда его робота заставляют обходит не значимые и технические страницы. Поэтому активно используете запрещающие директивы в файле robots и теги noindex, чтобы закрыть не значимые страницы сайта от обхода.

Кроме файла robots, на Joomla есть инструмент добавления мета тегов noindex и nofollow в материалы сайта. Используйте его.

Отсутствие robots и sitemap

Яндекс рекомендует использование файлов robots.txt и sitemap.xml для управления и ускорения индексацией сайта соответственно. Файл robots.txt создаётся вами самостоятельно или с помощью онлайн генератора (читать статью Как использовать файл robots.txt на Joomla 3). Для создания файла sitemap.xml (карты сайта для поисковиков) придётся установить сторонний компонент. Рекомендую Компонент OSMap,  о нём читать Компонент OSMap – .

Навязчивая реклама

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

Отсутствие страницы контактов с адресом сайта

Страница контактов на сайте не является безусловно необходимой. Однако именно в ней Яндекс будет искать региональную привязанность сайта, а это он любит. 

Заключение

Ошибки Яндекс продвижения Joomla сайта не являются санкционными и за них сайт вряд ли попадёт под санкции (кроме чёрного клоакинга). Данные ошибки затруднять продвижение сайта, хотя их отсутствие быстрого продвижения гарантировать не будет.

©joomla3-x.ru

Еще статьи