Сначала удивился — не может быть, чтоб авторизация не работала. А потом сообразил — наверняка свежую версию Альто с гитхаба не скачивали. В общем, добавил примечание в топик — для того, чтоб попробовать Start-Kit, нужна свежая версия Альто
Что касается маркеров, то я глубоко убежден, что маркеры — это самое злейшее из зол, что были придуманы в ЛС. Всегда был против их использования, как только внимательно посмотрел, как они работают. Поэтому их выпиливание — это вопрос решенный (я редко бываю столь категоричен, но тут особый случай).
Хуки, в принципе, можно было б юзать, если б jQuery нам не давал очень простого (и ставшим стандартом) аналога — триггер событий. Возможно, я упускаю какие-то нюансы, но я не вижу, чем же самопальные js-хуки лучше триггеров.
Поэтому в отношении скриптов планы такие:
1) Оставить набор старых js-скриптов для работы с шаблонами LS-style (сейчас они в папке /templates/frontend/ls/js/)
2) Скрипты для работы с шаблонами Alto-style (/templates/frontend/libs/) очищаются от маркеров и хуков и переводятся на триггеры.
Согласен однозначно! Есть ощущение какого-то хаоса, когда погружаешься в детали, слишком уж бессистемно все именовалось — файлы, классы, идентификаторы… Я уж не говорю о попытке создать некий альтернативный фреймворк а-ля Бутстрап, где реализуется точно такой же функционал, но как-то по-своему.
Поэтому переход на bs-скрипты отчасти позволят вообще отказаться и от лишних классов, и от лишних js-функций.
Что касается именований, то пока сформулировано только одно четкое правило: id модальных окон четко увязаны с названием файлов-шаблонов этих окон.
И есть еще одно (пока не очень четкое) правило: привязка js-событий должна выполняться к специальным классам, с префиксом «js-». Но сами именования этих классов пока как-то не регламентированы. Плюс есть случаи, когда события привязываются к id.
{if $oUserProfile->getProfilePhoto()}
<img src="{$oUserProfile->getProfilePhoto()}" alt="photo" class="profile-photo" id="foto-img" />
{else}
что-то выводим, если фото нет (иди ничего не выводим)
{/if}
Я обернул все это в конструкцию {if}{/if}, т.к. оригинального фото мажет не быть
Меня другое удручает: то, что я никак не могу приучить юзеров к подробному описанию проблем — что именно не подходит, с какими конкретно плагинами и какие ошибки возникают.
Несмотря на значительные изменения движка, задачу совместимости с предыдущими версиями никто не снимал. И если какие-то плагины работали в старой версии, то они должны работать и в новой. И в «плагин совместимости» постоянно какие-то доработки вносятся, чтобы это обеспечить. Правда есть нюанс — в старой версии Альто этот плагин был включен по умолчанию, а сейчас он по умолчанию выключен. Может, Вы забываете его включить?
Мне мало знать, с чем возникали проблемы, гораздо важнее знать КАКИЕ проблемы возникали — просто верстка ломается без всяких ошибок? Или ошибки какие-то вылезают? Или какой-то функционал перестает работать?
В версии на гитхабе убрал подгрузку класса капчи внутрь метода EventIndex(), чтоб проще было (не придется ничего трогать в родном экшене, достаточно будет плагин подключить)
Задумка такая: название и описание типа блога могут задаваться как явно (в админке), так и через языковые файлы. Первый вариант годится, если сайт у вас одноязычный. Например, если сайт только на русском, и вы даже не думаете о том, что он будет на других языках работать, то к чему лишние сложности? Вбиваете название прямо в админке — и дело с концом (хотя никто не мешает и языковой ключ использовать для одноязычного сайта, как это ниже описано).
Если же сайт мультиязычный, то можно с помощью двойных фигурных скобок задать ключ языкового файла. Например, можно указать {{blablabla}}, а в папку /app/templates/language/ положить языковые файлы, где определен этот ключ blablabla.
А поля с обозначением языка [ru], [en] — они для примера даны, чтоб видно было, как эти значения будут отображаться.
Т.к. первый вопрос топикстартера потребовал развернутого ответа, я дал его отдельно. Отвечаю на другие вопросы:
Front-end altocms, он же демо движка, по функционалу и внешнему виду сильно уступает livestreet. Шаблон в движке synio, своего нет. Будет что то делаться в этом направлении?
Не вполне понял про демо. А что касается шаблона — да, будет свой и уже скоро
3. Есть планы на продвинутое управления изображениями, фотогалереи юзера?
Обязательно! Для этого и была проделана серьезная работа по изменению алгоритмов обработки и хранению изображений. Теперь со стороны сервера для этого есть необходимая основа, и можно уже с клиентской стороны над этим работать.
4. Будет расширение возможностей админа?
Слишком размытый вопрос, чтоб на него можно было конкретно ответить. Возможности админа нужно расширять не для того, чтоб их было больше, а для того, чтоб они несли новый полезный функционал. Поэтому лучше будет, если Вы сформулируете, чего Вам не хватает
5. Здесь обвиняют altocms в «дохлом комьюнити»...
А это уже из серии «вам шашечки или ехать?» Кому-то важен сам движок, кому-то коммьюнити. Да, коммьюнити у ЛС сейчас больше. Но с тем, что здесь нет грамотных специалистов, не согласен категорически.
А расширение команды, конечно же, будет. Но процесс этот очень непростой, поэтому он не может быть быстрым. Приветствуются любые разумные инициативы, предложения и пожелания. С кем-то уже сейчас общаемся в личке, в т.ч. и на предмет сотрудничества. Как по поводу небольших локальных задач, так и в стратегическом плане. Так что если у кого есть желание и возможность работать над развитием движка в долгосрочной перспективе — велкам!
Альто последовательно развивается в том же направлении, что и было задумано с самого начала. И если какой-то функционал в движке появляется, то вовсе не потому, что захотелось кому-то там утереть нос, а потому, что есть понимание, что он необходимым. Многих функций в ЛС юзеры ждали и просили годами, т.е. в них была реальная потребность и именно поэтому они появились в Альто, а сейчас они реализуются в ЛС. Допускаю, что в каких-то случаях планируемая реализация на ЛС может выглядеть привлекательней. Но постоянно оглядываться на ЛС и исходить из принципа «а давайте сделаем только потому, что там это есть», я не хочу. Я убежден, что исходить надо именно из интересов пользователей, а не из-за какого-то никому не нужного соперничества.
Именно поэтому на вопрос 1 я однозначно ответить не могу — он слишком абстрактный. Нужно говорить о конкретном функционале. Это во-первых. А, во-вторых, просто взять код ЛС и тупо перенести в Альто (если говорить о коде ядра, а не про сторонний плагин) уже вряд ли получится, т.к. отличия в ядре Альто и ЛС 2.0 уже довольно значительны, и усиливаются с каждым днем.
Закоммитил сегодня изменения в гитхаб. Эту версию погонял в разных вариациях с включением/выключением объединения и/или сжатия css/js — у меня ошибка больше не повторилась.
Во времена оные движок не умел делать нужные размеры налету, поэтому они создавались в процессе загрузки изображений. Сейчас он это делать умеет, поэтому необходимость в этом отпала. А рудимент в конфиге остался.
Размер фотографии, которая выводится в фотосете, указывается прямо в шаблоне. Возможно, не очень хорошо (и нужно это будет исправить в будущем), но так всегда было. Поэтому, чтобы задать нужный размер, найдите в шаблоне topic_topic.tpl вывод миниатюр и задайте там нужный размер. Обычно это выглядит так:
<img src="{$oPhoto->getWebPath('50crop')}" ... />
Вот вместо '50crop' и задайте свое значение. Если нужно с обрезанием, то, например, так: '150crop'. Если без обрезания, то просто число: $oPhoto->getWebPath(150)
Хуки, в принципе, можно было б юзать, если б jQuery нам не давал очень простого (и ставшим стандартом) аналога — триггер событий. Возможно, я упускаю какие-то нюансы, но я не вижу, чем же самопальные js-хуки лучше триггеров.
Поэтому в отношении скриптов планы такие:
1) Оставить набор старых js-скриптов для работы с шаблонами LS-style (сейчас они в папке /templates/frontend/ls/js/)
2) Скрипты для работы с шаблонами Alto-style (/templates/frontend/libs/) очищаются от маркеров и хуков и переводятся на триггеры.
Поэтому переход на bs-скрипты отчасти позволят вообще отказаться и от лишних классов, и от лишних js-функций.
Что касается именований, то пока сформулировано только одно четкое правило: id модальных окон четко увязаны с названием файлов-шаблонов этих окон.
И есть еще одно (пока не очень четкое) правило: привязка js-событий должна выполняться к специальным классам, с префиксом «js-». Но сами именования этих классов пока как-то не регламентированы. Плюс есть случаи, когда события привязываются к id.
Остальные правила еще предстоит выработать
И т.к. у Вас уже наработан какой-то опыт с «родительским» шаблоном, то буду рад услышать какие-то соображения и пожелания
Несмотря на значительные изменения движка, задачу совместимости с предыдущими версиями никто не снимал. И если какие-то плагины работали в старой версии, то они должны работать и в новой. И в «плагин совместимости» постоянно какие-то доработки вносятся, чтобы это обеспечить. Правда есть нюанс — в старой версии Альто этот плагин был включен по умолчанию, а сейчас он по умолчанию выключен. Может, Вы забываете его включить?
Задумка такая: название и описание типа блога могут задаваться как явно (в админке), так и через языковые файлы. Первый вариант годится, если сайт у вас одноязычный. Например, если сайт только на русском, и вы даже не думаете о том, что он будет на других языках работать, то к чему лишние сложности? Вбиваете название прямо в админке — и дело с концом (хотя никто не мешает и языковой ключ использовать для одноязычного сайта, как это ниже описано).
Если же сайт мультиязычный, то можно с помощью двойных фигурных скобок задать ключ языкового файла. Например, можно указать {{blablabla}}, а в папку /app/templates/language/ положить языковые файлы, где определен этот ключ
blablabla.
А поля с обозначением языка [ru], [en] — они для примера даны, чтоб видно было, как эти значения будут отображаться.
Не вполне понял про демо. А что касается шаблона — да, будет свой и уже скоро
Обязательно! Для этого и была проделана серьезная работа по изменению алгоритмов обработки и хранению изображений. Теперь со стороны сервера для этого есть необходимая основа, и можно уже с клиентской стороны над этим работать.
Слишком размытый вопрос, чтоб на него можно было конкретно ответить. Возможности админа нужно расширять не для того, чтоб их было больше, а для того, чтоб они несли новый полезный функционал. Поэтому лучше будет, если Вы сформулируете, чего Вам не хватает
А это уже из серии «вам шашечки или ехать?» Кому-то важен сам движок, кому-то коммьюнити. Да, коммьюнити у ЛС сейчас больше. Но с тем, что здесь нет грамотных специалистов, не согласен категорически.
А расширение команды, конечно же, будет. Но процесс этот очень непростой, поэтому он не может быть быстрым. Приветствуются любые разумные инициативы, предложения и пожелания. С кем-то уже сейчас общаемся в личке, в т.ч. и на предмет сотрудничества. Как по поводу небольших локальных задач, так и в стратегическом плане. Так что если у кого есть желание и возможность работать над развитием движка в долгосрочной перспективе — велкам!
Альто последовательно развивается в том же направлении, что и было задумано с самого начала. И если какой-то функционал в движке появляется, то вовсе не потому, что захотелось кому-то там утереть нос, а потому, что есть понимание, что он необходимым. Многих функций в ЛС юзеры ждали и просили годами, т.е. в них была реальная потребность и именно поэтому они появились в Альто, а сейчас они реализуются в ЛС. Допускаю, что в каких-то случаях планируемая реализация на ЛС может выглядеть привлекательней. Но постоянно оглядываться на ЛС и исходить из принципа «а давайте сделаем только потому, что там это есть», я не хочу. Я убежден, что исходить надо именно из интересов пользователей, а не из-за какого-то никому не нужного соперничества.
Именно поэтому на вопрос 1 я однозначно ответить не могу — он слишком абстрактный. Нужно говорить о конкретном функционале. Это во-первых. А, во-вторых, просто взять код ЛС и тупо перенести в Альто (если говорить о коде ядра, а не про сторонний плагин) уже вряд ли получится, т.к. отличия в ядре Альто и ЛС 2.0 уже довольно значительны, и усиливаются с каждым днем.
Закоммитил сегодня изменения в гитхаб. Эту версию погонял в разных вариациях с включением/выключением объединения и/или сжатия css/js — у меня ошибка больше не повторилась.
В старую от 0.9.7? Или от ЛС?
Мое упущение — не доглядел, что мы все равно к квадрату привязываемся. Исправим в будущем
Размер фотографии, которая выводится в фотосете, указывается прямо в шаблоне. Возможно, не очень хорошо (и нужно это будет исправить в будущем), но так всегда было. Поэтому, чтобы задать нужный размер, найдите в шаблоне topic_topic.tpl вывод миниатюр и задайте там нужный размер. Обычно это выглядит так:
Вот вместо '50crop' и задайте свое значение. Если нужно с обрезанием, то, например, так: '150crop'. Если без обрезания, то просто число: $oPhoto->getWebPath(150)