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

Тогда таблицы придется вручную создавать.

Ну считаем дальше. 2 инвестора вложили по 25 тыс. в этот продукт. В магазине собственник один. И все деньги отправляются ему. И он должен поделиться со вторым (а то ещё и с третьим/четвертым и т.д.). И про программиста не забыть. Риск обмана и надежда на совесть.
Дальше. В продажу поставили за 1 тыс. руб. Т.е. за минусом комиссии инвесторы получат 700 руб. Из них 500 они должны отдать программисту за поддержку. Остаётся 200 р. Таким образом, прибыль инвесторы будут получать только с 251 продажи. А программист получает львиную долю — с каждой продажи по 500 р. И к тому моменту, как инвесторы получат первую прибыль, он к своим 50 тыс. дополнительно заработает ещё 125 тыс. При этом программист может вообще не оказывать никаких услуг, ну или в единичных случаях. А получает он с каждой продажи. В общем, самая проигрышная сторона — это инвестор.
А дальше встанет вопрос о развитии продукта — прикрутить какую-нибудь супер фичу. Опять же нужно собрать деньги. Один из инвесторов откажется вкладываться. Нашелся другой. И какие доли теперь будут у инвесторов? У отказавшегося доля может упасть так сильно, что он годами будет возвращать инвестиции. На что изначально он не подписывался. И это только математика. А если ещё юридические вопросы копнуть, то вообще расстроишься.

Перед тем как предлагать идею, её нужно сначала проработать, погрузиться в неё. Почитай как найти инвестора для стартапа, чтобы понимать вопрос. Да и вообще, тема инвестиций в России ещё не развита. Это в Америке люди готовы вкладываться. У них уже на генетическом уровне — «Вложусь, вдруг получится». У них даже домохозяйки вкладываются в фондовый рынок. У нас другой подход — «Не вложусь, вдруг не получится». Так что данный вопрос пока не своевременный.

Остается 70%. Пример: где 50% мастер, 20% инвесторы.

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

Начать статью можно было так — «Жили-были ...». А закончить — «И жили они долго и счастливо». Чтоб все понимали, что это сказка про идеальный мир с джентельменами и альтруистами. :))

Крутая вещь! Безусловно будет очень востребована. Не знал, что modhost поддерживает ноду.

Подскажите, пожалуйста, где посмотреть как такое делается по-уму?!

Я бы начал с обучения как пользоваться поисковыми системами и попробовал бы с фразы «Зависимые списки HTML».

А вот так через modHelpers

// Вариант 1.
count(resources(['parent:IN'=>[2,45368], 'published' => 1, 'deleted' => 0]));
// Вариант 2.
resources()->where(['parent:IN'=>[2,45368], 'published' => 1, 'deleted' => 0])->count();

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

// Вызываем функцию без аргументов и используем цепочки
email()
	->to('user1@mail.ru')
	->toUser(5)
	->cc('user2@mail.ru')
	->subject('Тема письма')
	->content('тело сообщения')
	->from('Администратор')
	->replyTo('admin@gmail.com')
	->attach('file1.jpg')
	->attach('file2.png')
	->send();

Prego, amico!

Ок. Пусть будет

Спасибо!

но нужно предусмотреть возможность отключения.

readOnly=`1`

А как быть с заданием прав на календарь?

Использовать сниппет-обёртку типа такого

[[!wrapCalendar? 
	&allowGroups=`admin,secretaries` 
	&teacher=`5` // id учителя
	&calendars=`1` // id календаря
	&readOnly=`1` // Редактирование запрещено
]]

А внутри проверять группы и учителя и выставлять readOnly в 0 для них.

Не думаю, что человек в здравом уме будет вести свой личный календарь на каком-то левом сайте

А вариант с правым сайтом не рассматривается? Бесит уже этот американский образ мышления — мне это не нужно, значит это никому не нужно.

На самом деле у сниппетов одна очень важная отличительная особенность — это параметры по умолчанию. Поэтому сниппеты можно вызвать без параметров. А вот вызывать файловый «сниппет» нужно всегда с параметрами. В остальном различия несущественные. Ну и понятно, что кэшировать файл нет необходимости.
Кстати, сниппеты кэшируются в 2 директории — core/cache/includes/elements/modsnippet/ и core/cache/scripts/elements/modsnippet/.

Обновил библиотеку. В основном доработки коснулись менеджера коллекции — добавлено несколько методов и возможность использовать callback функции.

// Получение списка с заголовками с использованием callback функции.
return resources()->where(['id:IN'=>children(5)])->each(function($resource, $idx){ return "<li>{$idx}. ".$resource['pagetitle']."</li>";});
// Получение массива заголовков дочерних элементов ресурса 5 с использованием UNION.
$array = resources()
            ->where(['id:IN'=>children(5)])
            ->union('select pagetitle from ' . table_name('modResource') . ' WHERE id = 1')
            ->union(['pagetitle'=>'New pagetitle'])
            ->get('pagetitle');
// Получаем всех пользователей группы "Managers"
$usersArray = users()->members('Managers')->toArray();

Изначально форма показывается. Добавьте в свой css файл

#comment-form {
    display: none;
}

Т.е. одна страница собирается из нескольких.
Судя по скриншоту ты это уже сделал.

Ламерский вопрос. А в каких случаях работает такая конструкция

{php код}

Я-то пользуюсь

{$.php.код}

Ну если контент-манагер не в состоянии поменять местами строчки в шаблоне и не в состоянии освоить компонент Structures, то наверно ты прав. Готов вместо такого менеджера порекомендовать своего пятилетнего сына. Недорого. :)

Версия 2.5.2 содержит критические исправления безопасности и закрывает известные методы взлома. Советую обновится.

Я в своё время думал про такое, но так и не смог выделить все преимущества, чтобы заставить пользователей отказаться от использования шаблона

<head>
...
</head>
<body>
	[[$header]]
	[[$mainMenu]]
	[[$gallery]]
	[[$content]]
	[[$footer]]
</body>

Только лишние запросы в БД. А вариант с шаблоном даёт большую гибкость, особенно с fenom.

П.С. Ну и ещё есть дополнения типа Structures для блочного редактирования.

Structures.

Особых требований по этому поводу нет.