Jump to content

Extension talk:HitCounters/Archive 1

Add topic
From mediawiki.org
(Redirected from Extension talk:HitCounters/Archive)
Latest comment: 5 years ago by Kghbln in topic Error in 1.32

Thank you for creating this extension!

[edit]

I look forward to following its development. --PhotographerTom (talk) 18:31, 2 June 2015 (UTC)Reply

Update from 1.24

[edit]

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 --[[kgh]] (talk) 11:59, 17 June 2015 (UTC)Reply
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)Reply
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: SELECT DISTINCT `page`.page_namespace AS page_namespace,`page`.page_title AS page_title,`page`.page_id AS page_id FROM `page` INNER JOIN `categorylinks` AS cl0 ON `page`.page_id=cl0.cl_from AND (cl0.cl_to='Comparison') WHERE 1=1 AND `page`.page_is_redirect=0 ORDER BY page_counter DESC LIMIT 5 OFFSET 0 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. --[[kgh]] (talk) 16:17, 17 June 2015 (UTC)Reply
This issue is now task T121155. Maiden taiwan (talk) 16:31, 11 December 2015 (UTC)Reply
I just uploaded a patch to fix this. You can find it attached to task T121155. (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)Reply

A database query error has occurred.

[edit]

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)

--[[kgh]] (talk) 16:04, 17 June 2015 (UTC)Reply

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. --[[kgh]] (talk) 16:13, 17 June 2015 (UTC)Reply
Just don't forget to run update.php while the extension is being included. :) Brettz9 (talk) 05:32, 3 October 2016 (UTC)Reply

HitCounters does not create a table if installed via web updater

[edit]

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.

--[[kgh]] (talk) 16:07, 17 June 2015 (UTC)Reply

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)Reply

Upgrade from 1.24 to 1.26 and how I unbroke my system

[edit]

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)Reply

MW 1.26.2 Compatibility

[edit]

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)Reply

Manual generation of DB tables during upgrade

[edit]

I'm upgrading a wiki from 1.20.0 to 1.27.0. Before executing MW's upgrade.php, I executed the following queries to save off the old hit counts for this extension. Then I executed upgrade.php (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;

--— lziobro (talk) 14:30, 1 August 2016 (UTC)Reply

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)Reply

Installing on upgraded 1.27.1

[edit]

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

[edit]

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)Reply

I'm hitting the same issue as well on 1.28 I went ahead and made a task for the bug Sorvis (talk) 11:53, 19 April 2017 (UTC)Reply

@Sigbert @Sorvis - the extension explicitly states right at the top in a large red warning box it's not going to run on fresh installs of 1.26 or newer, so I'm not sure what you're trying to accomplish. There is no bug - newer versions of MediWiki simply lack the hitcounter table the extension migrates data from. Anzacdoer 2 (talk) 21:18, 11 August 2017 (UTC)Reply
I don't think these issues are related. First, notwithstanding the warning and task T120216, I've installed this extension on a few newer wikis with no problems. It does lose data when upgrading directly to newer versions (1.26+), but after getting around this bug, it works fine with fresh installs (tested on 1.28 & 1.29). Second, this appears to be a legitimate bug and it appears it was fixed on the 1.29 and master branches, as I commented on task T163319. --Ike @ WikiWorks 22:36, 11 August 2017 (UTC)Reply

New Pages not being added

[edit]

I just noticed new pages are not being added to to the table ___hit_counters. I took a really, really quick look at the code and didn't see an insert to the table just page count updates. I could have missed it but I have to run. Did I miss it? Is there something I need to do on new pages? Should I report a bug? Hutchy68 (talk) 15:30, 9 March 2017 (UTC)Reply

Ok, I created a bug report about this with a work around that is not sustainable. See task T160129. Short of it, new pages -> add the page_id to the ___hit_counters table with an initial count set in page_counter field. Hutchy68 (talk) 23:00, 9 March 2017 (UTC)Reply

Issue with the display of the count for pages with the same name but in different namespaces

[edit]

See task T163957 for details on the observed behaviour. If you have thoughts on this please weight in. --[[kgh]] (talk) 22:31, 26 April 2017 (UTC)Reply

This also happens to the accompanying talk pages. This is pretty nasty so keeping the fingers crossed for a fix. --[[kgh]] (talk) 11:47, 2 January 2018 (UTC)Reply

Error in 1.32

[edit]

Was getting an error:

MWException from line 164 of /var/www/vhosts/wiki-aventurica.de/httpdocs/shared/includes/Hooks.php: Invalid callback HitCounters\Hooks:onAbuseFilterGenerateTitleVars in hooks for AbuseFilter-generateTitleVars

Turns out there are some typos in extension.json.

Wrong:

		"AbuseFilter-generateTitleVars": [
			"HitCounters\\Hooks:onAbuseFilterGenerateTitleVars"
		],
		"AbuseFilter-computeVariable": [
			"HitCounters\\Hooks:onAbuseFilterComputeVariable"
		]

Right:


		"AbuseFilter-generateTitleVars": [
			"HitCounters\\Hooks::onAbuseFilterGenerateTitleVars"
		],
		"AbuseFilter-computeVariable": [
			"HitCounters\\Hooks::onAbuseFilterComputeVariable"
		]

--188.109.197.56 09:33, 22 March 2019 (UTC)Reply

Thanks a lot for the note. Reported with task T219063. Cheers --[[kgh]] (talk) 12:03, 23 March 2019 (UTC)Reply