Если что-то пошло не так. Полезные советы

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

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

Поскольку статья в основном ориентирована для новичков, сначала вкратце, что есть что.

Версии Evolution и в чем их принципиальное отличие друг от друга.

Версия 1.4.x — это классическая версия, прямой потомок MODx Evolution. Дополнительно есть возможность установки шаблонизатора Twig (плагин EvoTwig2) и использовать контроллеры.
Вeрсия 2.х — с интеграцией Laravel v.6 с шаблонизатором Blade, на сегодня уже можно сказать, что это промежуточная версия, на ее замену пришла версия 3.х.
Вeрсия 3.х — с интеграцией Laravel v.8 с шаблонизатором Blade и полностью переделанным разделом работы с пользователями. Так же поддерживается работа в классическом варианте, как в версии 1.4.х, без применения Laravel и Blade.

Компоненты для cms Evolution

Документация по ним находится в разделе Компоненты
docs.evo.im/04_extras.html
их довольно много, и они не все актуальные, поэтому сделаю небольшой обзор наиболее популярных и актуальных с указанием, для чего каждый из них предусмотрен.

Самые ходовые компоненты, которые используются практически в каждом проекте, уже находятся «в коробке» и устанавливаются вместе с cms. Остановлюсь лишь на некоторых из них:
DocLister — базовый сниппет, вывод документов, пришел на замену Ditto, но имеет значительно более высокую функциональность. Кроме того, на его базе создано большое количество других компонентов.
FormLister — создание любых форм, от обычных форм обратной связи и вплоть до создания личнго кабинета веб-пользователя. Пришел на замену eForm, WebLogin, WebLoginPE, WebSignup.
DLMenu — создание меню, находится в составе DocLister. Пришел на замену Wayfinder.
DLCrumbs — создание хлебных крошек, находится в составе DocLister. Пришел на замену Breadcrumbs.
DLSitemap — создание карты сайта sitemap.xml, находится в составе DocLister. Пришел на замену SiteMap.

Дополнительно Вам могут потребоваться:
Commerce — создание интернет магазина, корзина, избранное, сравнение, модуль управления заказами, мультивалютность. Пришел на замену Shopkeeper.
editDocs — импорт / экспорт документов (товаров) и другие функции. Пришел на замену catalogFill.
Документация здесь editdocs.grishin.net/
eFilter — создание фильтров по параметрам, дополнительно в комплекте содержится сниппет для сортировки getSortBlock.
evoSearch — организация поиска на сайте. Пришел на замену AjaxSearch.
SimpleGallery — создание фотогалерей и фотоальбомов, заменил все что было раньше в этой области.
TagSaver — поиск по тегам.
JotX — отзывы и комментарии.
multiTV — создание списков и блоков на странице. Несмотря на возраст, компонент сохраняет свою актуальность и популярность.
multiFields и PageBuilder — по назначению компоненты аналогичные multiTV, но более современные и более функциональные. Особое внимание рекомендую обратить на PageBuilder, особенно если нужны блоки в блоках.
Документация multiFields здесь
64j.gitbook.io/multifields-2/
evoBabel и bLang — мультиязычность, имеют отличия в подходах реализации. bLang — языковые версии на одной странице (устаревший компонент с подобным принципом реализации YAMS), evoBabel — языковые версии каждая на своей отдельной странице.

Компоненты для админки.
ClientSettings — для организации пользовательских настроек, сейчас, пожалуй, ни один проект без него не обходится.
TemplateEdit 3 — как альтернатива, а где-то и на замену старого, доброго и неувядающего ManagerManager, который в версии 1.4.х по-прежнему идет «из коробки».

В версии 3.х «из коробки» не идет ничего, и если что кому нужно — устанавливайте самостоятельно.

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

1. Кэш
Несмотря на свою банальность и широкую известность, пожалуй, самая топовая «неисправность».
Если что-то где-то не так, если, к примеру «все сделал правильно, а оно не работает», то первое что надо сделать — это очистить кэш, как в админке сайта, так и кэш браузера (историю). При этом историю посещений браузера всю чистить не обязательно, достаточно очистить кэш просматриваемой страницы горячими клавишами, например, для браузера Chrome Ctrl+Shift+R.
Бывает, что очищать кэш браузера необходимо и в админке сайта, например, при настройках SSL, кастомизации админки, и в других случаях.
Чтобы снизить влияние кэш, можно в конфигурации сайта параметр Способ кэширования установить в режим Отключить для администраторов

