Для шаблонов есть рад изменений в версии 1.1 (пока коротко, но будет отдельным топиком):
— Добавлены шаблоны сниппетов common/templates/skin/experience/tpls/snippets.
— Добавлено шаблон модального окна вставки изображений common/templates/skin/experience/tpls/modals/modal.insert_img.tpl
— Добавлен шаблон поля картинки common/templates/skin/experience/tpls/fields/customs/field.custom.single-image-uploader-edit.tpl
В версии 1.0.8 файл паджинации был переименован. Для того, что бы плагин заработал на версии 1.0.7 нужно в файле плагина common/plugins/gc/templates/skin/experience/tpls/comments/comment.tree.tpl в строке 126 заменить
1. Если я правильно понимаю, любая соцсеть отдает нам email пользователя. С этим вопросов нет.
Твиттер, одноклассники и инстаграм не отдают email (
2. Можно ли сделать так, чтобы login автоматом брался как тут? Например, для Facebook — vasja.pupkin
инстаграмм гитхаб и твиттер не отдают разделяют имя и фамилию, а отдают одну строку и полным именем.
Еще остается опасность того, что пользователь войдя через другую соц.сеть создаст себе дубликат учетки.
Но для тех соц.сетей, которые отдают email задачу можно решить так:
1. В админке поставить галочку напротив настройки «Автологин». Таким образом логин будет формироваться авоматически по правилу «socialId» + «userId». Например для вконтакта будет id_555999999999999, где 555999999999999 — ид пользователя во вконтакте. В будущем логин менять нельзя будет, но если на сайте везде выводится profile name, то ничего разницы ни какой
2. В шаблоне common/plugins/ar/templates/skin/default/tpls/actions/ar/action.ar.confirm.tpl поля login и mail сделать типа hidden и зменить ее вид, оставив только текстовку/соглашение пользователя/приветствие и кнопку «Дальше»
Хотя согласен, такой режим «Быстрой регистрации» нужно делать в составе плагина. Займусь этим. Спасибо за идею.
Думаю, понятно, что делать это надо отдельным плагином.
И я бы cделал примерно так: создается плагин для конкретного сайта (напр., PluginMine, где переопределяется ActionContent, в котором расширяем метод checkTopicFields($oTopic):
class PluginMine_ActionContent extends PluginMine_Inherits_ActionContent
protected function checkTopicFields($oTopic) {
// сначала вызываем стандартную проверку
$bResult = parent::checkTopicFields($oTopic);
// а теперь проверяем заполнение дополнительных полей
if (empty($_REQUEST['fields'][2])) {
$this->Message_AddError('Поле не заполнено', $this->Lang_Get('error'));
$bResult = false;
}
return $bResult;
}
}
Немного замороченно, но можно. Если не программировать и не писать никаких плагинов, то можно чуть-чуть «накостылить» прямо в шаблонах.
Для начала надо узнать ID полей. К сожалению, увидеть их без того, чтоб лезть в базу, можно только обновившись с гитхаба, в админке там при просмотре типа контента теперь выводятся ID кастомных полей. Либо, если не обновляться, то можно увидеть их в таблице ?_content_field, поле field_id.
Дальше немного проще.
В шаблоне /common/templates/skin/_skin_name_/tpls/fields/customs/field.custom.textarea-show.tpl убирается этот самый кусок кода, который приведен выше.
В нужных местах шаблона, где нужно выводить кастомные поля, вставляете такой код:
В последней стабильной версии 1.0.6 это делается примерно так:
$iPhotoId = $oTopic->getPhotosetMainPhotoId();
$aPhotos = $oTopic->getPhotosetPhotos($iPhotoId, 1);
if (isset($aPhotos[$iPhotoId])) {
$oPhoto = $aPhotos[$iPhotoId];
// Здесь в $oPhoto оно и есть
}
В текущей разрабатываемой версии 1.0.7 так:
$oPhoto = $oTopic->getPhotosetMainPhoto();
В обоих случаях в результате в переменной $oPhoto получим фотографию, отмеченную как превью, в виде объекта ModuleTopic_EntityTopicPhoto. И получить ссылку на само изображение можно методом getUrl():
Ну в общем выложу список плагинов которые работают на новой версии AltoCMS 1.0.5:
1. AutoOpenID
2. Config Engine
3. Main preview topic
4. Premoderation
5. Sitemap
6. Similar topics
7. Attachments
8. Wmessage
1) Сила и рейтинг: нынешний алгоритм — это наследие прошлого. Мое мнение — систему рейтинга юзеров вообще нужно выносить в плагин. В движке если и оставлять, то самый простой, самый примитивный алгоритм. А все навороты делать снаружи. Тогда желающие смогут реализовать любые фантазии в части рейтингования юзеров на ресурсе (например, один владелец ресурса хотел в рейтинге учитывать число френдов и их общий средний рейтинг). Плюс в идеале хорошо бы дать возможность голосовать (и рейтинговать) вообще любую сущность, включая как фотосеты так и отдельные фото. В общем, в планах такая работа значится, но ее трудоемкость пока не определена.
2) Про фотосеты и опросы:
И шаблон создания фотосета, и шаблон отображения фотосета сейчас вынесены в отдельные файлы (см. /tpls/fields/field.photoset-edit.tpl и /tpls/fields/field.photoset-show.tpl). То же самое касается и опросов. В шаблонах редактирования и отображения топиков они включаются простыми инклудами (а это означает, что эти инклуды могут быть вставлены куда угодно). Т.е. работа с фотосетами и опросами как при создании, так и при отображении сейчас целиком и полностью в руках создателя шаблона! Можно при создании нового шаблона скопировать существующую структуру и логику, а можно реализовать свою собственную — все от Вашей фантазии зависит. Ограничение пока одно — в одном топике только один фотосет и только один опрос.
3) Администрирование медиаресурсов:
Тут много писать не буду, а просто соглашусь
4) Типы контента:
На самом деле тут «болячек» больше, чем Вы отметили. Но потребовалось какое-то время, чтобы наработать эксплуатационный опыт и сформулировать новые требования.
Что касается конкурентов, то отвечу так: то, что пилится в других движках (в т.ч. и в ЛС) — это, безусловно, интересно, но вот оглядки на это нет совершенно. Мы движемся по своему пути, без метаний из крайности в крайность.
ждем релиза, не стал сильно разбираться в 0.9 сайт сидит пока на LS 1.0.3, но очень хочу перейти на альто вопросики:
1. в новой реве будет возможность перенести сайт с LS на Альто, (желательно чтобы адрес топиков не изменился чтоб с поисков не вылетить)?
2. будет ли нормальный поиск без всяких сфинксов (как то не проверил на 0.9 забыл наверно просто)?
3. будут ли дополнительные поля?? желательно с инструкцией (хороший пример на вордпресс плугин magic-fields)уж больно хочется замутить: help.yandex.ru/webmaster/?id=1122752, а лучше бы это было из коробочки!!! вроде почти то же самое как и sitemap
4. вывод простых виджетов из админки (чтото типо счетчиков посещения и т.п.), если нужен сложный виджет допиливаем руками
5. авто cut из админки
6. зачем нужны персональные блоги которых нету в списке блогов?? лично моё мнение, чтобы была ссылка на список персональных блогов в которых есть хоть 1+ топиков, и чтобы в этих блогах были только топики автор, а который пишет именно в свой блог, а топики с коллективного туда не добавлялись ну и комментарии само собой, по мне как бывает полезно
7. категории блогов exsample.com/category/blog/topic
PS где то у вас читал что до выхода новой ревы осталось примерно 1.5 -2 месяца, сообщение было летом, так все же когда примерная дата выхода
5.
Для отображения иконок шаблона необходимо в папке templates сайта создать папку font-awesome и перенести в нее папку font расположенную в шаблоне в папке font-awesome.
ну и поправил пути в файле /templates/skin/developer-kit/font-awesome/css/font-awesome.min.css на
Успешно перешел с Livestreet 1.0.3 На AltoCMS 0.9.7.
Без проблем заработали все плагины, которые использовались на данном проекте, а именно:
Attachments: v.1.4.1
AutoOpenID: v.1.5.32
Config Engine: v.1.2.0
Cross linker: v.1.2.2
Mobile template: v.1.0
Simple Search and Auto Completer: v.2.0.0
Sitemap: v.0.3.0
Similar topics: v.0.3.0
TopicUp: v.0.1
Premoderation: v.1.6.3
И шаблон: onfleap
Естественно при включенном плагине LS Compatibility: v.1.0
— Добавлены шаблоны сниппетов common/templates/skin/experience/tpls/snippets.
— Добавлено шаблон модального окна вставки изображений common/templates/skin/experience/tpls/modals/modal.insert_img.tpl
— Добавлен шаблон поля картинки common/templates/skin/experience/tpls/fields/customs/field.custom.single-image-uploader-edit.tpl
на
инстаграмм гитхаб и твиттер не отдают разделяют имя и фамилию, а отдают одну строку и полным именем.
Еще остается опасность того, что пользователь войдя через другую соц.сеть создаст себе дубликат учетки.
Но для тех соц.сетей, которые отдают email задачу можно решить так:
1. В админке поставить галочку напротив настройки «Автологин». Таким образом логин будет формироваться авоматически по правилу «socialId» + «userId». Например для вконтакта будет id_555999999999999, где 555999999999999 — ид пользователя во вконтакте. В будущем логин менять нельзя будет, но если на сайте везде выводится profile name, то ничего разницы ни какой
2. В шаблоне common/plugins/ar/templates/skin/default/tpls/actions/ar/action.ar.confirm.tpl поля login и mail сделать типа hidden и зменить ее вид, оставив только текстовку/соглашение пользователя/приветствие и кнопку «Дальше»
Хотя согласен, такой режим «Быстрой регистрации» нужно делать в составе плагина. Займусь этим. Спасибо за идею.
И я бы cделал примерно так: создается плагин для конкретного сайта (напр., PluginMine, где переопределяется ActionContent, в котором расширяем метод checkTopicFields($oTopic):
Для начала надо узнать ID полей. К сожалению, увидеть их без того, чтоб лезть в базу, можно только обновившись с гитхаба, в админке там при просмотре типа контента теперь выводятся ID кастомных полей. Либо, если не обновляться, то можно увидеть их в таблице ?_content_field, поле field_id.
Дальше немного проще.
В шаблоне /common/templates/skin/_skin_name_/tpls/fields/customs/field.custom.textarea-show.tpl убирается этот самый кусок кода, который приведен выше.
В нужных местах шаблона, где нужно выводить кастомные поля, вставляете такой код:
Здесь N — это как раз ID поля, которое нам надо вывести в конкретном месте.
Вывести каждое поле по одиночке? При этом поля разного типа. Полей одного типа может быть несколько.
Т.е. должно стать так:
После этого параметр включения/выключения будет работать нормально.
Но в style.min.css, разумеется, надо вернуть все на место
В текущей разрабатываемой версии 1.0.7 так:
В обоих случаях в результате в переменной $oPhoto получим фотографию, отмеченную как превью, в виде объекта ModuleTopic_EntityTopicPhoto. И получить ссылку на само изображение можно методом getUrl():
и т.д.
Либо, если поставить плагин TopicIntro, то можно еще проще:
1. AutoOpenID
2. Config Engine
3. Main preview topic
4. Premoderation
5. Sitemap
6. Similar topics
7. Attachments
8. Wmessage
Шаблон: onfleap
Дополняйте у кого еще какие плагины работают!?
1) Сила и рейтинг: нынешний алгоритм — это наследие прошлого. Мое мнение — систему рейтинга юзеров вообще нужно выносить в плагин. В движке если и оставлять, то самый простой, самый примитивный алгоритм. А все навороты делать снаружи. Тогда желающие смогут реализовать любые фантазии в части рейтингования юзеров на ресурсе (например, один владелец ресурса хотел в рейтинге учитывать число френдов и их общий средний рейтинг). Плюс в идеале хорошо бы дать возможность голосовать (и рейтинговать) вообще любую сущность, включая как фотосеты так и отдельные фото. В общем, в планах такая работа значится, но ее трудоемкость пока не определена.
2) Про фотосеты и опросы:
И шаблон создания фотосета, и шаблон отображения фотосета сейчас вынесены в отдельные файлы (см. /tpls/fields/field.photoset-edit.tpl и /tpls/fields/field.photoset-show.tpl). То же самое касается и опросов. В шаблонах редактирования и отображения топиков они включаются простыми инклудами (а это означает, что эти инклуды могут быть вставлены куда угодно). Т.е. работа с фотосетами и опросами как при создании, так и при отображении сейчас целиком и полностью в руках создателя шаблона! Можно при создании нового шаблона скопировать существующую структуру и логику, а можно реализовать свою собственную — все от Вашей фантазии зависит. Ограничение пока одно — в одном топике только один фотосет и только один опрос.
3) Администрирование медиаресурсов:
Тут много писать не буду, а просто соглашусь
4) Типы контента:
На самом деле тут «болячек» больше, чем Вы отметили. Но потребовалось какое-то время, чтобы наработать эксплуатационный опыт и сформулировать новые требования.
Что касается конкурентов, то отвечу так: то, что пилится в других движках (в т.ч. и в ЛС) — это, безусловно, интересно, но вот оглядки на это нет совершенно. Мы движемся по своему пути, без метаний из крайности в крайность.
Кнопу сделал.
1. в новой реве будет возможность перенести сайт с LS на Альто, (желательно чтобы адрес топиков не изменился чтоб с поисков не вылетить)?
2. будет ли нормальный поиск без всяких сфинксов (как то не проверил на 0.9 забыл наверно просто)?
3. будут ли дополнительные поля?? желательно с инструкцией (хороший пример на вордпресс плугин magic-fields)уж больно хочется замутить: help.yandex.ru/webmaster/?id=1122752, а лучше бы это было из коробочки!!! вроде почти то же самое как и sitemap
4. вывод простых виджетов из админки (чтото типо счетчиков посещения и т.п.), если нужен сложный виджет допиливаем руками
5. авто cut из админки
6. зачем нужны персональные блоги которых нету в списке блогов?? лично моё мнение, чтобы была ссылка на список персональных блогов в которых есть хоть 1+ топиков, и чтобы в этих блогах были только топики автор, а который пишет именно в свой блог, а топики с коллективного туда не добавлялись ну и комментарии само собой, по мне как бывает полезно
7. категории блогов exsample.com/category/blog/topic
PS где то у вас читал что до выхода новой ревы осталось примерно 1.5 -2 месяца, сообщение было летом, так все же когда примерная дата выхода
5.
ну и поправил пути в файле /templates/skin/developer-kit/font-awesome/css/font-awesome.min.css на
заменяем на
Без проблем заработали все плагины, которые использовались на данном проекте, а именно:
Attachments: v.1.4.1
AutoOpenID: v.1.5.32
Config Engine: v.1.2.0
Cross linker: v.1.2.2
Mobile template: v.1.0
Simple Search and Auto Completer: v.2.0.0
Sitemap: v.0.3.0
Similar topics: v.0.3.0
TopicUp: v.0.1
Premoderation: v.1.6.3
И шаблон: onfleap
Естественно при включенном плагине LS Compatibility: v.1.0