Воеводский Михаил

Не удивлен.
Помнится, в те времена со знакомым разрабатывал магазин. Я тогда еще не вникал в глубь процесса, но он что-то правил в исходниках SHK, ибо так было проще. Я еще возмущался, что он тем самым сломал возможность обновлений.
Могу ошибаться, конечно. Давно было.

Так если он настолько хорош, почему толпы пользователей не ринулись к нему? Зачем им «отсталый» и «неповоротливый» MS2?
Не понимаю.

Надо будет на досуге посмотреть SHK.

Но пока не вижу ни малейших причин, почему любой желающий не может скопировать из SHK принцип добавления произвольных полей. Там же, в основе, MIGX, который легко подружится с товарами MS2.
Или я ошибаюсь?

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

По существу — вместо тона возмущенного вопля спокойно напишите список пожеланий. Больше вероятности, что кто-то откликнется.

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

Вы об этом?

Да.

Вот еще очень интересный компонент визуального редактирования: www.modmore.com/extras/contentblocks/
Представил сейчас, насколько удобным для неподготовленного пользователя может стать процесс редактирования при совместной работе обоих компонентов — захотелось попробовать где-либо.

Но: и здесь без админки не обойтись.

Очень близко к задаче: extras.io/extras/preview/
Именно редактирование в админке, но упрощенный переход на страницу редактирования + возможность посмотреть изменения непосредственно на странице с оформлением, но еще до публикации.

Я этот компонент еще не использовал, инфа только из официального описания.

Хоть я и за здоровую конкуренцию, но… Спасибо :)

Я озвучил свое предложение, Игорь взял время обдумать его. Спать тоже полезно :)

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

После беглого осмотра осталось впечатление, что еще не слишком поздно вынести из ядра добавленный функционал. Хотя бы из ядра. Измененная админка — не самое страшное.

Связывался с Игорем, смотрел сайт изнутри.

Функционал весьма интересный, но есть очень большой недочет всего сайта — существенно изменено ядро MODX.
На примере пользователей — от системной таблицы и, соответственно, схемы, до страниц админки.

Опять случайный коммент с телефона :(

[случайно созданный с телефона коммент]

Мне кажется рядовым администраторам вообще не нужно давать доступ в админку. Им, наверно, нужно во фронте интерфейс сделать. Я вообще сторонник фронт-энда. Работать в админке можно только с крепкими нервами — слишком тяжелый интерфейс с кучей запросов. Плюс, с правами заморочки, с формами.

Согласен.
Но сделать такой интерфейс не так уж сложно.

Это нужно искать гостиницы с сайтами на MODX. То же и для форм онлайн-бронирования. Они платформо-независимы. Поэтому, думаю, не каждая гостиница заинтересуется моим дополнением. Ведь тогда придется переделывать сайт.

Знаю одну гостиницу, у которой сайт на Revo с момента выхода системы в 2010 году, и еще одну, которой сейчас создают на ней сайт с нуля.
При наличии у Вас интереса, могу связать с ними для обсуждения возможного сотрудничества.

По ангулару: loftblog.ru/category/courses/angularjs-fundamentals/

4, 5 со стороны гостя требует Office — это нормально. Но со стороны менеджера Office не нужен.
Получается, что если предполагается самостоятельная отмена/изменение брони, то Office докупить будет дешевле, чем дорабатывать что-то дополнительное.
Или же в компоненте бронирования пара простых сниппетов для вывода списка броней заданного пользователя и выполнения действий с ними. Без реализации полноценного ЛК со всеми наворотами.

Что же до менеджера — он все равно работает со страницей в админке. Здесь функционал изменения и отмены Вы можете реализовать без лишних усилий. А после этого и сниппеты для гостей станут очень легкими в создании :)

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

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

Еще момент, почему гостиницы заинтересуются — многие на своем сайте размещают форму онлайн-бронирования для удобства гостей. Но операторам этих форм платят 2-5%. За несколько месяцев сумма может набежать значительно больше, чем стоимость компонента и работ по его установке.

4, 5, 7, 8 — это все логичное развитие компонента. Поэтому стоит заранее закладывать такую степень масштабируемости, чтобы не изобретать потом костыли или писать заново.

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

А теперь о применении — в простом варианте это, согласен, только система сбора заявок. Но при развитии компонент сможет стать не только полноценным сервисом бронирований для отелей/хостелов/гостиниц, но и платформой для создания на базе MODX агрегаторов бронирований для нескольких гостиниц. Более того, следующей ступенью (достаточно легко реализуемой) станет расчет комиссий для таких сервисов.

Но это я уже далеко смотрю. Можно будет сделать 2 версии — бронирование для одной гостиницы / сети гостиниц, когда все гостиницы принадлежат одному владельцу, и вторую версию — с комиссиями агентов и расширенными возможностями.

Еще одно направление — почасовое бронирование. Прием врача, игры и многое другое — сфера применения обширна, а базовая часть кода очень сильно будет совпадать с посуточным бронированием.

Сергей, Вы очень интересное направление взяли в работу. Уверен, что при реализации хотя бы половины описанного, компонент будет очень востребован. Причем, 1500 руб. за него будет абсолютно адекватной ценой. Или даже больше.

Когда-то я изучал вопросы бронирования номеров. Основное, что вспомнилось:

1. Возможность бронирования 1-2-3 номеров одновременно. В частности, каждому номеру указывается вместимость, а при поиске пользователь указывает количество заезжающих. Ищутся номера сразу для всех заезжающих. У номеров бывают дополнительные платные места. Часто один ребенок до 7 лет без отдельного места живет бесплатно., Это все тоже желательно учитывать.
2. В случае форс-мажоров, о которых писал Андрей, полезна возможность разбиения брони на периоды для частичного переноса в другой номер.
3. Статусы броней как в минишопе с возможностью указания необходимости рассылки писем при изменении статусов. Таким образом, внутренние изменения гостю будут неизвестны, но по существенным он получит письма.
4. Изменение дат необходимо как менеджером, так и гостем.
5. Аннулирование брони — тоже доступно обоим, но только в виде статуса. Физически удалять не нужно, ибо тогда теряется контроль отмен.
6. Ценовые периоды. Белые ночи, Новый год, майские праздники и т.д. — это все разные цены. Должна быть возможность создания различных периодов и проставления цены каждого номера для каждого периода. Примеры периодов: 30.12-11.01, 12.01-29.04, 30.04-12.05, 13.05-15.06, 16.06-15.07 и т.д.
7. Помимо периодов, цены могут быть разными в зависимости от дня недели — будни дешевле выходных. Наценка в виде процента или фиксированная надбавка.
8. Желательно это все связать с минишопом для онлайн-оплаты. Востребованная функция в последнее время.

Явно еще что-то забыл…

Более правильным вариантом будет не «с нуля», а сделать форк Tickets, и уже их капитально допиливать.

Самый простой способ — отправить ajax запрос с параметром:

/?ms2_action=cart/clean

bezumkin.ru/training/course1/

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