Итак, в планах:
- перевёрстка всех файлов шаблонов на валидный XHTML средствами блочной вёрстки;
(для реализации ждём дизайн, чтобы сразу всё сделать).- создание единого центра пользователя. Поясню.
сейчас:
http://bigstreet.ru/blog/user/admin/
http://bigstreet.ru/profile/admin/
http://bigstreet.ru/onair/user/admin/
будет:
http://bigstreet.ru/user/admin/blog/
http://bigstreet.ru/user/admin/profile/
http://bigstreet.ru/user/admin/comments/
бета доступна в SVN с ревизии 10- убрать поддомены для сообществ, и вообще не делать поддомены по-умолчанию.
ибо не на всех хостах можно править DNS.
но описать возможность прикрутки поддоменов к тому или иному модулю.
(закомментировать код);
SVN Revision 12 - перманентные изменения сделаны, осталось разделить на модули "community" и "communities"; есть предложение изменить название модулей на "group" и "groups" соответственно- прикрутка Sphinx Search Engine
(очень нескоро, но в планах);
- помесяцевое обновление TODO, регулярная (каждый месяц) отчётность каждого разработчика перед менеджером проекта, он же составляет отчёт о сделанном за месяц для юзеров;
- уже упомянутый файловый модуль;
- безболезненная возможность делать главной страницей сайта одну из страниц модуля page;
- хранение карт доменных объектов не в XML-файлах, а в PHP-Native файлах, с использованием массивов.
(прошу высказаться знающих людей "за" и "против");
- возможность «прикреплять» топик выше других (убиваем вебдваноль?);
- возможность при добавлении/редактировании топика задания названия ссылки перехода под кат (пример на хабре);
- ррр, убрать из файла установщика движка short tags (
). бесит.
- типизация постов. Простая запись, опрос, файл, ссылка, подкаст, перевод...
- замена ущербной pagination на нормальный класс для работы со страницами;
- интеграция класса form-checker`а (создание и автоматическая обработка форм классом);
- оптимизация, оптимизация…
я — программер, + верстальщик ))
SEO в BigStreet CMS )
Последний раз видел этот баг в ревизии 141 SVN'a
setDefaultAction в конфиге не работает, если модуль — блог, потому что blog в контроллере принудительно выставляет экшн = good если экшн не задан в запросе.
Надо убрать в modules/blog/controller.php 10-12 строчки включительно и тогда будет счастье.
если ID пользователя не задан:
http://bigstreet.ru/blog/user/
если ID пользователя заведомо ложный и его нет в БД:
http://bigstreet.ru/blog/user/tralyalya
если отсутствует ID топика:
http://bigstreet.ru/blog/topic/
то же, но уже в сообществах:
http://opensource.bigstreet.ru/topic/
если ID топика заведомо ложный, и его нет в БД:
http://opensource.bigstreet.ru/topic/80000000/
Во всех этих случаях как результат имеем кучу нотисов в месте вывода системных сообщений + как «бонус» раскрытие пути.
Сейчас ЭТО вываливается на ЛЮБОМ сайте, в основе которого лежит бигстрит, и похоже, до ЭТОГО вообще никому нет дела.
Самый просто выход — отключить нотисы в конфиге и в .htacess, но правильнее все же будет повесить обработчик на события в модуле blog, когда в БД отсутствуют значения topic_id и user_id.
P.S. Не могу не отметить, что обвешанный рекламными скриптами, bigstreet.ru ощутимо тупит. А прилепленный первой строкой к каждому посту begun, убивает всякую мотивацию что-либо постить…
старая сборочка рулит=)
анекдоты на funpeople.ru =)
Существующая пагинация ущербна? Я правильно понял? Можете обяснить почему?
И, раз уж о пагинации начал, сразу скажу: в SVN, в файле friendstape.action.php — ошибка. Из-за этой ошибки не работает навигация по страницам в ленте друзей. Поправить нужно всего одну строку в файле friendstape.action.php
заменить на строку:
Уверен, на всех сайтах, где стоит мод friendstape, присутствует та же самая ошибка. Т.ч. есть уникальная возможность исправить, пока ждем новую неущербную пагинацию =).
всё-таки у нас ООП-движок, поэтому есть возможность интегрировать пагинацию и вывод записей из БД, чтобы она создавалась автоматически.
пример - большинство фреймворков (Zend, Kohana, RoR)
насчёт френдленты - писал не я, пофиксим, тем более, что в модуле Blog она "deprecated" и скоро будет убрана оттуда, и перенесена в модуль User.
поэтому реализация будет весьма простой (возможно, даже простое наследование класса oProfile).
насчёт планирования...посмотрим.
Написать комментарий