Click counter missing for some internal links


UPDATE: I’ve found something here

I noticed the URL generated in the ajax call with path /click/track uses an out of date slug which was changed during the life of the target Topic - could that have affected it? I know most code should rely on the id only, but is this an isolated case where it requires the slug to remain the same as when the link was created in order to work?

BOOM, that’s the problem!

Update the old slug in the source link to the new target slug and the counter appears.

The counters fail because the slug has changed - I think this should be fixed if possible as this should not be a dependency?

WORKAROUND: Update the source link to the new target slug and the counter starts working! @tophee @sam

Unfortunately this is a lot of manual work and you need to identify each mismatching link. A fix to remove this dependency to rely only on the id would be lovely :slight_smile:

Would be also good to check:

  • if the bug affects the ‘arrived from’ counters in the post footers.
  • if adding a mid post location with a heading at the end of the url breaks the counter code e.g. #heading–myheading because I’m not seeing any counters on those types of links …

(Christoph) #13

Unfortunately, I cannot confirm this. Although I found one link where the target slug had indeed changed, but multiple others where correct but without a counter nonetheless. :woozy_face:


Ok but did fixing the slug add the counter in that instance? Worked for me. You may need to impersonate a user to accumulate a count (not sure if it registers admin clicks? Might not. Hence you need user account to check?)

Is it possible no user has clicked those links where the slug was up-to-date in the link? Don’t think using admin account is valid check.

i also think accumulation presently isn’t supported for targets involving mid post headings.

(Jeff Atwood) #15

My edit is your answer @tophee, see first post


Thanks Jeff, l’ll confirm that one tomorrow too.

Any chance we can add counter support for those cases?

(Christoph) #17

So you are saying that internal links will be counted if they don’t have a username appended but not if they do? (If so, is that intended behaviour and if it is why?)

This was one of the first things I checked before I wrote the post and could not confirm it. I have a long table-of-contents type post in which I intentionally omitted the username in order not to skew my stats, but none of the (internal) links had a counter. And this was the case also yesterday. Since people use that post a lot, it’s impossible that none of the links were clicked.

Looking at it today, however, I see some link counters appear for internal links. What has changed since yesterday? We upgraded to latest via a rebuild (because we had to remove the deprecated github linkback plugin).

So, if this ever was a bug (I was never sure from the start, because I wasn’t sure what the intended behaviour was), it may be fixed now.

But does anyone understand what was the cause of this? It looks like someone broke it and fixed it without even realizing it?

Or perhaps there are several things coinciding here? One is the thing with the appended username (which didn’t explain things for me), and another thing is some bug that was fixed in a recent commit.


Do any of your working links contain:

  • an out of date slug tested on latest, still not working/supported - slugs have to be identical to target.
  • a username (taking Jeff’s word for it, not tested).
  • a heading (mid-post) specific link? tested on latest, still not working/supported

Because I don’t think these are supported at the moment and will still fail.

Also I’ve just edited a page (changed just one link) and most of the counters were reset to zero and this is reflected in the database … (according to Data Explorer).

@zogstrip I saw you were looking at this, you might be interested:

  • Do we need to rebake posts?
  • Does rebaking fix out of date slugs?
  • Does rebaking reset counters?
  • Why would an edit of one link, reset all counters?

(Christoph) #19

Some additional observations: I just changed the ownership of that table-of-content post I mentioned earlier and the effect was that all (both internal and external) links had their counters reset to 0; all but the first link in the post (which is an external link).

So there is definitely some huge incoherent behaviour here.

But apart from that it would be more coherent if all counters were reset (or only internal ones or only external ones), I’m wondering whether a change of post ownership should/needs to reset any counter at all? After all, information is being destroyed here.

My proposal would be that neither rebaking nor change of ownership should reset counters.

(Régis Hanol) #20


It should.

Yes, the fix is not retro-compatible.

In the case of the bug I fixed, that was because there was a discrepancy between the cooked link and the link we stored to count the clicks.


Thanks for responding on the weekend!

When you get chance can you comment on the following:

  • Does including a username in the link matter
  • Does including a heading (mid-post # link) matter?
  • Is a global rebake recommended?

wrt to counters

  • is ‘rebuild HTML’ wrench option a rebake of the current post?

(Régis Hanol) #22

They shouldn’t.

If you want your click counters to go back to 0 and work properly sure. It won’t hurt.

Yup, “rebuild HTML” is the user-friendly term for a rebake.



I’ve tried to Rebuild two different posts’ HTML using the admin action on the Wrench but the slugs remained the same, old, incorrect ones:

  • No errors in logs.

from Data Explorer:

  • baked_at suggested the post was updated more or less immediately reflecting the time I requested the Rebuild action.
  • slugs not updated in either raw or cooked columns

(Christoph) #24

Okay, I’ll just start collecting some examples (of internal links without a click counter) as I see them (and, of course, I don’t mean the link reproduced here in the quote but the link in its original location):

Actually, there are even some external links without click counters (although I’m not sure about those since they are my own so I can’t test them):


(Jeff Atwood) #26

I am not sure this is strictly related @david

(David Taylor) #27

They were being counted on the server, but not displayed in the client. Should be fixed by

I am sorry to say that those examples are just because nobody clicked on them :wink: I clicked them and they now have counters.

There are some other issues mentioned in this topic which were resolved in the other topic, or by @zogstrip. If there are any outstanding, let’s open new topics for them.


Thanks a lot guys, appreciate the attention to this functionality!

(Christoph) #29

I think you misunderstood. It wasn’t about the link here on meta but about the links in the post that I linked to. When I referred to that post, none of the internal links had any click counter and even some of the external links didn’t have one (and neither was I able to produce one by clicking either). Today, for whatever reason, all links in that post have a links.

Not sure what this means but I thought I’d mention it.

BTW, here is another little bug: even though ypu are quoting my post and I did get a notification, it is now gone: [unfortunately, uploading my screenshot doesn’t seem to work at the moment, but believe me: it was there and now it’s gone]. Could it bd related to the new mobile menues?

(David Taylor) #30

:ok_hand: - hopefully we’re all good now, but if any issues persist please do start a new topic.

:thinking: unlikely related to the menus, but we did just have a small outage on Meta - it could be that the server went down halfway through publishing your notification.

Only showing most recent notification from a watched topic?
(David Taylor) split this topic #31

A post was split to a new topic: Notification missing from UI

(David Taylor) closed #32

This topic was automatically closed after 47 hours. New replies are no longer allowed.