I think to remove it is a good idea,
In general it is useless, it counts the bots, users ... everything ?

You would be amazed at the number of users that really demand this sort of thing. removing it would be a bad idea. iirc didnt @rdeutz do a PR to resolve the issue of hit counting and cache hits

well hit counter doesnt even increment if caching is enabled - its simply not fit for use for so many reasons.

If it is to stay then it should be decoupled from the content item, and implemented in an extendable architectured way

well hit counter doesnt even increment if caching is enabled - its simply not fit for use for so many reasons.

That is what the PR from @rdeutz resolved.

I think a lot of users are actually using this numbers so removing is not the best option. It might be not accurate but it says at least something about the popularity of an article. Maybe transparency about how these numbers are built is a better idea, this might be the plugin description or a tooltip.

That is what the PR from @rdeutz resolved.

partially but the looks of it. #15792

i'd prefer to go with option 1 Moving the hits counting to a new table

storage with redis/memcache as an option

I run several blog sites: hit counter is a 'must' > this is valuable feedback for both the blogger (how popular is my blog) as for the reader (many hits is a good blog).
In current version hit counter IS updated with caching enabled, only showing the actual hit counter is shown on page refresh.
Removing hit counter is a bad idea :S

My vote is for option 1, the hits counter is a must feature for any cms!
Also, many of listing and sorting functionalities are based on hits counter, so it is better to keep it with improvements as suggested.

I don't take those hit counters litteraly, but still it is quite handy.
Say you want to rewrite the texts of your website for example, you see immediatly which are most popular.

So removing it would not be a good option.
But if they are a problem as they are now, they can indeed be put in another table or whatever.

So option 1

I wouldn't mind if you decide to decouple it, so it gets its own repo and bug tracker where people can concentrate on fixing bugs and adding new features, if they wish.

@wilsonge can we have a decision on this please. If it is an accepted proposal it will need quite a bit of work and so it should start soon

Option 3.

Create a new parameter in the com_content component, where you can choose whether you want to or not, count hits.

It can be joined with Option 1.

As long as the hit counter also counts hits of deactivated articles and 404 pages and as long it counts hits even if the site is offline and counts reloading of pages and coming back to the same page during navigation for the same session and doesn't identify stupid bots "that never forget" and pushes up the article on the starting page and ... it's complete senseless and not reliable eyewash.

EDIT: ... and print views ...

Everybody who is relying on this stupid, undifferentiated "statistic" is making a mistake.

Nearly any Hoster is providing statistic tools based upon access logs.
Anybody can use several other statistic tools for no money.

Remove it completely!
Decouple it as a plugin that is clever enough to identify a minimum of these nonsense counts if you think it's worth to have it.

Sorry for harsh words!

None of those alternatives (while more accurate) can be used on a site that wants to display the hits or to sort articles based on hits

You could also show random numbers as hits ;-) Just a joke.

Create a new parameter in the com_content component, where you can choose whether you want to or not, count hits.

I guess it's most easiest and safe way. One option and one condition in controller.
#22413

It seems like something that could happily live in a plugin. onContentPrepare could be used to trigger it, counting hits in a separate table. If you want it, enable it, if not, leave it disabled. It could easily work for extensions other than com_content by using context like is used in the categories table.

With some planning, it could probably be done within a week.

i am just curios, if disabling hits options already merged in 3.9 it will be in 4.0? or we must do another PR?
#22413
also for those who interesting in more accurate counter i made plugin (sorry, it's pending on JED, so http://effrit.com/joomla ). U can also change it so it will stop increment hits for articles.

i am just curios, if disabling hits options already merged in 3.9 it will be in 4.0? or we must do another PR?
#22413
also for those who interesting in more accurate counter i made plugin (sorry, it's pending on JED, so http://effrit.com/joomla ). U can also change it so it will stop increment hits for articles.

i am just curios, if disabling hits options already merged in 3.9 it will be in 4.0? or we must do another PR?
#22413
also for those who interesting in more accurate counter i made plugin (sorry, it's pending on JED, so http://effrit.com/joomla ). U can also change it so it will stop increment hits for articles.

i am just curios, if disabling hits options already merged in 3.9 it will be in 4.0? or we must do another PR?
#22413
also for those who interesting in more accurate counter i made plugin (sorry, it's pending on JED, so effrit.com/joomla ). U can also change it so it will stop increment hits for articles.

i am just curios, if disabling hits options already merged in 3.9 it will be in 4.0? or we must do another PR?
#22413
also for those who interesting in more accurate counter i made plugin.

This is still in RFC phase? Is anyone working on this? A core plugin could be integrated in article sorting and article output. It just needs a decision to move forward.

A core plugin could be integrated in article sorting and article output.

Not really. Hit tracking either needs to be baked into the component or not a feature at all, anything that deals with models and database queries can't have conditionally added filters without either MVC overrides, introducing plugin hooks to allow for query manipulation, or you have the current state of affairs with a few features (i.e. voting) where the plugin adds the UI features but the controller to handle the vote submission or the sort/filter logic is baked into the component itself.