0.00
59 читателей, 58 топиков

Админка для Лендинга или аналоги Modx

Встал вопрос сделать админку для Одностраничника — и я захотел прокачать свои скилы в теме JavaScript (или Python);
Начал искать варианты по типу Modx, пока нашёл два:
первый — на базе JS github.com/xtremespb/zoia2
второй — на Питон wagtail.io/

Может кто-то подскажет ещё?! — требования простые: подходит для «непродвинутых юзеров» и имеет русский интерфейс в
Читать дальше →

Предлагаю данные MultiTV хранить в отдельной таблице (json)

Предлагаю разработчикам рассмотреть возможность хранить данные MultiTV хранить в отдельной таблице. Или сделать опцию — хранить по стараму или в отдельной таблице.
id (int)
tmplvarid (int)
contentid (int)
value (JSON)
данные хранить в формате JSON. Тогда можно будет использовать функции базы данных для работы с
Читать дальше →

Как обернуть тег table в в TinyMCE 4

Всем здасьте, думаю многие пользуются всеми любимыv Bootstrap 3, мне кажется
самый популярный фреймворк для разработки адаптивных и мобильных web-проектов. Я люблю собирать сайтики на Evolution CMS, у меня не возникало проблем что-бы сделать табличку резиновой или полосатой, но ведь после меня в админке сайтом будут заниматься люди !? Так еще мало или вообще не разбирающихся в HTML или CSS, они
Читать дальше →

И все же почему я выбрал EVO а не REVO?

Небольшое вступление
Недавно закончил проект, вернее еще доделываю мелочи но уже проект запустили.
Изначально проект был на REVO притом работал довольно хорошо и быстро. Но переделывали так как все равно была новая верстка а мне было проще перенести весь контент с REVO на EVO за 10 минут чем разбираться и переделывать. Так сказать обезопасил себя от старых неясных багов:) Собрав с нуля. Далее когда на днях перенес проект на хостинг был приятно удивлен на то на сколько EVO все же меньше кушает ресурсов и быстрее работает.

Хостинг
Понятно что на плохом хостинге РЕВО работает плохо. Но тут про хостинг я могу сказать только хорошие слова в целом это один из 2-х хостингов шаре который я рекомендую под REVO modhost.pro
Когда заливал EVO понимал что по логике проблем быть не должно :) но все же перевил так как изначально хостинг заточен под REVO. но все прошло как по маслу. И в итоге вот скрины нагрузки на сервер:

Скорость отдачи контента с 0.2-0.5 упала до 0,01- 0,2


Потребление памяти упало с 130 до 100


Нагрузка на процессор упала более чем в 2 раза


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

Спам по формам без капчи (eForm)

«Современные маркетинговые инструменты» требуют, чтобы пользователь делал меньше телодвижений для того, чтобы расстаться со своими контактными данными. Именно поэтому на страницах появилась куча форм через каждые пол-экрана и все без капчи. Пользователи стремительно тупеют и им лень даже набрать номер телефона, а о том, чтобы самостоятельно написать письмо и вовсе речи не идет. Периодически по сайтам пробегаются пауки на предмет тестирования отправок форм, потом, видимо, пишется какой-то обработчик, который скачивает страницу и делает POST-запрос. В логах сервера это видится примерно вот так



Затем бот сбегает с сайта, а в почту приходит какое-то очередное «оно».

Варианты решения проблемы без внедрения капчи

Рассматриваю только отмену отправки, а не пост-обработку. Сразу оговорюсь, что я не программист, и такие решения, может быть и весьма неидеальные, но зато лезть глубоко в кишки не нужно.

0. Для всех случаев такого рода лично я отключил вывод [+validationmessage+] и занулил requiredClass и invalidClass для усложнения изучения ответа при неправильной отправке. Пре-валидацию в простой форме можно сделать и на JS и аттрибута required достаточно. ИМХО.

1. По совету Dmi3yy создание пустого поля, обязательного к незаполнению. Например, такого:
<input value="" name="phone" id="phone" class="special" type="text" eform="Спец:date:0" placeholder="Phone*">
Необходимо спрятать это поле с глаз долой через CSS и дать ему часто используемое имя. В моем случае, после того, как стал сыпаться спам у одного из клиентов — не прокатило. Только позже я понял, почему. Скорее всего, простой бот считает количество элементов в DOM, и пишет в поля по счету, не ориентируясь на ID и name. Поле надо вставить так, чтобы сломать текущий порядок элементов внутри формы. Неплохо было бы делать это в случайном порядке, но eForm не любит, чтобы кто-то копался в шаблоне формы без его ведома, а на JS этого не сделать, потому что бот не скачивает JS.

2. Хардкор. Так я сделал на некоторых статичных сайтах, где форма отправляется не очень сложным скриптом на PHP. Сделать поле имя только на русском языке.
через eForm это делается так
<input type="text" class="inptext" name="name" id="name" eform="Ваше имя::1::#REGEX /^[А-Яа-яЁё ]+$/u" placeholder="Ваше имя*">
По понятным причинам — «трудно недооценивать всю предсказуемость тупизны» не самое идеальное решение. Но внезапно оказалось, что действенное.

3. Сделать форму подгружаемой в блок на странице скриптом и отправку через ajax. Вариантов реализации можно придумать несколько, у кого на что фантазии хватит. Или в форме заменить action на несуществующий, а POST на GET и по факту показывать вместо формы только ее верстку, которую «чинить» яваскриптом при отправке, а сам правильный вызов eForm сделать на странице, куда форма отправляется. Не спасет, если эту страницу с «чистым» вызовом eForm найдет бот. Но и тут тоже возможны варианты. Например, не отображать форму, если страницу не передано какого-нибудь интересного GET-параметра, содержащего неведомую строку. Забить значение этого параметр можно куда-нибудь в настройки через cfgTV или globalPlaceholders и периодически его менять.

4. Похоже на пункт 1, но к полю пишется атрибут required и мусор в value. Так как поле по условию проверки обязано быть пустым — форма не отправится. При отправке по событию submit через JS снимается атрибут required и чистится значение. Без скриптов отправка невозможна. Аналогично можно сделать проверку на соответствие строго заданному значению и проставлять это значение при загрузке страницы, но мне кажется, это менее интересно.

тема MODxRE2 и dir=rtl

Возник вопрос о разработке сайтов для иноземных клиентов и решил я попробовать перекючить админку на иврит (hebrew)… и потратил около получаса чтобы переключить обратно, и проблема не в переводе, думал уж было в базу лезть придется чтобы вернуть.

Внимание!!! неопытным пользователям не повторять!

а тем кто любит ребусы — можете попробовать)))
в общем есть некоторые проблемы с отображением верстки для правосторонних языков, так как при dir=rtl направление меняется не только для текста, но и для всех inline-block.

P.S. иврит не понадобился, так как админка нужна на английском

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

В связи с тем, что в бекенде 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] Переключение шаблона на лету с кэшированием, а так же предложения по расширению 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.

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

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