2. Версия php
Нужно всегда обращать внимание на системные требования не только самой cms используемой версии, но и компонентов, которые используются при разработке. Например, если вы используете 1.4.х и системных требованиях написано, что версия php не менее 5.6, но при этом используется какой-то компонент с требованием не ниже 7.3, то и использовать версию на сервере нужно не ниже 7.3. В противном случае cms будет выдавать жуткие ошибки, а достаточно всего лишь поменять версию php. Может быть и наоборот — на сервере к примеру, версия php 7.3, но вы поставили какой-то компонент, который данную версию не поддерживает.

3. Совместимость
Все течет, все изменяется, и довольно быстро.
Кроме версии php есть и другого рода совместимость.
Особенно это касается компонентов, разработанных на базе DocLister — эти компоненты и сам DocLister взаимоувязанные. Например, если Вы на существующий ранее разработанный сайт решили добавить фотогалерею SimpleGallery, то высока вероятность, что при установки из Extras вы установите более новую версию SimpleGallery и она может оказаться не совместимой с ранее установленным DocLister. Решается просто — нужно обновить DocLister.

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

4. Очередность
Имеет значение, и для плагинов, и для сниппетов, и для скриптов. Поэтому если где-то что-то не срабатывает, прежде всего, надо обратить внимание на очередность используемых элементов — возможно, вы пытаетесь использовать результаты выполнения какого-либо сниппета или плагина, которые еще не получены, т.к. он вызывается позже.
В некоторых компонентах, например, Commerce, в документации указано, при каких событиях этот плагин должен вызываться первым.

5. Ошибки js
Наряду с предыдущими, перед тем как углубляться в поиски причин, нужно проверить, нет ли ошибок скриптов в консоли браузера или других конфликтов, например, дважды вызван jquery. Следует так же иметь ввиду, что некоторые компоненты имеют собственные скрипты, в том числе и jquery, у них могут быть и специальные параметры для их отключения, если в шаблоне такой скрипт уже используется.

6. В админке не отображаются превью multiTV и подобные.
Как правило, с этим сталкиваются на локалке OpenServer, решение можно посмотреть здесь

7. Перенос на хостинг
Если вы перенесли сайт на хостинг, а он там не запускается или что-то криво, то в первую очередь надо сначала проверить свои действия:
— версия php соответствует (по умолчанию версия php на хостинге может отличаться от требуемой)
— ничего не потерялось в архиве, в котором переносились файлы (.htaccess, index.php и др.)
— базу данных подключили и у нее нужная кодировка
— пути к файлам сбросили
— файл assets/cache/siteHostnames.php удалили (или прописали в нем нужный домен)

8. Нет документации (нет в документации)
Если все перепробовал и ничего не получается, значит, пора еще раз более внимательно посмотреть документацию.
Где смотреть:
— на этом же сайте в разделе Документация
docs.evo.im/
— в релизах к новым версиям cms
— файлы readme.md компонентов
— папки docs внутри компонентов
— служебная часть сниппетов и плагинов, бывает, что авторы и там пишут пояснения и даже примеры
— темы на этом сайте, многое уже многократно обсуждено, для этого на сайте имеется встроенный поиск
— на сайтах авторов
— на других ресурсах в интернете, надо воспользоваться поиском

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

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

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

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

10. Нестандартное решение.
Если ничего похожего среди опубликованных компонентов вы не нашли, то это не означает что их вообще нет в природе и никто ничего подобного ранее не делал, или не сможет сделать под вашу задачу. В этом случае можно опубликовать свое объявление в разделе Работа.

Добавление и расширение списка «типовых неисправностей» приветствуется.

6 комментариев

avatar
11. Резервная копия
Это страховка, позволяющая сэкономить много времени и сил, если что-то пошло не так. Позволяет быстро откатиться назад на рабочий вариант. И да, это аксиома.

Когда я рекомендую делать резервные копии.
В ходе разработки нового сайта:
— перед установкой нового компонента
— после завершения очередного этапа разработки
— при удачно найденном решении, дабы оно не потерялось при последующем «улучшении»
Существующего рабочего сайта:
— если что-то захотелось улучшить или поправить, не важно что и где, и в каком объеме.
— перед обновлением cms и / или ранее установленных компонентов
— после первичного наполнения
— после существенных изменений в ходе эксплуатации
— перед тем, как дать доступ в админку (на хостинг) другому лицу, вне зависимости кому и для чего
— после того, как вам дали доступ в админку чужого сайта (на хостинг), например, для оценки каких-то доработок или еще каких-то действий — во избежание дальнейших недоразумений, тем более что этот доступ могли дать не только вам

