maxsite/cms

MaxSite CMS

MaxSite CMS

Система управления для сайтов, блогов, бизнес-сайтов, визиток, лендингов и т.д. Система отлично подходит обычным пользователям, фрилансерам и вебстудиям. MaxSite CMS обладает большим функционалом и высокой скоростью работы. Сделано в Украине.

Официальный сайт

ТРЕБОВАНИЯ СИСТЕМЫ

• Возможность работы с .htaccess и включенный mod_rewrite.
• База данных MySQL/MariaDB: 5.6 и выше. База должна быть уже создана.
• Минимальня версия PHP: 7.1 (рекомендуется 8.x). (Для PHP 5 используйте MaxSite CMS 104, скачать которую можно на странице релизов.)

Дополнительная информация по установке MaxSite CMS: https://max-3000.com/doc/install

Примечание. После установки системы вы можете добавить демо-данные.

АВТОУСТАНОВЩИК MAXSITE CMS

С помощью специального автоустановщика можно как установить новую систему, так и обновить существующий сайт.

Автоустановщик — это несколько небольших файлов, которые нужно загрузить на свой сервер. В файле «key.php» необходимо будет указать ключ доступа.

После этого в браузере нужно набрать «https://вашсайт/update-maxsite/?вашключ». Автоустановщик сам загрузит архив последней версии MaxSite CMS на сервер, распакует его и выполнит обновление.

Прямая ссылка для загрузки установщика: https://max-3000.com/uploads/update-maxsite.zip

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

Если это обновление существующего сайта, то перед обновлением ознакомьтесь с рекомендациями по обновлению MaxSite CMS, описанными ниже.

НОВАЯ УСТАНОВКА

1. Загрузите все файлы на сервер.
2. Наберите в браузере «http://сайт/install» и следуйте инструкциям.

Примечание. Если по какой-то причине при установке произошел сбой сервера, то повторную установку можно выполнить, предварительно удалив файл «application/config/database.php», а также созданные таблицы с помощью phpMyAdmin.

ОБНОВЛЕНИЕ СУЩЕСТВУЮЩЕГО САЙТА

В анонсе каждого выпуска MaxSite CMS может указываться рекомендуемый вариант обновления и особенности перехода к новой версии. Учитывайте это при обновлении своего сайта.

Важно:

• Если у вас версия ниже 106, то выполняйте обновление универсальным способом.
• Если меняется адрес сайта, то предварительно снимите опцию определения главного зеркала сайта в плагине Range_url.
• После обновления желательно сбросить кэш.

MaxSite CMS не вносит изменений в базу данных при обновлении, поэтому вы можете использовать любую версию системы. Если по какой-то причине, обновление не устраивает, вы можете загрузить файлы предыдущей версии.

УНИВЕРСАЛЬНЫЙ СПОСОБ ОБНОВЛЕНИЯ

Данный способ обновления подходит для любой версии MaxSite CMS.

1. Переименуйте каталоги «system» в «system-old». «application» в «application-old».

2. Загрузите файлы новой версии MaxSite CMS на сервер.

3. Скопируйте из «application-old» в новый «application» свой шаблон «/maxsite/templates/ШАБЛОН».

4. Если вы устанавливали сторонние плагины, то скопируйте и их.

5. Перенесите конфигурацию базы данных и сайта из «application-old» в новый «application» /config/database.php (используйте новый «database.php-distr») /maxsite/mso_config.php (используйте новый «mso_config.php-distr»)

6. Проверьте работоспособность сайта.

7. Каталоги «system-old» и «application-old» после проверки можно удалить.

---

(с) MaxSite CMS, 2008-2024

cms's Issues

Плагин "Голосования" (samborsky_polls)

Ошибка 1:
В "Защита от накрутки по-умолчанию" в выпадающем меню опечатка в слове "Coookies" (убрать одно "о")

Ошибка 2:
При нажатии на кнопку "Добавить новое" выходит Warning:

A PHP Error was encountered
Severity: Warning
Message: Creating default object from empty value
Filename: samborsky_polls/manage.php
Line Number: 254

D4 - main-файл

Несколько моментов, которые я хочу обсудить/предложить для будущего default-шаблона MaxSite CMS.

Есть некоторые моменты в текущем варианте, которые меня не устраивают и один из них main-файл.

Напомню, сейчас это солянка из управляющих php-конструкций, вроде подключение компонентов, ушек и т.п. и непоследственной html-разметки. Анализ файла позволил выделить участки кода, которые никак не завязаны (в рамках main-файла) на html-разметку. Отсюда я пришел к выводу, что можно выделить такой код в отдельные файлы, оставив в main достаточно простые подключениия.

