avatar
+19.03
38.572

Андрей

Упс, забыл скобки, спасибо ). Отвечу чуть развёрнутее. Поступить можно двумя способами:

Способ 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
{if $oContentType->getContentUrl()!='preview'}
    {include file="fields/field.tags-edit.tpl"}
{/if}

topic.type_default-list.tpl в строке 83
{if $oTopic->getType()!='preview'}
    {include file="fields/field.tags-show.tpl"}
{/if}

topic.type_default-show.tpl: в строке 161
{if $oTopic->getType()!='preview'}
    {include file="fields/field.tags-show.tpl"}
{/if}


Как вариант, если типов контентов, в которых не нужно выводить теги несколько, то можно делать проверку так (здесь 'preview', 'note' и 'other' — типы контента где НЕ нужно выводить теги):
{if !in_array($oTopic->getType(), ['preview', 'note', 'other'])}
    {include file="fields/field.tags-show.tpl"}
{/if}
Выложите полный кусок того кода, что у вас и название файла, в котором это делается
{if $oTopic->getType!='my_new_content_type'}
Здесь выводим теги
{/if}
Папка плагина должна называться «ab»
Наверное, вам лучше вообще разделить вывод блогов по типам, раз уж у вас для них планируется отдельное оформление. Можно сделать так:
— блог (его шапка и список топиков) выводится шаблоном «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) шаблона в котором будет выбираться нужный тип шаблона с единственной строчкой:
{include file="actions/blog/action.blog.{$oBlog->getType()}.tpl"}


То есть, шаблон блога будет подключать файл блога нужного типа. Теперь, имея различные шаблоны для блогов различного типа, внутри этого шаблона выводите нужные блоки, нужную верстку и т.д.
Попробуйте добавить в шаблон скрипты как указано здесь — getbootstrap.com/getting-started/#template в пункте «Basic template»
Нет, конечно ).
andreyv
andreyv
Давайте не будем усложнять :)
В переписке с radiolip я написал ровно так:
Сборка «Charming» сейчас в работе. Её состояние на текущий момент следующее:
— сборка уже переведена на Alto версии 1,
— тема оформления experience адаптирована под неё,
— адаптирован плагин галереи от stfalcon,
— под нее же адаптирован плагин интеграции с соц.сетями (который буквально на днях появится в продаже).
— уже есть бета, которую пару недель назад я выкладывал на своем сайте для тестирования.
Сейчас идет исправление ошибок и готовится релиз. Сроков пока не скажу. Решается и еще один вопрос — будет ли сборка платной и стоит ли её защищать с помощью ioncube.
Всё ещё в процессе, но если ионкуб будет использоваться для сборки, то только для части кода. полностью закрывать сборку, согласен, не хорошо. Но все еще висит в воздухе и окончательно еще ни чего не решено.
andreyv
andreyv
Проверка на право голосовать реализована в модуле 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;
}
andreyv
andreyv
Есть, например yii — http://yiiframework.ru/doc/guide/ru/index
andreyv
andreyv
Очень внимательно прочитал ваши комментарии к топику про галерею. Немного обобщу то, что я понял:

1. В альто сейчас все картинки, вернее ссылки на них. хранятся в таблице mresources. В админке эти картинки можно посмотреть и отмодерировать.
2. Программно картинки загружаются на сервер, а информация о них одними методами одних и тех классов.
3. Инициируется загрузка картинок в топик/коммент/фотосет/еще_куда_то разными способами.

Тут вопрос, можно ли сделать один механизм загрузки картинок, например так:
— картинки грузятся по кнопке из тулбара (топика/коммента/...) по одному или мультизагрузкой;
— картинки привязываются не к топику/комменту/чему_нибудь, а к пользователю
— один раз добавив картинки куда либо пользовтаель имеет к ним доступ (например в окне добавления картинки на третьей вкладке).

