LiveStreet CMS

Ресурсы жрать — это понятно и ожидаемо.

Насчет pusher.com — ограничение «20 Max Connections» удивило. Это 20 одновременно авторизированных пользователя весь бесплатный лимит съедят?

Впечатлен. Но необходимость дополнительного сервера по-моему значительно уменьшает диапазон применения.

1) в файле «topic_part_header.tpl» нужно добавить target="_blank" в строку

<a href="{$oTopic->getUrl()}">{$oTopic->getTitle()|escape:'html'}</a>

2) в файле «topic_part_footer.tpl» добавить target="_blank" в строки

<a href="{$oTopic->getUrl()}#comments" title="{$aLang.topic_comment_read}" class="new">

<a href="{$oTopic->getUrl()}#comments" title="{$aLang.topic_comment_read}">

3) в файле «topic_photoset.tpl» добавить target="_blank" в строку

<a href="{$oTopic->getUrl()}#cut" title="{$aLang.topic_read_more}">

4) в файле «topic_photoset.tpl» заменить строку

<div class="topic-photo-preview" id="photoset-main-preview-{$oTopic->getId()}" onclick="window.location='{$oTopic->getUrl()}#photoset'">

на строку

<div class="topic-photo-preview" id="photoset-main-preview-{$oTopic->getId()}" onclick="window.open('{$oTopic->getUrl()}#photoset')">

Поставьте значение 999999 вместо -20.

$config['acl']['create']['topic']['limit_rating']   	  =  -20;// порог рейтинга при котором юзер может создавать топики (учитываются любые блоги, включая персональные), как дополнительная защита от спама/троллинга

Интересная технология, но вот вот совместимость с браузерами не радует.

Можно подумать…
А какой именно функционал интересует?

Просмотр сделать просто, вопрос в том как определять кому можно смотреть, кому нельзя… Есть идеи?

Но по большому счету чем это будет отличаться от топиков в закрытых блогах?

Админы это и так могут, может не всегда напрямую, но всё же.

А так сможет напрямую. :)

Например, для совместной работы над черновиком или для приватного просмотра определённого круга лиц.

Совместную работу над черновиком (одновременное редактирование) на LS без очень крупной надстройки над стандартным функционалом не сделаешь.

На GitHub все версии вроде бы есть.

Правильно. Но всегда есть исключения. Как пример, к основному домену может быть привязан сервис, не связанный с HTTP — SVN, Git, FTP и др. В данном случае привязка к SVN основного домена не возможна. А отдельный поддомен с изображениями, почему не привязать, если он создает максимум загрузки траффика?

В данном случае nginx используется как front-end к apache. И это его основная задача.

Кстати говоря, как специалист по настройке серверов, как думаете, какой из методов производительнее:
1) настроен домен и поддомен;
2) настроен домен и правило, которое будет пропускать изображения, CSS, JS мимо Apache.

Для чего все это нужно?

Как и сказано — для выноса статических файлов на отдельный поддомен. В примере это позволяет четко разграничить доступ к файлам с помощью nginx. Конечно, это можно было и помощью дополнительного правила nginx сделать, но тут как кому нравиться. Дальше к этому поддомену можно прицепить CDN, например. Не сталкивались никогда с серверами, где нужно оплачивать внешний трафик и хотелось бы минимизировать затраты?

ServerAlias img.site.ru можно убрать.

У меня как минимум в одном случае без этой строки поддомен не заводился.

Не переносите файлы шаблона и отключаете привязку JS и CSS к статическому домену ($config['use_static_cache']=false) и остаются только картинки.

1) Работа плагина переделана на использование хуков вместо делегации файлов шаблона.
2) Добавлен параметр $config['show_icon'] — загружать скрипт, отображающий иконки соцсетей возле имени автора комментария.
3) Исправлена ошибка с формированием ссылки на профиль автора у гостевого комментария.
4) Исправлено отображение информации об авторах комментариев в «Активности».
5) Работоспособность плагина проверена:
— на шаблонах «Synio» и «Developer»;
— с плагинами «EditComment», «Starrating»;
— плагин «Reposter» требует небольшой модификации.

Искать пробовали?
livestreet.ru/blog/sollutions/15103.html
livestreet.ru/blog/16131.html

Какие-нибудь другие плагины, обрабатывающие изображения установлены?

А какой должен быть правильный адрес?

Сайт установлен не в public_html хостинга, а в субпапку, имя которой соответствует адресу сайта.

Это ни на что влиять не должно.
Вообще можно попробовать перегенерировать ссылки:
1) сохранить бекап БД;
2) деактивировать NiceURL;
3) очистить таблицу «prefix_niceurl_topic»;
4) активировать NiceURL.

Никто не запрещает временно настроить локальный сервер на использование реального домена.