Чтобы было понятно, я разместил файлы в main/blocks. Сам main-файл размещается как обычно в main/main.php

<?php if ($fn = mso_fe('main/blocks/body-start.php')) require($fn) ?>

<div class="header clearfix"><div class="wrap">
    <?php if ($fn = mso_fe('main/blocks/header.php')) require($fn) ?>
</div></div>

<?php if ($fn = mso_fe('main/blocks/header-out.php')) require($fn) ?>

<div class="layout-center-wrap"><div class="wrap flex flex-wrap-tablet main">

    <?php if ($fn = mso_fe('main/blocks/main-start.php')) require($fn) ?>

    <div class="content w70 w100-tablet"><div class="wrap">
        <?php if ($fn = mso_fe('main/blocks/content.php')) require($fn) ?>
    </div></div>

    <div class="sidebar1 w25 w100-tablet"><div class="wrap">
        <?php mso_show_sidebar('1', '<div class="widget widget_[NUMW] widget_[SB]_[NUMW] [FN] [FN]_[NUMF]"><div class="wrap">', '</div></div>') ?>
    </div></div>

    <?php if ($fn = mso_fe('main/blocks/main-end.php')) require($fn) ?>

</div></div>

<?php if ($fn = mso_fe('main/blocks/footer-pre.php')) require($fn) ?>

<div class="footer"><div class="wrap">
    <?php if ($fn = mso_fe('main/blocks/footer.php')) require($fn) ?>
</div></div>

<?php if ($fn = mso_fe('main/blocks/body-end.php')) require($fn) ?>

</body></html>

То есть здесь фактически оставлена только html-разметка. block-файлы, например header.php содержит более сложный код:

if (function_exists('ushka')) echo ushka('header-start');

if ($fn = mso_fe('custom/header-start.php')) require($fn);

if ($fn = mso_fe('custom/header_components.php')) require($fn);
else
{
    if ($fn = get_component_fn('header_component1', 'menu-only')) require($fn);
    if ($fn = get_component_fn('header_component2')) require($fn);
    if ($fn = get_component_fn('header_component3')) require($fn);
    if ($fn = get_component_fn('header_component4')) require($fn);
    if ($fn = get_component_fn('header_component5')) require($fn);
}

if (function_exists('ushka')) echo ushka('header-end');
if ($fn = mso_fe('custom/header-end.php')) require($fn);

В этом файле (и других из block) нет html-разметки. То есть таким нехитрым способом у нас появляется возможность выполнять верстку непосредстено в main-файле, не задумываясь о сложном php-коде.

Поддержка в MaxSite CMS bootstrap-шаблонов

Сейчас бутсраповских шаблонов как грязи. В основном они делаются ка лендинги, но иногда встречаются типовые блоговские варианты. Было бы неплохо придумать способ простой адаптации таких шаблонов под MaxSite CMS. Чтобы была простая схема переноса готовой html-верстки в MaxSite CMS-шаблон. Естественно, в этом варианте теряется много типовой функциональности default-шаблона, но зато нет необходимости возится с дизайном и версткой.

Добавить указание мета-тегов для категорий

Предлагаю добавить возможность указания мета тегов для категорий (title, description) и дополнительного названия, которое будет выводится на странице категории (для меню одно, для страницы другое).

Переделать вывод формы комментария

Файл shared\type\page\units\page-comment-form.php — сделать так, чтобы можно было по простому подключить свой формат вывода формы комментирования в шаблоне.

Добавить анимацию строки поиска в главное меню

Поведение такое:

• По клику на значке поиска показывать поисковое поле, фокусировать на нем курсор.
• При повторном клике на значке поле скрывать.
• Также скрывать поле, если фокус потерян (например, клик произошел в другом месте страницы)

Совместимость в будущей версии MaxSite CMS

Потохонечку пришел к выводу, что новая версия должна уже быть с «подчищенными хвостами». Если оставить как есть, но костыли ради совместимости со старыми версиями и дальше будут тормозить развитие системы. Через какое-то время всё-равно придется переделывать.

Итак, что может поменяться.

