Артем

Справедливости ради, я бы поспорил про join.
IN — еще большее зло, если в нем указана целая простыня (тысячи или десятки тысяч) id.
Вот ради интереса копипастнул себе на один из проектов оба варианта и, как я и ожидал, второй существенно быстрее.
На проекте 29705 товаров.
Ну и я заменил getCollection на getCount, потому что получать 30к объектов — самоубийство, даже через более оптимальный getIterator.

Вариант с IN:

Total time: 0.7136 s

Вариант с join:

Total time: 0.4630 s

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

Дико извиняюсь, не удержался

$where['o.makedate:>='] = '".$_GET['date1']." 00:00:00'";
$where['Detail.sk_order_id']=$.get.sk_order_id

$object->get('image');

Для получения остальных картинок нужно вытянуть массив объектов через $object->getMany('Files')
Либо через xPDO, если нужно сделать только выборку и объекты не требуются.

if ($product = $modx->getObject(msProduct::class, ['id' => 123, 'class_key' => msProduct::class])) {
    foreach ($product->getMany('Files') as $file) {
        $file->remove();
    }
}

вместо 123 нужно указать id нужного товара

Я выше вполне себе ясно написал, где оно хранится.

Значение по умолчанию придумано не для выборок по нему, а для удобства в админке, о чем говорит название поля в таблице тв — default_text

Очевидно, что здесь идет речь о том, что оно не добавляется в modTemplateVarResource.

ну так все правильно, значения у этих тв не менялись, что выводить-то?

еще раз, значение по умолчанию сделано не для выборки по нему, оно не добавляется в базу, наоборот, если установлено такое значение, то оно удаляется из базы, потому что оно «по умолчанию».

из этого следует, что если вы ставите значение по умолчанию 1, то оно никогда не попадет в бд
следовательно, если значения в бд нет, то значит оно = 1, если есть, то 0

Конечно, значения по умолчанию в БД не будет, откуда ему там взяться?
Представьте, что у вас 50000 ресурсов и вы добавили значение по умолчанию, не будут же они проставляться для 50000 ресурсов, логично?

Значение по умолчанию придумано не для выборок по нему, а для удобства в админке, о чем говорит название поля в таблице тв — default_text

Делайте исключающую выборку через :!=

Да, есть вариант делать unique по двум и более колонкам.
Лично я не вижу необходимости в этой схеме наследоваться от xPDOSimpleObject.
Используйте xPDOObject, указывайте эти 2 поля как primary & unique, добавив такой индекс

<index alias="PRIMARY" name="PRIMARY" primary="true" unique="true" type="BTREE">
        <column key="order_id" length="" collation="A" null="false" />
        <column key="field_id" length="" collation="A" null="false" />
</index>

Обновил ответ, изначально немного не так понял ваше сообщение.

Так а где в вашей таблице указано, что это primary/unique поля? Конкретно с вашей схемой в таблице может содержаться хоть 20 записей с одинаковыми значениями order_id и field_id. Добавьте индекс для этих полей, указав там, что это primary & unique (в случае с xPDOObject) или просто unique (в случае xPDOSimpleObject).

Все правильно, уже имеющиеся данные сборщиком не удаляются, это нужно делать самостоятельно. Для удаления сущностей я написал такой метод:

/**
 * Remove objects
 */
protected function remove()
{
    /** @noinspection PhpIncludeInspection */
    $removed = include($this->config['elements'] . 'remove.php');
    if (!is_array($removed)) {
        $this->modx->log(modX::LOG_LEVEL_ERROR, 'Invalid structure detected on \'Remove\' source');

        return;
    }

    $count = 0;
    foreach ($removed as $className => $conditions) {
        /** @var xPDOIterator $objects */
        if ($objects = $this->modx->getIterator($className, $conditions)) {
            /** @var xPDOObject $object */
            foreach ($objects as $object) {
                $count += (int) $object->remove();
            }
        }
    }
    $this->modx->log(modX::LOG_LEVEL_INFO, $count . ' items have been removed');
}

Соответственно, в папку elements добавляется новый файлик — remove.php, где указываются класс сущности в качестве ключа и условия в качестве значения.

return [
    'modResource' => ['id' => 1],
    'modTemplate' => ['id' => 1],
];

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

Для удаления файлов обычно хватает синхронизации в IDE, которая показывает расхождения между удаленным и локальным серверами.

$pdoTools = $modx->getService('pdoTools');
return $pdoTools->getChunk($tpl, $properties);

вместо обычного

$modx->getChunk()

{foreach $rows as $row}
    {$row@index + 1}
{/foreach}

или

{foreach $rows as $row index=$index}
    {$index + 1}
{/foreach}

Ответ касаемо modAccess гуглится буквально за 30 секунд:
opengeek Reply #2, 7 years, 1 month ago
It's a known bug and is harmless. modAccess is an abstract class which all the modAccess tables use and it does not have a table itself.

Остальное — не ошибки, а уведомление о том, что объект удален, о чем говорит константа LOG_LEVEL_INFO.

foreach ($modx->getIterator(modResource::class, ['parent' => 20]) as $object) {
    if (($parent = $object->getTVValue('parent')) && is_numeric($parent)) {
        $object->set('parent', $parent);
        $object->save();
    }
}

на минуточку, в тв всегда хранится строка, поэтому проверять на is_int чуть более, чем бесполезно.

$categoryOption = $modx->newObject('msCategoryOption');
$categoryOption->fromArray([
    'option_id' => 1,
    'category_id' => 2,
    'active' => true,
], '', true, true);
$categoryOption->save();

вместо 1 и 2, понятное дело, нужно указать нужные id опции и категории