И в других случаях, если есть какие-то сомнения в положительном исходе предстоящих действий. Лишняя резервная копия никогда не помешает, и ее всегда можно удалить с жесткого диска.

Объем резервирования выбирается исходя из объема решения предстоящих задач. Это может быть как полная резервная копия всего сайта (файлы и база данных), так и локальная, например, только база данных (сделать резервную копию базы данных есть возможность даже из админки сайта), или создание копии файла (файлов, директории), или копии кода какого-то элемента (сниппета, плагина, шаблона, чанка).
avatar
12. Кастомизация
Компоненты Evo в большинстве своем — это универсальный инструмент. Для достижения нужного функционала используется параметры, конфигурации, конфиг-файлы и другие настройки, содержащиеся в самих компонентах.
Если «штатных» средств не достаточно, то дополнительно разрабатываются сниппеты, prepare или дополнительные плагины. Как правило, стандартные компоненты поддерживают такие расширения.

А вот вносить изменения непосредственно в код компонентов не рекомендуется, по причине:
— стандартный элемент при обновлении компонента «затрет» все ваши изменения, и сайт перестанет работать в нужном режиме, или вообще «слетит»
— если сайт в дальнейшем попадет в другие руки на доработку или обновление, то вам будет долго икаться, а ваша репутация точно не улучшится. Аналогичный сюрприз может прилететь и вам, поэтому обращайте на это внимание уже на этапе первого ознакомления
— даже если сайт останется у вас на поддержке — через пару лет вы уже и сами можете не вспомнить, где и что изменялось и можете наступить на свои же «грабли» при очередном обновлении.

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

Это касается не только сниппетов и плагинов, но и шаблонов (чанков), и конфиг-файлов, которые бывают в составе компонентов (да и в самой cms v.1.4.х).

На них остановлюсь отдельно, т.к. они как раз чаще всего и нуждаются в изменениях, исходя из верстки сайта, и часто возникают вопросы, почему не работает (особенно если используется ajax, например, Commerce, eFilter, и др.).

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

В ядро cms лучше вообще не вмешиваться, а добавление (изменение) виджетов админки и другие кастомизации админки решать с помощью плагинов.
avatar
Как я делаю pagebuilder в BLADE gist.github.com/sashabeep/40cd5a08ac9fe7b9db2d710b7557bf4f

Немногие знают, что МultiTV тоже можно парсить сразу в шаблоне на 3.x без объявления tpl-ок

Как подключить контроллеры на пальцах gist.github.com/sashabeep/32355af4f27bf8d3732618a7f0208f7a
Комментарий отредактирован 2021-06-22 09:50:42 пользователем alexbeep
avatar
Вчера столкнулся с казалось бы простой штукой, которая вывела меня из строя на полдня. Правда, это больше не к самому modx относится, а к пониманию PHP, но ошибка случилась именно в типовой конструкции от modx-а.

Обычно код плагина выглядит примерно так:


switch ($modx->event->name) 
{
    case 'OnDocFormSave': 
    /*что-то делаем*/;
    break;
}

И пока такое размещено в базе данных, все работает.

Но чтобы не хранить код в базе, выносим все в файл, например, plugin.php, а в самом коде плагина подключаем этот файл.

Так вот если подключить его вот так:

require_once(/*.путь к файлу..*/ "plugin.php");

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

Правильным решенем было использовать require, а не require_once, вот так:

require(/*.путь к файлу..*/ "plugin.php");


Ну, либо добавить явный вызов функции, которая есть во включаемом файле, вот так:

require_once(/*.путь к файлу..*/ "plugin.php"); 
my_function($params);//функция из файла plugin.php
avatar
13. Обновление
По этому вопросу не получалось написать кратко, поэтому вынес его в отдельную статью, с которой можно ознакомиться здесь
modx.evo.im/blog/6317.html
avatar
14. Возможная возникшая ошибка (при переносе с хостинга на хостинг)
A possible CSRF attempt was detected from referer. Такую ошибку я словил и не мог понять откуда она идет. Спасибо за помощь Pathologic , все до банальности просто, надо удалить файл siteHostnames.php находящийся в директории /assets/cache/
Комментарий отредактирован 2021-10-01 13:44:26 пользователем umka
  • umka
  • 0
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.