Extension talk:HitCounters/Archive

Thank you for creating this extension!
I look forward to following its development. --PhotographerTom (talk) 18:31, 2 June 2015 (UTC)

Update from 1.24
Will this extension use old data statistic? Or it was removed from database by maintenance script?

BTW: Download link is broken.


 * If I am not mistaken the old core tables are still preserved when upgrading to 1.25 so the data should still be there. This is the zip for MW 1.25.x at the moment. Cheers --&#91;&#91;kgh&#93;&#93; (talk) 11:59, 17 June 2015 (UTC)


 * Thanks. It's work, but with Extension:DynamicPageList (third-party) and popularity sorting give this:


 * SELECT page_namespace,page_title FROM `wiki_page` INNER JOIN `wiki_categorylinks` AS c1 ON ((page_id = c1.cl_from) AND (c1.cl_to='Category')) WHERE page_is_redirect = '0' ORDER BY page_counter DESC LIMIT 10


 * 1054 Unknown column 'page_counter' in 'order clause' (localhost)


 * --UksusoFF (talk) 14:08, 17 June 2015 (UTC)


 * I get


 * The DPL extension (version 2.3.0) produced a SQL statement which lead to a Database error. The reason may be an internal error of DPL or an error which you made, especially when using DPL options like titleregexp. Query text is:  Error message is: Unknown column 'page_counter' in 'order clause' (localhost)


 * with DPL, so I think DPL is now incompatible with this extension and needs to be updated. --&#91;&#91;kgh&#93;&#93; (talk) 16:17, 17 June 2015 (UTC)


 * This issue is now . Maiden taiwan (talk) 16:31, 11 December 2015 (UTC)


 * I just uploaded a patch to fix this. You can find it attached to . (I'm not too familiar with MediaWiki code review etc., so - any volunteer to get the patch into the official code? ;-) --Cboltz (talk) 22:06, 2 January 2017 (UTC)

A database query error has occurred.
Placing it here until this extension is set up on Phabricator.

Hmm ..., I am a bit puzzled. I upgraded from 1.22.15 to 1.25.1. In a second step I added the HitCounters extension. From the error message I get I come to believe that the former "hit_counter" table was removed at the first step:

A database query error has occurred. This may indicate a bug in the software.

Query: SELECT page_counter AS hits FROM `hit_counter` WHERE page_id = '1' Function: HitCounters\HitCounters::getCount Error: 1146 Table 'myWiki.hit_counter' doesn't exist (localhost)

--&#91;&#91;kgh&#93;&#93; (talk) 16:04, 17 June 2015 (UTC)


 * After running "update.php" via the Extension:MaintenanceShell extension this error message vanishes and all the previous hits for pages show up. So I now figured out that core used "hitcounter" and this extension creates "hit_counter" and somehow moves the content over to keep on running. So this issue is invalid. --&#91;&#91;kgh&#93;&#93; (talk) 16:13, 17 June 2015 (UTC)


 * Just don't forget to run update.php while the extension is being included. :) Brettz9 (talk) 05:32, 3 October 2016 (UTC)

HitCounters does not create a table if installed via web updater
Placing it here until this extension is set up on Phabricator.

Actually a follow up to the previous post. I tried to add this extension via the web updated since it is a shared hosing environment however when running the update script no table is created. So I naturally get the same error message as before.

--&#91;&#91;kgh&#93;&#93; (talk) 16:07, 17 June 2015 (UTC)
 * I have evaluated the current situation with this extension: Basically, the update to MediaWiki 1.26 can or will screw things up in the following cases:
 * If the extension has been installed in MediaWiki 1.25, people should have run update.php when they installed the extension. Should they not have run update.php, the upgrade to MediaWiki 1.26 will remove hitcounter data. This is an installation error, which not the MW devs, but the according installation administrator is to be blamed for.
 * If people have used MediaWiki 1.25, but have not used the extension, they obviously do not care for these numbers. That's not a problem here; numbers will be old and inaccurate in that case anyway. Cleaning them up is the next logical step.
 * If people however upgrade to MediaWiki 1.26 from a version older than 1.25, then they cannot have used the extension before, because the original counter feature still had been there for them (and I think no one knows, if the extension might be working with MediaWiki versions, for which it was not made). In this case, the upgrade to MediaWiki 1.26 will remove hitcounter data.
 * With other words: If you upgrade from a version older than MediaWiki 1.25, you are screwed. --87.123.44.213 03:23, 3 January 2016 (UTC)

Upgrade from 1.24 to 1.26 and how I unbroke my system
The wiki I manage has about 600 pages. A week or so ago I upgraded it from 1.24.X to 1.26 and failed to spot that the PopularPages feature was turned off. This was pointed out to me yesterday my one of my editors who uses that function.

Fortunately I found this Extension, and also I had backed up the wiki before doing the upgrade! So all the data I needed was available (in the page_counter field of the page table). I have some knowledge of SQL, and phpMyAdmin access to the database. I was able to re-insert the page_counter data from the backup (OK so I've lost a few days' data) and run the upgrade.php, and all was well. Actually the first time I got the "A database query error has occurred." message mentioned above, but I re-ran update.php and it all worked after that. (This description is simplified of course)

So I was not screwed as "87.123.44.213" suggested!
 * You were not because you a) had a backup and because you b) knew how to manually fix the database - after the updater had already deleted the hit numbers. At least the last of these two should in fact not be necessary in order to do something as simple as an update.
 * However, thank you for testing the instructions, which I added to the article just yesterday. One thing is not completely clear to me: It is clear that you have to run update.php in order to migrate the data to the new places. But you say that you had to run it not once, but twice in order to get the migration done? --87.123.13.117 12:35, 3 January 2016 (UTC)

