EU e-Privacy Directive / General Data Protection Regulation

This website uses cookies to manage authentication, for analytics, and other functions. To fully use our website, you must agree that we can place these types of cookies on your device.

View Privacy Policy

View e-Privacy Directive Documents

View GDPR Documents

Cookie Name Domain Description
Session Cookie .gdpr.richeyweb.com The session cookie is required for authentication, preference tracking, and other necessary functions to fully engage with this website. The name of the session cookie is randomly generated.
Social Sharing .twitter.com .facebook.com .google.com Accepting this class of cookie will allow us to place social sharing buttons on the page.
Google Ad Cookies .doubleclick.net .everesttech.net Accept and revoke this consent to see Google ads (and associated cookies) come and go on the site.
You have declined cookies. This decision can be reversed.

The GDPR expands upon the EU e-Privacy Directive cookie consent requirements making them more restrictive. Recital 30 and Recital 26 classify (most) cookies as devices that can be used to identify users and define them as personal data. In order to collect personal data, you must gain consent. Because the GDPR demands that consent must be as easy to withdraw as it is to give, the EU e-Privacy Directive plugin has been modified to be in full compliance.

To maintain compliance with this Joomla extension, it must be implemented correctly. The method of implementation prescribes that cookie-creating content be treated in a specific manner in order to maintain a cookie-free environment until the user has consented to cookies.

This extension is a pair of plugins and a module. ALL 3 extensions are REQUIRED for operation of this extension and full compliance with the GDPR. This document will detail downloading, installing, and configuring the basic functionality. Extended documentation will cover 3rd party cookie blocking, as well as additional configurations to comply with some EU member state regulations.

Warning: When enabled, the EU e-Privacy Directive will log you out of /administrator if you refresh a front-end screen that has not accepted cookies within the same browser (different tab). If you wish to test and configure at the same time, you may want to use a second browser to remain logged in to /administrator while browsing the site without cookies.

If you haven't watched the full demo video, it may give you some idea of the display capabilities. This video was made before GDPR modifications were made, however, the modifications did not alter the way the extension appears or functions. I may make a new version of the video in the future to highlight the GDPR functionality.


This extension is different from the others in that it is free. So we can skip past the purchase instruction and dive straight to the download URL:


Look for the green "Download..." button.


In /administrator, go to Extensions > Manage > Install. Browse for the package you downloaded and press the install button. You should soon see a success message.

The package installs 2 plugins (System - EU e-Privacy Directive, and Ajax - EU e-Privacy Directive) and a module (mod_eprivacy). Although there are many configurations to be made, the first is enabling both plugins.

Browse to Extensions > Plugins and search for "privacy". You're looking for System - EU e-Privacy Directive, and Ajax - EU e-Privacy Directive - click the red X on each plugin to enable them. At this point, you're ready to begin configuring the extensions.

Configuration 1: Module Placement

The EU e-Privacy Directive extension uses a module to provide the circular consent options. When a user accepts cookies, the module offers the ability to revoke them. When a user revokes, the module offers the ability to reconsider again. The plugins will not work without the module, and the module will not work without the plugins. Together, they meet the GDPR consent requirements that users have the option to undo their previous decision.

Where the module is placed depends on your template and the available positions. On this site using a slightly modified Protostar template, the module was placed in position-0. Some users place it in the footer and even in the debug position. Because you enabled the system plugin in the last step, the module will display something when you place it in a position. Play around with different positions, and don't worry about the style for now. We will cover that next. First, find a good position.

Don't forget to choose which pages it displays on. By default, newly installed modules are configured to display on no pages.

Configuration 2: Module Styling

Now is as good a time as any to style your module to match your template. The default styling is contained in the system plugin under the "Module Display Options" tab.

If you aren't familiar with CSS, now is the time to get your designer involved. All of the elements in the module can be easily accessed in the DOM via descriptive class names. This site uses a slightly modified default. I removed 2 borders and added some left margin to the button. It is very close to the factory default.

