Сайты на MODX

Определимся сразу с вводными:

1. Я менеджер проектов с техническим бэкграундом. В статье будет мало кода, много концепций. Еще, так как я менеджер, мои проблемы отличаются от проблем программистов.
2. Задача данного текста — это получить фидбэк от тех, кто в потенциале мог бы использовать данный инструмент в своих проектах или критику от тех, кому идея показалось бредовой.
3. У проекта уже есть MVP, который решает свою задачу, что и сподвигло меня написать эту статью.

КОРОТКО О ПРИНЦИПЕ РАБОТЫ

Существует набор варфреймов в FIGMA — это может быть 10 шапок, 5 футеров, 12 обложек и так далее. Из этих элементов мы собираем прототип, не исключая кастомизации. После разработки дизайна мы знаем, из каких примерно блоков состоит макет. Набор блоков, из которых состоит макет, мы передаем в компонент MODX, который в ответ нам отдает сборку с настроенными шаблонами, TV-полями и ресурсами в соотвествии с макетом. Остается доработать верстку и несобранный функционал.

Всем привет!
Начиная знакомство с MODX, я частенько удивлялся логичности и простоте CMS, и не мог нарадоваться :) Однако были и моменты непонимания.
В этой заметке я хочу обозначить топ минусов в UI/UX, исправив которые, MODX станет заметно удобнее.

Представляем вашему вниманию готовый сайт с каталогом или магазином на MODx revolution от команды маркетплейс ULTRON. Сборка подойдет под различные тематики и для различных компаний, для примера нами была выбрана ниша электро-монтажной организации.

Помимо самого сайта в сборку включен интернет-магазин на расширении minishop2, который при необходимости можно отключить в 1 клик.

Вёрстка адаптивная, используется фреймворк bootstrap3, сайт отлично смотрится на всех мобильных устройствах. Все основное управление контентом (адрес, картинки, иконки, время работы, карты, тексты и т.д.) осуществляется через Панель Управления (конфигурация или допполя).

Сайт полностью адаптирован, подготовлен под SEO продвижение.

За основу был взять шаблон Bootstrap Ecommerce.

Всем привет, в который раз удивляюсь возможностям применения Tickets.

Цель — Сделать crm систему, чтобы менеджеры тратили минимум времени на заведение контрагентов, заявок и тд

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

Исправлю ситуацию, публикую оставшиеся части. На этот раз без картинок, да простят меня читающие :)

Часть 1. Предыстория.
Часть 2. Почему выбран MODX Revolution. Серверная часть.
Часть 3. Работа с оборудованием. Примерная хронология проекта.
Часть 4. Синхронизация данных и обновление компонентов АСУ
Часть 5. Пути решения проблем при «непонятном» поведении движка/компонентов. Реализация складского учета
Часть 6, 7. Текущие функциональные возможности АСУ
Часть 8. Текущие показатели АСУ. Желаемые планы. Заключение

Текущие функциональные возможности АСУ

1. Прием заказов в кофейне сотрудником с использованием сенсорного моноблока
2. Логирование действий барменов
3. Путеводитель по процессу создания заказа (вопрос-ответ)
4. Печать чеков на фискальном регистраторе
5. Центральный сервер (далее ЦС) для агрегации данных
6. Централизованное управление товарами и их составом
7. Отчетность (статистика) для по продажам локально в кофейне и централизованно
8. Синхронизация между всеми серверами в реальном времени
9. Комплексные предложения (наборы товаров)
10. Предложение доп. продаж позиций, соответствующих добавленным в заказ
11. Флаеры
12. Складской учет
13. Интеграция с системой видеонаблюдения Video.NET
14. Сотрудники – карточка сотрудника
15. Программа лояльности, гости
    • Карточка гостя
    • Лицевой счет
    
    
    • Оплата заказов с карты гостя
    • Система подарков
    • Самостоятельная регистрация гостей на отдельном сайте
