Сергей Шлоков

А если подключен jQuery, то ваааааааще все просто

$(element).removeClass('col-md-9').addClass('col-md-12')

где element — это скрываемая колонка.

По моему, нецелесообразное нововведение.

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

Да прибудет с тобой javascript.

Тут есть ряд сложностей.
1. Нужно протестировать mSearch во всех режимах, чтобы проверить, что ничего не сломалось. Это работы не несколько дней, чтоб разобраться, настроить, проверить и т.п.
2. Вряд ли Василий все это примет не глядя. А так как проверка займет кучу времени, то шансов на коммит мало. А если учесть, что такая фича нужна единицам, то шансов вообще 0. Если я ошибаюсь, то пусть Василий меня поправит.
П.С. Я в Яндексе часто пользовался это возможностью пока не убрали.

Вот те раз.

Если ты сначала устанавливаешь чистый modx на сервер, а потом только импортируешь БД, то конфиги трогать не надо.
А файлы modx ты переносишь на хостинг?

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

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

А что так много страниц? Начни с главной и смотри в журнал. И так пробеги по всем страницам.

Начни со страны, потом город, потом улица и т.д. Когда дойдешь до сайта, попробуй определить после просмотра какой страницы появляется. И гляди чего на странице.
Скорее всего чанк-шаблон вызывается в шаблоне или ресурсе.

Как же это так нет. А вот.
Кто ищет тот всегда найдет тут и тут

Для этого нужно вызывать так

[[!pdoMenu?
  &cache=`1`
  &cacheTime=`180`
  &fastMode=`1`
...

Не внимательно читаешь )

А так задумано, что считается просмотр любой страницы, а не только тикета?

Получается невозможно взять и закешировать меню разом на всех страницах?

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

[[!pdoMenu?
  &cache=`1`
  &cacheTime=`180`
  &fastMode=`1`
...

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

[[pdoMenu ...]]

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

+100. Быстрое и легкое решение.
У меня мысль потекла в сторону расширения класса Tickets и изменения метода SaveTicket() с учетом нового параметра redirectTo сниппета TicketForm.

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

В данном примере можно 2 if объединить в один для краткости.

if($modx->context->key != 'mgr' && $mode == 'new' && $resource->class_key == "Ticket" && $resource->get('parent') == 8)

Получается, ты решал задачу А, а решил задачу Б.
Т.е. задача изменилась с

чтобы после опубликования тикета перекидывало не на страницу тикета, а на определёную страницу.

на

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

А народ-то и не знал.

Это решается добавлением условия $modx->context->key != 'mgr'.
Я имел ввиду, что в плагине нет редиректа, только публикация тикета. Поэтому и вопрос — зачем нужно это делать в плагине, если можно поменять форму?