Максим Кузнецов

Максим Кузнецов

С нами с 01 июля 2013; Место в рейтинге пользователей: #27
Максим Кузнецов
30 марта 2017, 23:55
0
Т.е. даже при минимальном вызове и вышеописанной конструкции кнопка не появляется?

Хорошо, давайте подойдем с другой стороны — jQuery на сайте подключен?
Максим Кузнецов
30 марта 2017, 23:43
0
Есть ли вероятность того, что у вас в контейнере с id=6 просто дочерних ресурсов не более 3х?)

В противном случае, попробуйте начать с минимального вызова, последовательно дополняя его вашими параметрами:
<div id="pdopage">
    [[!+page.nav]]
    <div class="rows">
        [[!pdoPage?
            &parents=`6`
            &ajaxMode=`button`
            &limit=`3`
        ]]
    </div>
</div>

Ну и версию pdoTools можно проверить, на случай, если загружена устаревшая версия.
Максим Кузнецов
30 марта 2017, 23:33
0
&ajaxTplMore="@INLINE [[%pdopage_more]]"
— а это вам зачем?
[[%pdopage_more]] вернет только лексикон надписи в кнопке, но не саму кнопку.

Выставите для &ajaxTplMore дефолтное значение, или вообще избавьтесь от этого параметра.
Максим Кузнецов
30 марта 2017, 23:15
0
По документации вроде как кнопку самому вставлять не нужно — ее сгенерирует ajaxMode=`button`
Максим Кузнецов
30 марта 2017, 11:12
0
… или вы перенесли чанки из assets в core и они перестали быть доступы?

Скорее всего, где-то проблема с путями. В любом случае рабочая последовательность такая:
1. Создаете папку elements в core
2. В системной настройке pdotools_elements_path указываете {core_path}elements/
3. Переносите/создаете внутри директории необходимые чанки. Допустим, создадим внутри elements директорию chunks и внутри нее файл item.tpl
4. Прописываете в сниппетах путь в таком виде:
// core/elements не нужен
'tpl' => '@FILE chunks/item.tpl'
5. Чистите кэш

После этих шагов, файловые чанки должны корректно перевариваться сниппетами pdo.
Максим Кузнецов
29 марта 2017, 19:13
0
Приложите вызов сниппета корзины (его нужно вызывать некэшированным):
[[!msCart]]
Максим Кузнецов
29 марта 2017, 19:03
+1
Мм… а в чем конкретно вопрос? Запросы делаются примерно также, как вы и описали.

$query = $modx->newQuery('modDocument');
$query->where(array(
	'class_key' => 'msProduct',
	'price:>' => 100
));
$results = $modx->getCollection('modDocumen', $query);

Если вопрос в том, как в таких запросах фильтровать по tv-полям, то вначале их необходимо приджоинить к запросу.

docs.modx.com/xpdo/2.x/class-reference/xpdoquery/xpdoquery.where
Максим Кузнецов
29 марта 2017, 18:51
+2
Для реализации страницы «профиля» у вас есть 2 варианта:

1. При помощи собственной маршрутизации реализовать виртуальную страницу пользователя вида
/users/имя_пользователя, после чего в плагине на событие OnPageNotFound перехватывать имя пользователя и при совпадении с реальным пользователем — выводить информацию.
Таким способом реализованы страницы пользователей на этом сайте.

2. Плагином на событие OnUserActivate создавать полноценную страницу для пользователя, а на OnUserSave — синхронизировать данные.

В обоих случаях в чанке pdoUsers нужно будет сымитировать итоговую ссылку:
href="[[~2]]/[[+username}]]"
— где 2 = страница-контейнер для пользователей (users).
Максим Кузнецов
28 марта 2017, 19:10
+1
Это вставить где-нибудь внизу страницы в
<script type="text/javascript">
	//сюда
</script>
(после подключенного jQuery)
Максим Кузнецов
28 марта 2017, 19:02
0
Ну, видимо вы не указали для документа значение publishedon.
Что же до createdon, скорее всего, формула :strtotime:date=`%d.%m.%Y` для него сработает.
Максим Кузнецов
28 марта 2017, 18:57
+1
Потому что встроенный модификатор MODX'a преобразует дату из unix timestamp в выбранный формат, а в fenom'e во входящее значение принимаются как unix timestamp, так и форматы дат.

Посмотрите, что выдает [[+publishedon]] без модификаторов — скорее всего, у вас он по умолчанию возвращает дату, которую впоследствии не может переварить :date=``.
Максим Кузнецов
28 марта 2017, 17:39
+2
Вы можете воспользоваться сниппетом dateAgo для кастомизации даты.

Или таким образом через fenom:
{$createdon | date_format: '%d.%m.%Y'}
Максим Кузнецов
28 марта 2017, 17:38
0
Насколько я помню, внутри дочерних ресурсов коллекции не получится нормально хранить внуков.

Возможно, можно попробовать упростить структуру, вынеся часть переменных в тв-поля (города, категории), но в таком случае иерархия будет менее разграничена и свалена в кучу.
Максим Кузнецов
28 марта 2017, 17:10
0
Из коробки — да. Но тут уже или/или.
Максим Кузнецов
28 марта 2017, 16:59
0
Мне, честно говоря, кажется, что в таком случае вообще лучше пользоваться своей таблицей, а не плодить тысячи ресурсов. И в ней уже реализовать наиболее удобные связи.
А маршрутизацию и доступность по тому или иному URL'y реализовать через свою маршрутизацию из ссылки выше.
Максим Кузнецов
28 марта 2017, 16:51
0
Потому что tplInner и tplOuter — это обертки пунктов меню, у которых нет своих тв-параметром и вообще каких-либо переменных, кроме $wrapper.
Переменные $link, $cat_icon и прочие будут доступны в tpl, tplInnerRow и тд.
Максим Кузнецов
28 марта 2017, 16:50
0
Лучше воспользоваться кастомной маршрутизацией на событие OnPageNotFound, в которой при соответствии ссылки определенному шаблону (site.ru/город_из_списка/рубрика).

C другой стороны, все упирается в то, насколько сильно отличается контент/заголовки внутренних страниц между собой — возможно, что создать руками в итоге окажется самым корректным решением.