0.00
54 читателя, 55 топиков

(опрос) А как вы строите меню сайта?

В связи с тем, что в бекенде WayFinder морально устаревает, а со стороны фронтенда появляются более сложные задачи вёрстки меню, например комбинаций многоколоночных выпадающих пунктов (с особой вёрсткой) с обычными, комбинаций «mouseover» с нажатиями, не говоря о десктопных и мобильных версиях итд.
Вобщем всё сложнее структурируемо и шаблонизируемо, что ассоциация меню с деревом сайта с галочкой «показывать в меню» становится более запутывающей, то назрел вопрос, а как вы теперь строите и шаблонизируете меню сайта?

Читать дальше →

Переделка кеширования у MODx

Всем привет.
Очень нужна ваша помощь и совет. Сразу приношу извинения за многобукв и нескладную «речь» — пишу на скорую руку.

Сейчас занимаюсь важным делом — пробую полностью переделать кеширование у MODx EVO. Возникла одна интересная идея, которой хочу поделиться.

Нашел интересную разработку https://github.com/PHPSocialNetwork/phpfastcache, которая позволяет использовать такие методы кеширования: apc, cookie, files, memcache, memcached, predis, redis, sqlite, ssdb, wincache, xcache на выбор или автоматический выбор. Хочу

1) Позволить им пользоваться для разработки сниппетов, модулей и т.д.
2) Переписать под нее систему кеширования MODx;

1. Кеширование для разработчиков



На основе phpfastcache сделал новое расширение, которое в момент инициализации ядра MODx становится доступным как
$modx->cache


Использование

Запись данных в кеш:
$modx->cache->set('ключ','кешируемые данные');

Считывание данных:
$modx->cache->get('ключ');


Также доступны действия по удалению кеша по ключу, поиск по кешу и т.д. И все это доступно в ваших сниппетах, модулях и т.д. Можно кешировать все что угодно и везде.

2. Система кеширования самого MODx


У стандартной системы кеширования есть как минимум два слабых места:

  1. Сгенерированный для страниц HTML пишется в файлы типа docid_1.pageCache.php, а количество сгенерированных кеш-файлов для страниц может достичь большого числа, что создает проблемы.
  2. Все настройки MODx посещается в файл siteCache.idx.php. Но если сайт большой (много документов, сниппетов, плагинов и т.д.) файл siteCache.idx.php разрастается и при инициализации MODx весь грузится в память, причем даже те данные, которые могут быть не нужны.


Как я предлагаю решить эти проблемы.

1) Писать сгенерированный HTML не в файлы, а кешировать их с помощью, напр., memcache, memcached, predis, redis, sqlite, ssdb, wincache, xcache, используя вышеприведенную разработку;

Я переписал ядро MODx (всего несколько строк кода) так, чтобы весь сгенерированный контент кешировался не в файлы типа docid_1.pageCache.php, а в моем случае memcache (можно выбрать любой другой способ). Результат — избавился от сгенерированных кеш-файлов, а производительность при этом совершенно не пострадала по сравнению с теперешним методом кеширования.

2) При генерации кеша загоняем все настройки не в siteCache.idx.php, в, напр., в memcache ( в виде ключ=значение) с помощью той же разработки
$modx->cache->get('ключ','кешируемые данные');

А потом загружаем эти настройки по мере необходимости.

Сейчас весь конфиг загружается с помощью $modx->getSettings(), причем весь кеш заливается в память и висит там все время, нужен он или нет. Зачем? Не проще ли было бы извлекать нужные данные вот так:
$modx->cache->get('ключ','кешируемые данные');

Например, мне нужно в сниппете получить информацию о языке системы управления. Это можно сделать так:
$modx->cache->get('config:manager_language');
. Будет извлечено только это значение.

Вот тут нужен ваш совет. Будет ли это эффективным решением? Конечно, придется тогда немного переписать и ядро MODx, и имеющиеся разработки. Или же каким-то образом обеспечить совместимость. Что вы думаете по этому поводу?

[EVO] Twig

Agel_Nash поделился плагином, который позволяет поменять шаблонизатор MODX на Twig. Я решил посмотреть, что к чему, и сразу столкнулся с проблемами. Повозившись какое-то время, мне все же удалось запустить этот плагин, о чем и хочу поведать.

Читать дальше →

[EVO] Переключение шаблона на лету с кэшированием, а так же предложения по расширению API MODX по части кеширования

Сейчас все больше и больше клиентов просят добавить мобильный интерфейс для сайта.
Когда эта задача стоит на уровне планирования то это все легко решается средствами адаптивной верстки и по части MODX ничего не нужно делать.

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

