Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
mattab opened this issue Feb 28, 2010 · 10 comments
Assignees
Labels
Bug For errors / faults / flaws / inconsistencies etc. Major Indicates the severity or impact or benefit of an issue is much higher than normal but not critical. wontfix If you can reproduce this issue, please reopen the issue or create a new one describing it.
Milestone

Comments

@mattab
Copy link
Member

mattab commented Feb 28, 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
Copy link
Contributor

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

@robocoder
Copy link
Contributor

Rolling into #41.

@mattab
Copy link
Member Author

mattab commented Mar 5, 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 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
Copy link
Contributor

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
Copy link
Member Author

mattab commented Mar 5, 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
Copy link
Contributor

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
Copy link
Member Author

mattab commented Mar 5, 2010

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

@robocoder
Copy link
Contributor

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

@robocoder
Copy link
Contributor

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

@mattab
Copy link
Member Author

mattab commented Mar 18, 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.

@mattab mattab added this to the Piwik 0.5.5 milestone Jul 8, 2014
@mattab mattab self-assigned this Jul 8, 2014
@mattab mattab added the wontfix label Aug 3, 2014
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug For errors / faults / flaws / inconsistencies etc. Major Indicates the severity or impact or benefit of an issue is much higher than normal but not critical. wontfix If you can reproduce this issue, please reopen the issue or create a new one describing it.
Projects
None yet
Development

No branches or pull requests

2 participants