Да

Я бы повырезал все упоминания, а связанные страницы от любопытных глаз редиректил бы на главную или 404. Собственно,так и собираюсь сделать.

4. Открыть в папке скина tpls/menus файл menu.profile_created.tpl

Удалить:

            <li class="{if $sMenuSubItemSelect=='photos'}active{/if}">
                <a href="{$oUserProfile->getProfileUrl()}created/photos/">
                    {$aLang.user_menu_publication_photos}
                    {if $aProfileStats['count_images']} ({$aProfileStats['count_images']}) {/if}
                </a>
            </li>

Да, мне как раз такая идея в голову пришла, после прочтения топика http://altocms.ru/72.html. И даже пробовал добавить эти условия в сниппет спойлера, но почему-то гостям скрытый под хайдом текст все равно показывался. Правда у меня код немного иначе выглядел, но с вашим тоже не пашет, содержимое все равно видно гостям.

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

По типу блога тоже можно аналогично сортировать, не знаю, почему в прошлый раз у меня не получалось:

// * Получаем список блогов
$aResult = E::ModuleBlog()—>GetBlogsByFilter(
array('blog_type' => array('game')),
$iPage, Config::Get('module.blog.per_page')
);
$aBlogs = $aResult['collection'];

Где game — новый тип блога. Отлично работает. И не надо прописывать кучу id.

Т.е. при расположении templates/skin/start-kit/tpls/actions/games/action.games.index.tpl в папке /app сайт при переходе по ссылке /games ругается на отсутствие action.games.index.tpl. Но если templates/skin/start-kit/tpls/actions/games/action.games.index.tpl перенести в папку /common, ошибка исчезает.

Потребность в таком функционале есть. По аналогии с закрепленными, как правило, информативно важными темами на форумах. Но можно и самому выкрутиться из ситуации, вынеся ссылки на важные топики или даже теги в описание блога, которое, в свою очередь, сделать по умолчанию раскрытым. Например:

Плюс сделать в настройках профиля:



или в виде отдельной страницы

Ну да, проверил, так и получается. Добавляешь в друзья — автоматом подписываешься на активность. Но выходит несколько сложнее, просто так друзей в подписчиков переименовать не получится. Так как можно не быть другом, но быть подписчиком. Можно получить отклонение на запрос дружбы, но все равно быть подписчиком. Т.е. вкладка профиля «Друзья» переименованная в «Подписчики» будет дезинформировать, т.к. подписчиков у юзера может быть гораздо больше. При этом функционал «Дружбы» вроде как ничего свыше подписки на активность и отображения в профиле в качестве друга не несет. Поэтому в моем случае его проще скрыть, вместо этого выведя счетчик подписчиков в профиль. И если когда-то вдруг с очередным обновлением к нему будут добавлены гибкие настройки приватности, этот самый функционал всегда можно открыть для пользователей.

Хотя... ведь соседние кнопки в профиле «Добавить в друзья» и «Подписаться» несут одинаковую функцию, я точно ничего не напутал? Если это так, то, можно:

1. Убрать дублирующую кнопку «Подписаться»
2. Переименовать «Добавить в друзья» в «Подписаться»
3. Переименовать «Друзья» в «Подписчики»
4. Убрать возможность выбирать людей для слежки за контентом в Ленте, т.к. в активности все равно среди прочего отображаются обновления этого самого контента.
5. Оставить настройки событий, как и сейчас, на усмотрение подписчикам.

Тогда выходит очень даже ничего. Но это только если «Подписаться» и «Добавить в друзья» — точно одно и то же. Если возможность добавить в друзья дает нечто большее, чем просто подписка на активность, то мои рассуждения становятся неактуальными.

Виноват, немного запутался, чтобы следить за контентом, нужно добавить человека в Ленте. Итак, судя по тексту топика, выходит, что:

1. Добавление в друзья —> слежка за активностью.
2. Подписаться в профиле —> слежка за активностью.
3. Добавить в Ленте —> слежка за контентом.

Значит, первый и второй пункт выполняют одни и те же функции, разве нет. Следовательно, чтобы не путать людей, дублирующий пункт 1 надо удалить (в моем случае скрыть + скрыть любые упоминания), а пункт 3 — вынести в профиль юзера рядом с кнопкой пункта 2.

Вообще, функционал «Друзья» в движке назван немного неправильно. Ведь по описанию это просто слежка за активностью. Добавление в друзья можно было бы переименовать в «Следить за всей активностью» и вынести рядом с кнопкой «Подписаться» в профиле юзера. Кнопку «Подписаться» переименовать на «Следить за постами и комментами». Задачи у них схожие — тупо слежка. Но в первом случае за всей активностью, во втором — только за контентом. Вот если бы, не получив одобрение в друзья, нельзя было писать ЛС человеку, нельзя было бы, к примеру, читать его топики (если ТС того захотел), видеть какие-то скрытые настройками приватности поля профиля, то такой функционал можно было бы назвать «Друзья». Собственно, как это и реализовано в популярных социальных сетях. И было бы, кстати, очень круто, если бы это было реализовано в Альто в будущем (зависящие от дружбы настройки приватности профиля, топиков, постов, хайдов).

Мой вариант, на мой взгляд, будет проще, чем объяснять:

