LiveStreet CMS

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

Если вы имеете ввиду функционал закрытых блогов, то он реализован в SVN версии, для 0.3.1 есть модуль или хак. Воспользуйтесь поиском.

По поводу скрытия только некоторых записей, а не целых блогов — тут мороки еще больше будет.

Не думаю что это очень сложно!

Поверьте, это не просто.

С блоками в сайдбаре такое не получится сделать, если вопрос про них. Для того, чтобы убрать блоки из сайдбара, нужно в соответствующем Action найти строки $this->Viewer_AddBlock(), и поставить перед ними if($this->oUserCurrent).

В чем же тогда закрытость блога, если контент из него могут получить поисковики?

1. Для сущностей, обобщенных в одной таблицей с полями target_id, target_type конфиг не поможет — все равно нужно удалять «вручную».

2. Для остальных случае в конфигурации предусмотрена настройка. Точнее, будет предусмотрена, это давно оговорено :)

Так как вы описываете, было в движке раньше. Было несколько таблиц для голосования, несколько таблиц для favourite, разные таблицы для комментариев и т.д. Но так как, livestreet все-таки платформа для наращивания функционала, то решено было сгруппировать данные по сущностям, а не по привязкам.

Поэтому появилась единая таблица vote, единая таблица favourite и другие. Для их обслуживания были введены единые модели и единые сущности.

Почему дорабатывать функционал стало проще? К примеру, если вы делаете модуль «Фотографии». Вы создаете новый контент — фотка. Вам не нужно заботиться о написании функционала комментирования, так как вы можете использовать единый модуль Comment (просто добавив в базе данных новый таргет foto), вы можете не писать новую систему голосования, а использовать для этого уже готовый модуль Vote (снова-таки, просто добавив в одном поле базы данных новый target), ваши фотки можно очень легко заносить в избранное, и вам для этого не нужно создавать новый функционал — для этого можно просто использовать Fvourite-модуль.

Вот такой вот ход мыслей.

По поводу InnoDB, мы стараемся наоборот освободить пользователей от этого требования к базе данных. Так что это не последний коммит, который касается работы со связанными данными. Оставайтесь на линии :)

П.С. Пиво не пью, за предложение спасибо.

Topic.entity.class.php — добавьте функцию:

public function getAuthorAvatarPath($iSize=100) {
    $oUser = Engine::getInstance()->User_GetUserById($this->getUserId());
    return $oUser->getProfileAvatarPath($iSize);
}

Выводить в шаблоне так:

<img src="{$oTopic->getAuthorAvatarPath(48)}" />

Рад помочь )

До версии 5.2.1 для использования этой функции PHP должен быть собран с указанием --enable-memory-limit.

Ну, естественно :) $oUserCurrent это и есть текущий посетитель. Для вывода аватарки автора топика вам нужно этого самого автора топика получить. В 0.4 версии это будет проще

$oTopic->getUser()->getProfileAvatarPath(48)

А в 0.3.1 вам нужно либо

1) добавить в соответствующий Action код для получения из базы пользователя-автора топика, передать объект с этим пользователем во вьювер и дальше уже выводить;

либо

2) добавить во все методы mapper`a Topic код для вытягивания пути к аватаре пользователя (в JOIN соответствующей таблицы), реализовать в Topic.entity.class.php аксессор к этой характеристике;

либо

3) в Topic.entity.class.php добавить метод getAuthorAvatar(), которое будет вызывать метод класса User, получающий путь аватарки по переданному идентификатору пользователя (этот метод также нужно будет реализовать).

Ну тогда кусок шаблона с этим изображением в студию… посмотрим, что у вас там не так.

Имеется ввиду вывести в шаблоне или в тексте поста?

Если в базу нужно сохранять без ссылки, а выводить во вьювер с ней, то я бы создал новую функцию getLinkedText() в /classes/modules/topic/entity/Topic.entity.class.php.

(Это избавит вас от проблем с редактированием статьи). Что будет если пользователь открыв редактировать статью затрет ссылку? Или добавит новое предложение, тогда ссылка станет не на первой точке? Т.е. каждый раз нужно будет выяснять — есть ли ссылка, где и насколько правильная.

На какую ссылку и зачем это нужно? Для сохранения в базе? Или только для вывода во вьювере?

1) Правила нужно вписывать в основной конфиг. Или в любое другое место, где они будут добавлены в основной конфиг.
2) Правила не нужно использовать, они используются Viewer`ом автоматически.
3) Приведенные в примере строки уже добавлены в конфиг ядра.

Немного не понял проблему: о какой части конфига идет речь?

Так сделан шаблон.
/templates/skin/new/actions/ActionPage/page.tpl

{assign var="bNoSidebar" value=true}

вот эту строку уберите.

На самом деле — Sphinx это только инструмент, которые позволяет выполнять некоторые вещи гораздо быстрее, чем это делает СУБД.

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

Можно, конечно, рассматривать вариант хранения связи в базе данных, и считать при этом, что если топик А похож на Б, то Б похож на А. Плюс хранить условный показатель релевантности, чтобы по нему проводить сортировку.

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

В #551 исправлено (уже с новой системой проверки).