1. Шаблон должен быть полностью сам в себе. То есть никаких связей с default-каталогом быть не должно.
2. Связи с shared-каталогом только на уровне каталогов main, meta, options, stock и type. Там сложный php-код.
3. В shared-каталоге functions, css-less, js удаляются (переносятся в каталог шаблона). В blanks остаются только каркасы для новых плагинов.
4. В common/jquery остается только те jQuery, которые используются системой. Всё остальное — удаляется. В шаблоне можно будет загрузить свою верси jQuery, вместо системной.
5. PHP-компилятор less полностью удаляется из ядра системы. Он безнадежно устарел, нет смысла его тянуть дальше. Однако, подумать и сделать его в виде плагина (less_compiling) — кому нужно, пусть используют и дальше.
6. Внести изменения в парсере текста. Идея в том, чтобы при редактировании страницы была возможность указать обработчик. Стандартный — как сейчас, с авторасстановкой абзацей. Без обработки — отдавать как есть (годится для html-кода), и какой-то сторонний, например simple из LPF. Такая схема позволит снять проблемы при использовании сторонних визуальных редакторов — для записи просто указывается нужный парсер. Открытый вопрос — должен ли парсер быть один для записи (выбор select) или можно указать несколько (checkbox). Если несколько, то как определять приоритет срабатывания? В общем это крупная переделка.

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

В mso_menu_build() ссылки с # и ? делать без адреса сайта

Перенести из LPF.

D4 — компоненты. Несколько шаблонов в комплекте

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

Отсюда я предлагаю немного поменять концепцию default-шаблона. Сейчас он выполняет роль прототипа для новых шаблонов. Вместо этого отказаться от этой идеи и сделать просто какой-то красивый модный шаблон. Поскольку он будет менее функциональный и универсальный, чем текущий, то подумать о том, чтобы в комплекте MaxSite CMS шло несколько шаблонов, рассчитанных под разные потребности. Ну вроде «типовой блог», «аля-новости с колоночками» и «фотоблог». Построены они будут по единой схеме, с различиями по css-стилям, html-верстке и компонентами.

По компонентам, думаю, можно немного сменить парадигму. Если сейчас это возможность тусовать компоненты верх-вниз, то в новых шаблонах это может быть просто выбор заранее определенных полнофункциональных вариантов шапки/подвала. Например будет «шапка со слайдером», «шапка без слайдера», «шапка с видео» и т.п. Эти компоненты не нужно использовать оновременно, а нужно выбрать лишь один из них. Как вариант, если выбирается несколько, то в опциях можно выставить условия «только на главной», «только в записях» и т.п. То есть по технической реализации ничего не меняется, но меняется сам подход к понятию компонентов.

Что касается нескольких шаблонов в комплекте MaxSite CMS, сразу отмечу, что один я этого не потяну. Я бы с удовольствием полностью делегировал все работы по верстке, дизайну и поддержке шаблонов, включая и базовый default кому-то, кто заинтересуется. Мне интересна техническая сторона вопроса, прогрммирование, но поддерживать верстку и всё-такое, требует много усилий. В качестве альтернативы на начальном этапе можно не включать эти шаблоны в комплект, а выложить на гитхабе для пользования и отладки. После уже решить о включении в комплект. Главное, чтобы эти шаблоны всегда были полностью совместимыми с последней версией MaxSite CMS.

Предлагаю обсудить эти вопросы.

Мета-поля для комюзера

Предлагаю реализовать возможность использования мета-информации для комюзера. По типу как устроены опции шаблона. Т.е., например, на /admin/options сделать вкладку по типу forms, где можно задавать настройки мета-полей комюзера. Второй вариант - в папке custom шаблона должен быть файл типа my-comuser-meta.ini. Если хотя бы ожин из этих вариантов заполнен админом, то на странице редактирования комюзера после всех обязательных полей будут выводится дополнительные meta-поля. Значения этих полей будут сохраняться в таблице meta.

Благодаря таким полям можно будет реализовывать любые мыслимые сочетания полей, котоые могут понадобиться при создании сайта. Например, поле «Телефон». Также, можно было бы реализовать скрытие неиспользуемых полей типа Jabber или ICQ.

Если идея интересна, то могу взяться за реализацию.

Виджет твиттера

можно добавить в описание как получать rss через api https://api.twitter.com/1/statuses/user_timeline.rss?screen_name=maxsite

D4 — css и less-файлы

Сейчас сложилась довольно сложная схема работы с css-файлами. Там и css.php и style.php, а также style-all-mini, компоненты, профили и т.п.

Наличие php-файлов изначально требовалось для подключения less-компилятора. Я предлагаю полностью изменить данную схему.

