Александр

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



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

Разрабатываю проект, в котором необходимо было реализовать более простое редактирование дополнительных полей профиля, чем есть из коробки. К слову, неудобное редактирование — это не единственный минус нативного способа расширения профиля полями. Ни для кого не секрет, что фильтрацию по JSON полям нормально не осуществить, только костылями. Фактически, мне надо было получить решение, которое бы расширяло стандартный код MODX, не трогая исходники, дабы сохранить карму в порядке возможность обновления системы.
Пришёл к выводу, что буду расширять стандартную вкладку профиля «Общая информация». При желании можно чуть переписать код в событии OnUserFormPrerender и создать свою вкладку со своими полями.

Небольшое решение на основе ms2form.

Умеет: аплоад драг н дроп, менять местами фотки, удалять фото.

Бывают ситуации, что пароль от админа теряется, а к почте, на которую зареган админ, доступа нет. Данный скрипт создаёт sudo юзера при запуске с рандомным логином и паролем. Дальше уже можно через этого юзера поменять пароль от админа, а залогинившись под админом — удалить только что созданного sudo. Скрипт просто надо закачать в папку с MODX и запустить.

Мне нужно выбрать данные из нескольких кастомных таблиц через pdoResources, но не получается настроить Join-ы правильно.
Есть несколько кастомных таблиц с одинаковой структурой полей и с сгенерированными моделями.
Данные из одной таблицы выводятся легко:

[[!pdoResources?
    &loadModels=`orders_external`
    &class=`BazOrders1External`
    &tpl=`tpl.orders.row`
    &limit=`0`
    &where=`{ 'publishedby':2 }`
]]

А вот как приджойнить сюда другие таблицы по тому же условию?

Наверняка много кто использовал в своей практике TV-поля типа «Список» (множественный, одиночный, не важно) или «Тег». Здесь важно именно то, в каком виде в базе данных хранятся данные таких полей, ведь они сохраняют множественные значения. А хранят они их одной общей строкой в той же самой таблице ТВшек (естественно, по одной записи на один документ). К примеру, если мы отметили три значения 100, 1005, 10, в БД это запишется 100||1005||10. И здесь возникает вопрос как потом выполнить поиск по таким полям? Простой LIKE здесь не поможет, так как LIKE %100%, к примеру, найдет и '100||1000' и '1001||1005'. Данного вопроса мы уже касались здесь и подобный вопрос опять возник здесь.

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

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

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

Здравия.

У меня есть форма, в которой используются свои combobox-ы. Надо при выборе в первом select-е подгружать данные из базы во второе в зависимости от выбранного варианта в первом. С подгрузкой мне помог Сергей. Мне удалось сделать так, чтобы при выборе в первом поле во второе подгружались нужные варианты выбора. Однако если мы первый раз подгрузили в это поле данные, то второй раз они внешне никак не обновляются, хотя значения обновляются. Я так понял для этого надо разрушить и отрендерить поле заново. А вот как это сделать? Я получил нужное поле при событии select в первом Ext.getCmp( config.id +'-version'), выполняю в нём метод destroy(), а далее он уже не выполняет метод render(). Поле не появляется.

Вот код моих полей в форме:

В прошлой статье мы попытались понять как формируется интерфейс админки на ExtJs. Теперь давайте попробуем разобраться, что можно сделать интерфейсом, который нам нарисовал ExtJs.
В ExtJs за каждым элементом интерфейса (панель, окно, таблица, кнопка, элемент формы) стоит специальный объект, называемый компонентом. Он отвечает за управление элементом интерфейса — создание, отображение, скрытие, удаление. В админке MODX все элементы «являются» компонентами ExtJs, за исключением верхнего меню. Разницу можно увидеть, если заглянуть в исходный код страницы — у меню простая и привычная HTML структура (ul > li > a), а если глянем на элемент, созданный ExtJs, то увидим, что он обернут дополнительными тегами. Например, вот код кнопки тулбара дерева ресурсов

<span unselectable="on" class="x-btn x-btn-small x-btn-icon-small-left tree-new-static-resource x-btn-noicon" id="ext-comp-1062" style="">
    <em class="">
         <button type="button" id="ext-gen139" class=" x-btn-text" style=""> </button>
    </em>
</span>

В этой статье хочу немного развеять тучи над механизмом работы админки, логика которой основана на ExtJs. Для людей, далеких от php и javascript, это будет набором непонятных слов. А вот те, кого уже не пугают такие термины как ООП, наследование, конструкторы, поймут о чем я тут буду говорить. Это не курс. Я просто попытаюсь систематизировать информацию для понимания общего принципа работы админки.
В сети достаточно много различной информации об ExtJs. Есть отличный курс Василия, по которому многие из нас учились делать свои дополнения. В нем он разбирает тему создания различных ExtJs объектов. Я не буду повторять, то что у него уже разобрано, а постараюсь на простом языке сделать короткую выжимку. Начнем.