Сразу после активации плагина отображается статистика, которая уже была в БД. Насколько она актуальная — судить Вам, как владельцу сайта. В принципе можно было бы и обнулить всю статистику, чтобы получить равномерные данные.
В любом случае, если число просмотров увеличивается, значит плагин работает нормально.
Да, все правильно, плагин при активации проверил что таблица создана и не создавал.
Но вот откуда эта таблица у Вас и какой плагин ее создал — я не знаю. Возможно имеет смысл задать в конфигурации плагина Views другое имя для таблицы, чтобы не было конфликтов.
Данные ViewStat и не должны переноситься — плагин Views работает параллельно с ViewStat (должны быть включены оба), т.е. иконка Views не отображается (только иконка самого ViewStat), счетчик в таблице не обновляется для избежания дублирования (ViewStat сам считает).
По умолчанию используется класс «topic-info-comments» (стандартный стиль для счетчиков комментариев). Поэтому у Вас 2 пути:
1) изменить стандартный стиль «topic-info-comments» в CSS файлах шаблона;
2) исправить в файле "/plugins/views/templates/skin/default/inject_show_info.tpl" объявление счетчика в строке
<li class="topic-info-comments">
Тут либо задать свой класс, либо жестко прописать цвет в стилях.
В принципе, технически это легко реализуемо — добавить один столбец в таблицу БД и несколько функций для его заполнения. Но я лично не вижу смысла в хранении этой информации.
Цитата из упоминаемого выше комментария за авторством PSNet:
сейчас постоянно (!) апдейтиться таблица топиков с постоянным сбросом кеша каждого просматриваемого топика, это постоянная нагрузка на сервер, и если есть плагины, которые подписываются на событие изменения топика, то они постоянно смыкаются туда-сюда. это неверная логика, это ошибка в архитектуре.
это все равно что постоянно пересохранять топик.
а если счетчик в отдельной таблице (ид_топика, число_просмотров), то:
1. апдейтиться только она и значительно быстрее, без вызова цепочки подписанных плагинов и т.п. Плюс не нужно кеширование, если добавить индекс на поле ид топика.
2. параллельные запросы к данным топика, счетчик которого обновляется, не ждут выполнения этого запроса (не создается очередь)
3. переносимость и не зависимость от версий лс и структуры таблицы
более профессиональный подход ещё сложнее — для высоко нагруженных систем нужно две таблицы: первая, что уже описана (ид_топика, число_просмотров) и ещё одна (только ид_топика): за каждый просмотр топика инсертиться ид топика во вторую таблицу, а крон процесс с неё периодически собирает группированием количество просмотров на топик и обновляет счетчик в первой таблице, а потом удаляет записи ид топика в второй. это дает очень большой выигрыш в скорости т.к. первая таблица нагружена только в момент обновления её по крону и записи одним запросом всех обновленных данных по счетчикам топиков. а постоянная запись за каждый просмотр топика идет во вторую таблицу, которая тоже редко читается кроном. этот способ дает задержку в подсчете актуального количества просмотров на интервал запуска крон-процесса, но производительность вырастает в разы. именно так делают все серьезные проекты, например, ютуб, у которого можно видеть периодическое запоздалое обновление количества просмотров.
У меня нет доступа к платным шаблонам, так что лучше просить их авторов. Тем более, что в большинстве случаев, потребуются исправления одного файла и/или стилей CSS.
Без этого пользователя, Ваш сайт после отключения плагина просто умер. Все блоки, так или иначе связанные с комментариями выдавали бы ошибки при попытках обращения к сущности пользователя-автора комментария.
Альтернативное решение — после авторизации через соцсеть создавать новый аккаунт, но для этого есть специальные плагины, а усложнять этот смысла нет.
Нет, это совсем другой плагин, частично со схожим функционалом (в части работы счетчика), но с несколько другой реализацией (отдельная таблица в БД, использование сессий вместо куков для защиты от накрутки).
В общем можно расценивать как полную замену Viewcount.
Добавлены параметры конфигурации:
— $config['only_users'] — Считать просмотры только от авторизованных пользователей.
— $config['only_once'] — Считать только первый просмотр топика пользователем (в пределах сессии).
В любом случае, если число просмотров увеличивается, значит плагин работает нормально.
Но вот откуда эта таблица у Вас и какой плагин ее создал — я не знаю. Возможно имеет смысл задать в конфигурации плагина Views другое имя для таблицы, чтобы не было конфликтов.
Насчет самой ошибки — сейчас проверю.
1) изменить стандартный стиль «topic-info-comments» в CSS файлах шаблона;
2) исправить в файле "/plugins/views/templates/skin/default/inject_show_info.tpl" объявление счетчика в строке
Тут либо задать свой класс, либо жестко прописать цвет в стилях.
Альтернативное решение — после авторизации через соцсеть создавать новый аккаунт, но для этого есть специальные плагины, а усложнять этот смысла нет.
Но если отключить плагин «Просмотры», а потом включить, то данные из таблицы «prefix_topic» повторно перенесены не будут.
{if Config::Get('view.skin') != 'mobile'} {assign var="countRead" value=$oTopic->getCountRead()} <li class="topic-info-comments"> <a title="{$aLang.plugin.views.viewstitle}" class="views-count"> <i class="icon-views{if $countRead == 0}-zero{/if}"></i> <span>{$countRead}</span> </a> </li> {/if}(class_exists('MobileDetect') && MobileDetect::IsMobileTemplate())При обнаружении мобильного шаблона счетчик не вставляется, на тестовом сайте все работает без проблем
По умолчанию отображаются топики за последний день, если их нет — то за 7 дней. Это стандартный алгоритм, используемый также в «Обсуждаемые» и «ТОР».
Имеете в виду, что перекрыт стандартный класс иконки для мобильного шаблона?
А период «За все время» выбирали?
В общем можно расценивать как полную замену Viewcount.
— $config['only_users'] — Считать просмотры только от авторизованных пользователей.
— $config['only_once'] — Считать только первый просмотр топика пользователем (в пределах сессии).