LiveStreet CMS

да, VK не дает

есть такое. стоит в todo сделать выход только из текущей

вообще я вышеприведенным кодом CRUD и реализовывал. Там еще строчки по сути добавить с ORM сущностями и в БД даже лазать не нужно.

чтобы вас не «вышли» с помощью картинки с адресом http://livestreet.ru/login/exit/

*париться )

так можно взять ORM сущность и вообще не парится — там все есть из коробки

Посмотрите в сторону плагина api
А вообще реализация простая, что-то типа такого:

class ActionCrud extends Action {
    public function Init() {
        $this->Viewer_SetResponseAjax('json');
        $this->setDefaultEvent('read');
    }
    
    protected function RegisterEvent() {		            
        $this->AddEvent('read','EventReadData');
        $this->AddEvent('create','EventCreateData');
        $this->AddEvent('update','EventUpdateData');
        $this->AddEvent('destroy','EventDestroyData');  
    }

    protected function EventReadData() {
    
    }
    protected function EventCreateData() {
    
    }
    protected function EventUpdateData() {        
        $httpData = $this->getHttpContent();
    }
    
    protected function EventDestroyData() {
    
    }
    
    protected function getHttpContent() {
        $raw  = '';
        $httpContent = fopen('php://input', 'r');
        while ($kb = fread($httpContent, 1024)) {
            $raw .= $kb;
        }
        fclose($httpContent);
        return json_decode($raw, true);
    }
    
}

Пользуемся поиском

да, забыл, что так тоже можно

Конечно.
Сделайте наследование класса ModuleViewer в вашем плагине.

class PluginYourplugin_ModuleViewer extends PluginYourplugin_Inherit_ModuleViewer {
	
	public function Init($bLocal=false) {
            $this->sHtmlTitleSeparation = ' | ';
	    return parent::Init($bLocal);
	}
}

Я вообще себе сделал вытягивание и кеширование просмотров к топикам отдельно (так чтобы обновление не затрагивало кеш всего топика), даже к этому плагину когда-то писал дополнение.
Беспокоило то, что при большой интенсивности запросов update, вероятно, блокируется таблица со всеми топиками, что тормозит селекты.
Отдельная таблица не спасает, если она джоинится. Так что вариант таки дублировать это поле в двух таблицах и обновлять значения в таблице с топиками по крону, как предложил Wasja . Даже сделать ее типом MEMORY и транкейтить раз в час, например, после обновления данных в основной.

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

Если не секрет, можно на пальцах пояснить, будет ли прирост производительности, если данные о посещениях все равно надо вынимать. И та доп таблица будет джоиниться в каждом запросе. Разве что она не будет участвовать в выборке ключей топиков по фильтру (если не участвует в сортировке)?

Добавьте индекс на поле просмотров, раз есть возможность по нему сортировать.

Я делал нечто похожее, но с сохранением сессий в БД на каждую авторизацию + возможностью настроить макс количество хранимых сессий для юзера.

В своем приложении на фейсбуке надо включить параметр «status and review»

Тогда меняйте ту строчку на

$('#comment_wrapper_id_'+idCommentParent+' .comment:eq(0)').after(newComment);

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

попробуйте тогда prepend вместо append

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

по идее не должны:

$('#comments > .comment-wrapper:first').before(newComment);

тут стоит before