wrigs1

I suspect he wants it for testing setting changes and assurance that the notice is still working.

e.g. if an admin has previously “accepted cookies” he won’t then be able to view how the cookie bar will appear to visitors if he changes settings for the notice text/color etc.

Perhaps a better solution would be to include an option to delete/”reset” the current browser’s Cookie Notice cookie from within settings.

This would allow the admin who has previously accepted cookies to view cookie notice changes before once again “accepting cookies” in his browser. Or to ensure it works correctly with caching (and, in my case, with my own plugin, to ensure cookie bar is never displayed to non EU visitors).

Glad you found this useful.

The entry in theme’s style.css starts about line 3047. My first post only showed the relevant style in the media query block (min-width 56.875) and removed CR/white space.

Yes, if you show footer menu then the “line” following appears too close and to right of menu” (both part of the same “footer” container).

As I was creating a modified child footer.php my solution was to edit footer.php and move line 15(? starts with “<footer” to before div site-info (line 40?)

It works for me, you can also put the “line/s” following Nav Bar in a div and apply your own styles.

N.B. I suggest you delete the “Powered by WordPress” bit from your footer.php to help prevent comment spam.

Should have spent more time checking. This displays the bottom main navigation fine:

@media screen and (min-width: 56.875em) {
  .main-navigation ul .dropdown-toggle.toggled-on,
  .site-footer .main-navigation {
    display: block;
  }
}

Hi,

I’m no expert, but as you’ve not had a reply:

I suspect a media query in parent CSS is taking precedence. I set my wider screen entry-content width to 90% (I assume it would work for 100%)using the following in child css:

@media screen and (min-width: 61.5625em) {
  /*  widen entry content on wider screens  */
  body .entry-content, body:not(.search-results) article:not(.type-page) .entry-content {
    float: right;
    width: 90%;
  }
  /* your other site styles for width > 61.5em */
}

I did a cut and paste from parent CSS and just changed the width, you can probably strip out things like “float:right” etc

HTH

Cookie Notice by default is set for implied consent. It includes a filter(interface) that can be used by other plugins.

You can make it display the notice to EU visitors ONLY, if you install the Category Country Aware(CCA) plugin. Just check 2 boxes to configure, and confirming it works is also simple (I’m the author). More info in this article.

Whoops no code needed.

To display the Cookie Notice bar to EU visitors only:

Install the CCA Plugin

Go to Dashboard->Settings->Category Country Aware->Countries scroll down, enable the Cookie Notice check box and save settings.

Job Done. The CCA plugin will identify the visitors location and via a hook tell Cookie Notice whether or not to display the bar.

Its easy to test whether its working – see this post.

Thanks to Bartosz / dfactory one of his answers in another post enabled me to identify a solution.

I’m the author of the Category Country Aware WordPress (CCA) plugin. By using the CCA plugin together with a single line edit of Cookie Notice’s code I’m displaying the Cookie bar to EU visitors only.

For those happy modifying code: somewhere around line 665 in cookie-notice.php immediately below
public function cookie_setted() {
insert a new line
if (class_exists('CCAgeoip') && ! apply_filters( 'cca_is_EU',FALSE)) return TRUE;

If you have the CCA plugin installed then your good to go.

I’m not sure if I’ve picked the best place in cookie-notice.php for the check (done in a hurry as I’m away next week) but it works for me.

The filter checks visitor IP and returns true for this list of country codes “BE,BG,CZ,DK,DE,EE,IE,GR,ES,FR,HR,IT,CY,LV,LT,LU,
HU,MT,NL,AT,PL,PT,RO,SI,SK,FI,SE,GB”. You can alternatively use your own list in the filter e.g.
apply_filters('cca_is_EU',TRUE,"YO,UR,LI,ST"))

You can also check for specific countries apply_filters(cca_geoip_lookup,'ccode') == "IT" e.g. to cater for stricter Italian laws

Issues:

You will have to reinsert this line whenever the Cookie Notice plugin is updated. (I’d be more than happy if dFactory added this filter to the Cookie plugin!).

Don’t do it if you are also using a caching plugin. Caching and geo-location do not usually work properly together. I’m also the author of Country Caching Extensions for Zen Cache and WPSC but even I don’t recommend their use with the above until modified to work efficiently with an EU “group” (another couple of weeks).

@raamdev @jaswsinc Thanks again for the quick response/fantastic support.

ZenCache confirmed there was a bug (now emergency patched under the same release number – see above link).

However you will also need to download the latest version of the Country Caching Extension which had to be modified to detect the new version of ZC (it will also work with the unpatched ZC v150626).

If you downloaded ZC v150626 before it was patched you should clear your cache after installing the latest Country Caching.

Thanks JasWSInc & raamdev for the rapid response and quick fix.

From the links above (without wading through ZC code) it appears that the “AC class” is now “zencache_advanced_cache” whereas under previous versions it was “zencache__advanced_cache” (with a DOUBLE underscore).

I assume this change to a single underscore is not a typo; and to ensure my plugin is backwards compatible with older versions of ZC/QC I’ll have to do something like this:

if ( !empty($GLOBALS['zencache_advanced_cache']) ):
    $ac = $GLOBALS['zencache_advanced_cache'];
    $ac->add_filter('zencache_version_salt', 'my_salt_shaker');
elseif ( !empty($GLOBALS['zencache__advanced_cache']) ):
    $ac =  $GLOBALS['zencache__advanced_cache'];
    $ac->add_filter(get_class($ac). '__version_salt', 'my_salt_shaker');
else:
    $ac = $GLOBALS['quick_cache__advanced_cache'];
    $ac->add_filter(get_class($ac). '__version_salt', 'my_salt_shaker');
endif;

Also; I assume in other plugins to detect whether a site is using ZC/QC I’ll need to do something like:

if( class_exists('\\quick_cache\\plugin')
  || class_exists('\\zencache\\plugin')
  || !empty($GLOBALS['zencache_advanced_cache']) )
// then the site is using ZC/QC

Hi b-cat,

I may be missing something, but I think you’ve misunderstood how CC4SC works, I’ll modify documentation to explain it.

You don’t need to specify countries for it to work with IQBC (but doing so has advantages, and you would only have to specify the FEW valid countries). N.B. CC4SC’s country option is a “separately cache” not a “do not cache” option (see explanation below).

As is, WPSC stores a snapshot for each page. Simplisticly, page cache is stored as “WPSC/somepage” and “WPSC/anotherpage” etc. If the first visitor to “somepage” was blocked subsequent legitimate visitors will be served the “blocked” cache.

CC4SC enables WPSC to store and serve pages based on page PLUS visitor country e.g. snapshots are stored as “WPSC/somepage-FR” “WPSC/somepage-US“.
These will contain the correct “blocked” or “allowed” content for visitors from that country.

Using CC4SC Country Codes option minimises the number of snapshots stored. It enables WPSC to use “shared” cache for most countries (e.g. those disallowed) but separate cache for the countries you have specified. e.g. if IQBC only allows visitors from US and Canada then set CC4SC to “separately cache” US,CA.

Now, when “somepage” is requested by these visitors the “allowed” page cache will be stored and served from “WPSC/somepage-US” or “WPSC/somepage-CA“. All other visitors will see the “standard” “WPSC/somepage” (without country code) cache; this will have been created by the first non US/CA visitor and be a “blocked” snapshot.

If you do use CC4SC’s country option clear WPSC cache first.

You are spot on in your comments on legacy caching. However, I think impact on most sites using Legacy option instead of the other WPSC caching options will be negligible (Donncha advises use of Legacy caching for problem fixes in this forum; and his article for plugin developers does not warn/highlight a performance hit when using required legacy caching).

Thanks for the feedback

Hi b-cat

I’ve just added a Country caching for WPSC plugin on www.ads-software.com It enables WPSC to cache by page + country instead of just page. It should provide a solution to country GEOIP/caching problems for most(?) plugins.

I’ve done a vey brief test using WPSC and IQ BC; blocking my home GB and then using a US proxy, IQ block county and WPSC worked together no problem displaying (or not) pages as per IQ settings.

N.B. if this plugin does what you need, then configuring WPSC to use a custom folder for its add-ons is recommended; as explained in the country caching documentation

Thanks for the info Samuel.

Was just checking it wasn’t anything wrong with my plugin’s headers/readme.

I replicated the problem , and it was fixed by version 0.6.0 (released last week). Its been over a week and I’ve not heard back from Frid so I’m marking this topic as resolved.

I’m waiting to hear back from Frid but I’ve uploaded version 0.6.0 which should fix the problem.

If you have a test site that uses some geoip plugins, and you have wp-debug switched on you may find you get some PHP notices (the plugin still works). My bad I meant to upload version 0.6.1 but as I’ve only just published 0.6.0 I’ll leave it a few weeks. If you also have the latest version of the CCA plugin installed it will fix this PHP notice issue.