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

Добрый день!
А что на мобильном не так работает? Можете описать? какой телефон/браузер?
Пагинация через pdoPage.

Ну а сохраненная копия в кеше гугла страниц этих есть? Что там?

Прошу прощения… напутал.
Есть

<form action="" method="post" id="mse2_filters">

а есть

<div id="mse2_mfilter">

Вот первый да, форма, а второй обертка для всех фильтров.
Я, чтобы разнести фильтры в разные части страницы, второй id прописывал едва ли не для body, все получалось.

Не совсем так.
Обернуть действительно нужно в элемент с

id="mse2_filters"

, но это должен быть элемент div, а не form.
Сейчас у вас вся страница стара огромной формой, все hidden инпуты туда попали, перестали работать вложенные формы.

См. js ошибки в консоли браузера.

Вместо

{$_modx->getPlaceholder('my_filters')}

вам нужно сделать foreach по $filters и выводить каждый фильтр отдельно.
Тогда вы можете проверку сделать:

{foreach $filters as $filter}
{if $filter != 'вендор'}
{$_modx->getPlaceholder('фильтр')}
{/if}
{/foreach}

Не знаю, в точности все повторил, все ок:

Вроде как нет.
У меня есть сайт, где раздел «Доска объявлений» года с 2016 создан, периодически допиливаю. реализация на Tickets + сделан отдельный интерфейс, более удобный.
Но нюансов куча.
Во-первых, все эти тикеты дико мешаются на сайте. Объявления далеко не основная функция сайта. Я бы реально их лучше в отдельную таблицу вынес.
Во-вторых, сейчас пришли к вопросу платных объявлений, к поднятию и закреплению их, тоже не понятно, как все это реализовывать. И это при том, что уже огромное кол-во функционала было реализовано.
В-третьих, все чаще появляется проблема откровенного спама со стороны публикующих объявления. Они их создают сотни, с разных аккаунтов, немного меняя заголовки. Приходится много просматривать вручную, следить по IP и т.д. В общем автоматического контроля за этим никакого нет, все в ручную.

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

RewriteRule ^([0-9]+)_related_articles.json$ related_articles?article=$1

Сайт для проверки: htaccess.madewithlove.be/

Тысяча причин:
1. Товары не опубликованы
2. Неверный шаблон у товаров
3. Не все поля заполнены так, как это подразумевал разработчик
4. Отображается ограниченное кол-во товаров, ваши выходят за это кол-во

Ну через htaccess (или nginx) сделайте правило:
/1234_related_articles.json => /related_articles?artice=1234
А на этой странице работаем с get параметром

Maybe the “payment link” in the letter to the buyer is suitable?

github.com/bezumkin/miniShop2/blob/master/core/components/minishop2/elements/chunks/chunk.ms_email_new_user.tpl#L9

Тогда почему бы и нет)

На alpha версии? Я бы делал только если это «свой» сайт, не как продукт за деньги.

{foreach $data as $row}
    {if $row.active}
        {$row.value}
    {/if}
{/foreach}

Ну целиком я бы переопределять не стал…
Вдруг кто-то еще переопределяет метод? Хотя по идее это довольно базовый метод, менять в нем нечего процессорам.

В том, чтобы сделать так:

public function run() {
    if (!$this->checkPermissions()) {
        $o = $this->failure($this->modx->lexicon('permission_denied'));
        return new modProcessorResponse($this->modx,$o);
     }
    return base::run():
}

я вижу один минус… это двойной вызов checkPermissions().
Но, честно говоря, идей лучше у меня нет.

Судя по всему или полностью переопределить метод run() или сделать свой run, где сначала сделать checkPermissions, если что вернуть свое сообщение, а затем вызвать base::run.

В общем выяснили, что проблема была в настройках политик доступа, был закрыт доступ ко всей категории easyComm.

В сниппете ecThreadRating нет ни одной проверки на права… нет вызова процессоров…
Все что там есть, так это получение объекта цепочки из базы:

$thread = $modx->getObject('ecThread', array('name' => $thread));

Потому как ошибки на сайте не связаны с привязкой дополнений.