@mattab opened this issue on February 28th 2010

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 commented on March 1st 2010

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

@robocoder commented on March 1st 2010

Rolling into #41.

@mattab commented on March 5th 2010

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 usingdocument.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 commented on March 5th 2010

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 commented on March 5th 2010

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 commented on March 5th 2010

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 commented on March 5th 2010

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

@robocoder commented on March 5th 2010

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

@robocoder commented on March 5th 2010

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

@mattab commented on March 18th 2010

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.

This issue was closed on March 18th 2010
Powered by GitHub Issue Mirror