В секцию HEAD будут автоматом подключаться все css-файлы каталога /css/. То есть кинул css-файл он автоматом появился. Никаких больше движений не будет. Подключение происходит в алфавитном порядке. Если имя файла начинается с _ или -, то файл не подключается. Основной (автоматически создаваемый) файл — style.css.

Каталог css-less содержит less-файлы, где основной файл style.less. Именно для этого файла подключается встроенный less-компилятор. Алгоритм такой: смотрятся даты создания css/style.css и если она раньше, чем style.less, то происходит компиляция. При этом, я планирую сделать проверку на дату создания всех less-файлов каталога css-less и его подкаталогов. Это позволяет изменить какой-нибудь css-less/mixins/my.less, что автоматом приведет к компиляции style.less и обновлении style.css.

Если требуется отключить встроенную less-компиляцию, а использовать внешнюю, например winless, то я предполагаю, что оптимальным будет использование какого-нибудь less-complier.php с массивом опций, где указывается что-то вроде $LESS['complier'] = false. Здесь можно будет размещать и какие-то другие опции, если они возникнут в будущем.

CSS-профили подключаются как и прежде. Здесь ничего не меняется.

Для плагинов предусмотреть новый хук «head-css», по которому подключать их css-файлы. Сейчас используется просто head и это порождает изрядную солянку css-js файлов. С новым хуком будет больший порядок.

В секции HEAD порядок подключения css/js-файлов будет таким:

• вначале всё из css/
• css-файлы компонентов (out_component_css)
• хук head-css
• css-профили из css/profiles
• jQuery
• хук head
• все файлы из js/autoload/
• Файлы и ушки по head
• Стили из опций my_style
• Хук head-end
• Ушка google_analytics_top

Основная проблема всех этих переделок — частичная потеря совместимости со старыми шаблонами MaxSite CMS. Поэтому я думаю, что если перенести template.php с mso_default_head_section() на уровень шаблона, то это решит проблему: старые шаблоны будут использовать shared-версию, а новые уже свою.

mysql_escape_string() is deprecated в php 5.5

При установке движка на OpenServer с php 5.5 на борту получил такие сообщения после авторизации (инасталляция прошла успешно):

A PHP Error was encountered
Severity: 8192
Message: mysql_escape_string(): This function is deprecated; use mysql_real_escape_string() > instead.
Filename: mysql/mysql_driver.php
Line Number: 320

A PHP Error was encountered
Severity: 8192
Message: mysql_escape_string(): This function is deprecated; use mysql_real_escape_string() instead.
Filename: mysql/mysql_driver.php
Line Number: 320

При попытке использовать драйвер mysqli вместо mysql с помощью опции в database.php ($db['default']['dbdriver'] = 'mysqli') получил другие сообщения:

A PHP Error was encountered
Severity: Warning
Message: mysqli_real_escape_string() expects parameter 1 to be mysqli, boolean given
Filename: mysqli/mysqli_driver.php
Line Number: 316

A PHP Error was encountered
Severity: Warning
Message: mysqli_real_escape_string() expects parameter 1 to be mysqli, boolean given
Filename: mysqli/mysqli_driver.php
Line Number: 316

Эту ошибку смог побороть только вот такой правкой файла \system\database\drivers\mysqli\mysqli_driver.php (в строке 315):

if( !$this->conn_id)
{
    $this->initialize();
}

$str = mysqli_real_escape_string($this->conn_id, $str);

Может есть какие-то варианты, чтобы инсталляция движка не тербовала правки файлов CodeIgniter?

Перенести пункт меню "Комментарии" в блок "Содержимое"

Предлагаю перенести пункт меню "Комментарии" в блок "Содержимое", ведь комментарии относятся именно к записям, и логичнее было бы если они находились в блоке "Содержимое", а не как сейчас, в блоке "Пользователи".

Добавить ссылки на редактирование и удаление записи в админке

Предлагаю добавить в "Содержимое" -> "Все записи" под каждую запись ссылки на редактирование и удаление записи (мелочь, а удобно).

Нужны хуки

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

1. В файле \application\maxsite\admin\plugins\admin_page\form.php есть хук admin_page_form_add_block_1, который позволяет добавить свой код на вкладке «Прочее». Но это дабовление осуществляется перед всеми остальными полями вкладки. Хотелось бы иметь возможность добавлять свой код и после всех стандартных полей. Т.е. нужен хук типа admin_page_form_add_block_2, который расположен после поля «Дата публикации». Это должно быть примеро в строке 258 сейчас.

   Для примера покажу как у меня делается сейчас:
   

