evoYTAccess: data it handles
Summary
evoYTAccess keeps no personal data of its own about visitors or users. It creates no tables, writes no logs and, on the public side of the site, sets no cookies and writes nothing to the session. What it reads to decide whether a node is rendered is used in memory during the request and then dropped.
What it reads on each request
Only when a node with conditions turned on is about to be rendered, and once per request:
| Data | Used for |
|---|---|
| ID, username, groups and access levels of the logged-in user (or the fact that the visitor is a guest) | User rule |
| Active site language | Language rule |
| Current date and time, in the site’s time zone | Date and time rule |
| Browser user agent | Device rule: classified as desktop, tablet or mobile |
| Active menu item | Menu rule |
| Category of the page (Joomla or DJ-Catalog2), looked up in the database | Category rule |
None of this is stored. The user agent is not kept; it is only used to classify the device.
What it stores
| What | Where | Content |
|---|---|---|
| Plugin settings | Joomla plugin parameters | Two options: evaluate in Builder preview, and group matching |
| Conditions on each node | In the Builder layout, next to the node’s other properties | The rules you set (ytaccess_* properties) |
| Licence state | In the extension’s own data (custom_data on its extensions row) |
Download ID, a site identifier (site_id, a UUID the extension generates), the last signed response from the licence server, and the dates of the last check and last error |
One case to keep in mind: if you fill in Usuarios concretos (specific users) with user IDs or usernames, that data ends up inside the layout, and so in backups and exports of the page or module that holds it. It is data you type into the configuration, not data the plugin collects.
What leaves the site
There is one outgoing communication: the licence client, and only if you have saved a Download ID. It runs from the administration (when you open the plugin’s settings or press “Check now”), at most once a day apart from retries after a failure.
It sends this to the licence server at evoaddons.com:
- the Download ID,
- the site’s domain,
- the
site_id, - the environment (
production), - the evoYTAccess version,
- the PHP and Joomla versions.
It sends no visitor data, no page content and no rules. Joomla also queries the server for updates, as it does for any extension with an update site, and downloads the ZIP with your Download ID.
Privacy plugin
evoYTAccess has no privacy group plugin (export, check and delete a user’s data). Because the plugin stores no per-user data, there is nothing for it to export or delete. If you typed a specific user’s ID or username into Usuarios concretos on some node and that person asks for their data to be erased, you will need to remove it by hand in the Builder.
Retention
The plugin does not accumulate data over time, so it has no retention periods and no purge task. The licence state lives on the extension’s row and goes with it when you uninstall.
Settings that limit processing
- Leaving Usuarios concretos empty avoids storing identifiers of people in the layout; to segment, use groups or access levels.
- Not saving a Download ID avoids any communication with the licence server (and also updates through Joomla).
This is not legal advice; consult your own adviser.