Be sure to cycle through all of the options in order to see all of the displays. There are 3:

  1. Message
    • This is only displayed when the "Module" display method is chosen.
  2. Declined
    • This is displayed when a user has declined cookies, providing them an option to reconsider.
  3. Accepted
    • This is displayed only when a user has accepted, providing them an option to reconsider.

Once you have styled the module to your liking, you can (and should) copy the CSS to your template and turn "Use Plugin CSS" off. This will reduce the size of your pages and speed up your site slightly.

Configuration 3: Display Method

Return to /administrator Extensions > Plugins. Search for "privacy" and click "System - EU e-Privacy Directive" to edit the system plugin.

Each of the display methods perform identically with one exception. The JS Confirm type does not have the ability to link to a Privacy Policy or the e-Privacy law. Otherwise, they all do the same thing.

Styling each is a different story though. The JS Confirm, cannot be styled as it is part of the browser. The module and ribbons are styled in the plugin configuration. The System Message type is styled by your template (if your template developer bothered to add the System Message position to the template.) The modal is styled by your template.

The Module and Page Ribbon can both be styled within the System plugin. The modal type requires some Bootstrap expertise.

Configuration 4: Privacy Policy

If you chose a display method that can display a privacy policy link, you may want to create that now. There are many ways to do it, and the easiest is a text file somewhere in your site. Linking to this file within the plugin configuration will enable the "Privacy Policy" link in the display method and that link opens in a new window.

If you want to display a Privacy Policy which is an article on your site, copy the URL to that article and paste it into the Policy URL field. This part ONLY applies if you are linking to an article within Joomla - and this might get confusing, so please pay close attention:

  • If the pasted URL contains a "?" - add "&tmpl=component" to the URL
  • If the pasted URL does not contain a "?" - add "?tmpl=component" to the URL

At this time, you can decide if you want to display a link to the e-Privacy documents. If requested, I may add a link to the GDPR documents.

Configuration 5: ACL

In order to block 3rd party cookies and cookies from extensions (additionally, to hide modules, plugins and components that cannot operate without cookies), it's necessary to create a new User Group and Viewing Access Level.

Browse to Users > Group > Add New Group

Create a new group named "Cookies" and make it a child of "Public"

Browse to Users > Access Levels > Add New Access Level

Create a new level named "Cookies" and add the groups "Cookies" and "Registered" to it.

Configuration 6: Advanced Settings

Return to /administrator Extensions > Plugins. Search for "privacy" and click "System - EU e-Privacy Directive" to edit the system plugin. When open, go to the "Advanced" tab.

Finising ACL configuration

To finish up the ACL settings from the previous page, select the "Cookies"

Although the setup is finished, ACL settings are used throughout Joomla and will need to be a consideration whenever you install new extensions. These use cases will be covered in the EU e-Privacy Directive Advanced instructional document.


Enabling the geoPlugin allows you to limit the cookie consent requirement to only EU member states. When someone arrives at your site from a non-EU state, cookies are automatically enabled. The only time a user will see the accept message is if they arrive from an EU member state.

To enable this option, you must first sign up for a free account at http://www.geoplugin.com - Once you have signed up, you'll receive an email that describes the final step to enable your account. When (and only when) you're done setting up your geoPlugin account, enable the geoPlugin within the system plugin. It took about 5 minutes to complete the last time I did it - it doesn't take long at all.

Log Acceptance

When the geoPlugin is enabled, you have an option to enable acceptance logging. When enabled, every time a user accepts cookies, their country, IP address and the date/time they accepted is stored in the database. This data may be displayed in the plugin in a future version. Until then, know the data exists if you ever need it.

Initial Testing

By now, you have enough configuration to test the basic function of the extension - that is, blocking and allowing cookies based on consent. If you are using the geoPlugin, but browsing from a non-EU member state, you may want to turn off the geoPlugin temporarily, so you can see the operation of the extension.

Rather than try to describe the steps, I've created a testing video using this site as the example.

Did everything work? Of course it did, because you're awesome!

