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

Админка для Лендинга или аналоги 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, и имеющиеся разработки. Или же каким-то образом обеспечить совместимость. Что вы думаете по этому поводу?

Twig

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

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