2. Иногда есть необходимость добавить кнопки комментатору. Обычно уже работает плагин comment_button. Но часто (из-за шаблона) приходится извращаться со стилями, чтобы рядом с кнопками comment_button поставить свои кнопки. Да и писать целый плагин ради нескольких похожих кнопок как-то избыточно. Хотелось бы иметь хук в плагине comment_button, чтобы можно было через ушки-то-хук добавлять в ряд кнопок свою кнопку (или несколько).
   Если с этим пунктом поддержите, то могу реализовать не только хук, но и настройки плагину, чтобы была возможность включать-выключать нужные кнопки.

Переделать вывод форм для user

Файлы
shared\type\users\units\users-form.php
shared\type\users\units\users-form-lost.php

Добиться полной кастомизации в своем шаблоне.

Переделать вывод комментариев

Файл shared\type\page\units\page-comments.php сделать так, чтобы можно было по простому задать произвольный вывод комментариев в своем шаблоне.

Roadmap MaxSite CMS .87 .88 .89 .90

Небольшой анонс по плану выпуска версий MaxSite CMS. Поскольку мы не можем полноценно выполнить тестирование всех нововведений, то сделаем проще. Ещё недельку сами погоняем, поправим хвосты dev и это будет релиз версии .87 (с анонсом, чтобы привлечь народ). Она будет как ветка dev (как сейчас). Дальше с интервалом в 1 неделю делаем версии .88 и .89. Они также будут как dev. Версия .90 будет уже как master.

Текущая, которая .87 ещё нужно доделать дизайн default-шаблона. Это все те части, которые не зависят от плагинов/виджетов, а только завязаны на type-файлы и прочие части системы.

Версия .88 работа с плагинами (виджетами). Тут много переделок по верстке.

Версия .89 планирую переход на новую верстку админ-панели. Дизайн хочу изменить и главное сделать адаптивность.

Версия .90 — полноценный релиз. Пусть народ ставит, находит глюки, ошибки. Исправлять будем по ходу и выкладывать в ветку master, увеличивая номер версии пока не исправим.

В общем переходим в режим — если нет замечаний, значит всё работает отлично.

HTML шаблонизатор

Столкнулся с проблемой, которая пока тормозит дальнейшую разработку. У нас есть ряд файлов, которые содержат логику и представление. Например вывод комментариев или саму форму комментариев. В коде всё переплетено и php и html. По хорошему требуется отделить логику от представления. Обычно для этого используется шаблонизатор. То есть ему скармливаются подготовленные переменные, а в шаблоне вывода прописывается что-то вроде

<p class="comment-info">
    <span class="comment-num">№ <?= $comment_num ?></span> | 
    <span class="url"><?= $comments_url ?> | <?= $comusers_url ?></span>
    <?= $comment_edit ?>
    <?= $comment_approved ?> 
    <span class="date"><a href="#comment-<?= $comments_id ?>" id="comment-<?= $comments_id ?>"><?= $comments_date ?></a></span>
</p>

То есть стандартные короткие php-конструкции, которые не загромождают верстку.

Однако возникают сложности, если требуется использовать при верстке if-условия. Для затравки посмотрите файл shared/type/page/units/page-comment-form.php
https://github.com/maxsite/cms/blob/dev/application/maxsite/shared/type/page/units/page-comment-form.php

Здес такая куча и такое переплетение условий, что не так и просто разобраться.

Поэтому моё предоложение: подумать о каком-то простом шаблонизаторе, который упростит синтаксис php-кода и сделает верстку проще.

Чтобы было понятно, приведу пример готового кода для шаблонизатора:

<div class="comments-textarea">

    {% if (is_login()) : %}
        <input type="hidden" name="comments_user_id" value="{{ getinfo('users_id') }}">
        <div class="comments-user">
            {{ tf('Привет') }}, 
            {{ getinfo('users_nik') }}! 
            <a href="{{ getinfo('siteurl') }}logout">{{ tf('Выйти') }}</a>
        </div>
    {% endif %}

    {% if ($comuser = is_login_comuser()) : %}

        <input type="hidden" name="comments_email" value="{{ $comuser['comusers_email'] }}">
        <input type="hidden" name="comments_password" value="{{ $comuser['comusers_password'] }}">
        <input type="hidden" name="comments_password_md" value="1">
        <input type="hidden" name="comments_reg" value="reg">

        <div class="comments-user comments-comuser">

            {% if (!$comuser['comusers_nik']) : %} 
                    {{ tf('Привет!') }}
            {% else %}
                    {{ tf('Привет,') }} <a href="{{ getinfo('siteurl') }}users/{{ $comuser['comusers_id'] }}">{{ $comuser['comusers_nik'] }}</a>!
            {% endif %}

            <a href="{{ getinfo('siteurl') }}logout">{{ tf('Выйти') }}</a>

        </div>

    {% endif %}