Continue to the EU e-Privacy Directive Advanced page for more configurations for specific situations.

There are a number of reasons to hide a menu item, prevent display of a module, or prevent a user from reaching a component. There are some general configurations that will be covered first, and some specific configurations at the end of the document. More will be added as they arise and/or are reported by users.

Non-Functional without Cookies

Hiding modules that will not function without cookies is important for user experience, and the best example is the Login module. When cookies are blocked, users cannot log in. So, in this case, it's not that the Login module sets a cookie - but that it requires a cookie (the session cookie). If we hide it until users accept cookies, user experience is restored. If you must, you could place a message somewhere informing users that to log in, they must accept cookies.

The configuration for this scenario is very simple. Go to Extensions > Modules - search for your Login module and open it to edit. The only configuration you need to change is the "Access" setting - change it to the User Group we created earlier - "Cookies" if you followed the instruction faithfully.

Modules are not the only possible item that won't function without cookies, but the configuration is the same. If it's a component, go to the menu item that leads to that component and set its Access to "Cookies". Plugins are the same, find the plugin in the Plugin Manager and set its Access to "Cookies".

Preventing 3rd Party Cookies

On this site, System - HeadTag is used to add Adsense and Analytics scripts. The specific configurations are for 2 scripts and 2 script declarations. Each is configured to load on specific access levels "Cookies" and "Registered". So Analytics and Adsense only load for users who have accepted cookies and users who are logged in (which they must accept cookies to do).

The configuration for plugins that handle Adsense and Analytics is similar to the Module configuration on a previous page. Edit the plugin configuration and set its Access level to "Cookies".

Google Analytics

Google does a lot of things to ensure the ubuquity of their cookies. This is apparent when you look at the cookies set by Google Analytics. For maximum coverage of your web properties, they use a wildcard domain when setting their cookies. It's your domain, but it may not be the domain you're using for your normal site cookies.

