Протолкнуть в Joomla 4 отключение hits - Joomla 4 и Joomla 5: Общие вопросы

Всем кривет!
На днях на org-е опять всплыла тема про счетчик посещения статей, и мне стало как-то грустно опять объяснять, что в текущем виде это - козья какашка, бесполезная от слова "совсем".
Немного погуглив, я узрел чудесатые способы борьбы с этим счетчиком:
подмена системный плагином класса JTable или доп. запрос в базу на вычитание значение счетчика в зависимости от условий (типа, борьба с накруткой в момент правки статьи).
В связи с чем предлагаю знатокам логов и консолей толкнуть телегу в сторону гитхаба на предмет опции в админке, отключающей этот инкремент совсем.
Типа, чтобы можно было делать плагины для нормального счетчика, использующие это поле в базе (чтобы стандартные шаблоны и модули его казали) без оглядки на бессмысленную накрутку.

запостил сюда
https://github.com/joomla/joomla-cms/issues/22406
заинтересованным просьба пойти и наругать всех, кто сопротивляется прогрессу 

А ссылки на темы для поддержания?

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

реально ли это малой кровью

Реально.
Необходимо 3 новых триггера для плагина и новая folder.
1. Триггер вызов самой функции, прибавления хита.
2. Триггер в модели на обращения к функции JTable
3. Триггер в Jtable на изменении значения в таблице.

Можно сократить до двух. отставив 1 и 2 или 3 тригер. Или даже просто отставить только 1, потому что функции изменения значения в таблице, ни как не влияют на накрутку.

Однако, кроме написания самого плагина, придется править все компоненты из коробки в которой есть хиты. Так что объем все равно не маленький.

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

Это касается реализации данного замысла.


Что же касается самой идеи, делать PR без "поддерживаемого" issue, который покажет нужность и важность данного изменения, создавать PR простая трата времени ибо без должной поддержи и необходимости подобных изменений PR просто закроют, причем сначала он полгода будет "заброшенным", пока автор сам его не закроет.

Так или иначе создавайте issue, а там будет видно, если issue будет популярным кто-нибудь возьмется за реализацию, ну а если нет, то вы будете точно знать, что данная тема в сообществе не актуальна.

я имел в виду только отключение счетчика.
плагин можно отдельно написать тупо контентный. его не надо в PR.
нужна только настройка в общих опциях материала, которая заблокирует инкремент.

нужна только настройка в общих опциях материала, которая заблокирует инкремент.

Это еще проще.

Вызов функции находиться в главном контролере "обернуть" его в условие и готово.

Но все равно сначала issue

прикол в том, что это нифига не ошибка, а фича такая-счиать все-любое.
типа, они могут "исправить" отключив счетчик в админке, но это тоже никак не поможет в дальнейшем, так что надо сразу PR постить.

отключив счетчик в админке,

В админке счетчик и не считает, там нет функции вызова. Там просто поле hits.

так что надо сразу PR постить.

Не стоит. Будет просто трата времени. И споров прямо в PR. Лучше подобные вопросы решать в issue.

Лично я за то чтобы изначально исправить сам вызов, так чтобы исключать накрутку, но как это лучше сделать не знаю, да и не сильно меня данная тема волнует.

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

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

Не бойтесь вы так GitHub, там очень милые и добрые люди. Если идея покажется интересной, тогда и исполнитель найдется.

о, там же есть опция "предложить улучшение".
я думал, только ошибки можно постить )
ну, попробовал
https://github.com/joomla/joomla-cms/issues/22406

Опять это Брайн вылез. Где обещанные милые люди?!   

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

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

Опять это Брайн вылез. Где обещанные милые люди?!

Вот тут https://github.com/joomla/joomla-cms/issues/15771 =)

не, там совсем революционеры.
хотят все взорвать, а я мирный человек - только отключить хочу. 
но может они в мою тему переметнуться, раз у них не случилось революции ).

т.е. если тупо писать сторонний плагин, то надо будет везде хакать и переопределять вывод стандартного счетчика, а так - одна опция и все.

Не нужно ничего переопределять, просто получиться 1 лишний запрос во view=article, чтобы изменить значение столбца смотри пишем такой системны плагин.

• Добавляем столбей `my_hits` в в таблицу `content`, чтобы не делать запросов для получения кол-ва просмотров
• В onContentPrepare просто подменяем hits на my_hits
• В onAfterRender проверяем что это view=article и обновляем значение.`my_hits` Это единственный дополнительные запрос

да это все изврат!
есть готовое поле, которое не работает.
все что надо, отрубить от него бесполезный счетчик и все.
тем более, для тех, кому не нужен этот счетчик вообще будет прирост производительности за счет кэширования таблицы.
зачем обходить, когда правильнее сделать одну опцию?

да это все изврат!

Это обычное расширение ядра. Без каких либо костылей, и в рамках одного плагина.

тем более, для тех, кому не нужен этот счетчик вообще будет прирост производительности за счет кэширования таблицы.
зачем обходить, когда правильнее сделать одну опцию?

Тут я с тобой полностью согласен, об этом я написал на github.
Но и @brianteeman прав, счетчик тоже нужно исправить.

@effrit Добавь в заголовок на github [4.0]

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

эмм. имеешь в виду Joomla 4?

щас начнут латать корыто, а корабля все равно не выйдет и будет полумера, которая не вашим и не нашим.

Если исправят счетчик, то сделать потом опцию будет куда проще. Отключение из-за того что что-то не работает не примут.

эмм. имеешь в виду Joomla 4?

Да примерно так (4.0 и прощу прокомментировать)
[4.0] [RFC] Option for Disable Hits counter increment

щас начнут латать корыто, а корабля все равно не выйдет и будет полумера, которая не вашим и не нашим.

Будет одно из 3.
1. Удалят хиты с концами (мало вероятно)
2. Будут исправлять счетчик, вероятно, но не скоро.
3. Исправят счетчик и сделают опцию.

опция сразу несколько проблем снимает, не надо счетчик исправлять - это утопия на подобии встроенной системы аналитики.
смысл в том, что надо тупо освободить поле для конкуренции и убрать лишние запросы к базе.

не надо счетчик исправлять

Такой подход не прокатит. Счетчик либо сносить либо исправлять. Тут полумеру сделать врядли дадут.

По ходу, все прокатило )
https://github.com/joomla/joomla-cms/pull/22413
и работает.
просьба затестить и апривить тест.
https://issues.joomla.org/tracker/joomla-cms/22413

По ходу, все прокатило )
https://github.com/joomla/joomla-cms/pull/22413
и работает.
просьба затестить и апривить тест.
https://issues.joomla.org/tracker/joomla-cms/22413

Ну вот видишь. Значит я был не прав и возможно все таки прокатит. Хотя от создания PR до merge путь может быть долгим и тернистым. К тому же PR под 3.x

Да и хорошо, что под тройку. Если прокатит, то под 4-ку проще будет сделать.

протестил, проголосовал, лайкнул, расшарил, подписался а, это не тут

ага, кто третим будет? (и четвертым - тоже  )