yolabingo

Thanks for the very quick response.

This may have been an issue. It took me some time to track this down, but your thread here pointed me in the right direction.

In short, there is a bug in the older versions of the PCRE library used by PHP 7.3 that causes WP’s email address regex validator to fail. PHP 7.2 and under use a different PCRE library than does 7.3

https://gist.github.com/yolabingo/68b4f037661e702742c5abb324a3d992

• This reply was modified 5 years, 7 months ago by yolabingo.
• This reply was modified 5 years, 7 months ago by yolabingo.

Thanks for timely update @wfmattr

It looks like they just released 7.1.6 – I assume/hope it addresses this issue.

Perhaps this is of use to you or others
https://github.com/ericmann/WP-PowerShell

Just noticed it is an abandoned project so maybe less useful

• This reply was modified 8 years, 3 months ago by yolabingo.

Documentation on WooCommerce (linked above) doesn’t work for AJAX shopping carts. I struggled for a while with AJAX “add to cart” functionality in all browsers. I found I had to use “pipe” to appease some browsers (FF + XP, Safari + iPhone) for AJAX to work. Not sure why.

Season to taste:

backend default {
  .host = "127.0.0.1";
  .port = "8080";
}

sub vcl_recv {
  if (req.request != "GET" &&
      req.request != "HEAD" &&
      req.request != "PUT" &&
      req.request != "TRACE" &&
      req.request != "OPTIONS" &&
      req.request != "DELETE") {
    return (pipe);
  }
  # don't cache POSTs
  if (req.request == "POST") {
      return (pipe);
  }
  # don't cache for users logged into WP backend
  if (req.http.Cookie ~ "wordpress_logged_in_") {
      return (pipe);
  }
  if (req.url ~ "wp-(login|admin)" || req.url ~ "preview=true" || req.url ~ "xmlrpc.php" ) {
      return (pipe);
  }
  # don't cache ajax requests
  if (req.http.X-Requested-With == "XMLHttpRequest") {
      return (pipe);
  }
  if (req.url ~ "^/(cart|my-account|checkout|addons|sitemap)") {
    return (pipe);
  }
  if (req.url ~ "/feed/") {
    return (pipe);
  }
  unset req.http.cookie;
  return (lookup);
}

sub vcl_fetch {
  if (beresp.status == 404) {
    set beresp.ttl = 0m;
    return (hit_for_pass);
  }
  unset beresp.http.set-cookie;
  set beresp.ttl = 60m;
  return (deliver);
}

sub vcl_deliver {
    if (obj.hits > 0) {
        set resp.http.X-Cache = "HIT";
    } else {
        set resp.http.X-Cache = "MISS";
    }
}

sub vcl_pipe {
  set bereq.http.connection = "close";
}

I have had decent success with Woo Commerce + Varnish after a week of tweaking. I ended up using the nuclear option “pipe” rather than pass for requests I need to go to the back-end. When using “pass/hit_for_pass” certain browsers (Safari in iPhone, Firefox in XP) were still unable to add items to the cart via AJAX – not sure why, and don’t care to spend time figuring it out.

Using “pipe” may seem inelegant, but it proved to be a good solution to the problems that WordPress + Woo provide.

A few tips:

• Pipe all POSTs to the back-end
• Pipe all AJAX requests to the back-end
• Pipe all requests back-end if “wp_logged_*” cookie is set (otherwise logged-in users can pollute the cache with the “Howdy, Admin” banner when viewing pages on the site).
• If you want the “View Cart” link to display cart contents on every page, this must be done via AJAX. Just load a cachable “View Cart” link (that doesn’t include # items or $ of cart contents), then fetch their cart contents and update per-user.
• You should be able to strip cookies on pretty much everything else
• add this to your VCL any time you use pipe:

  sub vcl_pipe {
    set bereq.http.connection = "close";
  }

HTH

I had added two fields that I wanted to delete. I found that if I remove one of the fields and submit the form, that field is removed. But I cannot remove the last field.

After a quick look at POST data, it appears that changes to the “additional fields” require the presence of

label[1]:
meta_key[1]:

and so forth, in the POST data. But removing the last additional field means there is no label[] and such, so no action is taken.

Hope this makes sense. I can look more closely at this tomorrow.

Having the same issue. When I click the red button to delete the fields, they are removed from the screen. But after submitting the page with “Save Changes” button at the bottom (or just reloading the page) the fields reappear.

Reproducable in Chrome in Linux & OS X, and Firefox in OS X.

Ugh – just noticed the site was using an old copy of the plugin. Not sure why it did not show the available update for the plugin. Sorry

This patch will work, at least until JQuery 2.x comes out ??

1042         var JqueryVersion = $.fn.jquery.split(".",2);
1043         var majorJqueryVersion = Number(JqueryVersion[0]);
1044         var minorJqueryVersion = Number(JqueryVersion[1]);
1045         if ((majorJqueryVersion != 1) || (minorJqueryVersion < 3)) {
1046                 alert(CGMPGlobal.errors.oldJquery);
1047                 //Logger.fatal("Client uses jQuery older than the version 1.3.0. Aborting map generation ..");
1048                 return false;
1049         }

Please note that the plugin uses the minified version of this file – cgmp.framework.min.js – so you need to minify this file after making these changes.

https://www.php.net/manual/en/memcache.setcompressthreshold.php

I had similar trouble with the Memcache extension, but it was intermittent.
It seems memcache automatically compresses data once it hits a certain size – default is 20000 (units unknown – assume bytes?).
I added a “SetCompressThreshold” value in line 62 of wp-ffpc-common.php and that solved the problem. Not very elegant, but worked in a pinch.

54       case 'memcache':
 55          /* Memcache class does not exist, Memcache extension is not available */
 56          if (!class_exists('Memcache'))
 57                  return false;
 58          if ( $wp_ffpc_backend == NULL )
 59          {
 60                  $wp_ffpc_backend = new Memcache();
 61                  $wp_ffpc_backend->addServer( $wp_ffpc_config['host'] , $wp_ffpc_config['port'] );
 62                  $wp_ffpc_backend->setCompressThreshold(9999999, 0);
 63          }

You may also specify a large threshold in php.ini
memcache.compress_threshold=999999999