MW 1.26.2 Compatibility
I have recently installed MediaWiki 1.26.2. Am I understanding it correctly that if I try to install this it will not work? I have admin DB access, what if I create the hitcounter table manually? My goal is to create a list of most popular pages.
 * You can create the tables/columns manually, but if that is all you do, they will be empty. Counting will then start from 0. If you already have hit numbers and if you want to keep them, then you will have to move them to these new columns. Please note that, if you upgraded to MediaWiki 1.26 without having the extension installed and without having used update.php prior to that upgrade, then the upgrade to MediaWiki 1.26 will have removed your hit numbers. --87.123.15.121 15:34, 30 January 2016 (UTC)

Manual generation of DB tables during upgrade
I'm upgrading a wiki from 1.20.0 to 1.27.0. Before executing MW's, I executed the following queries to save off the old hit counts for this extension. Then I executed  (with this extension already installed). Still testing, though this seems to have worked...and is much easier than the double-upgrade method. RENAME TABLE hitcounter TO hit_counter_extension; CREATE TABLE hit_counter ( page_id INT(8) UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,  page_counter BIGINT(20) UNSIGNED NOT NULL DEFAULT '0' ) ; CREATE INDEX page_counter ON hit_counter (page_counter); INSERT INTO hit_counter (page_id, page_counter) SELECT page.page_id, page.page_counter FROM page; --&mdash;  lziobro   (talk)  14:30, 1 August 2016 (UTC)


 * I got caught by this after I'd upgrade my pre-production rehearsal for a wiki where I've eventually persuaded the owner to upgrade from 1.19 to current LTS. I prefer to have minimum down time, so I do a full dress rehearsal, then set parallel clone on prod, drop the service, execute a few mvs to hook up all of the correct directories and run the upgrade script on the DB.  So I am using some thing similar except cloning my page into temp_page, doing the upgrade, creating hit_counter and hit_counter_extension and then doing the insert, before bouncing Apache and bring the new version online.   Cut-over all fully scripted. Seems to work fine.  No counters lost.  :-) TerryE (talk) 04:44, 9 February 2017 (UTC)

Installing on upgraded 1.27.1
When installing this extension the wiki returned the following error on all page requests: A database query error has occurred. This may indicate a bug in the software. I presume it's because I had ran php maintenance/update.php after my upgrade while going straight to 1.27.1 from a much older version. Wiki's where I've so far ran update.php after upgrading appears to have removed the mysite_hitcounter table altogether.

I have of course done a complete mysqldump before upgrading, so my hitcounter data are not all lost.

Can anyone here provide clear instructions for a non-expert on how to make this extension work while restoring the past counter data from an sql or xml dump (I have both), either via the command line or via a phpMyAdmin web interface?

The original hit counter provided a useful measure of individual page accesses, nothing more or less. The counter should not have been removed from core in my opinion. Instead, it could better have been made a non-default option in case many people considered it useless.

Installing on 1.28
Downloaded and installed the extension on a fresh 1.28 Mediawiki. update.php delivers the following error

MediaWiki 1.28.0 Updater

Your composer.lock file is up to date with current dependencies! Going to run database updates for my_wiki Depending on the size of your database this may take a while! Abort with control-c in the next five seconds (skip this countdown with --quick) ... 0 PHP Fatal error: Class 'FormatJson' not found in /var/www/html/mediawiki/feedback/includes/exception/MWExceptionHandler.php on line 624

and on the wiki pages I got

A database query error has occurred. This may indicate a bug in the software.[ecc19dc621575289ab689029] 2017-03-09 10:44:29: Fatal exception of type "DBQueryError"

Anything I can do? --Sigbert (talk) 10:50, 9 March 2017 (UTC)