Best way to add services in ePrivacy Plugin

I’m making good progress with developing the ePrivacy Plugin but I need you girls and guys to think along please.

At the moment third party service like Twitter can be inserted into a page via a Twig variable like {{ eprivacy.twitter }} and somewhere in the middle of your page content by using a shortcode like [eprivacy-twitter/] right in your markdown. I’ll update the demo to show that soon.

What I’m not sure of is how to add the 62 service definitions tarteaucitron.js currently offers to this plugin?

By service definition I mean the code tarteaucitron.js requires to include a service. These are documented in “Step 3: Add your services” and look like for example:

  • for Amazon:
<div class="amazon_product" amazonid="xxxxx-xx" productid="product_id"></div>
  • for Google Analytics (gtag.js):
<script type="text/javascript">
    tarteaucitron.user.gtagUa = 'UA-XXXXXXXX-X';
    tarteaucitron.user.gtagMore = function () { /* add here your optionnal gtag() */ };
    (tarteaucitron.job = tarteaucitron.job || []).push('gtag');

What would be the best way to include all these definitions into the plugin and make it easy to set the required parameter values such as the values of amazonid and gtagUa in the above examples ?

I’m thinking about storing each definition in a separate file in the user/data folder and creating a single YAML file to hold all parameters. The service name (e.g. google-analytics-gtagjs) is used as the key to link an entry in the YAML file to it’s folder by the same name in user/data.

This is just one thought and because Grav puts so few limits on solutions there are many other scenario’s to solve this.

Please let me know what you think would be a smart way to add services and make them configurable from within the ePrivacy plugin.
Thank you for your time and thoughts!

I’d want to avoid user/data if I could. Can’t you just use the plugin config file? If I’m not mistaken, Grav merges the site-specific config file with the default file. So the default file could have the definitions, and the site-specific one could just have the parameters. And then the parameters could be overridden at a page level where necessary.

Hi Aaron,

Thanks for your reply. Yes I agree with your suggestion to use the site config file for the definitions.

However because the definitions are HTML snippets I can’t use them in YAML. For instance this definition uses both single and double quotes:

<script type="text/javascript">UserVoice=window.UserVoice||[];UserVoice.push(['addTrigger', {mode: 'contact', trigger_position: 'position', trigger_color: 'color', trigger_background_color: 'background-color', accent_color: 'accent_color'}]);</script>

I can’t think of a generic way to add this to YAML. Cases like these remind me of the CDATA-type element in XML but I believe there’s no equivalent in YAML is there?

Sure there is. A literal scalar, marked by a pipe. My theme uses this to include HTML snippets.

Here’s the spec:

And to be clear, I was thinking the site-specific plugin config file. Not site.yml itself. Though that’s a valid place, too.

Aha, I didn’t know that. Thanks. Rethinking options again.

I have doubts about storing these snippets in YAML as I need an easy way for webmasters to edit the snippets if they require modifications beyond what my plugin can offer. Editing a YAML file is tricky because of the formatting / indentation sensitivity. A small mistake turns into havoc easily.

Storing each definitions as a separate Twig template file seems more robust. To avoid being overwritten by a plugin update these templates must be stored outside the ePrivacy plugin folder. Which returns me to user/data. Or not?

If you store them as template/partials, then they can simply customize by moving them from the plugin folder to their theme and customizing. Then you can update the plugin, but the customized file will still override. You can see any of the many plugins that include visual elements (like Simplesearch) to see how they do that.

In the in between days I’ve implemented the Grav native mechanism of partial templates as you suggested. These are rendered to be used as Twig variables and shortcodes.

For the latter I got inspired by your home brew shortcode solution in your Schedule plugin. I love the simplicity. Thanks for that too!