Здесь всё очень просто. Есть две управляющие конструкции {{ }} и {% %}

Первая эквивалент
Вторая:

Всё остальное — обычный php-синтаксис. При этом в шаблоне можно использовать и его обычные конструкции.

Прошу высказаться по этому вопросу.

Правила именования css-классов MaxSite CMS

Давайте определимся раз и навсегда с правилами именования css-классов в MaxSite CMS. У нас есть html, который формируется на уровне type-файлов, плагинов и шаблонов.

Для шаблонов я предлагаю никаких правил не вводить вообще. То есть произвольное именование.

В type-файлах использовать приставку mso- Наример было <div class="type type_page"> станет <div class="mso-type-page">. То есть во всех классах, которые формирует система использовать эту приставку.

В плагинах для главного блока задавать div.mso-plugin-ПЛАГИН А остальные классы вложенных блоков уже задаются уже призвольно.

При такой схеме мы полностью разделяем классы системы от любого другого css-фреймворка.

-

D4 — дизайн шаблона

Пусть D4 будет заготовкой для будущего default. Давайте определяться с дизайном. За основу можно будет взять какой-то современный шаблон и переделать под свою задачу.

Cannonical для статичных страниц без /page/

И по умолчанию и у большинства сайтов на MS в меню, ссылки на статичные страницы, указаны без /page/, но коннонический адрес указывает на страницу с /page/.

Выкатил обновление

Очень много правок: 25eb82b?diff=split

Тестировать нужно всё.

Картинки для соц сетей

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

Соц сети берут картинку и из каждой страницы:
<meta property="og:image" content="http://****">

Хотелось бы, чтобы сам движок брал картинку, если она есть, из "Изображение записи" (image_for_page).

