Евгений Шеронов

Евгений Шеронов

С нами с 20 мая 2015; Место в рейтинге пользователей: #38
Евгений Шеронов
13 апреля 2021, 13:35
+1
Авторы могут и не заметить здесь и не знать о запрашиваемых интеграциях)
И в поддержке ни разу про такое никто не спрашивал.

Ну такая интеграция скорее всего потребует дополнительных расходов)

Вообще не помешала бы возможность подключать уведомления об интересующих компонентах, которые всё равно привязываются к топику при их упоминании.
Евгений Шеронов
04 апреля 2021, 13:31
0
А предпросмотр XML работал?
Напишите мне в поддержку с указанием доступов.
По скриншоту тяжело что-то сказать.
Евгений Шеронов
19 марта 2021, 12:28
0
Именно Vuetify 2, иначе бы ещё на несколько месяцев затянул))
Там в целом компоненты очень похожи на Ext JS, разве что гибче. Иконки все используются из MODX стилей.

В первом варианте этой статьи было слишком много технических подробностей, перенёс их в черновик.
Видимо, нужно как нибудь дописать)
Евгений Шеронов
18 марта 2021, 14:02
+4
Я тебе ещё в прошлом году присылал пример встраивания Vue.js в админку))
И вот только сейчас всё это выглядит как полноценный компонент.

Вообще разрабатывать гораздо приятнее и удобнее. Тот же hot-reload, обновляющий на странице только изменившуюся часть DOM, реактивность, роутинг, хранилище, прям хочется ещё что-то сделать)
Но всё равно, полноценный компонент слишком долго делать :(

Если сильно захотеть текущий компонент легко перенести из админки на фронт или вообще заюзать в другой CMS, так как старался абстрагироваться от MODX сущностей (не получилось).
Евгений Шеронов
02 ноября 2020, 15:05
0
Здравствуйте, Вы вроде уже писали мне?

Здесь только через prepareSnippet сможете сделать замену нужных Вам тегов.

Также, если есть какие-то теги или стили у html-тегов, то их нужно подчистить.
Для этого должен быть установлен Jevix.

Вот пример сниппета prepareMarketDescription, который сделает то, что нужно.
Добавьте его и укажите название в настройку ms2ym_prepare_snippet.

<?php
if(!empty($fields['description'])) {
    //масссив для замен 
    $replaces = [
        '[[*pagetitle]]' => $product['pagetitle'],
        '[[+article]]'   => $product['article']
    ];
    
    // все доступные поля можно посмотреть в логе расскоментировав две строки ниже:
    // $modx->log(1,'Поля в XML: '.print_r($fields,1));
    // $modx->log(1,'Поля товара: '.print_r($product,1));
    
    $fields['description'] = $modx->runSnippet('Jevix',[
        'input'=> str_replace(array_keys($replaces), array_values($replaces), $fields['description']),
        'cfgAllowTags'=>'h3,ul,ol,li,p,br',
        'cfgSetAutoLinkMode'=>0,
        'cfgAllowTagParams'=>'{}',
        'cfgSetTagNoAutoBr' => 'ul,ol',
        'cfgSetTagChilds' => '[["ul",["li"],false,true],["ol",["li"],false,true]]',
        'cfgSetTagParamDefault' => '[]',
        'cfgSetTagParamsRequired' => '{}',
        'cfgSetTagNoTypography' => '',
        'cfgSetTagPreformatted' => '',
        'cfgSetTagShort' => 'br'
    ]);
}

return $fields;
Евгений Шеронов
04 июня 2020, 03:29
+2
Вот я тоже задавался вопросом «а зачем?».

Судя по github экономией тут не пахнет)
В результате пары недель ...
Стоимость пары недель любого разработчика — это годы для хостинга c MySQL)

Мало того, что схему нужно добавлять, так ещё в дополнениях бывают подготовленные запросы не через XPDO, и вполне может быть отличный синтаксис запросов. Так что и код править может придётся.
По мне такой путь точно в никуда.

Я бы ещё понял использование SQLite на сайте для какого-то внутреннего локального использования, где будет только 1 человек пользоваться сайтом.

Вот например, поддержка PostgreSQL принесла бы больше пользы. Но здесь будет проблема в том, что shared-хостингов с постгресом сильно меньше, следовательно поставить не у каждого получится.
Ну и некоторые решения могли бы сильно от БД зависеть, например от типов данных.

Так что сейчас даже хорошо, что в MODX все используют MySQL, всё легко перенести, не нужно вникать в другие БД, где их искать, как подключаться и т.д.

Хотя и с MySQL то можно много улучшать, добавлять поддержку новых типов, массивы, JSON.
Но под это дело простые шаред хостинги уже не успевают обновлять MySQL, но это уже другая тема)
Евгений Шеронов
18 мая 2020, 12:14
0
Действительно, а я подумал, что все файлы имеют такой же вид, как в статье описан пример конфига.

Ну теперь это очевидно для всех, что в тех файлах настроек должен быть return, чтобы способ сработал.
Но даже если там будут переменные, они также включатся в эту область.
Евгений Шеронов
18 мая 2020, 11:52
0
Только так работать не должно, потому что require возвращает true или падает с ошибкой.

А переменные, определённые в файле становятся доступны в текущей области действия.
Если же массив с настройками там называется $config_options, то получать его лучше так:
//...
require $file;
if (isset($config_options) && is_array($config_options)) {
    $modx->config = array_merge($modx->config, $config_options);
}
//...
Евгений Шеронов
11 мая 2020, 20:43
1
0
Я не специально проигнорировал сообщение. Но ответить лучше поздно, чем никогда)

