+391.30
Рейтинг

Борисов Евгений

Спасибо
Линейное меню проще формировать через DocLister
Помощи пока никакой ни в каком направлении. Чтож, зайдем с другой стороны через краудфайндинг funding.webmoney.ru/pokrytie-unit-testami-modx-evolution
Не поверите, на моих сайтах шаблоны состоят исключительно из вызовов сниппетов БЕЗ ПАРАМЕТРОВ. При этом вызовы сниппетов типо 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. Попробуйте, это удобнее чем программировать в админке.
Самый примитивный сниппет [!Snippet!] с вашим условием вместо true и вашими asd, qwe чанками
if(true){ $out = $modx->getChunk('asd'); } else { $out = $modx->getChunk('qwe'); } return $out;
Переключил тест на парсер 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
— Если честно, я вообще не понимаю всей магии происходящего тут. Смахивает на какой-то жуткий костыль.
— И простите, почему префикс таблицы указывается как [+prefix+], а не как getFullTableName? Почему эта хрень еще тут и активно пропихивается в ядро как вроде бы нормальное поведение? А ничего, что при таком подходе идет лесом подключение к 2 базам с разными префиксами (потому, как всегда используется один префикс основной базы)
— А почему тут лишь в 1 месте $_REQUEST['password'], а в других $givenPassword? Если так и должно быть, то проблема видимо где-то внутри login* функций. Передаваемые данные должны быть идентичны по логике. И это мы фиксим в рамках фикса
— А получение расширения файла. Благо читал чужой код и нашел у себя ошибку

Такое чувство, что никто не просматривает коммиты других. Прислал — молодец. Кривой? Пофигу, багрепорт пришлют. Главное у меня сейчас работает. И это опасно господа. Я боюсь такой код ставить к себе на сайты.
А вообще:
— давно бы уже причесали код при помощи phpdoc, хотя бы в основном классе DocumentParser
— Обернули все функции в function_exists
— Привели к единому виду работу с массивом настроек $modx->config (чтобы настройки получались через метод, а не из массива)
— Продумали бы куда положить composer.json, чтобы народ начинал знакомиться хоть что-это и с чем едят

Столько времени прошло, а топчемся вокруг японской сборки и перекрашиванием кнопочек. Не в обиду, но по сути, в последнее время это ключевой фактор из-за которого я отдалился от Evo.

Ветка официально брошена. Доступы к репозиторию розданы людям у которых кардинально отличаются подходы в разработке. Добавим сюда языковой барьер, отсутствие четкого плана в какой версии будет закрыта та или иная задача. На выходе получаем релизы версий сомнительного качества.

Вот скажите мне, пожалуйста, что нас держит в официальном репозитории, если мы не одобряем их подход, а они наш? Название MODX? Поднимите вопрос — создайте ветки EvoJP, EvoRU или EvoUA. Я думаю никто против не будет. А если будут — ну и чихать на них. MODX Evo Dmi3yy и погнали. Сколько вы дополнений видели от японцев за последние 2 года? А сколько новых багов их рефакторинги добавили? Зато с новым парсером вы можете писать вот так:
[[#MySnippet?name=[*pagetitle@1*]]]

Вы меня простите, а вам что, DocInfo не хватало? У вас рук нет создать сниппет MySnippet в котором вы вызовете нужную функцию? Добавьте сюда phx и попробуйте сообразить — как из следующих конструкций возьмет заголовок страницы с ID = 1, потом посчитает сколько в нем символов и пропустит через MySnippet где MySnippet это какая-то функция…

[[#MySnippet?name=[*pagetitle@1*]:length]]
[[#MySnippet?name=[*pagetitle@1:length*]]]

Верните прежний парсер — простой и понятный без этих свистоперделок. С текущим парсером проще действительно на Revo переключиться, чем продолжать велосипедить. Те, кто программировать не умеет, с phx и гав-операторами тем более не научится.
$modx->db2 = new DBAPI('localhost', 'db2', 'login2', 'password2', 'modx_', 'utf8', 'SET CHARACTER SET');
Когда же вы уже начитиесь писать емкие скрипты под CLI, а не извращаться с ajax
Элегантное решение которое может пригодится не только для modx evo. Спасибо.
Несколько раз подобное делал. Тут и тут
return $modx->runSnippet('DocLister', array(
        'idType' => 'parents',
        'orderBy' => 'menuindex ASC',
        'addWhereList' => 'c.hidemenu = 0',
        'prepare' => function($data, $modx, $_DL, $_eDL){
                //Так
                $_DL->renderTPL = '@RENDERPAGE: '.$data['id'];
                //Ну или так
                $_DL->renderTPL = '@CODE: '.DLTemplate::getInstance($modx)->renderDoc($data['id'], true);
                return $data;
        }
));


Если не нравится идея подмены шаблона, то всегда можно получить коллекцию документов и там ее отрендерить. В итоге тот же самый сниппет без всяких костылей с подменой шаблона принимает вид
$modx->runSnippet('DocLister', array(
        'idType' => 'parents',
        'orderBy' => 'menuindex ASC',
        'addWhereList' => 'c.hidemenu = 0',
        'saveDLObject' => '_DL'
));
return $modx->getPlaceholder('_DL')->docsCollection()->reduce(function($out, $data) use ($_DL, $modx){
        $tpl = DLTemplate::getInstance($modx);
    return $out.$tpl->renderDoc($data['id'], true);
});

Правда понять суть происходящего сложно без детального изучения DL.
ЧтоаААА?
&filter=`tvtypeApartment,@EVAL return $_POST['typeApartment'];,8|tvbedroom,@EVAL return $_POST['bedroom'];,1|tvprice,@EVAL return $_POST['price'];,4|tvprice,@EVAL return $_POST['priceOt'];,3|tvsquare,@EVAL return $_POST['squareOt'];,3|tvsquare,@EVAL return $_POST['square'];,4`

Возможно это и работает, но так делать нельзя.
[+dl.debug+] после вызова сниппета вставьте
В режиме API вместо точки используется нижнее подчеркивание. [+tv_h1+]