How does WP DoNotTrack help me comply with the EU Cookie Law?

Most solutions for Cookie Law compliance focus on alerting the user of the fact that cookies are needed and on allowing or disallowing 1st party cookies (i.e. from your own site) from being set. WP DoNotTrack takes a different (and complementary) approach, with the ability to act on user preference as configured in the browser or an opt-out cookie being present (see below) to conditionally stop javascript-initiated 3rd party tracking.

How can I make my users choose not to be tracked and/or integrate with Civic Cookie Control?

Starting with version 0.8.0, WP DoNotTrack supports conditional tracking based on cookies. There currently are two approaches to do this:

display a message asking your user to allow (or OK) tracking. If the user does not want to allow this, simply set a cookie (in JavaScript or PHP) with name “dont_track_me” and value “1” and WP DoNotTrack will pick up on that much in the same way it works with the browsers DNT-flag.

Should I run WP DoNotTrack in black- or whitelist mode?

Although whitelist is more robust and future-proof, it might break things in both frontend and wp-admin. If you don’t want to test extensively and you’re not sure to begin with, start out going blacklist first.

How should I create my blacklist?

Check what requests the browser makes when not logged in (look at a couple of different pages) and add the hostname of URL’s you deem unfit to the blacklist

Disable any caching- or javascript-aggregating plugin while testing/ making changes

Try an external service like webpagetest.org to make sure you’re seeing a real anonymous user’s view

How should I create a whitelist?

Whitelisting is somewhat more impacting, as it’ll stop anything you don’t explicitely allow. Be sure to study requests for both visitors and logged in users in wp-admin. In general you’d want to allow known hosts such as e.g. google-analytics.com.

Make sure to test extensively after enabling the whitelist and tweak until everything works to your satisfaction.

Disable any caching- or javascript-aggregating plugin while testing/ making changes

Try an external service like webpagetest.org to make sure you’re seeing a real anonymous user’s view

Can WP DoNotTrack stop all 3rd party tracking?

Yes, but No. When running in Normal or Forced mode, WP DoNotTrack stops most javascript-initiated 3rd party code inclusion. When running in SuperClean Mode, WP DoNotTrack will also filter the HTML. There are, however, circumstances in which tracking is unavoidable or invisible to WP DoNotTrack:

some widgets (in the broad sense) only work with tracking enabled (e.g. Facebook Like button or Google Analytics tracking)

some trackers use Flash, which is simply out of reach of what WP DoNotTrack currently can do

Why would I need “forced” mode?

Javascript (and CSS/ HTML) optimizing plugins such as W3 Total Cache and Autoptimize change the way JavaScript is loaded (by combining, minimizing and loading at the end of the page), which can break or limit WP DoNotTrack’s functionality.

Why use “SuperClean” mode?

By default DoNotTrack is used to stop javascript trackers, which typically only add the tracking stuff to your pages when executed in the browser. Some widgets/ plugins/ themes might also add tracking to the HTML (as a hidden image, iframe or with javascript). “SuperClean” mode checks the HTML before it is sent to the browser to stop that kind of tracking. Be warned that SuperClean is pretty invasive functionality, so do test extensively!

Why can’t I select “SuperClean” mode?

Superclean is not yet available if you’re only enabling WP DoNotTrack for people who configured their browsers to do so (conditional filtering based on the donottrack-header) or who opted out with a cookie. This might become available in the future, but there’s caching plugins to take into account when combining conditional filtering with SuperClean.

Any bugs/ issues should I know about?

After installing or when making changes to the WP DoNotTrack configuration, you might have to clear the caches of caching plugins you might be using (e.g. WP Super Cache or W3 Total Cache). Consider it “best practice” to disable caching & javascript-aggregating plugins while testing new black- or whitelists

ClourFlare seems to interfere with the way the plugin gets loaded and the way it functions. You can solve the problem by disabling “Rocket Loader” and/or “Auto Minify” alltogether.

Not a bug, but still an known issue; as WP DoNotTrack is also active in the wp-admin-pages, it will -when in whitelist mode- impact plugins that (for whatever reason) pull in javascript from elsewhere in their option-pages. This very plugin for instance, depends on googleapis.com to render a rss-widget.

0.8.4

0.8.3

bugfix: wp donottrack did not act on trackers in admin-screens (there’s no output buffering in /wp-admin/*, so revert to “normal” mode type of enforcement in that case). hat tip to iltrev from minimoblog.it for reporting!