JS Tracking API should allow filtering of the hash of a url via setAllowAnchor( false )

[mattab]

This is similar to what GA provides with _setAllowAnchor( bool )

When called in the pages, the page URL report would contain the URL hash part, eg. "page.php#news3" instead of "page.php"

see also #1042

[robocoder]

piwik.js doesn't currently strip off the anchor. For backward compatibility, default behavior would be setAllowAnchor(true).

[robocoder]

Rolling into #41.

[mattab]

reopening: the piwik.php "url" parameter doesn't contain the URL hash part. It has to be manually appended in piwik.js https://github.com/piwik/piwik/blob/master/js/piwik.js#L183 by using document.location.hash

However I wonder about side effects of doing so; maybe it should be added at the JS level right now, but stripped off at the php level for backward consistency (most people wouldn't want to have their pages split by hash).

Agreed that #41 is a good place to allow users to show the "Pages" report with Hashes (which would be disabled by default, current behavior)

[robocoder]

I tested under Firefox/IE/Safari, and the hash/anchor/fragment is included in the url parameter. (I'm looking at the web server's access log.)

So, it appears this is stripped off by the server.

[mattab]

You're right indeed.

The bug is that, if you load page#hash1, navigate to page#hash2 and track a page view, the url parameter will still be page#hash1.

I think instead the url parameter should be re-set in the https://github.com/piwik/piwik/blob/master/js/piwik.js#L485 getRequest() function.
If the url was set using setCustomUrl(), it should always override the 'url' parameter.

[robocoder]

With Firefox, trackPageView isn't triggered a second time when navigating to an anchor on the same page because the page isn't reloaded.

[mattab]

I meant, when one manually triggers trackPageView when the anchor changes (which is what I was doing on my website :))

[robocoder]

Ok... I can make the change in comment 8. What about the server and setAllowAnchor?

[robocoder]

(In [1886]) refs #1180 - uses current document.location.href if not overridden by custom URL

[mattab]

I think the current behavior is fine, I'm not sure that we need the setAllowAnchor actually. the current behavior is that the 'url' parameter will contain the hash, which is useful is we need to track campaign parameter in the hash. The hash is then ignored and not recorded in the page view URL. It is however recorded as expected if set in the "Page title", eg. using setDocumentTitle.