Уважаемый, просьба — не выражаться. А на счет доказательств — подобное обсуждалось уже в сети. А если это не правда, в этой же теме присутствует представитель данного хостера, который скорее всего получается уведомления из этого топика (если не отключил уведомления), и мог бы попробовать разобраться в ситуации.
Это не решает проблемы большой нагрузки при генерации кеша.
Придумал решение. Поскольку я не использую поле parent, то кэш ресурсов мне вообще и не нужен. Соответственно, после генерации файла context.cache.php (или при первой (после генерации карты) загрузке страницы) плагинами его можно подрезать. А именно — почистить подмассив 'resourceMap' (а всё остальное оставить) и перезалить этот файл. В итоге при загрузке страниц сайта будет подгружаться маленький файлик с config, webLinkMap, eventMap и policies.
Это что ещё за гумно на вентилятор. Пукнуть каждый может, а где развёрнуто и с доказательствами?
У Василия вариант 2 получается, потому что ms2Gallery рассчитана на то, чтобы на странице ресурса вывести много картинок. И в вариантах 1 тоже просто вывести много картинок на странице. Только браться они будут не из одной папки на диске (соответствующей одному ресурсу), а из нескольких (зависит от физической организации папок с изображениями) — т.е. делаем выборку требуемых ресурсов-изображений по их TV-характеристикам и получаем url'ы физических файлов. В случае с ms2Gallery — там ведь нет характеристик у каждого изображения? И связь изображений с ресурсами М:1, а у меня — М: М
В своём проекте я не использую какие-либо сторонние сниппеты и компоненты (кроме компонентов для работы с комментариями), поскольку ни один компонентов не обеспечивает требуемого функционала проекта. Даже элементарно хлебные крошки, пагинация, баннеры, псевдонимы, uri, ajax-подгрузка, редиректы, SEO и многое другое — всё это реализовано собственным кодом с индивидуальной логикой. Соответственно, и сабжевый вопрос подразумевает написание собственного интерфейса для загрузки изображений (но только для загрузки). Именно поэтому, я и не рассматриваю здесь возможность использования сторонних компонентов в качестве критерия выбора. Ну а собственный интерфейс для загрузки изображений будет обеспечивать возможность загрузки и одного изображения, и нескольких одновременно (с указанием характеристик для каждой из них).
А еще тем выше риски, издержки и т.п., и соответственно ниже профит и больше срок окупаемости. Тут не все так однозначно.
Есть еще вариант дублировать их в отдельную таблицу (: Тогда для каждого типа ресурсов придётся свою таблицу создавать с TV (из-за ограничения на число индексов в одной таблице). Ну а коли для каждого типа ресурсов будет своя таблица, то и сами ресурсы логично будет хранить в этих таблицах. А коли ресурсы будут храниться в отдельных таблицах, тогда и modx не нужен.
Чем сложнее проект, тем меньше потенциальных конкурентов
а) все TV-поля дублируются в поле (properties) таблицы ресурсов (в формате json) — это поле используется для выборки TV Есть еще вариант дублировать их в отдельную таблицу (: