Age | Commit message (Collapse) | Author |
|
added a new url parameter send_image=0 to disable sending an
image and instead response with a 204 code
|
|
This change includes three things:
1. Removing note about omitting version number due to "security best practices" as not including a version number is actually more [security through obscurity](https://en.wikipedia.org/wiki/Security_through_obscurity) rather than any real security.
2. Removed the irrelevant Stallman reference.
3. Syntax highlighting.
|
|
Otherwise the behavior whether lifetime will be extended or whether
remaining will be calculated would depend on the time at which
setVisitorCookieTimeout is called which is very confusing. Also makes
sure in case the page is open for an hour and there is a tracking
request the lifetime will not be extended by an hour.
|
|
|
|
after 13 months
instead of 24months. This is the now done by default. If you want different
behavior you can call setVisitorCookieTimeout() manually
|
|
We will now always wait 800ms after a first tracking request was issued.
This should give enough time to create a visitor before any other request
is executed. Ideally we will resolve this issue on the server side as
this problem can occur using other SDKs as well and for some servers or
sometimes the 800ms might be not long enough.
|
|
Delay first content tracking request a bit to make kinda sure a possible
previous pageview request is already executed. If there is a new visitor
and there are 2 tracking requests at nearly same time (eg trackPageView
and trackContentImpression) 2 visits will be created as both visitors
are basically at the same time. This is only a workaround and it this
problem might still occur. Also delay a link earlier in case an
interaction is happening to make sure the browser waits for the
interaction to be tracked.
|
|
remove duplicated code to load autoload.php and to be able to register more autoloaders (eg for test files) on demand. This I got read of many includes that had to be updated all the time and that had to be updated all the time when moving iles
|
|
integration => system
|
|
refs #6257 visitorUUID equal by default for each new Piwik.Tracker
|
|
|
|
|
|
|
|
|
|
installed. When replacing the initial link urls link tracking might not be installed yet but enabled (will be installed on load event). When a click is happening on a content block we still need to use linkTrackingInstalled since then the credirect/tracking request is actually happening and we need to know whether outlink/download will track it or whether we have to do it separately. Make sure to call enableLinkTracking before trackContentImpressions although there should be no huge difference as both will be delayed until ready/load event anyway
|
|
|
|
interaction and also have to use default values
|
|
subdirectory although could not really test it. Also encode redirect uri
|
|
documentation
|
|
could be maybe moved to trackCallback in general?
|
|
in case we detect the URL of an image, video or audio, pdf, ... automatically. Otherwise we cannot display a preview in the UI and one would not know which URL was actually meant. Thinking about using //domain/path instead of http://domain/path as it would track different content pieces for http and https otherwise
|
|
to piwik.js to prevent caching sometimes
|
|
also added removed update script again
|
|
|
|
+ Opera and on my local phantomjs but not on travis phantomjs
|
|
|
|
|
|
|
|
for cross browser support. I fixed many issues as I did not consider that link tracking may be disabled or enabled and the behavior should be different in such a case.
|
|
|
|
track content via php tracker (not tested yet)
|
|
support
|
|
issues and disabled the whitespace check which makes no sense to me. The tests do now run again in PhantomJS but report a lot of failures and I have not looked yet into it.
|
|
still 4 or 5 errors I could not fix so far
|
|
|
|
actually should track the redirects as an event. I do not really see an advantage here as the pageview will be tracked later anyway. Makes it rather confusing...
|
|
the request directly in the helper / private methods we return the request and send the request in the actual tracker callback method
|
|
|
|
|
|
|
|
patch quint in order to make the tests work :(
|
|
were visible before but are not now, mark absoulte url out of content target in case it is a link
|
|
Gonna write some tests
|
|
this I noticed a few things that need to be changed and that do not work, also many possible new features for V2. Already updated a few things but will need to adjust more things before writing tests
|
|
automatically
|
|
Conflicts:
js/piwik.js
|
|
|
|
not. This is quite a complex task and I do not think it can always work 100%. There are too many factors and ways to hide an element. For instance using a zIndex, zoom level, when a div is scrollable, CSS might not be applied yet at the time we scan etc. So far this should cover most cases but it must be clear it cannot work in all and there still needs to be a lot of testing. Also need to detect whether CSS was applied or not
|
|
some APIs to manually track impressions and interactions (we might remove them later again, to be discussed)
|
|
|