As you can see above, this site is "gdpr.richeyweb.com" - cookies set by this site (HTTP or Javascript) are from the domain "gdpr.richeyweb.com". Analytics cookies for this site, however, are from the domain ".richeyweb.com" (notice it's the domain.tldr preceded by a period). It's difficult to reliably determine the domain that Analytics may use - so there is a configuration in the System - EU e-Privacy Directive plugin to handle this (and other) scenario. When you determine the domain used for your analytics cookies - just add it to the plugin Advanced tab "Cookie Domains" setting. This is what it looks like for this site:

The easy way out is to use a Google Analytics plugin that does not use cookies, like this one: https://www.richeyweb.com/software/joomla/plugins/137-system-google-analytics-cookie-free

Google Adsense

Google Adsense is an example of a cookie that can be prevented, but once it's set there is no way for EU e-Privacy Directive to remove it because of the Same Origin Policy. This is what you will see if you're using Adsense. These cookies will remain after a user has chosen to remove cookies. This is OK though. As long as you prevent them from loading initially, when the user accepts cookies - it's Google who is placing these additional cookies on their computer.

When a user chooses to remove cookies, your site is no longer loading the Adsense javascript and that's all you can do because browsers have security measures in place to prevent one site from manipulating cookies from another site.

This is what it looks like. Don't lose your mind trying to find a way to remove them.

Forcing a user to consent to terms that were created AFTER their registration in pure Joomla would require that user to edit their profile. I've seen users accounts that were NEVER updates since their creation, so waiting for a profile edit to receive consent is a waste of time. This is one of the reasons the System - Required Fields plugin was created.

Using this plugin, you can select fields which will be tested upon login and if they aren't complete - the user is directed to their profile edit screen where they cannot leave until the required fields are populated.

For GDPR compliance, we're using this plugin to force users to edit their profiles when a new Fields - Terms of Service field has been published and they have not yet consented to it.

This specific plugin is really powerful, and has many uses beyond GDPR compliance. I highly recommend exploring the capabilities of this extension for other uses on your site.

Downloading System - Required Fields

To download the extension, you must be a subscriber to either System - Required Fields or to the GDPR Bundle. By popular demand, I created the bundle to make it easier to purchase all of the GDPR extensions at once (turning 3 trips to Paypal/Stripe into 1). To reward users for buying the bundle, I gave it a 20% discount.

Once purchased, the GDPR Bundle page and the System - Required Fields page will present download links in a section labeled "You are a subscriber".


In /administrator, go to Extensions > Manage > Install. Browse for the plugin you downloaded and press the install button. You should soon see a success message.

Browse to Extensions > Plugins and search for "Required". One of the results should be "System - Required Fields". Click the red X next to the plugin to enable it. When you're finished, it should have a green check next to it as seen in this screenshot:


The only absolutely necessary setting in the plugin is selecting the "Edit Menu Item". This refers to the menu item that leads a user to their user profile edit screen. If you don't have one of these links set up, do it now.

The rest of the settings change how it behaves for different users on the site. The most likely configurations you'll want to make is to Un-Require the TOS fields for your administrators. By Un-Requiring these fields, your administrators will be able to edit a profile without being force to agree to terms.

This is where the "Required" setting of the TOS field comes into play. By setting a field as "Required", it becomes available within the Un-Require fields setting of the System - Required Fields plugin. The best practice is to select every required field in "Un-Require" so admins may freely edit profiles without being forced to fill in details they may not know.

The Fields - Terms of Service (TOS) plugin provides the ability to present users with a field they MUST accept prior to continuing with registration and/or saving their profile. This plugin links the field label to an article (in a modal window) and will not allow the form to be submitted until the user accepts the term. Where this differs from the Joomla User Profile plugin and its "Terms of Service" field is that where the Profile plugin offers one terms field, this plugin allows you to create as many TOS fields as you like. When paired with the System - Required Fields plugin, you can force users to accept new terms that were created after they registered.

Keeping with the GDPR guidelines, the fields will ALWAYS default to "No", requiring users to actually click the radio to agree. Requiring the users to select the agree meets Citation 32 of the regulation. Something important to note. The TOS fields should not be used for arbitrary items which are not critical to the operation of your site. As these fields require consent, using them for non-critical reasons may run afoul of Citation 42 of the GDPR, which states:

"Consent should not be regarded as freely given if the data subject has no genuine or free choice or is unable to refuse or withdraw consent without detriment."

If the term for which you seek consent is not critical to the operation of your site, you may want to create it using the procedure detailed in Non-Mandatory Consent Fields.

The nature of this plugin makes configuration complicated. This guide will take you step-by-step to deployment of a new TOS field. You need the plugin to begin.

Download the Fields - Terms of Service Plugin

To download the extension, you must be a subscriber to either Fields - Terms of Service or to the GDPR Bundle. By popular demand, I created the bundle to make it easier to purchase all of the GDPR extensions at once (turning 3 trips to Paypal/Stripe into 1). To reward users for buying the bundle, I gave it a 20% discount.

Once purchased, the GDPR Bundle page and the Fields - Terms of Service page will present download links in a section labeled "You are a subscriber".


In /administrator, go to Extensions > Manage > Install. Browse for the plugin you downloaded and press the install button. You should soon see a success message.

Browse to Extensions > Plugins and search for "Terms". One of the results should be "Fields - Terms of Service". Click the red X next to the plugin to enable it. When you're finished, it should have a green check next to it as seen in this screenshot:

Create Terms

Before you create your first TOS field, you need an article to link to. Review the GDPR guidelines for specifics, but the general idea is that these terms are simple and easy to understand. The best example of a term would be a single, short sentence. This article you are creating is a slightly longer description of your term - but again, keep it simple or you may run afoul of the intent of this portion of the GDPR. The simple version of your term will be used as the field label during registration and will trigger a popup/modal window containing the longer terms article.


Citation 42

How you organize terms on your site is up to you, but I encourage you to have a system of organization. Additionally, you should consult legal council before altering any term article that any user has already consented. Doing so may render the previous consent void. Please consult with legal council. My suggestion is to amend terms with additional terms, but never alter terms unless resolving a typographical error.

Creating the Field

Once you've created articles for each of your fields, it's time to create the fields themselves. If you have a lot of terms, you may want to consider the organization of terms as they are displayed to users. If you don't create field groups, you may end up with all of your terms fields bunched together in an automatic field group named "Fields", which might be confusing to users.

Before creating the field, create the group where your related TOS fields will be displayed together (otherwise they end up in an automatic group called "Fields" which doesn't look very good). On this site, the terms are all children of the "Terms" group - it's simple, but effective and clear. For the purposes of this instruction, I will assume that you took that advice and want to create a "Terms" field group, so that is where we will begin. The name of the group isn't set in stone - you can name it anything you like, and you can have as many as you need to organize your terms logically.

Browse to Users > Field Groups

Create a new Group, name it "Terms"

Browse to Users > Fields

Create a new field. The label should be (as described on a previous page, and in Citation 42 of the GDPR) a simple description of the consent you wish to receive. If it's longer than a sentence, it is too long. Keep it simple, use the terms document to explain further if necessary. I like to make my title and labels match, so they are easily identifiable in the fields listing.

Select "Terms of Service" as the type. When the page refreshes, change the "Required" setting to "Yes" - this is important for configuration of the System - Required Fields plugin.

At the bottom, select the terms article you created previously.

To the right, choose the appropriate "Field Group" - if you're following this guide closely, that group will be named "Terms"

When finished, it should look like this:

Click "Save" (do not close it, we aren't done yet)

After saving, the "Name" field should auto-populate. Our last configuration is on the "Permissions" tab.

In Permissions, change the Public > Edit Custom Field Value setting to "Allow". Your screen should look like this:

Now you can "Save and Close" this field.

This is not quite the end of our configuration for this field. This field will be displayed and required for users at registration, but if you add new terms - the user will not be required to agree unless they edit their profile. To resolve this issue, the configuration of this field continues with the installation and configuration of the System - Required Fields plugin.

* One of the first GDPR Bundle subscribers pointed out that the "Public - Edit Custom Field Value" permissions can be set on the field group. If you make this setting on the field group, any field in that group inherits the permission. If you choose to go this route, you can skip the permission step on the creation of each field. - Thanks for the tip Michele!

This is the end, of this small piece

You've completed setting up one piece of the GDPR, but there are many parts to this law. Explore other implementation guides in this site to get closer to compliance.

Implementation Video - Start to Finish

Citation 42 of the GDPR indicates that consent must be freely given. The TOS plugin forces users to consent, but that is intended for critical functionality. On this site, it acknowledges that a user agrees to terms, understands the privacy policy, and consents to receiving emails critical to operation of the site (standard Joomla communication, not newsletters or spam)

For all other consent, the user must have an option to decline. This document will help you to create such a field and configure it to be required using the System - Required Fields plugin

Determine your requirements

For the most part, you can create any kind of field that Joomla offers. Consent will generally have 2 or maybe a few options (including the option to decline). An example of a multiple option consent might be newsletter frequency. You might offer your user Annual, Monthly, Weekly, or No Newsletter. It's up to you to comply with these values using whatever software or method you're using to send the newsletters. These fields hold data - how you act upon that data is up to you.

Creating the field

For purposes of this document, we will assume you have a consent requirement that is a simple yes/no field.

You could use a radio or a list field type. They both work the same for this purpose. If you have more than 2 or 3 options, you probably want to go with a list.

Field Permissions

Remember to change permissions so users are able to edit the field. You can skip this step if you completed it for the field group that this field is a part of.

Un-Require Fields

Don't forget to Un-Require the field so your admins can edit users without being forced to consent. Using the System - Required Fields plugin, you can require that existing users fill in answers to your required fields. If you haven't set that plugin up yet, take a look at the System - Required Fields implementation guide.

The "Un-Require" setting here is used to remove the requirement for administrators, so they can edit a user without being required to consent to anything on behalf of a user.