Если "og:image" не заполнено, или заполнено неправильно, когда посетители пользуются соц кнопками. получается какой-то ужас :( хотелось бы увидеть это в 0.90, по возможности.

Возможность отключения вывода комментариев

Неплохо бы добавить возможность отключения родных комментариев со стороны. Например, из плагина. + предусмотреть хук, чтобы в место вывода комментариев можно было вставить нужный код.
Пригодится при создании плана(-ов) сторонних комментариев.

Планы по MaxSite CMS

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

Принципиально: есть желание серьезно подчистить старые хвосты. Это касается удаления каких-то старых файлов, вроде jQuery-плагинов или стилей. Они нужны только ради совместимости со старыми версиями и шаблонами. Плюс мы отказываемся от поддержки старых браузеров, в частности минимальная версия IE11. Это то, что заявляется. Остальное на откуп вебмастера. Хоть для IE6 делай.

Скорее всего это приведет к частичной потери совместимости со старыми шаблонами. Поэтому основное требование для шаблонов — использование концепции D3. Как «отсекать хвосты» я уже писал на своем сайте.

LESS-компилятор заменю на новый. Но, тут важно отметить, что я планирую всё-таки использовать его опционально. На текущий день тот же winless с родной версией less.js работает лучше. Поэтому lessphp будем рассматривать как фишку, но не более того. К сожалению поддержка php-компиляторов less практически прекратилась, а то, что есть сильно отстает от нативного less.js.

Касаемо less в шаблоне есть пара моментов. В первую очередь я хочу изменить логику секции HEAD (см. mso_default_head_section() ). Подключение css/less-стилей очень запутанны. Вместо этого там оставить единый style.less, который автоматом компилируется в style.css. Но при этом автоматом подключаются все css-файлы из /css/. Эта логика сейчас используется в LPF и отлично себя зарекомендовала.

Далее по шаблонам. Дефолтный шаблон хочу переписать с использованием a-style (http://lpf.maxsite.org/rules-for-css) и только в варианте D3.

Админку тоже планирую переделать с помощью a-style. В админке есть несколько нехороших вещей, нужно будет их поправить. Там же нужно добавить адативность. Сам дизайн меня устраивает, но рассмотрю ваши идеи.

Часть вещей, придуманных для LPF, я бы хотел внедрить в MaxSite CMS. В частности очень нравится парсер simple. Чтобы его использовать потребуются некоторые переделки во встроенном autotag. Это сложная проблема и как её решать нужно ещё подумать. То есть основная идея в том, чтобы вынести все autotag отдельно и подключать опционально для каждого случая. Этот подход позволит разрешить конфликт визуально/невизуалього редактирования — используй тот парсер, который больше нравится.

Вот это основные моменты.

D4 — функции шаблона

Я буду выкладывать по отдельным тикетам свои соображения, чтобы после не путаться и чтобы держать вас в курсе своих планов. :-)

Функции шаблона работают через functions.php. В нем подключение файлов из shared_dir и custom/my_functions.php. Я хочу разорвать эту связку и переместить два файла из shared functions/template.php и functions/set_val.php в каталог шаблона custom/template.php и custom/set_val.php.

Файл template.php содержит только функции шаблона. Единственная функция — mso_add_file() её можно перенести в common.php, поскольку будет востребована всеми шаблонами. Самая спорная функция mso_default_head_section(), если она будет на уровне каталога шаблона, то может меняться под задачу вебмастера.

Файл set_val.php переносим в шаблон, поскольку в нем, опять же, только то, что относится к шаблону.

Опции для настройки текстов почтовых уведомлений

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

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

Могу реализовать всё необходимое сам, если идею поддержат.

Автоустановщик/автообновление MaxSite CMS

Выкладываю каркас возможного автоустановщика MaxSite CMS. Не проверяйте на рабочем сайте!

http://max-3000.com/uploads/_update_mso.zip

Эта штука позволяет полностью автоматизировать загрузку zip-архива последней версии системы, распаковать его, скопировать на уровень выше и выдать ссылку на инсталяцию.

Порядок такой. Загрузить каталог _update_mso и три его файла на сервер. После набрать в браузере сайт/_update_mso

Задача — протестировать этот код на разных серверах. Подозреваю, что из-за особенностей хостингов, может что-то неверно работать.

Если получится отработать эти вопросы, то можно будет доделать этот код до полного автообновления MaxSite CMS.

-

Обновление библиотеки lessphp

В последней версии MaxSite используется версия v0.3.9, но 9 августа вышла версия 0.4.0: http://leafo.net/lessphp/changelog.html

https://github.com/leafo/lessphp/blob/master/lessc.inc.php

Обратите внимание, что новая версия компилирует Twitter Bootstrap 3, но может быть несовместимой со старыми LESS-файлами. Возможно к плагину стоит добавить LESS compiling возможность выбора версии.

Плагин colorbox

В последней версии не работает плагин colorbox

Требуется обновить Font Awesome с 3.2.0 до 4.1.0

В составе шрифта появились новые полезные иконки. Подробности - https://github.com/FortAwesome/Font-Awesome/releases

Требуется обновить jQuery scrollTo до 1.4.13

Сейчас версия 1.4.2 и она имеет баг при работе в хроме - http://stackoverflow.com/questions/14546002/jquery-scrollto-does-not-work-in-chrome

Нужно обновить - https://github.com/flesler/jquery.scrollTo
Текущая версия - 1.4.13

Добавить в mso_get_pages хук на обработку page_title

В функции mso_get_pages есть такой фрагмент:

        foreach ($pages as $key=>$page)
        {
            $all_page_id[] = $page['page_id'];


            $content = $page['page_content'];

            $content = mso_hook('content_init', $content);

            $output = mso_hook('content_complete', $output);

            ...

            $pages[$key]['page_content'] = $output;

            $pages[$key]['page_categories'] = array();
            $pages[$key]['page_categories_detail'] = array();
            $pages[$key]['page_tags'] = array();
            $pages[$key]['page_meta'] = array();
        }

В этом фрагменте важно то, что контент записи передаётся на обработку в хуки и тем самым появляется возможность производить дополнительную обработку (например, обрабатывать бб-коды) содержимого записи ещё до его вывода на странице.

Хочу предложить добавить такую возможность ещё и для заголовка записи page_title. Например, так:

        foreach ($pages as $key=>$page)
        {
            ...
            $page_title = $page['page_title'];
            $page_title = mso_hook('page_title_out', $page_title);
            ...
            $pages[$key]['page_title'] = $page_title;
            ...
        }

Такая возможно может пригодиться, например, при формирвании подстраивающихся лендингов или А/Б тестировании.

Доработка плагина popup

В плагине popup версии 4.0 нужно добавить возможность затенения всего сайта (серая полупрозрачность), когда показывается popup-блок.

Плагин colorbox

Что-то там неверно со стилями. Может нужно обновить плагин до последней версии.

Кастомизация текстов всех емайл-сообщений

Надо сделать так, чтобы можно было настраивать тексты стандартных емайл-уведомлений. Также, возможно, имеет смысл реализовать пропускание этих текстов через спейциальный хук (хуки?) перед отправкой писем.

Плагин lightbox

Нужно переделать на новую версию http://lokeshdhakar.com/projects/lightbox2/

Новый автопарсер текста

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

Теоретически такая схема позволяет подключить сторонние визуальные редактора, которые сами формируются html-код. То есть для них никакой парсер не нужен. Это требуется протестировать.

Плагин parser_simple из LPF — просто парсер для тех, кто сам привык контролировать html-код. Чуть позже в него добавлю обработчик тэгов PRE и CODE — будет автозамена спецсимволов.

Поскольку отключились масса хуков по обработке текстов, то нужно прверить работу всех плагинов вроде вв-кода и т.п.

Чем быстрее проведем тестирование, тем быстрее пойдем дальше. Подключайтесь, все кому не лень. :-) О багах можно здесь сообщать.