А как было бы удобно просто добавить еще 1 поле для выбора шаблона(шаблонов для телефона планшета), это бы дало возможность легко работать с другим отображением сайта.

В целом для решение поставленной задачи нужно решить 2 этапа:
1 КЕШ.
Давно хотелось его научить умным вещам, последнее чему его учили это запоминание в кеш с учетом ГЕТ параметов, тут все ок, только после использования стал вопрос а почему только GET? да и почему все параметры а не только указанные, ведь порой удобно кешировать в зависимости от определенных параметров + в идеале от параметров которые или по умолчанию или указанны в конкретном документе.

итого задача 1: Вынести в настройки выбор параметров от которых зависит кеш

так же если уж ковырять кеш то очень хотелось бы научить MODX сбрасывать не весь кеш а только определенный, ибо если мы добавляем новости то зачем нам трогать каталог? где нет новостей?
тут тоже все довольно просто достаточно расширить api modx->clearCache добавив возможность не только удалять все но и удалять выбранные документы к примеру так:

modx->clearCache(array('1','4')); — тоесть если получаем масив то там список id которые чистим.

Таким образом мы расширим функционал Кеширования что даст больше гибкости в работе.

2 Плагин MOBILE-template
— как только у нас будет решена задача по части Кеша то написать данный плагин даже на базе существующих решений будет уже не проблемой, просто добавляем параметр к примеру $_SESSION['mobile'] к кешированию и в зависимости от него уже кешируем документ. таким образом у нас в кеше будет 2 файлика 1 под десктом второй под mobile.

Думаю это было бы очень актуально. В целом свободного времени пока мало :( потому есть идея попробовать решить эти задачки в рабочем порядке. Собрав под это дело немного денег :)

Пишите в коментах сколько готовы закинуть :) как соберется приятная сумма то сделаю указанный выше функционал. Так же если есть пожелания предложения касающиеся данной темы так же пишите

Для чего нужен documentObject

Столько времени я в каждом сниппете использую следующую схему:
$id = $modx->documentIdentifier;
$doc = $modx->getDocument($id);
$tvs = $modx->getTemplateVarOutput('*', $id);
...

Не задумываясь о том, что есть уже прописанная переменная, которой можно смело пользоваться и это будет максимально правильно и эффективно. К тому же, такой подход противоречит здравомыслию, так как в неопубликованном ресурсе, во- время работы такого сниппета, будет непредсказуемый результат.
Читать дальше →

[EVO] Тестируем MySQLi Extender

Давайте потестируем:

Без обновления
  • Забираем файлик с git — github.com/modxcms/evolution/blob/develop/manager/includes/extenders/dbapi.mysqli.class.inc.php
  • Кладём в /manager/includes/extenders/dbapi.mysqli.class.inc.php
  • Правим /manager/includes/config.inc.php
    $database_type = 'mysqli';
  • Ищем is_resource и заменяем его на $modx->db->isResult как минимум в файлах:
    /assets/modules/docmanager/tv.ajax.php
    /manager/includes/controls/datagrid.class.php
    /manager/includes/controls/datasetpager.class.php
    /manager/includes/tmplvars.format.inc.php
    /manager/includes/tmplvars.inc.php

С обновлением

[EVO] Где хранить элементы или как улучшить работу с git в MODX

С каждым нормальным проектом, который в последствии требует доработок уже в процессе работы и просто так делать по живому там нельзя встает вопрос как же все это связать в MODX?

Есть пару интересных идей, но хотелось бы узнать мнение сообщества кто и как решает подобный вопрос.

Modifiers, быть или не быть? Вот в чём вопрос.

Стоит ли внедрить механизм модификаторов в ядро MODx EVO Custom, добавить раздел в Extras — «Модификаторы», так чтоб можно было устанавливать модификаторы.

Как по мне разницы между [[NumberForma?number=`[+Price+]`]] и [+Price:NumberFormat+] особой нету. Но дело в том что плодить сниппеты в Extras из-за мелочных задач нет смысла, а вот модификаторы как раз в тему.

[EVO] updateNotify - пугаем заказчиков сообщением об устаревшей версии Evo (:

Идея такая: смотрим, какая последняя версия выложена в релизах на github, и сравниваем ее с версией установленной системы. Если на гитхабе свежее — показываем сообщение.

Конечно есть лента новостей, но вряд ли заказчики будут ее читать, да еще и по-английски. К тому же зачем обновлять и платить за это, если сайт еще не взломали работает.

Читать дальше →