Честно говоря, не очень хочется это доказывать, т.к. задача стоит гораздо более масштабная и гораздо более сложная, нежели просто «переманивать людей с ЛС» — занять свою нишу на рынке CMS
Это уже проблема текстовок. Боюсь, на все случаи жизни вряд ли получится их придумать, поэтому, если какие-то значения по умолчанию меняются, лучше для своего сайта их придумать по-своему. Тем более, что сделать это элементарно: в папку /app/templates/language положить файл ru.php такого содержания:
Думал об этом, но в текущем варианте не подойдет. В админке wordpress, кстати, тоже нет иконок в подменю.
Иконки для подменю хороши для того, чтоб можно было более гибко адаптировать под низкое разрешение экрана — тогда меню можно по ширине сворачивать почти до размера иконки. Только где ж столько подходящих иконок набрать? (ключевое слово — «подходящих») Плюс возникает проблема в случае, когда плагины свои пункты в админку встраивают — там же тоже иконки должны быть
На сегодняшний день нет у нас готовых шаблонов, чтоб полностью были свободны от всяких ограничений — без всяких копирайтов и пр. Делается такой, но медленно
Да я бы хоть сегодня мог объявить, что стабильный релиз готов. Но опыт говорит мне, что наверняка есть баги, которые пока остались незамеченными. Поэтому нужно какое-то время, чтобы разные люди погоняли, потестировали, попробовали эту версию на зуб и сообщили об ошибках и недочетах. Надеюсь, исправление их не займет много времени.
В принципе, кто задумывает новые проекты, могут уже на этом релизе попробовать, насколько он годится для воплощения их задумок. Т.к. функционал меняться не будет, структура базы — тоже, а возможные баги гарантированно будут исправлены, то к чему время терять?
Но от переноса уже работающих проектов на эту версию стоит пока воздержаться.
Роадмап, в общем-то, есть, но в силу разных причин он требует серьезного пересмотра. Поэтому не хотелось бы его приводить в нынешнем виде. Но могу дать список наиболее важных задач, которые, на мой взгляд, нужно решать в ближайших релизах (это НЕ в порядке важности, а просто список, но пожелания по приоритетам принимаются):
1) Улучшение работы с медиаресурсами, в т.ч. с изображениями
Развитие и улучшение того, что было описано в этой статье altocms.ru/424.html. Нужно постараться унифицировать загрузку изображений во всех местах – топик, страница, фотосет, профиль, аватары сущностей и т.д.
2) Улучшение работы с дополнительными полями
Сейчас это сделано немного коряво и есть необходимость доработки этого функционала. Сюда же можно отнести доработку фотосета и опросов
3) Разработка новой системы шаблонов
Только ленивый, наверное, еще не пнул нынешнюю схему шаблонизации. И вполне заслуженно. Одна беда – все знают, что есть плохо, но никто не знает, как сделать хорошо. Во всяком случае, никто не говорит, как сделать, чтоб было хорошо. Разумеется, есть некоторые соображения, как это сделать, но будем благодарны за любые соображения и практические советы. Подчеркну – речь в данном случае не о том, как что должно выглядеть, а как спроектировать схему так, чтобы адаптировать скин можно было гораздо проще и легче, чем сейчас.
В базе есть уже поле user_profile_name. В сущность User, думаю, нужно добавить метод getDisplayName() (это небольшая доработка движка), а в шаблонах для отображения юзера использовать этот метод вместо getLogin() (доработка шаблона).
А в админке, пожалуй, стоит задать формат вывода этого метода (примерно так же, как сейчас задается формат УРЛа топика):
* логин
* имя пользователя
* имя пользователя (логин)
* имя пользователя (ИД)
Уже есть в планах. Но тут вот какой нюанс: плюс логина в том, что он уникален, а имя (даже с фамилией) может оказаться неуникальным, и поэтому может быть путаница.
Поэтому тут не преимущества надо расписывать, а хотелось бы предложения услышать, как лучше решать возможные коллизии.
Правильно ли я понимаю, на диске будет храниться ТОЛЬКО оригинал
Нет, не правильно. Тут речь о том, что в большинстве случаев нет необходимости для всех изображений, лежащих на диске, заранее создавать все размеры, которые потом могут пригодиться. При обращении, если нужного размера нет, то выполняется ресайз и новое изображение сохраняется. При повторном обращении отдается картинка, созданная раньше.
Во многих плагинах PSnet'a используется его же плагин для сохранения настроек (в т.ч. настроек многих его плагинов). И он как-то уже сказал, что адаптировать под Альто он это не собирается
Запрос принят. Вообще есть очень большое желание обеспечить полноценную поддержку PostgreSQL, но остро не хватает кого-то, кто целенаправленно бы занимался тестированием под этой базой и указывал на подобные «нюансы», давал бы рекомендации, как лучше это сделать.
Лог обычно здесь: /_tmp/logs/error.log
Подчеркну: не обязательно весь языковой файл туда класть, если нужно изменить одну фразу, то достаточно только изменяемую фразу в этот файл вставить.
В принципе, кто задумывает новые проекты, могут уже на этом релизе попробовать, насколько он годится для воплощения их задумок. Т.к. функционал меняться не будет, структура базы — тоже, а возможные баги гарантированно будут исправлены, то к чему время терять?
Но от переноса уже работающих проектов на эту версию стоит пока воздержаться.
1) Улучшение работы с медиаресурсами, в т.ч. с изображениями
Развитие и улучшение того, что было описано в этой статье altocms.ru/424.html. Нужно постараться унифицировать загрузку изображений во всех местах – топик, страница, фотосет, профиль, аватары сущностей и т.д.
2) Улучшение работы с дополнительными полями
Сейчас это сделано немного коряво и есть необходимость доработки этого функционала. Сюда же можно отнести доработку фотосета и опросов
3) Разработка новой системы шаблонов
Только ленивый, наверное, еще не пнул нынешнюю схему шаблонизации. И вполне заслуженно. Одна беда – все знают, что есть плохо, но никто не знает, как сделать хорошо. Во всяком случае, никто не говорит, как сделать, чтоб было хорошо. Разумеется, есть некоторые соображения, как это сделать, но будем благодарны за любые соображения и практические советы. Подчеркну – речь в данном случае не о том, как что должно выглядеть, а как спроектировать схему так, чтобы адаптировать скин можно было гораздо проще и легче, чем сейчас.
Хочу напомнить несколько своих статей на эту тему, возможно, кто-нибудь захочет продолжить:
Скины и шаблоны — термины и определения
Общий принцип организации шаблонов
CSS-классы — общий подход и стандарты
4) Улучшение функциональности админки
Улучшение работы с виджетами, с медиаресурсами, создание меню сайта из админки.
5) Улучшение поддержки PostgreSQL, в т.ч. и соответствующая доработка установщика
Разумеется, это не все, планов-то громадье, но это, ИМХО, наиболее важное. Если кто-то считает, что есть более важные и насущные вещи — пишите
В базе есть уже поле user_profile_name. В сущность User, думаю, нужно добавить метод getDisplayName() (это небольшая доработка движка), а в шаблонах для отображения юзера использовать этот метод вместо getLogin() (доработка шаблона).
А в админке, пожалуй, стоит задать формат вывода этого метода (примерно так же, как сейчас задается формат УРЛа топика):
* логин
* имя пользователя
* имя пользователя (логин)
* имя пользователя (ИД)
В итоге получим более-менее универсальное решение
Поэтому тут не преимущества надо расписывать, а хотелось бы предложения услышать, как лучше решать возможные коллизии.