|
|
roadmap
Ход работ
Планы (ближайшие)
- - Сделать в админке страницу загрузки файлов/картинок.
- - Сделать импорт данных из WordPress.
В связи с открытием моего сайта, дальнейший ход работ планирую публиковать на http://max-3000.com/
15 апреля 2008 г.
- + Подключил таблицу комментаторов. Принцип будет такой. Существует одна таблица комментариев. Есть таблица авторов/юзеров (users). Так же есть таблица comusers - она предназначена только для регистрации комментаторов. В форме комментариев есть переключатель (radio), которым определяется будет ли комментатор регистрироваться или же хочет остаться анонимом. Если анонимом, то у него есть одно единственное поле - имя. Причем имя это автоматом проверяется, чтобы не было ссылок адресов и т.п. Естественно, никаких ссылок на сайт анонима нет. Если же посетитель хочет зарегистрироваться как комментатор, то он указывает свой email и пароль. Сразу же можно оставить комментарий. После того, как он нажал кнопку отправить, проверяется существование в таблице comusers такого email. Если нет, то этот комюзер регистрируется и ему отправляется ссылка на активацию (пока не реализовал). Сразу же от имени этого комюзера добавляется комментарий. Ссылка ведет на его персональную страницу (users/его номер). Здесь будет возможность указать свои данные: сайт, аська, комментарий и т.д. Если же комюзер зарегистрирован, но неверно указал пароль, то этот комментарий не публикуется. Данная схема позволяет разделить авторов (обычных юзеров) от комментаторов. Соответственно для комментаторов можно устравивать рейтинги, делать персональные страницы, не заботясь о том, что они могут получить доступ в админ-панель. Происходит разделение доступа. Чтоже касается обычных авторов, то если автор залогинен, то он публикует комментарий без ограничений. При этом на его ник формируется ссылка, которую он укажет в своем профиле. Впрочем в цикле вывода комментариев доступны все поля профилей как авторов, так и комюзеров.
- + Немного подправил функцию редиректа. Добавил еще один «header location». Почему-то redirect не всегда срабатывал.
- + В связи с комментаторами много мелких правок.
12 апреля 2008 г.
- + Подключил виджет «Календарь». При обычной странице выводится текущий месяц. Если же это тип «archive», то смотрятся сегменты дата/месяц и выводдится календарь на них. Ссылки формируются на архив по дням: archive/год/месяц/день. Сам вывод записей уже в странице с типом «archive». В календаре неплохое оформление, которое я вынес в css.
- + Сделал вывод шаблона архива (archive).
- + Подключил RSS. Поскольку у меня получилась функция получения записей mso_get_pages универсальной, то и feed автоматом делает нужные выборки. В общем для получения rss для любого типа достаточно дописать к адресу «/feed». Единственное, что потом наверное нужно будет что-то придумать по подписке на комментарии.
11 апреля 2008 г.
- + Добавил в функцию получения страниц mso_get_pages еще и возможность указать требуемый тип. По-умолчанию используются два типа «blog» и «static». Сейчас можно явно указать какой тип нужно получать.
- + Сделал в виде плагина-виджета вывод последних записей. С его помощью можно вывести и статичные страницы (static).
10 апреля 2008 г.
- + Некоторые мелкие исправления в пагинации страниц. Ссылка формируется с учетом типа страницы.
- + Исправил ошибку в роутере. Как оказалось у меня стояло принимать все непробельные символы. Это создавало проблему с выводом меток с пробелами.
- + Подключил вывод в шаблоне страниц, рубрик, меток. Работает пагинация.
- + Функция получении страниц (mso_get_pages) разбил на основную часть и функции, которые формируют сам sql-запрос. Как я заметил, так гораздо проще отслеживать код для разных типов данных.
- + Опять вернулся к функциям рубрик. Пережде всего mso_cat_ul, которая выводит их список и mso_cat_array_single, которая получает все данные рубрик в один массив. Пришлось добавить еще один запрос к БД, который позволил сформировать в кажой рубрике массив из номеров страниц (в этой рубрике). Теоретически это можно использовать для разных целей, но для меня важно было получить общее количество записей в каждой рубрике. То есть теперь при выводе рубрик можно выводить и количество страниц. Появилась опция - отображать рубрики без записей и немного усовершенствовал формат вывода. Теперь автоматом для каждого элемента li указывается classы с учетом вложенности (level) и количества записей (count): <li class="level2 count7"> - таким образом можно настроить оформление для разных целей.
- + При создании и редактировании страниц заменил отображение рубрик на новые функции.
- + Версия 0.09
8 апреля 2008 г.
- + Встроил постраничную навигацию в функцию выборки страниц. Теперь страницы перелистываются как положено.
- + Добавил функции для вывода страниц в шаблоне. Это вывод рубрик, меток, edit pages, Обсудить, дата, «Далее...».
- + Сделал вывод заголовка. Все функции универсальные, то есть у них есть параметры, которые можно использовать для разных случаев. Например mso_page_title() может выводить заголовок как в виде ссылки, так и просто текстом. Возможно, что часть функций будет еще расширена, поскольку будет еще вывод записей в зависимости от типа страницы.
- + Немного оптимизировал выборку данных при выводе страниц. С учетом кеширования, вывод главной страницы расходуется всего 4 sql-запроса. Потребление памяти php - всего около 2МБ.
- + Для сайдбаров решил использовать виджеты. Описание добавил здесь же в отдельной странице в вики. Пока я не готов вынести их настройки в админ-панель, но на будущее необходимо сразу решать вопросы унификации. С учетом того, что я собаку съел на виджетах WordPress, то сразу решил делать нормально. Скорее всего в качестве эксперимента какие-то выджеты-плагины я вынесу в админ-панель для исследований. Впрочем все равно их придется явно прописывать в шаблоне.
- + Немного подправил шаблон по дизайну и функционалу.
7 апреля 2008 г.
- + Переделал функции рубрик. После того, как опубликовал у себя просьбу с помощью(http://maxsite.org/kak-iz-dereva-sdelat-ul-li-strukturu), получил вариант от TedBeer (http://tedbeer.net/wp/), поэтому и решил его взять за основу. Получилось довольно неплохо. Итоговая функция mso_cat_ul() принимает формат вывода ( %NAME% %ID% %DESC% %LEVEL% %LINK% %CHECKED%), массив для %CHECKED%, массив для class="selected", класс для основного списка, поле сортировки и порядок сортировки. То есть с помощью этой функции можно выстроить список практически для любой задачи, включая и чекбоксы, и раскраска списков с помощью стилей. Исходные данные получаются, как и прежде mso_cat_array_single. Это всего один запрос к БД. С учетом кэширования - 0. Также можно использовать и свой кастомный исходный массив. Правда в том же формате.
4 апреля 2008 г.
- + Подключил плагин пагинации, которая позволяет листать страницы. За основу взял чужой скрипт и почти полностью его переделал.
3 апреля 2008 г.
- + Сделал дефолтный шаблон. Точнее пока основной дизайн. Уже на нем буду отрабатывать функции для вывода текстов. В дизайне использовал свою фотографию из путешествия к Эски-Кермен. Это гора-крепость в Крыму. Очень красивый вид.
2 апреля 2008 г.
- + Подключил вывод записей в шаблоне. Так что сегодня тот день, когда с помощью MaxSite CMS можно построить реальный сайт. Теперь я вышел на финишную прямую. :-)
1 апреля 2008 г.
- + Доделал страницу редактирования страниц. Теперь можно и создавать страниц и их редактировать.
- + Версия 0.08
- + Сделал удаление страницы. Решил, что в XMLRPC эту функцию нет смысла добавлять, поэтому сделал через обычную форму.
- + Реализовал синонимы коротких ссылок. Это нужно на тот случай, если не указан первый сегмент в url. Например у нас есть страница id=7 с короткой ссылкой «about». В этом случае синонимами будут следующие ссылки:
То есть алгоритм такой: если обычным способом получается page_404 (т.е. не найдено), то дополнительно проверяется существование page с таким slug. Если такой нет, то проверяется рубрика с таким slug. И уже если и этого нет, то отдается в page_404. Если же есть, то модифицируется тип страницы и управление передается вьюверу page или category. Следует учесть, что для каждого такого поиска выполняется дополнительный sql-запрос.
30 марта 2008 г.
- + Сделал страницу всех страниц. Рядом ссылка на редактирование.
29 марта 2008 г.
- + Доделал одну из самых сложных задач: публикация страниц. У страницы можно указать: заголовок, текст, рубрики, метки, короткую ссылку, парметры обсуждения, разрешения на добавления в rss, автор, статус (опубликовать, черновик, личное), пароль для чтения, родительская страница. Все реализовал через XMLRPC. Осталось доделать дату публикации (сейчас она автоматом ставится), дату deadline, а также метаполя. Метки сделаны через метаполя, поэтому часть задачи уже реализована.
26 марта 2008г.
- + В свете того, что я разобрался что такое twitter :-), сделал небольшой плагин, который отображает любую ленту. Используется кэширование, а также можно задать формат вывода и формат даты. Работает через MagpieRSS. Думаю что эта небольшая библиотека будет востребована и в будущем, поэтому есть смысл её включить сразу. Разместил в common.
25 марта 2008 г.
- + Два дня ушло на то, чтобы сделать работу с рубриками. Основная проблема в том, что рубрики могут иметь родителя. Таким образом формируется "дерево" рубрик. Задача сложна тем, что использует рекурсию и выполняет за одну итерацию цикла (обход) запрос к БД. Таким образом при большом количестве рубрик создается примерно столько же и запросов. Всё это мне не нравилось, поэтому я решил сделать обход массива в цикле. Я знаю про сторонние библиотеки, но мне они оказались не нужны, поскольку содержать много лишнего кода. В итоге оставновился на двойном решении. 1. Для построения иерерхической структуры ("дерево") рубрик, выполняется функция mso_cat_array, которая возвращает массив с той же структурой вложенности, что и рубрики. 2. Если нужна "плоская" модель рубрик, то используется функция mso_cat_array_single, где все рубрики находятся на одном уровне, зато у них расчитаны все parents (родители), childs (потомки) и level (уровень - левый отступ). Таким образом, в зависимости от задачи можно использовать либо одну, либо другую. Разница в том, что в первом случае используется множество запросов к БД, а во второй функции всего один. Для того чтобы снизить нагрузку на БД, используется кэширование.
- + Начал формировать страницу создания записи. В целом данные готовы, но все уперлось в рубрики - хотелось сразу сделать вывод "дерева". Для этого на основе предыдущего пункта сделал функцию mso_cat, которая и выводит нужные данные. Функция поддерживает формат данных (%NAME%, %ID%, %DESC%).
22 марта 2008 г.
- + Доделал настройку пользователей. Можно редактировать существующего пользователя. Работает через метод XMLRPC.
- + Сделал добавление нового пользователя. Также работает через XMLRPC.
- + Добавил новые разрешения для дефолтных страниц админки. Проверка доступа в самих админских плагинах.
- + Немного подправил вывод админского меню: теперь, если в пункте меню нет подпунктов, то он вообще не выводится.
- + Исправил метод основного контролера "url", чтобы он удалял тэги из входящего url-параметра. Во избежании XSS-атаки.
- + Примерно также исправил mso_redirect - тоже для избежания XSS-атаки.
5 марта 2008 г.
- + Сделал страницу выбора шаблона.
- + Частично сделал страницу редактирования пользователя. Будет через xmlrpc работать.
3 марта 2008 г.
- + наконец-то доделал страницу настроек групп. Сделал в виде таблицы-матрицы: сверху группы, слева - действия, а в самой таблице - чекбоксы. Отмечаем нужные и сохраняем. Думаю, что такая форма не вызовет особых сложностей.
- + Там же добавил возможность создавать и удалять группы.
28 февраля 2008 г.
- + Доделал страницу настроек плагина. Вместо одиночных кнопок для каждого плагина решил всё-таки сделать просто чекбоксы, а внизу кнопка нужного действия для отмеченных: включить, выключить, деинсталировать.
- + Самое главное, что я потихонечку определился с группами пользователей. Поскольку на ум ничего более гениального не идет, то схема будет более менее простая. Описание выложил на отдельной странице здесь же http://code.google.com/p/maxsite/wiki/user_groups
27 февраля 2008 г.
- + За эти пару дней еще раз пределал контролер. А то получилась такая штука: в самих методах вызывается всего одна функция с какими-то параметрами. Вот я и подумал, что есть смысл сразу же в remap смотреть, что за метод и вызывать конечную функцию. Из всего этого остались только методы install и page_404.
- + Отказался от $MSO_data. Изначально идея была в том, чтобы в момент инициализации создавался объект $MSO. А в $MSO_data хранились только некоторые настройки (не известные на момент инициализации), например тип данных или сессия. В итоге я и сам начал путаться где и что хранится. Поэтому сейчас все перенесено в $MSO.
- + Немного подправил логику включения плагинов. Теперь схема такая: подключается lib/maxsite в ней создается объект $MSO. На этом этапе выполняется инициализация и загружается часть конфигурации. Но, поскольку здесь мы еще не знаем ни тип данных (метод), то перед вызовом вьювера мы подключаем плагины, после этого выполняем хук "init" и определяем тип данных. Таким образом плагины подклчаются после инициализации и перед вьювером. Это позволяет в плагинах происывать хуки для самых ранних действий.
- + Изменил mso_config.php. Поскольку у нас единый $MSO, то и смысла в $config отпал. Вместо этого файл просто подключается, а что там делается определяет уже разработчик. Единственное, что пришлось придумать функцию mso_autoload_custom, которая срабатывает перед подключением плагинов.
- + Добавил возможность сохранять в опциях сложные объекты и массивы. Естественно через сериализацию. Работает все прозрачно. При сохранении опции (mso_add_option) проверяется тип значения (value) и если он не скалярный, то выполняется сериализация и в начало дописывается его признак «serialize». При считывании же - процесс обюратный. Если есть признак, то он удаляется и выполняется унсериализе.
- + Добавил плагин, который подключает настройки шаблона в админ-панель. Причем сама страница настроек находится в файле options.php текущей темы. Это из расчета того, что можно какие-то настройки шаблона вынести в админку. При этом саму админку, есно, менять не нужно.
- + Почти доделал подключение плагинов через админку. Пока выводится их список, а также кнопки вкл/выкл и удаление.
24 февраля 2008 г.
- + Немного переделал основной контролер. Немного упростил за счет вынесения повторяющегося код в отдельную функцию.
- + Упростил функцию инициализации. Изначально было две функции, одна из которых возвращает конфигурацию, а вторая выполняет хуки инициализации. Решил, что есть смысл их объединить.
- + Добавил в model.sql запросы на создание таблиц БД. Отработал инсталятор. Вроде ошибок нет.
- + Добавил в админку страницу настроек основных опций. Подключил, настроил. Все работает. Добавление и изменение.
- + Добавил в админку настроек типов страниц. Все работает. Правда я не стал сильно заморачиваться насчет оформления, думаю, что это оставим на потом. Сейчас главное отработать сам функционал.
- + Добавил несколько вспомогательных функций для построения админских страниц. Например добавление горизонтального меню. Проверка входящих данных (POST), а также ряд других. Получилось, что любая форма обрабатывается совсем небольшим кодом.
- + Для работы с рубриками сделал несколько методов XMLRPC: редактирование, удаление и добавление рубрик осуществляется именно через этот интерфейс. Это несколько увеличивает потребление ресурсов, но работает без проблем. И код получается совсем компактный. При чем удобство еще и в том, что корректность данных проверяется уже на стороне XMLRPC-сервера.
- + Добавил функцию mso_slug, которая преобразует короткие ссылки (ЧПУ) в нормальные английские. При этом убираются все служебные символы, чтобы получился корректный url.
- + Еще ряд функций и доработок. Версию увеличил до 0.05.
18 февраля 2008 г.
- + Подключил авторизацию пользователей при входе в админку. То есть теперь вход только по паролю.
- + Добавил каркас для организации RSS. Решил всё-таки перенести feed.php в сам шаблон. Проблема там в том, что тип данных определяется в самом шаблоне. Если же оставить feed.php в views, то придется дублировать код получения данных, а так же будет все в одном месте. Соответственно немного упростился основной контролер.
16 февраля 2008 г.
- + Решил вместо редактора tinyMCE использовать http://FreeRichTextEditor.com. Прежде всего решение принял из-за того, что freert гораздо меньше: 160Кб вместо 1.4Мб у tinyMCE. Кроме этого в freert уже решен вопрос с отображением текста в html-коде и даже существует предпросмотр. Поэтому переделок получилось минимум. Редактор выполнил в виде плагина. Для админки он подключается автоматом.
- + Редактор freert вызывается одной функцией. В параметрах указываются нужные кнопки, панельки, режимы, нужное оформление и т.д. То есть сам редактор завернут в отдельную функцию, которой можно управлять по своему усмотрению.
- + Подключил редактор freert в админку в создание новой записи.
- + Определился с админскими плагинами. Они будут находиться в admin/plugins. Причем сделал так, чтобы всё управление было передано в эти плагины. По функциональности и структуре они ничем не отличаются от обычных. Разница только в том, что находятся в другом месте и обычно нужно подключать сразу при входе в админку. Собственно поэтому и разделил их.
- + Подключил базовые админские плагины admin_home (главная страница админки), admin_cat (рубрики), admin_menu (вывод меню. Само меню хранится в массиве - здесь же просто его отображение), admin_options (настройки), admin_page (записи), admin_plugins (плагины) и admin_users (пользователи). В каждом плагине можно использовать дополнительные действия.
- + Переделал темплейт админки.
- + Добавил функцию mso_remove_hook, которой можно удалить из хуков определенную функцию.
- + Подправил вывод дефолтных данных в админке.
- + Сделал функцию mso_hook_present - проверяет существование хука. Для админки оказалось полезная вещь.
- + Для работы с текстом добавил функций: mso_text_to_html (конвертирует html-спецсимволы в нормальный html), mso_auto_tag (расстановка тэгов - функцию внаглую выдрал из WordPress/wpautop).
- + Наконец-то добрался до сессий и сделал авторизацию. С куками решил пока не делать. Сессии всё-таки универсальней. Но вообще вопрос пока открыт.
- + Сделал функцию вывода формы логина mso_login_form. Достаточно указать параметры для настройки оформления. Можно указать куда редиректиться. Проверяется xss-атака на основе сессий: если сессия истечет, то форма автоматом средиректит на страницу логина.
- + В шаблоне ввел еще один тип страницы loginform, где можно кастомизировать дизайн формы логина.
- + Функция is_login проверяет залогинен ли пользователь.
- + Изменил версию на 0.04.
11 февраля 2008 г.
- + Подключил xmlrpc. Вначале была идея отложить эту штуку на более поздний срок. Но когда стал делать админку, то решил взять тайм-аут. Дело вот в чем - если делать админку как у всех, то есть переносить админские функции в отдельный админский каталог, то неизбежно можно столкнуться с тем, что админских функций будет очень много. Ну представим себе, что нужно сделать не только получение списка записей, форму отображения; придумать сам вывод и действия над этим списком. После этого нужно сделать редактор и т.д., и т.п. То есть получается не только очень много, но и путано. WordPress - как раз и есть пример такого подхода. В итоге получается, что изменение одной функции или части «движка», неизбежно влечет за собой изменение и других. Я же исхожу из того, чтобы админка выполняла только роль менеджера. То есть ей должно быть абсолютно все равно: отображает ли она текстовый редактор или страницу настроек плагина Демо. Получается, что нужен единый интерфейс взаимодействия админки (читай "действий в CMS") с любыми другими частями системы. Xmlrpc для таких вещей как раз и подходит. В итоге получается такая схема: есть некий плагин (например только для админки), который получает список записей и выводит их списком и рядом указывается ссылка на редактирование. Обычный подход заключался бы в формировании SQL-запроса и вывода данных. Потом у нас появился бы другой плагин, который хотел бы получить эти же данные, но оформить их по-другому. Дальше третий и тоже ему нужен список для своих нужд. Вместо того, чтобы перекладывать формирование запросов в плагины, мы предложим ему сформировать xmlrpc-запрос, где нужно будет указать метод/действие и параметры, например количество записей. После этого выполняется, например такое «mso_xmlrpc_send('getRecentPostTitles', array('23'))» чем и получаем готовый результат - 23 последних записи. Но главное во всей этой вещи в том, что логику получения мы переносим в одно место, а вот отображение результата в другое. Кто в этом понимает, тот сразу уловил, что это дает дополнительные возможности по работе с программами офф-лайн клиентов. То есть ничего не стоит прописать API под blogger, metaWeblog или mt: указал их методы на свои функции. :-) Да и еще. Очень хочется, уже не знаю что с этим делать - так это перенести все админские функции именно в плагины. Потому что весь функционал для подключения к админке в принципе уже есть - и не имеет значения будет ли это какие-то особые функции, или чужой плагин. Механизм тот же!
7 февраля 2008 г.
- + Добавил функцию mso_admin_url_hook которая цепляет хук, который срабатывает в админке. Для объяснения выложу плагин Демо. Там все очень просто. Также предусмотрел проверку чтобы хуки не цеплялись на зарезервированные url.
- + Благодаря http://www.simplecoding.org/ (Владимир), а также http://mihailt.wordpress.com/ (Михаил?) сделал автоопределение базового url. Теперь его не нужно прописывать в конфиге. Пусть сам определяется :).
- + Там же, благодаря http://rmcreative.ru/ (Sam, Александр) избавился от единственного хака CodeIgniter, который я сделал, чтобы срабатывал мой 404-метод. Все оказалось очень просто и все работает. Спасибо.
28 января 2008 г.
- + Доделал окончательный вариант инсталяции. Как оказалось для нормальной работы достаточно всего двух таблиц - options и users.
- + Добавил отображение количества запросов к БД. Хм, пока неплохо: 0 или 1.
- + Добавил отдельную переменную-флаг, которую можно выставить в true если инсталяция уже выполнена. Если этого не делать, то будет проверять существование таблиц - а это лишний запрос в БД.
- + Начал работать над админкой. Сделал каркас-дизайн. Изменяться и подключаться будет очень просто. Функционально будут четыре функции для вывода header, menu, content и footer. Само оформление задается в шаблоне. Там же css.
- + Продумал и реализовал схему подключения любого плагина или функции к админке (в content). Для этого в плагине прописывается хук на admin_init для своей функции. В этой функции делаются две вещи. Первая - добавляется свой пункт в меню (функция mso_admin_menu_add). Вторая - создается свой динамический хук 'admin_url_'.$url, где $url - плагин. Например для плагина Демо это будет admin_url_demo. Работает до безобразия просто: когда мы обращаемся к какой-либо странице админки, например site/admin/demo, то система смотрит третий параметр. В нашем случае это "demo". Теперь при выводе content мы указываем отработать хук на admin_url_demo. Ну а поскольку такой хук у нас есть, то и выполнится функция плагина.
- + Разобрался с меню в админке и сделал для этого специальную функцию. Главное, что я всё-таки смог сделать так, чтобы меню было двухуровневым и можно было бы указать сортировку пунктов. Ради интереса полез посмотреть как админское меню реализованно в WordPress. Ужас!!! Огромное мессиво кода и куча циклов, которые обрабатывают массивы меню-подменю... Для сравнения - моя функция 5 строчек. :)
27 января 2008 г.
- + Отработал схему таблицы options, где хранятся опции с группировкой по типам. С группировкой - для того, чтобы разделить опции для сайта, или каких-то плагинов.
- + Также добавил таблицу пользователей.
- + В инсталяции добавил создание этих таблиц и занесение основных данных.
- + Добавил функцию mso_md5, которая будет служить заменой стандартной md5. В общем для безопасности.
- + Сделал функцию для работы с опциями: mso_add_option('ключ', 'значение', 'тип'). Данные сразу добавляются в базу данных.
- + Функция mso_refresh_options() служит для обновления опций из базы данных. Для кэширования служит глобальный массив. По-уму, так нужно обновлять без обращения к БД. Достаточно добавить изменения в массив по образцу. Но тут нужно еще думать.
- + Подключил функции кэширования на диск. mso_add_cache - для добавления даных в кэш и mso_get_cache - для получения значения из кэша.
- + Добавил функцию mso_initalizing, которая будет выполняться в момент инициализации сайта. В неё присутствуют два хука: start_init и end_init. Это если какие-то плагины будут себя навешивать на эти события.
- + Добавил в автозагрузку базу данных. Как ни крути, а система будет на БД работать, так что подключение все равно нужно, хотя бы для того, чтобы получить данные о конфигурации.
25 января 2008 г.
- + Переделал файлы под CodeIgniter 1.6 (еще не вышел). Как оказалось в нем есть изменения в хранении данных (массивы). Поэтому решил, что есть смысл сразу использовать новую версию. К тому же в 1.6 внесли кодировки в конфигурацию БД - тот же способ, что и я делал для 1.5.4
- + Добавил пути для admin. Для эксперимента подключил tiny_mce в качестве редактора. Всё работает.
- + Изменил версию на 0.02
21 января 2008 г.
- + Добавил в контролер тип "admin" - это на будущее доступ к админ-панели. Запросы можно делать например так:
- http://сайт/admin/page/edit/23 - редактировать страницу 23
- http://сайт/admin/page/new - новая страница
- + Добавил тип для ссылок-редиректов. Вот такая ссылка: http://сайт/url/maxsite.org - клик на которой будет переход на maxsite.org. То есть внешняя ссылка станет внутренней. :)
20 января 2008 г.
- + Добавил hooks хуки
- + Добавил плагины
- + Сделал демо-плагин - выводит вначале и в конце body полоску с текстом
- + Сделал и подключил как плагин Lightbox
- + Сделал плагин RandomText - выводит цитаты в случайном порядке
19 января 2008 г.
- + Сделал инсталятор. Структура данных еще не готова, поэтому сами SQL-запросы вывел в отдельный sql-файл. Эта возможность позволит будущим вебмастерам сразу же кастомизировать свою структуру.
- сам инсталятор запускается так: http://сайт/install
- + В инсталяторе есть возможность установить демо-данные. Пока админка не готова, будем ручками их добавлять.
до этого
- Много чего. :)
Sign in to add a comment

чтобы не растекаться мыслею по древу, - стоит уйти от ограничения CodeIgniter? вида модуль/действие.
Вот мой код для REST. Ещё есть нечто полезно-похожее для блоков.
index.php <?php
require_once(путь конфига); require_once(PATH_INC. '/ModuleBase?.class.php');
ModuleBase?::runAppropriateModule();
?>
ModuleBase?.class.php <?php
class ModuleBase? {
}