Кастомизация формы плагина forms

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

-

Перенести компилятор less в плагин less_compiling

Полностью вырезать из ядра MaxSite CMS на уровень плагина.

Автоматически обновлять превьюшки файлов на странице создания записи

Предлагаю избавиться от ссылки "обновить" которая появляется после загрузки файлов, привязанных к записи. Видимо, можно сделать, чтобы превьюшки обновлялись автоматически. Если получится, вышлю пулл-реквест ;)

Полная кастомизация html-вывода

Задача довольно сложная. Причём её решение в каждом случае получается индивидуальным. Например форма логина. Я сделал так, чтобы саму форму можно было настраивать через type/loginform/units/form.php Аналогично — password-recovery, search и registration. Если в шаблоне нужна своя верстка, то кидаем только этот файл и правим под свою задачу.

Теперь в чем сложность. Некоторые type-файлы состоят из сложной if-логики. Например тип users и page-comment-form.php. Каким образом её отделить от содержимого пока не ясно.

Отсюда вопрос: какие ещё блоки, «зашитые» в систему вызывают сложности и требуют разделения?

Отмечу еуще один момент — плагины. Ну тот же forms. Форма жестко зашита в плагин. Можно попробовать её выделить отдельным файлом. Но поскольку там опять же сложная логика, то получится как-то так:

$f['format_textarea'] = '<p><label class="ffirst ftitle ftop" for="{id}"{require_title}>{description}{require}</label><span><textarea name="forms_fields[{key}]" id="{id}"{placeholder}{required}{attr}>{pole_value}</textarea></span></p>{tip}';

$f['format_tip'] = '<p class="nop"><span class="ffirst"></span><span class="fhint">{tip}</span></p>';

То есть это некий шаблон вывода разных html-участков формы. Насколько такой код сложен для понимания верстальщиков?

Требуется обновить jCarousel

Идущая с движком версия jCarousel v0.3.0-beta.5 имеет проблемы с работой в браузере Хром. http://forum.max-3000.com/viewtopic.php?f=2&t=7243&p=27941#p27941

В новой версии jCarousel проблема исправлена.

Не добавляет записи на главную

Установка последней актуальной версии из dev-ветки.
Создаю в админке блоговую запись, публикую, но она не добавляется на главную.

Организация работ и обсуждений

Основная ветка для загрузки — master. Из неё все посетители качают проверенную версию. Для разработчиков же используется ветка dev (и только dev — https://github.com/maxsite/cms/tree/dev). Она только для разработки. После того, как будет достигнута критическая масса изменений, я её объединяю с master и ставлю как новая версия для загрузки.

Все issue я рассматриваю и думаю как исправить. Если вы предлагаете что-то изменить, обязательно делайте issue, чтобы его можно было автоматом отслеживать. Я могу поставить метку, чтобы включить в работу.

Закрывайте свои issue или хотя бы пишите, что проблема решена. Если тикет не закрыт и не имеет ответной реакции в течение нескольких дней, я его принудительно закрываю (ищите их в closed).

Если ваш вопрос не относится к ошибкам MaxSite CMS, а просто нужна помощь и ответ на вопрос, то задавайте его на форуме https://github.com/maxsite/cms/discussions.

Ваши pull request я не принимаю автоматом. Но дело не в этом. Я проверяю все изменения вручную. Поэтому вы просто показываете изменения в pull (хз как это правильно называется) и там есть ссылка «Files changed» — там я и проверяю и беру изменения.