wrigs1

Server not being configured for IPv6 is probably not the issue. The above script handles both IPv4 & IPv6 and 6 to 4 conversion. HOWEVER problem might be due to other known bugs in the script. Proposed fix (for WP5.0?) here: Dashboard: Strip more extraneous IP parts to prevent PHP warnings.

Other possibilities:

The WordPress script checks for “visitor” IP address in some BUT NOT ALL relevant server IP address variables. Surprisingly the script does not look for an IP address in $_SERVER[‘HTTP_X_REAL_IP’] which is sometimes (often?) the only variable containing the “actual” visitor IP on sites that are behind NGINX servers.

If familiar with PHP you can copy and run this [link redacted] script to identify which IP address variables are set and contain valid visitor IP addresses. (I wrote it for my own use).

Are these errors appearing when you are logged in over the internet or only if your device is “directly” connected to your server? e.g. via inTRAnet in which case your device may be assigned a private IP address.

• This reply was modified 6 years, 6 months ago by Andrew Nevins.

Question answered, and no response. Marking as resolved.

Unfortunately your question was unclear. On checking questions you asked elsewhere I assumed you were inappropriately using the term “preload” to simply mean creating a cache “snapshot” on first request that would be served to later visitors. As I’ve not had a response I assume my assumption was correct.

For others wanting to know about preload (as described by WPSC) and advance creation of cache files for all possible “v” values; then the answer is NO, neither WPSC nor this plugin will do this.

N.B. The “v parameter” identifies visitor location at below Country level e.g. US state. So “v param” pre-loading (if possible) would result in the creation of about 300 FILES (cached snapshot pages) for EACH PAGE! (More if visitors outside the US are also identified at below country level).

• This reply was modified 6 years, 7 months ago by wrigs1.

From a question you asked elsewhere, I assume you are referring to the “v” parameter in WooCommerce query strings.

Short Answer:
As this plugin requires WPSC setting “Cache HTTP headers” to be checked, then it should still cache. However I don’t use WooCommerce (WC), and on my site requests with query strings are currently rewritten to slugs – it will be a few weeks before I can test/confirm. However whatever solution (below) you use with WC will have drawbacks.

Long Answer:

From WC docs it appears that the “v” parameter is set when you enable WC’s “Geolocate with page caching support” option. In reality it is a cache buster and on for most sites does the opposite! A better label would “Disable caching – but still let my site waste time running a caching plugin” .

Option 1.

Likely to be faster and more efficient. Use Country Caching Extension and change your WC settings to switch off “Geolocate with page caching support”. Unfortunately this also switches off geolocation by Ajax.

Issues: This might be fine if you are only selling in say Europe, Russia and UK but probably no good when also selling in US as different states have different taxes (a page cached as US due to a visitor from Texas might be wrong for later visitor from NYC).

Option 2.

This plugin should work with the “v” query string, however if your site is WC (ecommerce) ONLY then it is probably unnecessary. Apparently the “v” parameter translates to a location e.g. Alabama, US. If your site is WC (ecommerce) ONLY then you might as well just use WPSC (with “HTTP header” option) or other query string capable cache plugin.

Issues: If your site has only a few thousand visits per day the benefits of caching may end up negligible or even negative. e.g. You may only get single visitors from many locations; as your site has to check for cache and then create one before sending the page – response will actually be slower.

It will also result in a horrific exponential increase in the number of cache files stored by your server, at some point this could also cause performance issues. n.b. the increase would be the same whether using just WPSC or WPSC with Country Caching just cache suffix would be different e.g. “v123” or “UK-v123” as v123 is always UK.

Option 3.

Deactivate caching. May be the best option if response times still okay.

I have no experience of WooCommerce so there may be other issues/solutions I am unaware of. In my view WooCommerce would be improved if it provided an additional option to cache and use Ajax. Or maybe an (if country caching) allow cache except user specified list of country codes e.g. “US,XX,YY” to cover issues of regional taxes (and shipping costs?) etc.

Unfortunately no more info from poster. Likely cause: failure to identify valid visitors IP address.

The new version (1.1.0) of this plugin checks additional server variables for a valid IP. Additionally Admin Panel CCA settings now includes a checkbox (under the “Testing” tab) to list values contained in a variety of Server variables. This should provide useful info in any future support requests.

NOTE: if you use WPSC’s settings to temporarily disable caching it also unsets “Cache HTTP headers with page content.” You will have to check this again on WPSCs Advanced tab.

Should have read the sticky. Plugin no longer supported.

Hi @njesson “42 | WARNING | INI directive ‘safe_mode’ is deprecated since PHP 5.3 and removed since PHP 5.4”

I think this is a “false positive” and there is nothing to fix the “offending code is:

if ( version_compare( phpversion(), '5.3.0', '<' ) ) {
  $safe_mode = ini_get( 'safe_mode' ); // etc.

i.e. plugin checks PHP version and “safe mode” is only “invoked” on PHP 5.2 or less – it is ignored in PHP 7

To anyone checking up on this (like me). I’ve upgraded to PHP 7 and the widget continues to function and display the correct posts for category. I’ve not tried anything in admin or a fresh install.

The error above is in a portion of code intended to create a MySql table so potentially a prob. However, I’m guessing the “/2.8/” in the file path to the script means it is for use for use with WP v 2.8 (which no one should be using anyway).

WPEngines latest checker also reports this “error”

/wp-content/plugins/extended-categories-widget/4.2/class/avh-ec.core.php
362 | ERROR | Indirect access to variables, properties and methods will be evaluated strictly in left-to-right order since PHP 7.0. Use curly braces to remove ambiguity.

As “4.2” is the highest version number(?) in my plugins files I assume it relates to WP4.2 and LATER. Not had time to check it out but it relates to one of the widget settings in Admin and may or may not be a minor issue.

hth

If Maxmind files are present, then another possibility is that the check (which uses standard PHP validation) for whether your server is IPv4 or IPv6 is failing (it should be one or the other!). An online IP 6 checker should tell you.

IF you are familiar with PHP see Line 292:

if( filter_var($visitorIP, FILTER_VALIDATE_IP, FILTER_FLAG_IPV4) ) {
     $geoIPdb = 'GeoIP.dat';
} elseif ( filter_var($visitorIP, FILTER_VALIDATE_IP, FILTER_FLAG_IPV6) ) {
    $geoIPdb = 'GeoIPv6.dat';}
else return '';

Editing plugins in situ can bring your site down. But if you know whether your server is using IPv4 or 6, and are confident you can solve problems then you could try commenting out the above and add a new line (let me know if it works):
“$geoIPdb = ‘GeoIP.dat’;” for (IPv4) OR
“$geoIPdb = ‘GeoIPv6.dat’;” if you are IPv6

From your post I’m assuming you know PHP. If not, no worries just let me know whether files are present, whether server is IP 6 and also your website address if you are happy to disclose it.

Andy

Hi Ryan,
Sorry for the delay in response – notifications from this forum are going don’t go to my main email and worse yours ended up in Yahoos Bulk Mail (spam folder)(I’ll see if I can change that later). Edit: DONE – support forum notifications now go to my main email.

Thanks for all the info – from the detail provided I’ll assume you are technical and are using Maxmind not Cloudflare. My rushed thoughts are that Maxmind data failed to install possibly due to file/dir permissions – but this should have displayed a warning.

Go to CCA settings (Dashboard->settings->Category Country Aware Goodies
Select the Country Tab. You should see info like this:

Maxmind Directory: “/home/acc/public_html/wp-content/cca_maxmind_data/”
File “GeoIP.dat” last successfully updated : July 30 2017 07:40:33.
File “GeoIPv6.dat” last successfully updated : July 30 2017 07:40:33.

Can you let me know the details. (but don’t show your dir structure prefix before “public_html” bit) If a directory is displayed can you check whether it exists and contains the files.

Andy

• This reply was modified 7 years, 3 months ago by wrigs1.
• This reply was modified 7 years, 3 months ago by wrigs1.

Marked this as resolved as simply was a question and questioner did not respond to my response on how it could be achieved.

• This reply was modified 8 years, 1 month ago by wrigs1.

As a workaround you can try one of the following which will redirect for “rejected” countries. N.B. the page title may appear for a flash before the browser redirects. To test if it works just swap your own country code in and out of the short code

[cca_display only=US,CA]<script>window.location = "https://example.com";</script>[/cca_display]
text content (NOT for USA and Canada) here
.....
.....

or

[cca_display not=US,CA]<script>window.location = "https://example.com";</script>[/cca_display]
text content (ONLY for USA and Canada) here
.....
.....

The [cca_display] shortcode with its javascript should be above your content.

Make sure the post editor is in Text mode (NOT Display) when you add the shortcode javascript. Change the exmple.com in above to the URL you want the page redirected e.g. your sites home page or a custom 404 not found page.

I am considering writing a proper solution (on my own site I already have code to prevent listing of selected posts on the home page). The workaround above isn’t perfect: if your home page lists your posts they will still be listed for ALL visitors (but when a user from the specified country clicks the link on your homepage he will be redirected). Even worse if your home page displays every post in full (instead of excerpts) then I even visiting the home page might cause a redirect for the specified countries.

Last time I checked Google crawlers were US based, if you hide a post from US visitors it won’t be indexed by Google.

• This reply was modified 8 years, 1 month ago by wrigs1.
• This reply was modified 8 years, 1 month ago by wrigs1.
• This reply was modified 8 years, 1 month ago by wrigs1.
• This reply was modified 8 years, 1 month ago by wrigs1.
• This reply was modified 8 years, 1 month ago by wrigs1.

Marked as resolved (no response to my response after one week, and it is only a request for additional features anyway)

Apologies for late response. Somehow I unsubscribed for emails from this support forum – now rectified.

Your suggestion is great, but it is not as simple as it seems (see below). It might be possible using WPSC’s “wp_cache_served_cache_file” filter (mentioned below).
It would be many hours work to investigate the feasibility and add the suggested option. I’m happy to add to my to-do list but it may be 6 months/year before anything happens.

@korneelwever if you want to have a go in the meantime, then get in touch (via the contact page on wptest.means.us.com)

Goal (simplistic): if “somepage.PHP” is requested by a visitor from USA then use htaccess to efficiently serve the cached page “/cache-dir/somepage-US.HTML” without the need for any PHP/WP scripts to run.

Problems/Issues/possible Solution:

WPSC will only allow plugin extensions to intercept and override what is uniquely cached (e.g. by country) in legacy mode. This in itself would not prevent “direct” serving of cached pages via htaccess.

However, in legacy mode the filename used for the cached file is an MD5 “hash” so “/some_cat/some_page.php” (as generated for a US visitor) might be stored as “/cache-dir/wp-cache-0d7a305c74941f7ddde3d9b180ef6040.php”. Unfortunately, as far as I am aware, there is no way for htaccess to rewrite/regex the requested URL to an MD5 “hash”.

That said;
the country caching extension currently hooks into WPSC with “wp_cache_key” filter to append the country code to the “filename” before it is MD5’d and saved.

there is also a “wp_cache_served_cache_file” filter, I’ve yet to check but this may allow the country caching extension to make WPSC use this extensions generated filenames instead of MD5 ones.

If that is possible then we also need to consider htaccess – off the top of my head I think WPSC generates about 30 lines of rules to cater for admin users etc – this extension would need to do similar.