Евгений Шеронов
С нами с 20 мая 2015; Место в рейтинге пользователей: #30Вчера в 15:27
Есть у кого-то идеи? или в данном случае через плагин и событие пробовать, или мсинк тупо всё обрезает?
Msync как записать html контент, а не обработанный без тегов? 1
Вчера в 12:15
воротите, что хотите. Вплоть до удаления исходников сайта, это уже на ваше усмотрение.
Это определённо очень важная возможность 😊
mmxFenom - нативная интеграция шаблонизатора 3
Вчера в 11:30
Управляя настройками mysql, можно задать параметр sql_mode пустым значением (после чего все заработает), но хостер такую возможность не дает… Есть ли ...
pdoTools и sql_mode=only_full_group_by - ошибки при работе PdoPage 1
Вчера в 10:27
<?php
$id = $modx->getOption('id', $scriptProperties, $modx->resource->id);
$field = $modx->getOption('field', $scriptProperties);
$tpl...
Вывод даты msTimeStamp полей MiniShop2: new, favorite, popular... 3
01 мая 2024, 21:40
$pdoTools = $modx->getParser()->pdoTools;
$data['count_products'] = count($data['products']);
$renderedHtml = $pdoTools->get...
Как передать переменные внутрь чанка из сниппета и заполнить с помощью fenom? 2
30 апреля 2024, 11:46
— эта заготовка для создания ОДНОГО дополнения? Да
Или можно в рамках одного сайта разработать сразу 5 несвязанных друг с другом дополнений?Наверно...
mmxApp - разработка новых composer дополнений 6
29 апреля 2024, 20:52
Добрый день, подскажите, перестал работать плагин в Хроме и Эдж, а в Яндекс браузере работает. Что может быть?
modx + webp просто и надежно - автоматически 20
28 апреля 2024, 22:59
Настроил всё по инструкции, но заказы в Сделки не попадают.
Анонс modB24CRM 18
Даже если нужно будет фронтенд раскидать между командами — то это точно будет не так.
Варианты:
1) Разные фреймворки — но по разделам, админка например на одном фреймворке, пользовательская на другом.
2) Если прям хочется поделить одну страницу — то всё просто в пределах одного фреймворка, но использованием одного нормального хранилища с модульной структурой, типо Vuex или Redux.
Поэтому, что это видео, что то на английском — всё это жуткий bad practice. Остаётся надеяться, что все просмотревшие восприняли это как учебный эксперимент и никогда не подумают повторять.
Полностью смотреть не стал (там на канале ещё 2), но подход автора видео по Vue.js мягко говоря странноват.
Сам компонент вот github.com/jaredfhealy/extrabuilder/ и, наверное, он хорошо выполняет свои функции.
Но автор умудрился намешать ExtJs, Vue.js и даже jQuery и всё это подрубается в админку через iframe!
Конфликт будет только с простыми названиями классов, это можно и как плюс использовать. Именно для иконок используются стандартные классы. Но все свои классы я пишу добавляя префикс компонента.
Я в админку совсем не захожу, только после сборки раз в неделю что-то проверить)
По идее всё как видишь на отдельной страничке — так и отображается в админке.
Есть смысл локально развернуть как раз для дебага PHP. Xdebug на modhost не поставить же?
Сборка стилей и js в master ветке локально в шторме. Я их и в git кладу.
Можно и на сервере, в заготовке есть пример сборки assets. Но потом опять надо буде выкачать изменения себе)
Так, уточню про процесс по пунктам подробнее)
1) Открываю PhpStorm
2) Жму serve во вкладке npm (читай пишу npm serve в терминале)
3) Происходит небольшая сборка и становится доступна страничка localhost:8080
4) На этой страничке есть только стили и шрифты от MODX и один
5) В него Vue.js уже маунтит приложение.
6) Для ajax запросов я использую axios, в который в зависимости от окружения добавляются псевдокуки в main.js (там где new Vue(...)) и создание конфига.
7) И при каждой правке обновляется даже не вся локальная страница, а именно тот участок DOM, что обновился. Vue очень умный) Вся страница обновится если что-то сильно общее поменять.
А чтоб это всё работало админке MODX уже Home контроллер отвечает за создание windows.ym2Config и создание разметки:
В комментах чуть поделюсь кодом:
Этот код у меня только в dev ветке. Людям в продакшн он уже не попадает)
Действительно, но в где-то явно может быть иначе. Видел, что вообще по умолчанию PHP 5.4, в /usr/bin/ только один php. А нормальный лежит тут: /opt/php70/bin/php
Как раз чтобы не привязывать логику к конкретным xPDO объектам. Ну и они не подходят под PSR-4.
Идея была в том, что компонент не должен особо знать, что там подсунуто.
В идеале от этих объектов требовалось имплементация методов save, toArray и get-set для свойств.
Надеюсь, что легко можно будет портировать интерфейс хоть под Laravel, там тоже ActiveRecord модель, которую можно будет смаппить с моделями из компонента)
Найду когда-нибудь время и поэкспериментирую с предложенным функционалом, замерю разницу.
Там нет никакой формы и вообще ничто никуда не отправится.
При этом сниппет addfavorites ведёт себя как хук для FormIt (хотя вполне себе можно без него, просто оперируя POST данными).
Следовательно вызов в таблице должен быть таким:
(чтобы не мешать синтаксис, ведь люди старались сделать всё изначально на Fenom)
Параметры fi.name и т.д. нужны, чтобы прокинуть данные в форму. См. modx.pro/components/3342
А чанк tpl.Favorite переделать хотя бы так:
Это, конечно, не отменяет множество проблем в коде автора.
Например строка $id_user = $modx->user->get('id'); будет работать только для авторизованных пользователей (для админа когда он проверяет). А на пользователях-гостях вполне себе будет падать.
Ну и какой-то странный формат HTML вёрстки с запятой и разными кавычками)
Мне немного страшно и интересно, как же будет выглядеть запрос, который положит данные в базу.
Есть же хук FormItSaveForm, под который есть даже визуальный интерфейс в админке.
Ну это прям призыв, чтобы пришли люди и грохнули сайт без каких-либо сложностей))
И даже так (и вроде когда используется массив) (обсуждали уже где-то здесь) что-угодно можно пропихнуть.
Всегда когда работаем с целыми числами всего лишь нужно добавить (int) перед чем-угодно и спать спокойно.
А это открывает доступ к другим типам инъекций.
Возможно, Fenom что-то там и порежет, но надеяться не стоит.
Теперь по замечаниям.
1) Абсолютный путь в целом там и не нужен, оставлю относительный.
Но ещё более не секьюрно давать кому-то доступ в админку))
Там и без этого никаких проблем получить все системные настройки через Fenom.
2) Поправил, в следующем обновлении уже не должно всплывать.
И в поддержке ни разу про такое никто не спрашивал.
Ну такая интеграция скорее всего потребует дополнительных расходов)
Вообще не помешала бы возможность подключать уведомления об интересующих компонентах, которые всё равно привязываются к топику при их упоминании.
Напишите мне в поддержку с указанием доступов.
По скриншоту тяжело что-то сказать.
Там в целом компоненты очень похожи на Ext JS, разве что гибче. Иконки все используются из MODX стилей.
В первом варианте этой статьи было слишком много технических подробностей, перенёс их в черновик.
Видимо, нужно как нибудь дописать)
И вот только сейчас всё это выглядит как полноценный компонент.
Вообще разрабатывать гораздо приятнее и удобнее. Тот же hot-reload, обновляющий на странице только изменившуюся часть DOM, реактивность, роутинг, хранилище, прям хочется ещё что-то сделать)
Но всё равно, полноценный компонент слишком долго делать :(
Если сильно захотеть текущий компонент легко перенести из админки на фронт или вообще заюзать в другой CMS, так как старался абстрагироваться от MODX сущностей (не получилось).
Здесь только через prepareSnippet сможете сделать замену нужных Вам тегов.
Также, если есть какие-то теги или стили у html-тегов, то их нужно подчистить.
Для этого должен быть установлен Jevix.
Вот пример сниппета prepareMarketDescription, который сделает то, что нужно.
Добавьте его и укажите название в настройку ms2ym_prepare_snippet.
Судя по github экономией тут не пахнет)
Стоимость пары недель любого разработчика — это годы для хостинга c MySQL)
Мало того, что схему нужно добавлять, так ещё в дополнениях бывают подготовленные запросы не через XPDO, и вполне может быть отличный синтаксис запросов. Так что и код править может придётся.
По мне такой путь точно в никуда.
Я бы ещё понял использование SQLite на сайте для какого-то внутреннего локального использования, где будет только 1 человек пользоваться сайтом.
Вот например, поддержка PostgreSQL принесла бы больше пользы. Но здесь будет проблема в том, что shared-хостингов с постгресом сильно меньше, следовательно поставить не у каждого получится.
Ну и некоторые решения могли бы сильно от БД зависеть, например от типов данных.
Так что сейчас даже хорошо, что в MODX все используют MySQL, всё легко перенести, не нужно вникать в другие БД, где их искать, как подключаться и т.д.
Хотя и с MySQL то можно много улучшать, добавлять поддержку новых типов, массивы, JSON.
Но под это дело простые шаред хостинги уже не успевают обновлять MySQL, но это уже другая тема)
Ну теперь это очевидно для всех, что в тех файлах настроек должен быть return, чтобы способ сработал.
Но даже если там будут переменные, они также включатся в эту область.
А переменные, определённые в файле становятся доступны в текущей области действия.
Если же массив с настройками там называется $config_options, то получать его лучше так:
По сути это делается через sfMenu просто с указанием параметров &parents=`[[*id]]` и &mincount=`1`.
Там ещё можно учитывать относительность через параметр &relative=`1` (тогда ссылки будут каждый раз уходить в глубину от выбранного параметра, если такие правила есть).
Но, конечно, как и на DNS, это просто популярные фильтры для этой страницы, и желательно, чтобы они были на странице. Их можно скрыть стилями или передать немного скрипты, чтобы проставленное значение сохранялось для пагинации.
А как сделать фильтры для mSearch2 особо разницы нет, хоть ТВ поля, хоть опции, хоть через Tagger.
А как себя ведёт БД в докере на production?
Пока только видел, что так совсем не стоит делать по ряду причин.
И в этом случае, если контейнер Docker с БД упадёт, то все данные до последнего сохранённого дампа тоже пропадут?