Упс, забыл скобки, спасибо ). Отвечу чуть развёрнутее. Поступить можно двумя способами:
Способ 1. Создать собственный шаблон для каждого типа контента. Сейчас контент всех типов выводитмся через три шаблона:
— topic.type_default-edit.tpl: шаблон страницы редактирования;
— topic.type_default-list.tpl: шаблон элемента списка;
— topic.type_default-show.tpl: шаблон страницы топика (контента);
Например, новый тип контента называется «preview», то можно скопировать эти шаблоны и в имени сменить «default» на «preview» что бы получилось так: topic.type_default-edit.tpl и т.д. Затем в этих шаблонах просто удалить вывод тегов. Получится что все типы контента будут выводится через шаблоны «default», а контент типа «preview» через свой специальный шаблон.
Способ 2. В каждом из этих шаблонов поставить проверку на тип при выводе тегов (на примере шаблона experience):
— topic.type_default-edit.tpl в строке 98
Как вариант, если типов контентов, в которых не нужно выводить теги несколько, то можно делать проверку так (здесь 'preview', 'note' и 'other' — типы контента где НЕ нужно выводить теги):
Наверное, вам лучше вообще разделить вывод блогов по типам, раз уж у вас для них планируется отдельное оформление. Можно сделать так:
— блог (его шапка и список топиков) выводится шаблоном «tpls/actions/blog/action.blog.blog.tpl» — переименуйте его в action.blog.one.tpl;
— скопируйте этот же файл, но с соответствующими именами для разных типов блога, в вашем случае: action.blog.two.tpl, action.blog.open.tpl, action.blog.close.tpl, action.blog.personal.tpl
— создайте файл (action.blog.blog.tpl) шаблона в котором будет выбираться нужный тип шаблона с единственной строчкой:
То есть, шаблон блога будет подключать файл блога нужного типа. Теперь, имея различные шаблоны для блогов различного типа, внутри этого шаблона выводите нужные блоки, нужную верстку и т.д.
Давайте не будем усложнять :)
В переписке с radiolip я написал ровно так:
Сборка «Charming» сейчас в работе. Её состояние на текущий момент следующее:
— сборка уже переведена на Alto версии 1,
— тема оформления experience адаптирована под неё,
— адаптирован плагин галереи от stfalcon,
— под нее же адаптирован плагин интеграции с соц.сетями (который буквально на днях появится в продаже).
— уже есть бета, которую пару недель назад я выкладывал на своем сайте для тестирования.
Сейчас идет исправление ошибок и готовится релиз. Сроков пока не скажу. Решается и еще один вопрос — будет ли сборка платной и стоит ли её защищать с помощью ioncube.
Всё ещё в процессе, но если ионкуб будет использоваться для сборки, то только для части кода. полностью закрывать сборку, согласен, не хорошо. Но все еще висит в воздухе и окончательно еще ни чего не решено.
Проверка на право голосовать реализована в модуле common/classes/modules/acl/ACL.class.php, дорабатывать нужно его, а не экшен ActionAjax.class.php.
Вот пример, в котором реализована проверка на то, является ли пользователь модератором или администратором в каком-либо блоге, которая происходит при голосовании за топик. Добавлено первое условие. Для блога и комментария делается аналогично в этом же модуле.
/**
* Проверяет может ли пользователь голосовать за конкретный топик
*
* @param ModuleUser_EntityUser $oUser Пользователь
* @param ModuleTopic_EntityTopic $oTopic Топик
*
* @return bool
*/
public function CanVoteTopic(ModuleUser_EntityUser $oUser, ModuleTopic_EntityTopic $oTopic) {
// Если пользователь авторизован, тогда будем проверять
// Не авторизованные и так не могут голосовать
if (E::IsUser()) {
// Получим массив идентификаторов блогов, в которых текущий
// пользователь - модератор или администратор
$aUserRelation = $this->Blog_GetBlogUsersByUserId(
E::UserId(),
array(ModuleBlog::BLOG_USER_ROLE_MODERATOR, ModuleBlog::BLOG_USER_ROLE_ADMINISTRATOR),
TRUE);
if (!$aUserRelation) {
// Пользователь ни в одном блоге не состоит в качестве
// модератора или администратора, значит голосовать
// за этот топик не может
return false;
}
}
// Дальше типовая проверка
if ($oUser->getRating() >= Config::Get('acl.vote.topic.rating')) {
return true;
}
return false;
}
Очень внимательно прочитал ваши комментарии к топику про галерею. Немного обобщу то, что я понял:
1. В альто сейчас все картинки, вернее ссылки на них. хранятся в таблице mresources. В админке эти картинки можно посмотреть и отмодерировать.
2. Программно картинки загружаются на сервер, а информация о них одними методами одних и тех классов.
3. Инициируется загрузка картинок в топик/коммент/фотосет/еще_куда_то разными способами.
Тут вопрос, можно ли сделать один механизм загрузки картинок, например так:
— картинки грузятся по кнопке из тулбара (топика/коммента/...) по одному или мультизагрузкой;
— картинки привязываются не к топику/комменту/чему_нибудь, а к пользователю
— один раз добавив картинки куда либо пользовтаель имеет к ним доступ (например в окне добавления картинки на третьей вкладке).
Если продолжить мысль, то нужен еще механизм группировки пользовательских фото, а это не что иное как альбом :(
Мне кажется сейчас это не вполне удобно. Т.е. помимо того что можно добавить фото через тулбар редактора, через фотосет к топику, еще какое-то изображение обозначается как превью и в некоторых шаблонах это выводит его в топике. Но не всегда, например только при просмотре списка интересных топиков. Это все создает ненужную путаницу.
Те способы, которые вы указали используются для разных задач. Как я понимаю, фотосет предназначен только для прикрепления к топику фотографий, в то время как вставка изображений в топик добавляет их в контекст содержимого. И это два разных по назначению, не пересекаемых набора фото. Сам фотосет – это доп.поле топика, и работает отдельной сущностью, аналогично опросу и может у топика отсутствовать – такова компонентная структура топика в Alto и это, скорее всего, не поменяется.
Если дать пользователю возможность вставлять картинки в топик из фотосета и наоборот — это только запутает его.
И в такой ситуации, галерея просто эту путаницу уберет и пользователи не будут путать понятия «Альбом» и «Прикрепленные фото», потому что сейчас путаница, мне кажется, именно в этом.
Только этот тип, на мой взгляд, должен очень сильно отличаться от обычного текстового топика,
У Alto есть функционал по работе с типами топика:
— их можно не выводить вместе с другими топиками, а например только там где нужно — виджеты, профиль, отдельные страницы…
— для отдельного типа топика можно указать отдельный же шаблон и оформлять как захочется.
В каком виде галерея может быть реализована в Alto? Способов несколько, но наиболее правильным, с моей точки зрения, будет реализовать его в виде отдельного типа топика. Топик-фотоальбом.
Такой тип топика будет иметь в качестве базовых полей:
— наименование;
— описание (здесь можно поступить по-разному: разрешить форматирование и картинки в тексте описания или запретить. Здесь же может возникнуть непонимание пользователя относительно того, что картинки можно добавлять в описание и в фотосет);
— собственно, сам фотосет;
— теги;
— опрос, если владелец захотел узнать, например, понравились ли другим фотографии;
То есть я подвожу к такой мысли, что базовый функционал для организации фотоальбома уже есть и сделать фотоальбом можно легко через админку.
Что касается другого функционала, то его придется дописывать, но с учетом уже готовых функций из коробки выглядеть всё будет так:
1. Видимость альбома: Создаются типы блогов: «закрытые альбомы», «открытые альбомы», «альбомы только для друзей». Каждому пользователю при регистрации автоматически создаются по одному экземпляру каждого блога. Ка сейчас персональный, но добавляются: «Персональные закрытые альбомы», «Персональные открытые альбомы», «Персональные альбомы для друзей». пользователь создавая альбом относит его в один из этих своих типов блогов тем самым регулируя их видимость. Поскольку альбом это топик, то его легко перенести в любой другой блог.
2. Наборы альбомов: Пользователь может создавать свои наборы альбомов (блогов типа «Альбомы»), например, «Фото природы для друзей»
3. Коллективные наборы альбомов: Пользователи могут делать коллективные «фото-наборы» (коллективный блог) размещая в них свои тематические фотографии
4. Лучшие фото: Механизм реализации следующий: В БД к записи голоса добавляется поле – id_foto, которое хранит голос за фотографию. Общее количество голосов будут показывать рейтинг всего альбома.
5. Просматриваемые фото и комментарии к фото: аналогично, внеся изменения в БД, можно разделить в рамках одного топика (альбома) комментарии к каждой фото и просмотр каждой фото.
6. Виджеты с фото, альбомы в профиле и т.д. Так как альбом – это топик, то выборка различных данных по топику сложности не представляет и этот функционал еть в движке.
7. Вывод альбомов отдельным списком: Сейчас Alto выводит персональные и коллективные блоги на отельных страницах, добавить новое условие на вывод какого-либо другого типа топика, например «открытые альбомы пользователя» не сложно, функционал в движке уже есть. Также есть экшен «ActionFilter», который выводит отдельный вид контента на странице.
8. Фотосет: фотосет сейчас довольно хорошо выполняет функции захгрузки фото, но его можно дополнить другими функциями: порядок фото, пометка человека на фото и т.д.
Вот в краце, как интегрировать функционал альбома с уже существующим функционалом Alto.
Если что-то забыл – пишите, дополню список.
C аватаркой буду смотреть что случилось, а вот с репостов во вконтакт такая штука: По спецификации методов API вконтакта репостить может только Standalone-приложение, но дело в том, что если я создам в ВК приложение такого типа сайт им все равно не будет. Что бы репостить нужен специальный токен приложения, получить который можно только из адресной строки браузера а сайт к этой строке доступа не имеет.
Можно поступить так — вручную сформировать запрос к ВК, отправить его и когда ВК перенаправит на свою пустую страницу руками скопировать этот токен в плагин и потом можно будет репостить — но это уж очень напоминает костыль. При чем если этот токен сменится, то такую процедуру придется повторить. Такой вид репоста я делать не стал.
Но ВК поддерживает репост «С открытием окна подтверждения». Когда после репоста сайт открывает всплывающее окно и там вы разрешаете репостинг. Вот это самое окно изначально браузерами блокируется — вам нужно разрешить сайту открывать всплывающие окна и репост получится.
Понимаю, что не удобно и криво, но других способов репоста в ВК нет. Вы можете напсиать в поддержку ВК и вам могут открыть, а могут и нет, возможность репоста, но это уже индивидуально.
Репост в ВК плагин поддерживает только через открывающееся окно подтверждения.
Способ 1. Создать собственный шаблон для каждого типа контента. Сейчас контент всех типов выводитмся через три шаблона:
— topic.type_default-edit.tpl: шаблон страницы редактирования;
— topic.type_default-list.tpl: шаблон элемента списка;
— topic.type_default-show.tpl: шаблон страницы топика (контента);
Например, новый тип контента называется «preview», то можно скопировать эти шаблоны и в имени сменить «default» на «preview» что бы получилось так: topic.type_default-edit.tpl и т.д. Затем в этих шаблонах просто удалить вывод тегов. Получится что все типы контента будут выводится через шаблоны «default», а контент типа «preview» через свой специальный шаблон.
Способ 2. В каждом из этих шаблонов поставить проверку на тип при выводе тегов (на примере шаблона experience):
— topic.type_default-edit.tpl в строке 98
— topic.type_default-list.tpl в строке 83
— topic.type_default-show.tpl: в строке 161
Как вариант, если типов контентов, в которых не нужно выводить теги несколько, то можно делать проверку так (здесь 'preview', 'note' и 'other' — типы контента где НЕ нужно выводить теги):
Здесь выводим теги
{/if}
— блог (его шапка и список топиков) выводится шаблоном «tpls/actions/blog/action.blog.blog.tpl» — переименуйте его в action.blog.one.tpl;
— скопируйте этот же файл, но с соответствующими именами для разных типов блога, в вашем случае: action.blog.two.tpl, action.blog.open.tpl, action.blog.close.tpl, action.blog.personal.tpl
— создайте файл (action.blog.blog.tpl) шаблона в котором будет выбираться нужный тип шаблона с единственной строчкой:
То есть, шаблон блога будет подключать файл блога нужного типа. Теперь, имея различные шаблоны для блогов различного типа, внутри этого шаблона выводите нужные блоки, нужную верстку и т.д.
В переписке с radiolip я написал ровно так:
Всё ещё в процессе, но если ионкуб будет использоваться для сборки, то только для части кода. полностью закрывать сборку, согласен, не хорошо. Но все еще висит в воздухе и окончательно еще ни чего не решено.
Вот пример, в котором реализована проверка на то, является ли пользователь модератором или администратором в каком-либо блоге, которая происходит при голосовании за топик. Добавлено первое условие. Для блога и комментария делается аналогично в этом же модуле.
1. В альто сейчас все картинки, вернее ссылки на них. хранятся в таблице mresources. В админке эти картинки можно посмотреть и отмодерировать.
2. Программно картинки загружаются на сервер, а информация о них одними методами одних и тех классов.
3. Инициируется загрузка картинок в топик/коммент/фотосет/еще_куда_то разными способами.
Тут вопрос, можно ли сделать один механизм загрузки картинок, например так:
— картинки грузятся по кнопке из тулбара (топика/коммента/...) по одному или мультизагрузкой;
— картинки привязываются не к топику/комменту/чему_нибудь, а к пользователю
— один раз добавив картинки куда либо пользовтаель имеет к ним доступ (например в окне добавления картинки на третьей вкладке).
Если продолжить мысль, то нужен еще механизм группировки пользовательских фото, а это не что иное как альбом :(
Как-то так.
Если дать пользователю возможность вставлять картинки в топик из фотосета и наоборот — это только запутает его.
И в такой ситуации, галерея просто эту путаницу уберет и пользователи не будут путать понятия «Альбом» и «Прикрепленные фото», потому что сейчас путаница, мне кажется, именно в этом.
— их можно не выводить вместе с другими топиками, а например только там где нужно — виджеты, профиль, отдельные страницы…
— для отдельного типа топика можно указать отдельный же шаблон и оформлять как захочется.
Такой тип топика будет иметь в качестве базовых полей:
— наименование;
— описание (здесь можно поступить по-разному: разрешить форматирование и картинки в тексте описания или запретить. Здесь же может возникнуть непонимание пользователя относительно того, что картинки можно добавлять в описание и в фотосет);
— собственно, сам фотосет;
— теги;
— опрос, если владелец захотел узнать, например, понравились ли другим фотографии;
То есть я подвожу к такой мысли, что базовый функционал для организации фотоальбома уже есть и сделать фотоальбом можно легко через админку.
Что касается другого функционала, то его придется дописывать, но с учетом уже готовых функций из коробки выглядеть всё будет так:
1. Видимость альбома: Создаются типы блогов: «закрытые альбомы», «открытые альбомы», «альбомы только для друзей». Каждому пользователю при регистрации автоматически создаются по одному экземпляру каждого блога. Ка сейчас персональный, но добавляются: «Персональные закрытые альбомы», «Персональные открытые альбомы», «Персональные альбомы для друзей». пользователь создавая альбом относит его в один из этих своих типов блогов тем самым регулируя их видимость. Поскольку альбом это топик, то его легко перенести в любой другой блог.
2. Наборы альбомов: Пользователь может создавать свои наборы альбомов (блогов типа «Альбомы»), например, «Фото природы для друзей»
3. Коллективные наборы альбомов: Пользователи могут делать коллективные «фото-наборы» (коллективный блог) размещая в них свои тематические фотографии
4. Лучшие фото: Механизм реализации следующий: В БД к записи голоса добавляется поле – id_foto, которое хранит голос за фотографию. Общее количество голосов будут показывать рейтинг всего альбома.
5. Просматриваемые фото и комментарии к фото: аналогично, внеся изменения в БД, можно разделить в рамках одного топика (альбома) комментарии к каждой фото и просмотр каждой фото.
6. Виджеты с фото, альбомы в профиле и т.д. Так как альбом – это топик, то выборка различных данных по топику сложности не представляет и этот функционал еть в движке.
7. Вывод альбомов отдельным списком: Сейчас Alto выводит персональные и коллективные блоги на отельных страницах, добавить новое условие на вывод какого-либо другого типа топика, например «открытые альбомы пользователя» не сложно, функционал в движке уже есть. Также есть экшен «ActionFilter», который выводит отдельный вид контента на странице.
8. Фотосет: фотосет сейчас довольно хорошо выполняет функции захгрузки фото, но его можно дополнить другими функциями: порядок фото, пометка человека на фото и т.д.
Вот в краце, как интегрировать функционал альбома с уже существующим функционалом Alto.
Если что-то забыл – пишите, дополню список.
Можно поступить так — вручную сформировать запрос к ВК, отправить его и когда ВК перенаправит на свою пустую страницу руками скопировать этот токен в плагин и потом можно будет репостить — но это уж очень напоминает костыль. При чем если этот токен сменится, то такую процедуру придется повторить. Такой вид репоста я делать не стал.
Но ВК поддерживает репост «С открытием окна подтверждения». Когда после репоста сайт открывает всплывающее окно и там вы разрешаете репостинг. Вот это самое окно изначально браузерами блокируется — вам нужно разрешить сайту открывать всплывающие окна и репост получится.
Понимаю, что не удобно и криво, но других способов репоста в ВК нет. Вы можете напсиать в поддержку ВК и вам могут открыть, а могут и нет, возможность репоста, но это уже индивидуально.
Репост в ВК плагин поддерживает только через открывающееся окно подтверждения.