Артур

$resource=$modx->getObject ('modResource', array('pagetitle'=>$media['title'], 'parent' => 2));
Индексируется страница, а на странице можно вывести например longtitle.

Там где получаете ресурс в массив добавьте ещё один элемент с ключом parent вот и будет вам ограничение по родителю. А про tv умоляю вас, забудьте, они не для этого, для программной работы с ресурсами используйте поля описанные в модели их обычно хватает, а tv это для дополнительной информации когда прям без вариантов. В вашем случае лучше писать уникальный id в pagetitle.

А где проверка? Удалили? Или и не добавляли?

$userMedia откуда берётся?

Да не нужно вам это TV, выше уже написал почему))
Вот весь код который нужен

foreach($usersMedia['data'] as $media){

$resource=$modx->getObject ('modResource', array('pagetitle'=>$media['title']));
if(!$resource){

//Создаём новый ресурс
    $rss = $modx->newObject('modResource');
    $rss->set('template', 2);                     // Назначаем ему нужный шаблон
    $rss->set('isfolder', 1);                         // Указываем, что это не контейнер   
    $rss->set('published', 1);                      // Неопубликован
    $rss->set('createdon', time());              // Время создания
    $rss->set('pagetitle', $media['title']);               // Заголовок
    $rss->set('content', $media['caption']);               // Контент
    $rss->set('alias', strtolower($media['username'].'-'.$media['id']));    // Псевдоним
    $rss->set('parent', 2);                 // Родительский ресурс
    $rss->save(); 
////

}
}

Какой второй цикл, его там быть не должно. Надо перебрать только $userMedia['data']

Пришлите целиком код сниппета

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

Так вот, для чего вы получали $docs. Это конечно ваш код, но на мой делетантский взгляд, такой подход нерационален. Вам нужно создать TV, в цикле его получать, преобразовывать в массив, проверять есть ли в массиве текущий id, если нет, то создавать ресурс и добавлять новый id в массив, массив преобразовывать а строку, строку записывать в tv и сохранять изменения. Вам не кажется что это избыточный путь?

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

Вообще-то должно работать. Проверьте что находится в $media['title'] и в $resource->get('pagetitle'), может там пробелы какие или спецсимволы или ещё что-то и значения не совпадают. Я в коде ошибки не вижу, а то что проверка должна работать это факт.

Насколько мне известно, платных компонентов которые решают эту проблему нет. Поэтому вариантов у вас немного
1. Ждать что-то кто-то, напишет решение, а оно будет сложным для неподготовленного человека, т.к. нужно будет кастомизировать админку, а это непросто, как по мне.
2. Написать своё дополнение.
3. Сделать этот функционал как отдельную страницу на фронте доступную только админу.

Если у вас будет повторяться pagetitle, то modx будет ругаться, оно вам надо? Думаю, нет. А проверить элементарно. Если я правильно понял, $usersMedia['data'] содержит массив полей, из которых вы создаёте ресурс, значит надо в цикле делать прямой запрос в БД через newQuery, где в условии ставить pagetitle=$usersMedia['data'][поле которое помещается в заголовок ресурса]. Если запрос вернёт хотя бы одно значение значит, такой ресурс уже есть и надо его либо обновить, либо пропустить и продолжить выполнение цикла. Как сделать запрос в БД подскажет Гугл ключевые слова modx xpdo sql. Ну а дальше уже всё как сейчас. Либо можно поступить проще, но если ресурсов много, то это может быть неоптимальным решением с точки зрения потребления ресурсов, просто попытаться получить объект

$resource=$modx->getObject ('modResource', array('pagetitle'=>$usersMedia['data']['fieldname']));
if(!$resource){
//Создаём новый ресурс
}
<code>

Думаю это лишнее, в конце концов, тут не курсы по программированию, а форум. Но если @Павел Бигель расскажет подробнее в чём плюсы его варианта, то это будет здорово. Пока я вижу только один — не нужно ничего изобретать, можно использовать как есть.

Так $idpost содержит всего одно значение и это всегда значение предыдущей страницы, т.е. вероятность того, что у вас подряд идут два одинаковых id крайне мала. Далее, зачем вообще вам idpost, если гораздо логичнее перед добавлением нового ресурса проверять есть ли ресурс с таким pagetitle и если есть, то не добавлять? И getCollection лучше заменить на getIterator так как вам все объекты разом не нужны. И ещё, чистить кеш всего сайта в цикле не кажется мне хорошей идеей.

Господа, не ссортесь, право слово программирование штука гибкая и у задачи может быть много решений, в какой-то ситуации лучше одно решение, в какой-то другое. getCollection кушает много памяти это факт, но если ресурсов немного, то данное обстоятельство некритично. Хотя я склоняюсь на сторону Артёма использование процессора сложновато и плохо вписывается в понятие «по-быстрому», я сам новичок и писал для новичков, Артём подсказал, где поправить, чтобы было быстрее и безопаснее получился, на мой взгляд вполне простой и понятный код, неуниверсальный конечно, но такая задача и не ставилась.

Таки согласен, см. в-третьих. Постараюсь написать и такой вариант. Хотя я тот ещё любитель ООП))

А ошибки в консоли браузера есть?

Во-первых, мне лично не очень понятно как и что я могу передать в этот процессор и что он мне вернёт, где можно почитать как с ним работать?
Во-вторых, зачем мне поиск по TV, чанкам, сниппетам и пользователям, это избыточный функционал для моей задачи.
В-третьих, я не учел что такой процессор существует.
В-четвёртых, для саморазвития полезно изобрести велосипед другой, в конце концов я никого на нём ездить не заставляю:-)

Валидатор у вас странный. Он данные берёт из базы, а должен с фронта. Я бы проверял $_FILES на количество файлов.