16. Сканирование штрих-кодов на картах сотрудников и гостей
17. Система резервного копирования всей сети в облачное хранилище

Часть 1. Предыстория.
Часть 2. Почему выбран MODX Revolution. Серверная часть.
Часть 3. Работа с оборудованием. Примерная хронология проекта.
Часть 4. Синхронизация данных и обновление компонентов АСУ
Часть 5. Пути решения проблем при «непонятном» поведении движка/компонентов. Реализация складского учета
Часть 6, 7. Текущие функциональные возможности АСУ
Часть 8. Текущие показатели АСУ. Желаемые планы. Заключение

Пути решения проблем при «непонятном» поведении движка/компонентов

В далеком 2014 году, когда я приступил к активной реализации проекта, я не знал и десятой доли всего того, с чем столкнулся в процессе и что пришлось изучить. В условиях катастрофической нехватки времени очень быстро (почти мгновенно) пришло понимание, что официальная документация весьма скромна в плане описания определенных механизмов, по которым появляются вопросы. Естественно, времени на написание вопросов в сообществе и ожидание ответов на них у меня не было.



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

Часть 1. Предыстория.
Часть 2. Почему выбран MODX Revolution. Серверная часть.
Часть 3. Работа с оборудованием. Примерная хронология проекта.
Часть 4. Синхронизация данных и обновление компонентов АСУ
Часть 5. Пути решения проблем при «непонятном» поведении движка/компонентов. Реализация складского учета
Часть 6, 7. Текущие функциональные возможности АСУ
Часть 8. Текущие показатели АСУ. Желаемые планы. Заключение

Синхронизация данных и обновление компонентов АСУ

Первоначально, пока АСУ была запущена всего в 3-х кофейнях, любые изменения осуществлялись в ручном режиме. Чем больше времени проходило, тем меньше радости возникало при необходимости скорректировать цены, добавить товар или обновить компонент. Благо, с самого начала предполагалось создание центрального сервера (ЦС) и синхронизации всех локальных серверов через него.

Часть 1. Предыстория.
Часть 2. Почему выбран MODX Revolution. Серверная часть.
Часть 3. Работа с оборудованием. Примерная хронология проекта.
Часть 4. Синхронизация данных и обновление компонентов АСУ
Часть 5. Пути решения проблем при «непонятном» поведении движка/компонентов. Реализация складского учета
Часть 6, 7. Текущие функциональные возможности АСУ
Часть 8. Текущие показатели АСУ. Желаемые планы. Заключение

Работа с оборудованием

Фискальные регистраторы

Главным нюансом было взаимодействие с фискальным регистратором, который в 2014 году в качестве коммуникационного поддерживал только COM-порт. Второй сложностью в работе с ФР был протокол работы, основанный на бинарном обмене данными.

Вторая статья из цикла.

Часть 1. Предыстория.
Часть 2. Почему выбран MODX Revolution. Серверная часть.
Часть 3. Работа с оборудованием. Примерная хронология проекта.
Часть 4. Синхронизация данных и обновление компонентов АСУ
Часть 5. Пути решения проблем при «непонятном» поведении движка/компонентов. Реализация складского учета
Часть 6, 7. Текущие функциональные возможности АСУ
Часть 8. Текущие показатели АСУ. Желаемые планы. Заключение

Почему выбран MODX Revolution

Ключевые технические требования к АСУ, которые были выявлены до начала технических работ:

• Язык программирования — PHP;
• WEB-сервис для упрощения процесса замены клиентского терминала;
• Локальный сервер в каждой кофейне для минимизации влияния отсутствующего интернета;
• Возможность передачи проекта для развития сторонним разработчикам;

Главная причина выбора MODX Revolution банальна: на момент начала работ я знал данный инструмент лучше всех остальных. Из-за ограниченных сроков сравнение с другими инструментами не рассматривалось, так как любой из других движков/фреймворков, помимо чтения теории о них, потребовал бы значительного времени на вникание в его подходы.