Если продолжить мысль, то нужен еще механизм группировки пользовательских фото, а это не что иное как альбом :(

Как-то так.
andreyv
andreyv
Мне кажется сейчас это не вполне удобно. Т.е. помимо того что можно добавить фото через тулбар редактора, через фотосет к топику, еще какое-то изображение обозначается как превью и в некоторых шаблонах это выводит его в топике. Но не всегда, например только при просмотре списка интересных топиков. Это все создает ненужную путаницу.
Те способы, которые вы указали используются для разных задач. Как я понимаю, фотосет предназначен только для прикрепления к топику фотографий, в то время как вставка изображений в топик добавляет их в контекст содержимого. И это два разных по назначению, не пересекаемых набора фото. Сам фотосет – это доп.поле топика, и работает отдельной сущностью, аналогично опросу и может у топика отсутствовать – такова компонентная структура топика в Alto и это, скорее всего, не поменяется.
Если дать пользователю возможность вставлять картинки в топик из фотосета и наоборот — это только запутает его.
И в такой ситуации, галерея просто эту путаницу уберет и пользователи не будут путать понятия «Альбом» и «Прикрепленные фото», потому что сейчас путаница, мне кажется, именно в этом.
andreyv
andreyv
Только этот тип, на мой взгляд, должен очень сильно отличаться от обычного текстового топика,
У Alto есть функционал по работе с типами топика:
— их можно не выводить вместе с другими топиками, а например только там где нужно — виджеты, профиль, отдельные страницы…
— для отдельного типа топика можно указать отдельный же шаблон и оформлять как захочется.
andreyv
andreyv
В каком виде галерея может быть реализована в Alto? Способов несколько, но наиболее правильным, с моей точки зрения, будет реализовать его в виде отдельного типа топика. Топик-фотоальбом.
Такой тип топика будет иметь в качестве базовых полей:
— наименование;
— описание (здесь можно поступить по-разному: разрешить форматирование и картинки в тексте описания или запретить. Здесь же может возникнуть непонимание пользователя относительно того, что картинки можно добавлять в описание и в фотосет);
— собственно, сам фотосет;
— теги;
— опрос, если владелец захотел узнать, например, понравились ли другим фотографии;
То есть я подвожу к такой мысли, что базовый функционал для организации фотоальбома уже есть и сделать фотоальбом можно легко через админку.

Что касается другого функционала, то его придется дописывать, но с учетом уже готовых функций из коробки выглядеть всё будет так:
1. Видимость альбома: Создаются типы блогов: «закрытые альбомы», «открытые альбомы», «альбомы только для друзей». Каждому пользователю при регистрации автоматически создаются по одному экземпляру каждого блога. Ка сейчас персональный, но добавляются: «Персональные закрытые альбомы», «Персональные открытые альбомы», «Персональные альбомы для друзей». пользователь создавая альбом относит его в один из этих своих типов блогов тем самым регулируя их видимость. Поскольку альбом это топик, то его легко перенести в любой другой блог.
2. Наборы альбомов: Пользователь может создавать свои наборы альбомов (блогов типа «Альбомы»), например, «Фото природы для друзей»
3. Коллективные наборы альбомов: Пользователи могут делать коллективные «фото-наборы» (коллективный блог) размещая в них свои тематические фотографии
4. Лучшие фото: Механизм реализации следующий: В БД к записи голоса добавляется поле – id_foto, которое хранит голос за фотографию. Общее количество голосов будут показывать рейтинг всего альбома.
5. Просматриваемые фото и комментарии к фото: аналогично, внеся изменения в БД, можно разделить в рамках одного топика (альбома) комментарии к каждой фото и просмотр каждой фото.
6. Виджеты с фото, альбомы в профиле и т.д. Так как альбом – это топик, то выборка различных данных по топику сложности не представляет и этот функционал еть в движке.
7. Вывод альбомов отдельным списком: Сейчас Alto выводит персональные и коллективные блоги на отельных страницах, добавить новое условие на вывод какого-либо другого типа топика, например «открытые альбомы пользователя» не сложно, функционал в движке уже есть. Также есть экшен «ActionFilter», который выводит отдельный вид контента на странице.
8. Фотосет: фотосет сейчас довольно хорошо выполняет функции захгрузки фото, но его можно дополнить другими функциями: порядок фото, пометка человека на фото и т.д.
Вот в краце, как интегрировать функционал альбома с уже существующим функционалом Alto.
Если что-то забыл – пишите, дополню список.
andreyv
andreyv
Это фон ссылки с картинкой H4 лезет на фон элемента списка со смайликом. Убирается и в experience и в start-kit стилем:
.editor-smiles > a, .editor-smiles > a:hover {
    background: none;
}
Спасибо, сейчас буду исправлять.
Исправил, обновите файл common/plugins/ab/classes/hooks/HookBanneroid.class.php с гитхаба
Да, API смены статуса для сайтов в ВК тоже не поддерживается.
C аватаркой буду смотреть что случилось, а вот с репостов во вконтакт такая штука: По спецификации методов API вконтакта репостить может только Standalone-приложение, но дело в том, что если я создам в ВК приложение такого типа сайт им все равно не будет. Что бы репостить нужен специальный токен приложения, получить который можно только из адресной строки браузера а сайт к этой строке доступа не имеет.

Можно поступить так — вручную сформировать запрос к ВК, отправить его и когда ВК перенаправит на свою пустую страницу руками скопировать этот токен в плагин и потом можно будет репостить — но это уж очень напоминает костыль. При чем если этот токен сменится, то такую процедуру придется повторить. Такой вид репоста я делать не стал.

Но ВК поддерживает репост «С открытием окна подтверждения». Когда после репоста сайт открывает всплывающее окно и там вы разрешаете репостинг. Вот это самое окно изначально браузерами блокируется — вам нужно разрешить сайту открывать всплывающие окна и репост получится.

Понимаю, что не удобно и криво, но других способов репоста в ВК нет. Вы можете напсиать в поддержку ВК и вам могут открыть, а могут и нет, возможность репоста, но это уже индивидуально.

Репост в ВК плагин поддерживает только через открывающееся окно подтверждения.
В ближайшие дни, как только закончу тестирование. Уже исправил несколько ошибок.