Наумов Алексей

Тоже готов скинуться. Но ввиду значительного объема работ и их сроков действительно считаю более разумным сделать поэтапную разработку. Периодическое появление результата будет стимулировать интерес к затее и не позволит ей «затухнуть» в наших умах.

Если своими словами:
1. делаем xml схему
2. На ее основе через migx: а) создаем компонент, б) парсим классы, в) создаем таблицы
3. Так же через migx настраиваем интерфейс, настроек там много, но все делается визуально, он сохраняется как конфигурация
4. создаем TV с типом migxdb, указываем ему id конфигурации с прошлого шага, назначаем шаблону, и создаем ресурс с этим шаблоном

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

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

Весьма просто (если опыта нет) это можно сделать с использованием MIGx db.
И весь интерфейс в админке будет доступен (ну кроме функций экспорта, это придется дописать).

Почитай эту статью rtfm.modx.com/extras/revo/migxdb/migxdb.tutorials/migxdb.create-a-basic-gallery-management-from-scratch-with-migxdb и статьи рядом в этом разделе.

Серия и номер это ресурсы обязательно?

Лучше сделать отдельную таблицу под них, а запросы хранить в еще 1 таблице, структуру ее сделать типа:
дата, запрос, найден(да/нет), id найденого номера

почему бы не сделать это в сниппете? Зачем городить такую штуку?

MySnippet:

$param = empty($_GET['param']) ? '' : $_GET['param'];
...

github.com/bezumkin/miniShop2/blob/master/core/components/minishop2/model/minishop2/mscarthandler.class.php#L100

Мне кажется, что речь шла об «умеренном использовании» TV. Я лично пользуюсь, но в меру стараюсь. Что бы избежать излишнего их количества или сортировки по ним.

К примеру если нужно вывести список в 1000 строк и 20 столбцов, где каждый столбец — TV, будут проблемы, так как у нас 20 джойнов получится.

А если же эти 20 TV выводятся просто на одной странице для одного объекта — разницы в скорости вы не увидите.

В общем с умом подходим к делу.

Спасибо! Как то странно )

Окей, в принципе да. Я об этом тоже подумал.

Но в существующем коде возможности голосовать за объект с другим class нет, я верно понимаю:
github.com/bezumkin/Tickets/blob/master/core/components/tickets/processors/web/ticket/vote.class.php#L53
?

Тогда пишу свой код для поддержки голосования за другие типы объектов на сайте!

Для слайдера сделай галерею с использованием MIGx. В случае с 3 изображениями загрузить их вручную вполне себе обыденная задача.

Ну вот в форме:

<input type="hidden" name="resource_id" value="[[*id]]" />

resource_id — вы ставите id ТЕКУЩЕГО документа, на котором форма расположена

а в сниппете код:

$doc = $modx->getObject('modResource',array('id'=>$hook->getValue('resource_id')));
 
if (empty($doc)){
    $doc = $modx->newObject('modResource');
    $doc->set('createdby', $modx->user->get('id'));
}
else{
    $doc->set('editedby', $modx->user->get('id'));
}

построчно:
найти ресурс, который указан в поле resource_id
если он пустой — то создать новый ресурс
иначе — редактировать существующий.

отсюда и все идет…

кстати, если кто-то умный подменит и установит resource_id = 1, то будет преспокойно менять текст главной страницы вашего сайта =)

а вообще задача для новичка в MODx — сложная

В принципе я тоже согласен с добавлением пары полей.

Придумать можно много чего.
Например смело:
alt, title,tags (или для упрощения я бы назвал это group). Теги предполагают что их может быть несколько через запятую, все это несколько усложняет реализацию, а группа она группа =), одна, без деления запятыми.

Ну и вообще было бы прикольно добавить field1, field2, field3 просто на всякий случай).

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

Сразу в голову пришло запихнуть куда-нибудь массив вида $sales[$resource_id] = $sale в виде json и проверять новое значение TV с ним.

Или для этих же целей можно использовать:

$prop = $modx->fromJSON($resource->get('properties'));
$old_sale = empty($prop['old_sale']) ? 0 : $prop['old_sale'];

... тут сравниваем скидку с $old_sale
...

$prop['old_sale'] = $resource->getTVValue('sale');

$resource->set('properties', $modx->toJSON($prop')))
$resource->save();

как то так…

Хотя вру, вызывается там strftime github.com/modxcms/revolution/blob/master/core/model/modx/filters/modoutputfilter.class.php#L443

Модификатор date по сути и вызывает php функцию date.

php.net/manual/ru/function.date.php

в табличке вторая строка снизу

Если пункты меню не будут часто добавляться, то я делаю так:

[[pdoMenu?
	...
	&parents=`0` 
	&resources=`1,5,6,7,8`
        &sortby=``
	...
]]

resources — список id пунктов меню, пустой sortby — сортировать в том порядке, как указаны id.

Я использую параметр rowClass=`item-[[+id]]` или как то так он называется, что бы добавить к каждому пункту меню class=«item-123» (для примера), а потом прописываю эти классы в css файле.

Я б наверное не рискнул =)

Хотя ради теста можно поставить MODx с минишопом и нагенерить нужное кол-во товаров, посмотреть, как будет открываться все =)

У меня жуткий костыль, код разбросан в 10 местах, суть такая:
1. В низу страницы есть код скрытой формы, эта форма отображается при помощи fancybox при загрузке картинки.
2. В форме есть input type=file, загрузка файлов идет по одному
3. Сама форма отправляется на сервер через ajax (jquery forms)
4. На севере висит php скрипт файл сохраняет и выдает в ответ сформированный html код со ссылкой на картинку и маленьким превью.