riccarbi

Great! Thank you.

I’ve got the same vulnerability alert from Plesk WordPress Toolkit.

Happy to heat that, @rogierlankhorst. For the time being, I’ve installed the 4.8.2 version which works fine.
Thank you for your great work!

PS. I replaced the installed 4.9.1 version of the plugin with the one in the WordPress repository as suggested but it didn’t make any difference, unfortunately

Hi @riccarbi, @anselmo

Could you check the following, for example in Chrome;

1. Visit your website incognito
2. Make a choice on the banner
3. Click on the lock in the front of your URL and see if the complianz_consent_status cookie is on the right path, if using a subfolder it should refer to the subfolder. And check if the cookie is valid longer than just 1 session.

Unfortunately, Chrome works for me as well.

regards Aert

Done. My website is bilingual and uses WPML, the problem arises with my secondary language only (whose pages are located in a /it/ subfolder). (https(://)www.inexhibit.com/ and https(://)www.inexhibit.com/it/).
In incognito (Chrome) everything works fine in both primary and secondary language.
In normal mode, the primary language works fine, while the secondary language pages always show the banner irrespectively of the user’s consent. Furthermore, in normal mode and navigating the /it subfolder pages, the complianz_consent_status and the complianz_policy_id cookies are listed two times each, one time pointing to the main folder and the second time to the secondary language subfolder. In incognito mode, they appear one time only, pointing to the subfolder as expected.

Therefore, the problem is possibly related to a conflict between the subfolder structure of secondary languages in WPML and the latest version of Complianz.

Please, can you tell me where I can download an older version of Complianz to check whether the problem is related to the latest version or not?

• This reply was modified 3 years, 10 months ago by riccarbi.
• This reply was modified 3 years, 10 months ago by riccarbi.
• This reply was modified 3 years, 10 months ago by riccarbi.
• This reply was modified 3 years, 10 months ago by riccarbi.
• This reply was modified 3 years, 10 months ago by riccarbi.
• This reply was modified 3 years, 10 months ago by riccarbi.

Same problem here, but not on all computers. After updating the plugin, one PC always shows the banner, it doesn’t matter if you agree with the GDPR policy, empty Chrome’s cache, and so on; while the other has no problem at all, even after clearing cache and cookies. Weird.

• This reply was modified 3 years, 10 months ago by riccarbi.

Great! I didn’t mention that your plugin is really outstanding. Thank you for your great work!

Can I suggest to edit and compact mobmenu-icons.css as well, in the next release?
I’d already edited and reduced mobmenu.woff by myself (I didn’t know about the version available on Dropbox); yet, to edit the corresponding CSS is really a pain…
Thanks

• This reply was modified 4 years, 3 months ago by riccarbi.

No way. I disabled lazyloading for feature images, logos, and so on. No change. Furthermore, I can’t identify where the CLS occurs. It’s probably too fast to tell it visually. It’s possibly something related to the sidebar (CLS is always 0 on mobile either you have enabled lazy loading or not; and I removed the sidebar on all my mobile templates). Some tests show CLS=0 also on desktops; yet, Google Pagespeed Insights always shows a CLS increase between 0.026 and 0.030 when A3 lazyLoad is activated on desktop. It’s a real headache…

In my experience, if used properly and as long as you have set image height and width in your WP theme correctly, A3 lazy load increases CLS only marginally (from 0 to 0,026 in my case). Yet, a possible workaround is to disable above the fold images (header logo and feature images, for example) lazy loading altogether. I’ll try, and I’ll give you my two cents after testing it.

Hi lucasdinorma, have you tried to change the locale and to override the city name (if needed)?
So, into something like: [awesome-weather location=”location name in English” units=”C” override_title=”location name in BR” forecast_days=”hide” background_by_weather=”1″ locale=”pt”]

Note that Awesome Weather uses the OpenWeather Maps service which does not support BP (Brazilian Portuguese) but standard Portuguese (PT) only.

• This reply was modified 5 years ago by riccarbi.

Grazie Nicola!
Appena mi si libera un attimo, provo a scrivere un po’ di codice e vedere se funziona.
Avevo fatto una cosa simile in PHP con un altro plugin GDPR settando un paio di if-else collegati agli eventi e alla fine funzionava.

Ti faccio sapere.
Riccardo

• This reply was modified 5 years, 4 months ago by riccarbi.
• This reply was modified 5 years, 4 months ago by riccarbi.

Ciao Francesco,
ho affrontato anch’io il problema e per bloccare gli script in Cookie Notice uso una tecnica diversa che pare funzionare. Lascio completamente vuota la sezione di blocco script del plugin (che poi non è un blocco ma un’autorizzazione) e edito invece il codice delle pagine in questo modo:

<?php if ( function_exists(‘cn_cookies_accepted’) && cn_cookies_accepted() ): ?>
<script>
(function(i,s,o,g,r,a,m){i[‘GoogleAnalyticsObject’]=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,’script’,’//www.google-analytics.com/analytics.js’,’ga’);

ga(‘create’, ‘UA-XXXXX-Y’, ‘auto’);
ga(‘require’, ‘displayfeatures’);
ga(‘send’, ‘pageview’);
</script>
<?php endif ?>

Questo dovrebbe bloccare GA finchè l’utente non accetta il banner, ovviamente imposto il reload della pagina in Cookie Notice.

Un approccio più raffinato (ma non mi è ancora chiaro se GDPR compliant o no) potrebbe essere di usare:

<?php if ( function_exists(‘cn_cookies_accepted’) && cn_cookies_accepted() ): ?>
script GA normale

<?php else: ?>
script GA anonimizzato

<?php endif ?>

Ciao,
Riccardo

• This reply was modified 5 years, 8 months ago by riccarbi.
• This reply was modified 5 years, 8 months ago by riccarbi.

I reply to myself. I guess that is possible by using mashupClick=”post”. Yet, I am seriously worried about continuing using this plugin (and buy the “pro” version), which seems to largely lacking support from its author, who doesn’t find a minute in a week to reply to a so simple (for him) question.

• This reply was modified 6 years ago by riccarbi.
• This reply was modified 6 years ago by riccarbi.

No, no, and no! Don’t allow Google to index your attachment pages, whatsoever. I did it by mistake sometimes ago and I lost 50% of my traffic in less than a week.
Set Yoast to redirect attachment to parent and to noindex unattached image pages.