Для разработчиков

UPD: Пробуем по новому. Возвращаем всё на место и комментируем 49 строку плагина:

//'sections/resource/update.js',

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

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

Последние дня 4 занимаюсь созданием фронтэнд менеджера, решил подсмотреть в сторону mobiledetect, а точнее в парсинг тегов.

Собственно вот, что получается:


Подробности под катом.

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

В силу того, что время и развитие не стоит на месте (включая появление Фенома), у меня возник дополнительный интерес к минишопу и прочим сопутствующим продуктам. Так как бесплатно их ковырять не интересно, публично сообщаю, что я открыт для предложений по доработке разрабатываемых проектов на минишопе, pdoTools и прочем. В общем, на всем чем угодно, лишь бы MODX Revo. Здесь есть только пара пожеланий:
1. Пока интересуют только локальные не стандартные задачи. То есть кто-то разрабатывает какой-то проект, и с чем-то не может справиться. Уверен, я много в чем могу помочь.
2. Желательно задачи не особо объемные, то есть на пару часиков буквально.

Цена вопроса акционная: 1 час времени 1000 рублей. Каждый 3-ий час в подарок. Скорее всего данное предложение будет действительно в течение недели. На всякий случай уточню, что и сегодня я еще несколько часов буду доступен. Если кому интересно, пишите в личку или на почту n.lanets@modxclub.ru

Вчера в поддержку магазина обратились с жалобой на медленную работы mSearch2 при небольшом количестве товаров.

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

Изначально debugParser показывал такой результат работы.

В первой части познакомились с методом Ext.getCmp() для работы с компонентами ExtJs. Он позволяет взаимодействовать с виджетами ExtJs — панелями, таблицами, формами, окнами, запрашивать и обрабатывать данные с сервера и т.д. Но иногда требуется просто поработать с обычными HTML элементами. А для этого метод Ext.getCmp() совсем не подходит. Можно, конечно, пользоваться обычным javascript. Но уж очень хочется иметь такой же удобный инструмент как jQuery. И ExtJs предоставляет нам такой функционал. Для работы с элементами DOM у него есть несколько методов.

В прошлой статье мы попытались понять как формируется интерфейс админки на 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 объектов. Я не буду повторять, то что у него уже разобрано, а постараюсь на простом языке сделать короткую выжимку. Начнем.

Нужны добровольцы с разными версиями выгрузки из 1с в формате commerceML 2

Добрый день!
Все мы знаем, что MODX прекрасен мощью решений с помощью компонентов. Я, например, всегда отдаю заказчику сайт в виде компонента, содержащего нужные элементы, зависимости от других компонентов, инициализацию нужных опций и т.д. В этом мне всегда помогал modExtra.
Но вот в один прекрасный момент я задумался, как сделать пользовательские таблицы в своём компоненте таким образом, чтобы при апдейте компонента они были способны расширяться, да и вообще поддерживаться в актуальном состоянии.
Итак задача:

• У нас есть файл схемы mycomponent.mysql.schema.xml, который поставляется вместе с компонентом (или его новой версией) и содержит актуальную информацию о структуре пользовательских таблиц.
• У нас есть БД в которой может не быть наших таблиц (установка с нуля), а могут быть (как правильной, так и неправильной структуры).

Цель: добиться идентичности схемы и реальных таблиц для нормальной работы компонента.