Почему [[+views]] различается у разных сниппетов?
Почему количество просмотров ([[+views]]) различается у разных сниппетов, а именно у getTickets и TicketMeta?
Вот вызов getTickets:
Оба эти вызова выводят разное количество просмотров для одной и той же страницы. Почему так?
P.S. Накрутка просмотров гостями разрешена в настройках, хотя не думаю что из-за этого разница в выводе.
Вот вызов getTickets:
[[!getTickets?
&tpl=`@INLINE Просмотров: [[+views]]` // выводит 18
]]
а вот вызов TicketMeta уже на самой странице:[[!TicketMeta?
&tpl=`@INLINE Просмотров: [[+views]]` // выводит 6
]]
Оба эти вызова выводят разное количество просмотров для одной и той же страницы. Почему так?
P.S. Накрутка просмотров гостями разрешена в настройках, хотя не думаю что из-за этого разница в выводе.
Поблагодарить автора
Отправить деньги
Комментарии: 6
Не нужно использовать [[+views]] в INLINE чанках, парсер может неожиданно обработать их еще до вызова сниппета.
Замени на {{+views}} — должно помочь.
Замени на {{+views}} — должно помочь.
Интересно, спасибо. Но проблему это не решило.
Дело в том, что первый вызов вызывался в обычном чанке (тут я упростил для примера), а второй в INLINE.
Заменил второму на {{}} — не помогло.
Указал второму реальный чанк (теперь оба вызова в реальных чанках) — результат тот же…
Дело в том, что первый вызов вызывался в обычном чанке (тут я упростил для примера), а второй в INLINE.
Заменил второму на {{}} — не помогло.
Указал второму реальный чанк (теперь оба вызова в реальных чанках) — результат тот же…
Ну тогда не знаю, у нас на сайте такой проблемы не вижу.
Очень странно. Сменил везде на INLINE чанки с {{+views}}, результат тоже разный, хотя [[+id]] у них одинаковый.
Интересно что на сайте есть ещё и блок «Популярные статьи», где просмотры совпадают с первым обычным getTickets и сортируют правильно по просмотрам:
P.S. Попробовал просмотреть в режиме инкогнито — количество просмотров уравнялось (как у TicketMeta). Очистка кэша не влияет.
Почему интересно у залогинившегося пользователя getTickets считает чуть ли не в геометрической прогрессии?
Интересно что на сайте есть ещё и блок «Популярные статьи», где просмотры совпадают с первым обычным getTickets и сортируют правильно по просмотрам:
[[!getTickets?
&tpl=`@INLINE
<li>
<a href="{{+uri}}" class="clearfix">
<div class="h3 uk-text-left" title="{{+pagetitle}}" data-uk-tooltip>{{+pagetitle:ellipsis=`40`}}</div>
<p>{{+introtext:notags:ellipsis=`50`}}</p>
<div class="uk-text-muted">
<span class="glyphicon glyphicon-eye-open"></span>
<span>{{+views}} {{+views:units=`просмотр|просмотра|просмотров`}}</span>
</div>
</a>
</li>
`
&parents=`[[%articles_tickets_id]]`
&includeContent=`0`
&leftJoin=`{
"View": {
"class":"TicketView",
"alias":"View",
"on": "Ticket.id = View.parent"
}
}`
&select=`{
"Ticket":"*",
"View": "COUNT(View.parent) as views"
}`
&sortby=`views`
&groupby=`Ticket.id`
&sortdir=`DESC`
&limit=`5`
]]
Вот какая закономерность у статей:getTickets || TicketMeta
21 || 7
18 || 6
8 || 4
3 || 3
2 || 2
Может быть сниппеты как-то считают только по конкретному пользователю (например &getUser)?P.S. Попробовал просмотреть в режиме инкогнито — количество просмотров уравнялось (как у TicketMeta). Очистка кэша не влияет.
Почему интересно у залогинившегося пользователя getTickets считает чуть ли не в геометрической прогрессии?
Проверил под другим пользователем всё нормально. Это скорее всего из-за того, что одним техническим логином (под которым я проверял) работало одновременно несколько человек, хотя это только догадки…
Вопрос снят, спасибо за помощь!
Вопрос снят, спасибо за помощь!
Да, эта проблема почему-то только у одного пользователя, под которым я и работал. Сброс кэша, снятие блокировок, перезагрузка прав доступа и завершение всех сеансов не вылечили этого пользователя…
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.