Важные нюансы: если вы, находясь в профиле пользователя, подписываетесь на него, то вы подписываетесь на его активность, но не на контент, автором которого он является. Чтобы подписаться на контент пользователя, вам надо перейти на Ленту и там подписаться на него. То же самое касается и дружбы — при добавлении пользователя в друзья, вы подписываетесь на его события, но не на контент.

и проще, чем объяснять юзерам, почему это работает так и не иначе, можно ли сделать по-другому и почему нельзя. Проще убрать с глаз долой.

Вместо этого виджета можно разместить виджет с коротенькой инструкцией. Что-то вроде «Подписаться на блоги, за которыми вы хотите следить, можно на странице блогов, там же вы можете отписаться от больше не интересующих» плюс сопроводить маленькой пикчей, как это делается. Ведь подписываться/отписываться ему так и так придется на странице блога/в списке блогов, т.к. при отключении галочки отписка не происходит, а происходит некая сортировка, когда записи из блога без галочки на странице feed перестают показываться, но подписка на сам блог все равно остается. Вот если бы еще и отписка при убирании галочки автоматом происходила, тогда другое дело.

Я вот думаю у себя все максимально упростить, убрав ссылки подписки на пользователя и ссылки на добавление в друзья, и любые упоминания этого функционала, дабы не создавать юзерам лишней путаницы и не вызывать вопросов, а также убрав возможность ставить галочки в настройке событий и фолловить людей по ссылке /stream. А сам stream редиректить на stream/all.

Таким образом фактически получив лаконичную ленту активности наподобие форумного типа (как forum/search.php?search_id=active_topics на phpbb или find-new/posts на xenforo) с последними постами и комментами т.е. без лишней для большинства пользователей информации. Такая лента позволит следить за всем добавляемым контентом на сайте, и в то же время не задаваться вопросами — а что это там за галочки, а что дает добавление в друзья или подписка на человека, а почему оно так работает а не иначе, etc.

При этом конечно же оставив feed, в котором будут отображаться обновления в подписанных блогах и топиках. Но отключив виджет с выбором блогов. Т.к. он опять же создает путаницу, ведь, убрав в нем галочку с одного из блогов, юзер будет думать, что отписался от блога. Но при этом в списке блогов он увидит, что на этот самый блог подписка все равно осталась. Для него это будет непонятка. Если скрыть со страницы feed виджет с галками («Выберите блоги которые вы хотели бы читать»), логика будет такая: юзер подписался на блог в списке блогов, значит он видит обновления этого блога в фиде, т.к. галка ставится автоматом. Юзер отписался от блога в списке блогов и перестал видеть его обновления в фиде. Без всяких для него непоняток.

Итого получим страницы:

— последние посты
— последние комменты
— последние посты из отслеживаемых блогов
— последние комменты из отслеживаемых топиков

Без возможности настройки пользователями, без функции френдов и фолловинга, но и без путаницы.

У вас здесь по адресу /feed, если, к примеру, выбрать юзера и кликнуть по его ник в окне «Добавьте людей, статьи которых вы хотели бы читать», то в поле вставляется не его ник, а html код аватара этого человека. В результате работает как надо, только если вписать ник вручную, не кликая по предложенному варианту. Иначе вот что получается:

Единственное что неудобно, так это придется id каждого нового созданного блога прописывать в нужный файл, но это пара минут времени — глянуть айдишники в phpmyadmin и вписать их куда требуется.

Например, есть у нас ссылка blogs по которой отображаются блоги с id 1-10. И есть вторая группа блогов другая по тематике с id 10-20 которую нужно отобразить списком по ссылке blogs2.

Делаем копию ActionBlogs.class.php и переименовываем ее в ActionBlogs2.class.php. Внутри прописываем условие на вывод только блогов с id 10-20. class ActionBlogs extends Action внутри ActionBlogs2.class.php меняем на class ActionBlogs2 extends Action. Ищем в папке шаблона tpls/actions папку blogs и делаем ее копию. Переименовываем копию в blogs2. Идем внутрь, переименовываем action.blogs.index.tpl в action.blogs2.index.tpl.

Теперь идем по ссылке /blogs2. Вуаля! У нас там отображается список из блогов с id 10-20, и не отображаются блоги с id 1-10. Осталось только прописать на эти страницы ссылки в шапке. Еще бы додуматься, как прописать на эти страницы блогов сортировку и фильтрацию по алфавиту...

Внезапно додумался до такого решения. Просто подумал, раз у меня почему-то не выходит фильтровать по типу блога, то почему бы не попробовать фильтровать по другому параметру. И таким параметром стал id блога.

В ActionBlogs.class.php используем GetBlogsByFilter(array('blog_id' => array('x','y','z') ) вместо x,y,z и так далее вписываем id нужных блогов, которые берем в blog->blog id. В итоге на странице блогов будут выводиться только нужные нам блоги. Далее создаем Action1.class.php Action2.class.php Action3.class.php и так далее для остальных категорий, где по аналогии вписываем уже другие нам нужные блоги. Работает. Выводятся списки блогов.

Очень удобно, можно разбить все блоги, к примеру, на игровом портале, на «Игры», «Эмуляторы» и тому подобное. На странице «Игры» выводя список блогов по играм, на странице «Эмуляторы» — список блогов по эмулируемым платформам. И в том же духе.