ばか！バカ！　馬鹿ー月！

Is the view counts having problems, or is it officially gone?

RikiNutcase wrote:Is the view counts having problems, or is it officially gone?

I'm pretty sure TLG disabled it again, in favor of faster caching.

thelastguardian wrote:More importantly, however, is that the server is getting overloaded. Mediawiki is not very efficient and requires much computation power. One common way to cut down on usage is to disable the page counter and enable caching.

However every time I do that, people start complaining.

^that...

We already changed to a new server, but still...

Nurin wrote:

thelastguardian wrote:More importantly, however, is that the server is getting overloaded. Mediawiki is not very efficient and requires much computation power. One common way to cut down on usage is to disable the page counter and enable caching.

However every time I do that, people start complaining.

^that...

We already changed to a new server, but still...

We still have spammers so i think that is a bigger problem.

We have some smart cs people here, right? I don't think view-counts are going to be re-enabled on Baka-Tsuki.

So let's talk about alternatives to track page views (or link clicks) with a third party application. Naturally, it has to be free. xD

I was imagining some kind of javascript click counter. "Onclick", it'll submit things to a third party database that tracks the number of times a link on the sidebar is clicked. Would this work on BT (provided the code is added to common.js)? XDD

I was imagining some kind of javascript click counter. "Onclick", it'll submit things to a third party database that tracks the number of times a link on the sidebar is clicked. Would this work on BT (provided the code is added to common.js)? XDD

It would be a bit tricky because of the same-origin policy, i.e. you can't easily call another website via AJAX. A common workaround is using a script (or img) tag to force the browser to load the external site nonetheless (see JSONP). But in general I think it would be better to use the load event on all pages, because you have no guarantee that the request will be fired at all when the user leaves the page after the click event. On the other hand, using that workaround, the user will have to load additional content if you use an external script, increasing the loading time depending on the bandwidth of the external server.
Another alternative, using the onclick event, might be storing the values in the local storage of the user and then, after a certain threshold, committing the numbers to an external server using <script>, <img>, or whatever. But that's silly, I guess.

Alternatively, I often see: Google Analytics (Premium vs. Free) which is supported by MediaWiki via an extension.

Been using Google Analytics for years for things. Their pageview breakdown is very comprehensive and easy to use. Since B-T pages have project name, volume, and chapter as part of the URL this makes searching for the page desired a piece of cake.

Although account permission management with Analytics may prove more annoying, as Analytics is only accessed via Google account and permission given on such a basis. Since the extension seems to modify wiki's general setting and thus forcibly tie all pageview counting for the entire site into one Google Analytics account, information dissemination may require a lot of managing...

Aorii wrote:Although account permission management with Analytics may prove more annoying, as Analytics is only accessed via Google account and permission given on such a basis. Since the extension seems to modify wiki's general setting and thus forcibly tie all pageview counting for the entire site into one Google Analytics account, information dissemination may require a lot of managing...

I think we would have to deal with that problem either way, since there would still be a "data manager" who has access to the server (unless we collectively rent a server that is, but that's overkill) — with the difference that Google might be more reliable than a (probably) cheap server, both in terms of stability and accessibility.

Speaking of which, I just exported the pageview data that I have collected for my lil' statistics web app. Those who are interested can grab them here. All saved as CSV files, but there's also an Excel workbook with a nice chart.

EusthEnoptEron wrote:

Aorii wrote:Although account permission management with Analytics may prove more annoying, as Analytics is only accessed via Google account and permission given on such a basis. Since the extension seems to modify wiki's general setting and thus forcibly tie all pageview counting for the entire site into one Google Analytics account, information dissemination may require a lot of managing...

I think we would have to deal with that problem either way, since there would still be a "data manager" who has access to the server (unless we collectively rent a server that is, but that's overkill) — with the difference that Google might be more reliable than a (probably) cheap server, both in terms of stability and accessibility.

Speaking of which, I just exported the pageview data that I have collected for my lil' statistics web app. Those who are interested can grab them here. All saved as CSV files, but there's also an Excel workbook with a nice chart.

I volunteer Simon. XD

Anyways, if we think the google analytics extension will work, then I'll add that to the mental list of issues to pass to TLG the next time a large cycle comes around.

Also, if people want monthly fb stats, I'll be uploading them here. Unfortunately I don't have raw versions of these past months 'cause I didn't think and already started arranging the data.

*sigh*
My load average is somewhere around this: 0.30, 0.26, 0.19
ePUB generation doesn't even take 10% of that^.

So I have a few spare cores and 70% of the CPUs and 10TB traffic with a gigabit connection.
So the server would easily take on the analytics from B-T

Today I installed Piwik, so if TLG doesn't mind. He could embed it into the wiki.

And to show how it would look like, you can access this PAGE.