Дальнейшие планы
В целом последняя версия MaxSite CMS (0.19) уже обретает более-менее законченные формы. Конечно же говорить о завершении этапа разработки пока рановато, но в каких-то направлениях основные работы практически завершены.
[cut Далее еще %wordcount% слов »]
Виджеты/плагины. Отработан сам механизм, вспомогательные функции, а также template для их создания. Самих же виджетов я сделал достаточно, чтобы удовлетворить самые разные потребности. Из того, что еще предстоит сделать отмечу только плагин для Sape, какой-то аналог «Ушек», аналог «Псевдокода» и xml-sitemap. Еще буду думать о замене лайтбокса, но хотелось бы увязать его с созданием галереи. В более далекой перспективе - плагин для голосования.То есть в целом ситуация с плагинами удовлетворительная. По мере новых потребностей я буду делать еще что-то, но в принципе особых сложностей я не вижу. Поскольку плагины могут распространяться отдельно от «движка», то, думаю что в целом, с дефолтным набором плагинов я уже окончательно определюсь через 1-2 обновления.
Шаблоны. С ними немного сложнее. С одной стороны на MaxSite CMS можно делать разные сайты с разным выводом данных. Но с другой, большинство потребностей именно в блогах, то есть с примерно одним набором типов данных и одинаковым выводом. По этой причине я выделил все файлы типов в отдельный каталог «type» и в версии 0.19 сделал возможность использовать в любом шаблоне дефолтный «type».Таким образом значительно упрощается разработка новых шаблонов - часть файлов может использоваться из default. При этом, если нужно как-то кастомизировать тип данных, то достаточно скопировать файлы вывода в свой шаблон и там его поправить. Более того, сохраняется возможность выборочного использования файлов разных типов.
Но здесь важный момент. Для разработчика шаблона нет надобности вдаваться во все эти тонкости - если он использует default-типы, то работа по созданию шаблона по сути сводится только к созданию html-разметки в нескольких php-файлах. При этом разработчик будет уверен, что его шаблон будет всегда работать с любой версией системы, поскольку в случаях изменений, default-шаблон будет обновлен вместе с системой.
Придумал я это из чистого прагматизма. На предыдущих версиях системы старые шаблоны оказываются «законсервированны», хотя уже появились новые возможности. Впрочем, какие-то изменения в шаблонах всё-равно неизбежны, но только в плане увеличения их универсальности и настраиваемости.
Собственно я подвожу к мысли, что уже сейчас можно пробовать делать свои шаблоны под MaxSite CMS. Вероятность того, что они будут совместимы с будущими версисями весьма велика. Более того, я планирую потратить время и сделать несколько вариантов шаблонов: с одной стороны дать возможность выбора, а с другой попробовать и показать как это реализуется на практике.
Получение и вывод данных. Здесь все более-менее стабильно. На данный момент у меня нет задач, которые требуют изменения этих функций. В основном это касается «mso_get_pages». Поэтому я уже буду её дорабатывать только в случае если возникнет какая-то новая потребность.Какие-то мелкие доработки системы еще предстоит сделать, да и они будут постоянно возникать, поэтому нет смысла на них останавливаться. Например часть работ еще предстоит доделать по комюзерам и авторам. Отдельным пунктом стоит вопрос локализации. Я уже придумал алгоритм: по сути это будет всего несколько функций и файлы перевода. Еще пока не решил: сделать ли основным языком русский или английский. С последним у меня определенные трудности, поэтому перевес пока в пользу русского.Из сложных вопросов - реализация удаленного постинга. Размышлений на сей счет много и потихонечку я подхожу к мысли, что использовать XMLRPC нет смысла. Технически это сделать сложней, чем обычный POST. Да и если строго, то XMLRPC это тот же самый POST, только предварительно данные формируются в XML. Именно в этом и заключается сложность его реализации - разборка и сборка XML-запросов. Мне же хочется сделать так, чтобы данные отправлялись самым обычным POST. Таким образом создание клиента станет совсем простым делом.Конвертер данных с WordPress будет. Но не сразу. Во-первых не все адреса удасться скопировать один в один. ЧПУ разные, а если в WP-блоге используется в адресе дата или какой-то префикс, то после конвертирования адреса точно поменяются. Так что здесь еще будут трудности. Во-вторых не все данные могут быть перенесены - всё-таки это разные системы и в чем-то они окажутся несовместимы. Так что конвертера не стоит ждать очень быстро.И на последок самый сложный вопрос - визуальный редактор, рубрики и сайбдары. Всех их объединяет JS. Точнее его отсутствие. Вопрос о включении jQuery в комплект уже решенный, поэтому потихонечку я с ним разбираюсь и уже есть подвижки. Но мне бы хотелось вначале добить основные вопросы до jQuery, а уже потом вплотную им заняться. Тем более поставленные задачи по JS я всё-равно пока не могу решить, следовательно и переживать особо не о чем.Вот примерно таковы планы. По текущему todo работ не очень много, поэтому я думаю, что их основная часть выйдет где-то на 2-3 обновления. Впрочем, если я придумаю еще какую-либо задачу, то это потребует некоторого времени. ;)
Самое главное, чтобы пользователь мог легко установить эту CMS!
У меня с двух раз не вышло. ((
С точки зрения популяризации - это огромный минус, на которым Автору нужно работать в первую очередь.
Иначе. все озвученные достоинства не будут стоить и копейки!
Читайте инструкцию в комплекте.
Достойный ответ!
Сомнений больше не осталось.
Ну вы как вопрос поставили, так я и ответил. ;)
Привет )
Очень хочется в панели Создания/Редактирования страниц выпадающее меню, или просто окошко, где можно было-бы указать размер шрифта. Часто возникает необходимость в одном посте использовать разные размеры шрифта.. это возможно ?
Заранее спасибо ;)
ой-ой-ой
пропустил выход новой версии, если там уже это пожелание учтено, то сорри :)
Ну это как раз из области визуального редактора. В идеале я бы вообще хотел сделать возможность прикручивать любые кнопки и любые коды. Но пока не знаю как... :(
Максим, два замечания.
1. Действительно система не устанавливается с нуля. После заполнения формы с начальными данными, url меняется на .../install/2 и опять выводится окно ввода начальных данных. И так до бесконечности.
2. А вот поле ввода пароля нужно как-то исправить, а то введённый пароль запоминается, и кто-то другой сможет подсмотреть. Может буквы скрыть точками?
Сложно сказать. В 99% случаев это проблема ЧПУ. Нужно взять соответствующий .htaccess.
По паролю я понял. Исправлю.
Хотя нет. Пароль вводится только один раз, инсталяция повторно никогда не запускается, поэтому вроде и подсмотреть не получится.
.htaccess точно тот, который был в комплекте. Я так понял, что у Билли те же проблемы были. А кто нибудь ещё устанавливал с нуля? Есть такие? А по паролю..., ну не знаю. Славик, чё-то я очкую (с)
Максим, убрал из .htaccess #subdir#/ и всё получилось. В чём подвох?
А вы читали инструкцию? ;)
Да, Максим, я читал инструкцию. И просто по ошибке взял для редактирования не тот файл. Прошу прощения за ошибку.
У меня ещё вопрос. Просто для самообразования. Если я захочу сделать свой шаблон для админки, я так понял просто добавлением папки с шаблоном в admin/temeplates/ дело не ограничится? нужно его ещё и в список где-то добавлять?
Да еще нужно указать каталог шаблона в admin_options/general.ini
Пусть лучше будет XMLRPC, чтобы пользователи могли использовать уже существующие блог-клиенты.
Да, сторонние блог-клиенты то хотелось бы пользовать. Но если у максима будет хороший(бесплатный!!!) клиент то с удовольствием буду им пользоваться
XMLRPC сложен в реализации. Это так, в теории, кажется все замечательно. Но н практике нужно продумать и серверную часть, и клиента. Еще этот разборка/сборка xml - тоже не подарок. Я же планирую сделать попроще: xml - вообще будет не нужен, а отправка обычным POST. Поэтому будет только предопределенные имена полей - и этого хватит для постинга и сам клиент по идее будет работать даже в обычном браузере.
Сразу возникает идею онлайн блог-клиента. Такой сервис можно сделать в принципе. Пользователь укажет адрес блога логин и пароль. А дальше все как по маслу.
Но программу отдельную тоже хотелось бы. чтобы она была довольно функциональной.
У меня есть неплохой опыт создания своего блог-клиента и я знаю, что самое сложное это именно обертка из XML. А организовать прием и передачу post-данных в программах - довольно простая задача.
Что касается online-клиент, то в принципе можно попробовать. Это обычная форма, которая отображается в браузере. Если уж на то пошло, то можно попробовать генерировать готовый html с формами на стороне сайта. Тогда можно вообще будет обычную html-страницу использовать. :)
А как будет у онлайн клиента с обратной связью? ну например блог клиенты же грузят себе список рубрик и тп. Чтоб пользователь мог выбрать нужную. Такое будет возможно?
Хотя сейчас стукнуло, что это же та же админка и получается :) смысл есть?
В принципе да, админка. Правда есть разница - только для одного действия - создание/редактирвоание страницы. Я пока не готов говотрить конкретно, но, кажется к FireFox есть плагин для удаленного постинга. Так, что скорее всего потребность всё-таки существует. :)
Да, к ФФ есть плагин. Можно кстати если есть знания и для Maxsite CMS сделать плагин :)
Очень странно работает перенос строки в визуальном редакторе - если это делать Enter ом в визуальном режиме, то строка обрамляется параграфом () - но этих тегов в режиме кода не видно. А если в режиме кода после каждой строки поставить (), то () опять же будет заменен на тег параграф - который не видно режиме кода. Можно ли это исправить?
Можно ли подключить другие визуальные редакторы? - хотелось бы попробовать Tiny MCE.
В предыдущем комментарии я имел ввиду теги P и BR
Редактор jWYSIWYG подключается как плагин (админки) в ...\application\maxsite\admin\default.php
mso_admin_plugin_load('editor_jw');
там еще есть закомментированные строки:
// mso_admin_plugin_load('editor_freert');
// mso_admin_plugin_load('editor_wymeditor');
У меня не получилось сделать WYMeditor плагином - было интересно
Вполне устраивает jWYSIWYG - если бы он каждую новую строку не делал параграфом, а просто переносил бы ее на новую - BR. Да, и в режиме кода хотелось бы видеть весь реальный HTML.
Нашел подходящий плагин (хак) jWYSIWYG : http://plugins.jquery.com/project/jWYSIWYG
Пробую :)
напишу редактор для своей CMS, да и с вами поделюсь =)
На форуме я уже высказывался по поводу этих br и p. Тут куча тонкостей. Грубо говоря все p удаляются, ставится только br, а потом переделываются в авторасстановке тэгов в p.
Но сам редактор я буду доделывать - меня он тоже не устраивает.
Извиняюсь за оффтоп, но наткнулся тут на ещё одного тёзку вашей CMS:
http://maxsite.kirov.ru/
PS. Жду появления на свет конвертера с WordPress на MaxSite. Как только будет таая штука - попробую перевести один из своих сайтов.
Да таких сайтов - пруд пруди. :) Кстати на нем ничего кроме заголовков нет. У тайцев есть своя MaxSite доступная для скачки.
По поводу диалога с Билли. Я тоже не могу установить систему в некорневую папку домена. Получаю сообщение:«Не могу выставить кодировку utf8 для соедниения с БД.» На мой вопрос на форуме Вы мне ответили:«Это значит, что либо ваша база не поддерживает установку кодировки, либо вы неверно указали параметры базы в конфигурации (database.php)»
Я намеренно выставил в database.php не верные логин и пароль. При установке системы получил другой ответ:«Не могу соединиться с базой данных.» На мой запрос к администраторам хоста о поддержке базой кодировки utf8 получил положительный ответ. На этом же хосте у меня есть сайт (правда в корневой папке) на wordpress 2.6.0 и там не было проблем с utf8 при установке. Где мне искать ошибку?
Ошибка возникает при попытке выставить кодировку таблиц командами SET NAMES и COLLATE. То есть ваша версия MySQL скорее всего не поддерживает эти команды.
Максим, спасибо огромное за движок. Такой вопрос, не планируешь ли ты в будущих версиях добавить возможность эмуляции поддоменов, создания пользовательских групп, коллективных блогов? Так сказать реализовать полноценную социальную сеть. Или это в принципе невозможно?
Честно говоря, особого желания нет. Технически наверное нет проблем, потому что поддомены реализуются на уровне .htaccess, а дальше разбор входящего url. Но для мультиюзера нужно решать много вопросов по базе данных доступы и т.д. Так что мне, честно говоря не очень хочется с этим возиться.
Очень жаль Макс, гимора много конечно, но система бы была супер:(
Может быть и не в тему. Но Будет ли возможность реализовать постраничную навигацию для каждой записи? Как бы аналог
в вордпресе?Вообще-то планировался. Но там нюанс в том, что это разбиение по сути в самом шаблоне (или плагине) должно быть, поэтому я как-то не стал уделять этому особого внимания. Я вообще не уверен необходимости разбивать текст на несколько страниц.
Несколько раз уже сталкивался с необходимостью размещать комментарии отдельно от текста, который (текст) оказывался довольно длинным. Что-то вроде site/page/slug/comments
Решал, естессна, несложным шаманством с шаблоном. И даже ничего, что нужно помнить про type/users.php type/comments.php и прочие виджеты, которые туда не ссылаются. Самая жесть оказалась там, где часть страниц (с рассказами) должна идти отдельно от комментариев, а часть (новости и т.п.) — вместе. Тут на выбор два решения: сделать везде отдельно или забить на ссылки в комментариях и у комментаторов.
Я это к тому, что разбивка длинных статей на отдельные страницы вполне может быть нужна. Может быть не везде можно обойтись несколькими взаимосвязанными постами.
Ой, кстати, только сейчас подумал (и проверил), вариант
site/page/slug/comments#comment-id работает даже когда комментарии на одной странице с постом! Классно! Задача решена!
Еще бы. ;-) Страница определяется по второму сегменту. Всё, что дальше её не интересует. Можно цеплять хоть пагинацию, хоть что угодно.