srs

А в чем проблема? Что-то типо:

window.addEventListener('scroll', () => {
      const eventLine = document.getElementById('result');
        if (eventLine[0].top < document.documentElement.clientHeight) {
          // действия
        }
    })

Это не точный код, пишу без проверки синтаксиса. Тут главное, что общая суть ясна. Просто слушаем скрол и проверяем находится ли наш блок в видимой части окна браузера (там толи top элемента, толи bottom, поэкспериментируй сам).

Я бы использовал первый вариант + корзина minishop`а или универсальную корзину. Это в реализации быстрее и надежней, так как позволяет не задумываться над огромным количеством задач (доступность товара, если товаров много то хранилище под них и т.д.)

Позволю себе вклиниться.
1) Скорее всего автор имеет ввиду не дубли «с точки зрения поисковых систем» а дубли с точки зрения modx и тут все гораздо проще.
2) Позволяет, если у них разный алиас, просто создайте два ресурса с pagetitle = modx.pro, но при этом с разными алиасами и все у вас будет отлично.Так-же под похожими подразумевается ===, в вашем примере «Товар 1» !== «Товар 1-1», никакой из них не будет удален.
Хотя возможно я не прав и просто не понял концепцию этого дополнения.

А почему не по alias? Можно ли установить свой критерий?

Пост в разделе «Новые дополнения и их версии»

Да, не обратил внимания. Прошу прощенья.

По заголовку, ожидал хоть немного кода и пояснения того как автор прикручивал nodejs к xparser, но оказалось, что это скорее анонс. В любом случае, новость хорошая.
Пару лет назад, писал парсер на php который должен был собирать данные и создавать/обновлять ресурс. Изначально нужно было парсить чуть меньше 500 позиций. Затем требования увеличились до 1,5-2к, через пару месяцев 5-7к. Соответственно время парсинга увеличилось в разы. Клиенты компании на которую я работаю, утверждали, что ваш modx говно, решение тоже говно, и мол на битриксе есть готовое решение которое делает это за 20-30 минут. В начале я думал, что просто я не компетентен и упускаю какую-то очень важную деталь, но все оказалось куда проще. Клиенты наглые врунишки!
В итоге тоже пришлось родить монстра на nodejs+php. На текущий день нода обрабатывает порядка от 60к до 80к позиций от разных источников. Начиная от парсинга xml фидов, до работ с api сторонних сервисов. Нода отрабатывает все это дело от 8 до 20 минут (там есть еще пару факторов). В итоге получаем файлик с позициями которые нужно создать/обновить/удалить, этот файлик отрабатывает php, примерно от 10 до 80 минут. Такая разница возникает из-за того, что количество обновляемых/создаваемых ресурсов всегда разная, это может быть как 1к так и 10-15к. Но в среднем 3-3,5к на создание/обновление и 800-1500 позиций на удаление. Вот такая вот кулсторибоб)

Если требуется сделать все заголовки h1, то хорошо, если нет, то нет… Проблем не вижу. Мы с вами по разному понимаем обязанности контент менеджера. Я считаю что html/css и тем более знание шаблонизаторов, точно не является приоритетным и важным знанием. А отличить заголовок h1 от h2-h3 можно визуально. Просто говоришь, что самый большой заголовок должен быть только 1-2-3-n раз и все.
Контент менеджер должен хорошо писать тексты и наполнять карточки товара. Я намеренно не стал продолжать диалог, так как реплика «В суровой реальности так не работает.», является частично ложной. У кого-то в реальности так не работает, а у меня именно так и работает (работало… я сейчас занимаюсь немного другим).

я бы еще добавил что-то вроде:

if($modx->resource->content_type != 3) { // или 3 или 2, тут надо проверять
    $output = preg_replace('|\s+|', ' ', $output);
}

Чтоб не минифицировать докуметы формата txt, по типу robots.txt.

Нет! Просто мне последняя часть данного поста показалось немного лишней. Но вы художник — вам видней.

Вы конечно большой молодец, спору нет.

Я задаю вопрос сюда, потому что вот есть тема где магазин отвечает на такой же вопрос

Ну вот, да. В этой теме отвечаю на этот вопрос, магазин без проблем предлагает вернуть деньги. Вы наверняка все комментарии там прочитали, просто решили лишний раз «уколоть» магазин или разработчика. Ну да ладно -) у каждого свои тараканы в голове.

Еще как вариант, можно писать их а алиас.

Я конечно не автор дополнения но думаю это является ответом:

этот компонент не про это. он заточен под юзеров

А как правильно тогда?

Там должны быть все отправленные сообщения которые проходят через хук.

Я минуснул за то, что его сообщение вообще не в тему топика (на мой взгляд). Плюс
каждое второе сообщение на modx.pro от Павла, это сообщение в сторону октября. Ну серьезно, это даже не смешно. Давайте теперь каждый из нас будет постоянно говорить о наиболее импонируемых CMS. Почему нет?!
P.S. Называя людей никчемными за минус в интернете, вы подписываетесь в собственной никчемности. На это предлагаю закончить, так как топик совсем о другом.

fred

Для интереса можно посмотреть как подобное проходило с WP. В начале один энтузиаст собрал компонент реализующий JSON-API для WP, за несколько лет это решение получило популярность и было впилино в ядро. Если вообще никто не хочет предпринимать, то я мог бы попробовать начать, но боюсь, что у меня нет достаточной компетенции и знаний. Так что Сергей, либо это сделаете вы! Либо я! Но предупреждаю, я это буду делать долго и плохо!
P.S. Да это угроза-).

Понимание wysiwyg это очевидно, но блин понимание знать html, css и базовое знания шаблонизаторов. Может это тогда не контент менеджер а начинающий фронтендер. Всегда думал, что контент менеджер это прежде всего маркетолог.

Отдельных полей не напасешься

А в чем сложность отдельных полей? Один раз сделал как надо и забыл. Я очень сомневаюсь, что вам надо на одном и том-же сайте в админке создавать дополнительные поля (это прям совсем абсурдный пример). Как правило вовремя тестового запуска такие проблемы выявляться и решаются.

Не согласен. На мой взгляд контент менеджер не обязан знать html,css. Его задача грамотно наполнить необходимые позиции, все остальное должны предусмотреть мы с вами. Во первых это наиболее верный и «красивый» подход. Во вторых, если вдруг будет текучка менеджеров, то не нужно будет тратить время, на объяснения подобных «хаков». Для себя — пожалуйста. Использовать на работе, такая себе идея. Но да ладно, возможно тут

Дело хозяйское

*дополнение — modx + elasticsearch
Но опять же, стоит задуматься нужно ли это делать на modx если у вас:

1. 800к+ позиций
2. у них по 100+ различных свойств
3. должен нормально работать на 100к посещений в сутки

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