По сути это делается через sfMenu просто с указанием параметров &parents=`[[*id]]` и &mincount=`1`.
Там ещё можно учитывать относительность через параметр &relative=`1` (тогда ссылки будут каждый раз уходить в глубину от выбранного параметра, если такие правила есть).

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

А как сделать фильтры для mSearch2 особо разницы нет, хоть ТВ поля, хоть опции, хоть через Tagger.
Евгений Шеронов
21 апреля 2020, 16:59
0
Для разработки прям то что надо.

А как себя ведёт БД в докере на production?
Пока только видел, что так совсем не стоит делать по ряду причин.
И в этом случае, если контейнер Docker с БД упадёт, то все данные до последнего сохранённого дампа тоже пропадут?
Евгений Шеронов
11 февраля 2020, 11:03
1
0
Условия в полях немного по другому работают, они вообще больше созданы для условий, когда значения из сторонних таблиц.
По идее эти условия срабатывают при сохранении поля, а при сохранении ресурса нет.
Но вообще, надо бы этот момент поправить когда-нибудь, спасибо!

Вот для ограничения сбора ресурсов есть настройки по шаблонам и типам ресурсов.

Основные же условия для правильности подсчёта результатов пишутся в правилах. Вот они гораздо важнее, так как влияют на видимость страницы.
Евгений Шеронов
31 января 2020, 22:31
+1
Здесь важнее версия mSearch2 — от версии 1.12.2 в чанке tpl.mFilter2.filter.number вместо [[+value]] можете использовать [[+current_value]] для этой микроразметки.

На SEO страницах тоже корректно будет отрабатывать.
Евгений Шеронов
31 января 2020, 16:37
0
Добрый день!

На демке не обновлял чанки от mSearch2 и упустил это изменение в mFilter2.
Обновитесь до версии 1.7.2 Сейчас работает так как надо?

Но не думаю, что поисковики берут данные именно оттуда.
Яндекс показывал, только если загружен фид для маркета в я.Вебмастер.
С гуглом не знаю как — но можете написать мне в техподдержку по этому вопросу подробнее.

Но всё равно, на стандартной установке с mSearch2 значения меняются только после загрузки.
В исходном коде же они хранятся в атрибуте data-current-value=«500» элемента input, а в value будет минимальная сумма, в случае демки — 100.
Евгений Шеронов
31 января 2020, 15:59
0
Добрый день!
Обновитесь до SeoFilter 1.7.2 — вернул там поддержку параметра urls.

Ещё теперь можно писать параметры rules, parents и urls через массив:
{'sfMenu' | snippet : [
	'rules' =>[2],
	'parents' => $_modx->resource.id,
	'urls' => [2,3,4]
]}
Евгений Шеронов
24 декабря 2019, 20:12
0
Не может быть, а точно.
Перед обновлением не забывайте делать бэкап.
Евгений Шеронов
23 декабря 2019, 22:48
0
Добрый день!

В текущей версии прям так пока нет, но запишу в TODO.

Сейчас можете сделать сниппет, напрмиер getVendorValues, который будет подготавливать значения.
Его название нужно будет вписать в настройку seofilter_snippet.

Вот код, у меня работает:
<?php
$vendorAlias = 'vendor'; //псевдоним поля вендор, добавленный в SeoFilter
$vendorKey = 'vendorData'; //ключ для массива, по которому можно будет обращаться в полях
$vendorAsArray = true; // если да, то все поля будут доступны как массив (через точку от ключа), если нет, то через нижнее подчеркивание от ключа

if(!is_array($row)) {
    $row = unserialize($row);
}
if(isset($row['params'][$vendorAlias])) {
    $vendorData = [];
    $q = $modx->newQuery('msVendor');
    $q->select($modx->getSelectColumns('msVendor','msVendor'));
    $q->where(['id'=>(int)$row['params'][$vendorAlias]['input']]);
    if($q->prepare() && $q->stmt->execute()) {
        $vendorData = $q->stmt->fetch(PDO::FETCH_ASSOC);
    }
    
    if($vendorAsArray) {
        $row[$vendorKey] = $vendorData;
    } else {
        foreach($vendorData as $key => $val) {
            $row[$vendorKey.'_'.$key] = $val;
        }
    }
}

return serialize($row);

И потом можно обращаться во всех правилах, где есть производитель, так:
{$vendorData.description} //с массивами только через Fenom
{$vendorData_description} //при $vendorAsArray = false;
Если как ключ оставили vendorData.
Евгений Шеронов
29 октября 2019, 19:27
0
А для кого техническая поддержка по компонентам на modstore сделана?)

Все проблемы, связанные с компонентом, решаются, как правило, бесплатно.

Напишите туда с доступами, посмотрю в чём дело.
Евгений Шеронов
29 октября 2019, 10:41
0
Напишите мне в телеграм или на почту — обсудим)

P.S. лучше, конечно же, в телеграм
Евгений Шеронов
28 октября 2019, 17:58
0
Пока нет такой возможности, но можно «допилить»)
Евгений Шеронов
23 октября 2019, 13:29
0
Обычно так, как просит их документация.

Но каждый компонент выставляет свои плейсхолдеры раличными способами.
Плейсхолдеры, выставленные раньше, чем сработает SeoFilter на событие OnPageNotFound, будут доступны.

Для более детального разбора — пишите в поддержку.