• avatar igvind
  • 0
Disallow: /*?afid
или
Disallow: /*?afid=af&opt6_select=
  • avatar neils
  • 0
Спасибо за информацию :)
Не поверите, на моих сайтах шаблоны состоят исключительно из вызовов сниппетов БЕЗ ПАРАМЕТРОВ. При этом вызовы сниппетов типо DocLister, evoSearch и т.п. происходят тоже внутри сниппетов. Таким образом, шаблоны получаются лакончиней и в разы читабельней. Нет необходимости глазами выискивать где кавычка открывается, а где закрывается.
[[if? &is=`[[snippet? ¶m=`qwe`]]:=:5` &then=`{{chunkA}}` &else=`[[snippet? ¶m=`b`]]`]]

Нет необходимости думать как же будет работать ваш сайт после очередного рефакторинга от Yama. И еще много плюсов.

Благодаря плагину LoadElement сниппеты и чанки можно хранить в файлах группируя их по каталогам. Соответственно, если в шаблоне есть есть вызов сниппета [[V1\Sidebar\News]] я четко понимаю, что файл этого сниппета лежит в папке V1\Sidebar и называется News.php

Работать с этими файлами очень удобно в Sublime с плагином Sublime SFTP. Попробуйте, это удобнее чем программировать в админке.
  • avatar neils
  • 0
Логично :) Почему-то уважаемый Agel его не посоветовал :)
Хотя в случае <@IF есть подсветка синтаксиса, что удобней.
Так есть же сниппет if, для условий в шаблонах.

[[if? &is=`[*id*]:=:5` &then=`` &else=``]]
[[if? &is=`[*template*]:in:5,6,7,8` &then=`` &else=``]]
[[if? &is=`[+iteration+]:%:4` &then=`` &else=``]]


и т.п. Для простых условий он, для сложных вложенных условий — свой.
  • avatar neils
  • 0
Ясно. Хотя условия в шаблонах — это удобная вещь. Каждый раз создавать новый сниппет не очень удобно :) И, честно говоря, не понятно, зачем резать такой удобный функционал.
Самый примитивный сниппет [!Snippet!] с вашим условием вместо true и вашими asd, qwe чанками
if(true){ $out = $modx->getChunk('asd'); } else { $out = $modx->getChunk('qwe'); } return $out;
  • avatar neils
  • 0
Я извиняюсь, если уберёте <@IF, что нужно использовать?
Да, для апдейта цены по формуле, которую заказчик может сам придумать и плюс ручная корекция отдельных товаров. Решение бомба, обязательно попробую на ближайшем магазине.
может это будет полезным modx.im/blog/4802.html
Переключил тест на парсер 7.1.6 к вот этому коммиту.

Для всех желающих помочь, а заодно и попрактиковаться/поучиться я накидал пример составления теста для одной из примитивных функций DocumentParser::parseText. Смысл этой функции — нерекурсивная замена тегов как можно понять по коду. Итак, ваши действия пошагово:

— Делаем форк (как сделать форк на примере DocLister-а, почитать можно тут)
— В папке tests/DocumentParser создаем файл с названием тестируемого метода + Test на конце. Получаем parseTextTest.php
— Название класса parseTextTest, а namespace соответственно ModxEvo\Tests\DocumentParser
— В методе setUp указываем какой именно метод мы будем тестировать. В данном случае parseTextTest
— Методы классы начинающиеся с test и заканчиваются Success означают, что внутри метода будут описаны тесты которые должны завершиться успешно.
— Придумываем какой-нибудь сценарий тестирования, определяем уникальное имя метода по правилам из предыдущего пункта
— Вызываем тестируемый метод с вашими параметрами и проверяем результат

Так, например, в методе parseTextTest::testArrayParamsSuccess проверяется корректность исполнения следующего кода

//$text = $this->method->invoke($this->modx, '[+text+]', array('text' => 'content'));
$text = $modx->parseText('[+text+]', array('text' => 'content'));

Логично предположить, что $text должно сохраниться content. Что мы и проверяем в тесте
$this->assertEquals('content', $text);


Все предельно просто. Чем глупее тест вы придумаете, тем лучше проекту с точки зрения всестороннего тестирования. Поэтому
* Если вы боялись/стеснялись написать хрень — тут это приветствуется
* Если вдруг вы хотите начать разбираться с phpunit/git/composer/modx api и вам не безразлична судьба modx evolution, то вы просто обязаны помочь с тестированием. Все уже настроено и от вас потребуется всего лишь много копипаста + фантазия
* Если вы считаете, что все тесты уже написаны, то этого просто не может быть. Тестирование даже таких примитивных функций, как getCacheFolder защитит нас от случайного удаления метода в будущих версиях. А так же позволит держать под контролем изменения логики работы движка.

В общем подключайтесь. Ну а те, у кого:
* Нет желания помогать? А с чего вы вообще взяли, что вам тоже кто-то должен будет помогать? Поэтому не удивляйтесь в будущем, если ваши вопросы будут долгое время оставаться без ответов
* Нет навыков помогать? Развивайтесь. Для этого вам и даются стартовые точки где можно безболезненно попробовать себя.
* Нет времени помогать и работаете с MODX? Круто. Видимо у вас намного больше работы чем у меня Dmi3yy , Pathologic и многих других. Мы все с нетерпением ждем от вас доната. Реквизиты мои и Максима — тут. Донаты Диме можно слать от сюда
Что бы ни было написано в чанке inside, мы всегда получим
{{{{inside}}}} // string(4) "{{}}"
По результатам теста видно
[[[+inside+]]] // string(1) "]"
[[[(inside)]]] // string(1) "]"
[[[+inside+] ]] // string(0) ""
[[[(inside)] ]] // string(0) ""

Проверьте, так ли это в предыдущих версиях
— Предлагаю удалить [*pagetitle@2*] и прочие извращения из mergeDocumentContent

— Для всех, кто хочет помочь в тестировании одновременно начав с самообразования — предлагаю подключиться к написанию phpunit тестов. Пока всего 2 теста для тестирования [*pagetitle*] и [*#pagetitle*]. Вы можете по образу и подобию добавить новых тестов (пока для тех, где нет работы с базой данных). Установка проста:

$ git clone https://github.com/AgelxNash/test.modx.evolution.git
$ composer install
$ ./vendor/bin/phpunit
Согласен на 100%, пока пользовался по старинке дитто и еформ, все вроде ничего, но с каждым проектом понимаю, что не хватает возможностей, тяжело было заставить себя начать изучать что-то новое(все хочется быстрее и проще), но все же уделил время и о чудо, как же это круто! Когда наконец-то понял что к чему, дело пошло в гору, прям как открытие новое сделал, и дела пошли быстрее)) Не ленитесь начинайте использовать FormLister, DLbulidMenu, Doclister и т.п.
:D меняй, никому @IF и phx не нужно
Протестил старый и новый парсер по наследованию сниппетов 4 вложенных друг в дружку новый даже коректней отдает тестил [[ [! [! [[ варианты и другие

По части ошибки проблемы с Twig надо разобраться что так но в целом это не влияет на парсер.

По скорости работы разницы не заметил. поэтому в целом настоятельно рекомендую не использовать @IF и phx ) ибо я эти шутки как минимум мной поддерживаться не будут :)
Вот с этим еще нужно разобраться: вернуть на место вызов события и убрать непонятный метод.
  • avatar Chus
  • 0
как вариант, но работать с ним крайне не удобно.
Уже не вспомню, но у меня была, какая-то глупость типа опечатки.