svet

@ryanhungate

Thanks for the fast response and the solution.

The use of the GDPR field is mandatory and it not an option for me to disable it completely. To be honest I did not notice the subscription field in the registration form till just now. Maybe a plugin option to turn it on/off can prove useful for some users.

I use the flatsome3 theme: https://flatsome3.uxthemes.com/demos/shop-demos/classic-shop/. The login button of this theme opens the login + register form in a lightbox. This explains why the register form is available on every page of the website – it is not on the /profile route, but on every route instead. The mailchimp_woocommerce_newsletter <input> can be found in the source of every website page…

Still, I think that an updated version of the plugin, where it requests the GDPR field in the background and/or caches the field is much needed. It will remove the load to the mailchimp servers (my site alone is sending millions not-needed requests monthly… and flatsome is very popular theme…) and will free server resources on my VPS.

All best

@ryanhungate
Thank you for replying and your willingness to solve the problem.

For performance and error tracking I am using newrelic platform. Below I will share some insights from the reports I have from today. Please note that the tracking information is from today, and not from the time when the incident happend.

If you have a high throughput on your site, I think the best thing for you to do would be to consider using the Action Scheduler in the CLI version. Have you tried that?

Yes, I am using already Action Scheduler through the linux system cronjob.

1. Single page requests: https://drive.google.com/file/d/1cO2NxnpW0Is4_fjPEwNyl3AGiRasmcbP/

As you can see from the breakdown, the requests to the mailchimp server happen on every request to a single post. I selected single post page, since after the index, it has the most impact to the performance.

The question here is: Why mailchimp needs to contact external server on every request?

2. Slow mailchimp server response:
https://drive.google.com/file/d/1Sxb7yOSg3OWm1gznnmP220g_6Qms95_l/view

It can happen that the mailchimp server respond does not arrive in the 30sec time-frame and timeouts. The php-fpm server child process is blocked for 30 seconds. During these 30 seconds new requests arrive. They also need 30 seconds to complete, since the mailchimp API does not respond. This escalates quickly and the php-fpm opens hundreds of child processes and finally stops accepting new connections to avoid filling the whole system memory.

3. Call stack:
https://drive.google.com/file/d/1J1vcPYk9jp1Hm6rD_AeyJ2oo4B1Jnb_m/view

I hope this call stack can help you identify the problem. For me it is clear that the MailChimp_WooCommerce_MailChimpApi class is making curl request to the shown server to retrieve(or update) the members of a mail list. For me neither retrieving nor updating a list on every request makes sense.

The questions here is: Why mailchimp needs the members of a mailing list? If this is an update of the list, why it is done on so many requests?

I hope that the provide information will help you find the problem, which will benefit both of us and many plugin users.

All best

Did you tried to upload the file linked above with ftp?

Oh, I see. You updated the file by adding the else statement on lines 224,225 :

diff yasr-includes-init.php.old yasr-includes-init.php.new

223a224,225
> } else {
>     define('YASR_FIRST_SETID', 1);

Yes, this fixes the problem with the PHP warnings.

Thanks for the solution! Hoping that I helped too!

Regards
Svet

Dear @dudo,

I was talking from my experience, not guessing. After disabling the plugin the CPU load on the VPS dropped several times.

I saw load on the CPU for the following reasons:

1. The error should logged in the log file – CPU/IO load
2. The Sentry monitoring system should processes, prepare and report the error to the Sentry servers
3. The newrelic php-module also should processes the warning, log the data, the call stack, the context etc. and report it to the server

Please note that some of the error reporting above (p.2 and p.3) is happening in real-time. This means that several API calls are made in the same request cycle. The API calls themselves require several hundred milliseconds and are “blocking” the child php-fpm process during this time. For this reason a new child php-fpm processes must be spawn to accept the next requests.

Of course a php Notice/Warning/Error leads to CPU load in any system that has some type of error reporting, which is most hosting providers and most of the managed or self managed VPS servers.

Please note, that it took minutes the plugin to deplete my monitoring quota on both platforms… Quota, which in normal usage lasts a whole month ??

The problem:

From the dump below it is clear that the warning comes from the
includes/shortcodes/classes/YasrShortcode.php and not from the yasr-includes-init.php. I suppose that the yasr-includes-init.php file is never included/required in this execution path.

E_WARNING: Use of undefined constant YASR_FIRST_SETID - assumed 'YASR_FIRST_SETID' (this will throw an Error in a future version of PHP)
in YasrShortcode::__construct called at WEBROOT/wp-content/plugins/yet-another-stars-rating/includes/shortcodes/classes/YasrVisitorVotes.php (35)
in YasrVisitorVotes::__construct called at WEBROOT/wp-content/plugins/yet-another-stars-rating/includes/shortcodes/yasr-shortcode-functions.php (88)
in shortcode_visitor_votes_callback called at WEBROOT/wp-includes/shortcodes.php (343)
in do_shortcode_tag called at ? (?)
in preg_replace_callback called at WEBROOT/wp-includes/shortcodes.php (218)
in do_shortcode called at WEBROOT/wp-content/themes/THEME/inc/helpers/helpers-shortcode.php (203)
in flatsome_contentfix called at WEBROOT/wp-includes/class-wp-hook.php (292)
in WP_Hook::apply_filters called at WEBROOT/wp-includes/plugin.php (212)
in apply_filters called at WEBROOT/wp-includes/post-template.php (253)
in the_content called at WEBROOT/wp-content/themes/CHILD_THEME/template-parts/posts/content-single.php (3)
in require called at WEBROOT/wp-includes/template.php (732)
in load_template called at WEBROOT/wp-includes/template.php (676)
in locate_template called at WEBROOT/wp-includes/general-template.php (204)
in get_template_part called at WEBROOT/wp-content/themes/THEME/template-parts/posts/single.php (14)
in require called at WEBROOT/wp-includes/template.php (732)
in load_template called at WEBROOT/wp-includes/template.php (676)
in locate_template called at WEBROOT/wp-includes/general-template.php (204)
in get_template_part called at WEBROOT/wp-content/themes/THEME/template-parts/posts/layout.php (12)
in require called at WEBROOT/wp-includes/template.php (732)
in load_template called at WEBROOT/wp-includes/template.php (676)

I hope this helps to fix the problem.

Kind regards
Svet

Hi @levanticaeu,

What is the currency of your WooCommerce shop?

Hi @marcusskyverge,

I see that you want to make the plugin better and I am happy to provide you with my feedback.

Today, after months using the version 1.11.4 of the plugin without problems, I decided to test the latest version – 2.2.0.

Here are the steps I went through and the results:

? Disconnected the plugin from facebook through the plugin interface
? Used the provided by @jenskyverge plugin to remove the related data
? Updated to the latest (2.2.0) version of the plugin
? Followed the multi-step process and it worker till the last step
? the very last step showed me an error message, similar to the one in my first post.

Here is the response from one of the latest requests:

{
    "errors": [{
        "message": "Invalid values provided for variables of operation \"RunFBEInstallMutation_PrepareAssetsMutation\": Value \"Array of size 17 starting with: { client_mutation_id => \"2\" }\" cannot be used for variable \"$input\": Field \"config\" has value of invalid type: Field \"setup\" has value of invalid type: Field \"currency\" has value of invalid type: There is no value named \"BGN\" in this enum.",
        "severity": "CRITICAL",
        "code": 1675012,
        "api_error_code": null,
        "summary": "Your Request Couldn't be Processed",
        "description": "There was a problem with this request. We're working on getting it fixed as soon as we can.",
        "description_raw": "There was a problem with this request. We're working on getting it fixed as soon as we can.",
        "is_silent": false,
        "is_transient": false,
        "requires_reauth": false,
        "allow_user_retry": false,
        "debug_info": null,
        "query_path": null,
        "fbtrace_id": "CpdgK8PAoMd",
        "www_request_id": "AHt6IjtZTYvdaHFnDYNQCYO"
    }],
    "extensions": {
        "is_final": true
    }
}

In the console there was also the following error:

ErrorUtils caught an error:

GraphQL server responded with error 1675012: There was a problem with this request. We're working on getting it fixed as soon as we can.

Subsequent non-fatal errors won't be logged; see https://fburl.com/debugjs.

For my case, it seems that all other problems which I faced before were fixed, but the main one still exists – from the very readable error message is it clear to me that facebook does not accept the currency of my shop – BGN, which is well supported by WooCommerce and by the old (1.11.4) plugin version.

All best
Svet

Hi @jenskyverge,

Since the plugin does not support all pixels, it is not an option for me. For example, I manage a website that uses a “shared” pixel. I do not know how the pixel was created and it is not important to me. I expect to be able to use it if the needed permissions are provided to me.

I will update the plugin to its next version, only when it supports all pixels. I think that most of the plugin users will do the same.

P.S. The old version works with the shared pixel and does a good job, with only small bugs and some errors in the pixel code.

All best

Svet

Hi @jenskyverge,

I installed the plugin “Facebook for WooCommerce – settings tools” and made the reset. Then I started the process and I had faced the following two problems:

1. I was unable to select the desired facebook page. There was a tooltip showing the following message: “Page is already associated with a Commerce Account and cannot be moved to a different Business Manager”. I even do not know what is a “Commerce Account”. If this was the only problem I would have investigated the error further. Sadly there was another problem [2], for which I had no solution, so I canceled the process.

2. The pixel which I wanted to use was not in the list of available pixels

I decided to cancel the process, since I didn’t want to mess up the statistics of other non-related pages just for the test. Then installed the old version of the plugin and the pixel online now.

All best

Svet

Hi @jenskyverge,

have you investigated further the problem with the currency I reported previously, the error message in one of the requests:

Message: “Invalid values provided for variables of operation “PlatformBusinessOauthDialogUnifiedFBEDataSetupView_CreateFBEMutation”: Value “Array of size 16 starting with: { client_mutation_id => “1” }” cannot be used for variable “$input”: Field “config” has value of invalid type: Field “setup” has value of invalid type: Field “currency” has value of invalid type: There is no value named “BGN” in this enum.”

I believe that this error message, in my specific case, is showing the real problem.

All best

Svet

Hi @jenskyverge,

Yes, the pixel which I am talking about is created through the Business Manager (as far as I can remember).

Do you plan to update the plugin and to include support also for the pixels created through the Business Manager? In my Business Manager account all pixels look the same to me ??

All best

Svet

Hi @jenskyverge,

I have just tried the new version (Version 2.0.1) and the connection still cannot be made, receiving the same error as before:

“Oops, something went wrong.
This may be because of a technical error that we’re working to get fixed. Try reloading this page.”

I have noticed 2 things:

1. The error in the console is the same as before:
   Message: “Invalid values provided for variables of operation “PlatformBusinessOauthDialogUnifiedFBEDataSetupView_CreateFBEMutation”: Value “Array of size 16 starting with: { client_mutation_id => “1” }” cannot be used for variable “$input”: Field “config” has value of invalid type: Field “setup” has value of invalid type: Field “currency” has value of invalid type: There is no value named “BGN” in this enum.”
2. The pixel which I want to use is not in the list of available pixels

All best
Svet

Hi @jenskyverge,

Thanks for your fast response. I followed your advice and spent some time with the old plugin (v1.11.4) and it worked well. The plugin version for me is not so important if the pixel works properly. That’s all I need on my website.

That said I hope that soon you will manage to make the new v2 of the plugin more stable and that we all could benefit the better security, better interface and more functionality.

All best

Hi @dudo

I did set the global setting to “CreativeWorkSeries”, but it looks like that the yasr_review_type value overwrites this global setting (I guess based on the plugin behavior).

This was the reason for my old posts showind as “BlogPosting”, but the new ones had the corrent (set as a global setting) “CreativeWorkSeries”

All best
Svet

P.S. I deleted all custom yasr_review_type values from the wp_postmeta table with the query:
DELETE FROM wp_postmeta WHERE wp_postmeta.meta_key = 'yasr_review_type'
and now the default configuration ‘CreativeWorkSeries’ is applied to all posts

Please backup your database before executing the queries. The advice I give is only an information and I am not responsible for what you are doing with your data!

Hello @dudo,

would you suggest to just delete all these records instead of updating them?

Hello @dudo,

I am using YASR from some time, but I recently found out that there is an option to change the schema @type. The whole “Rich snippet options” are new to me.
I know what does those mean and how the data there is used, so the settings are clear to me.

After your comment I decided to find a good example url for you and checked some posts. What I have found is that on some posts, the ld+json uses “BlogPost” type and on some the consifured “CreativeWorkSeries”. Then I looked into the database and found the following stored for the specific post into wp_postmeta

meta_key: yasr_overall_rating
meta_value: Other

It looked to me like there is a setting for every posts. I went into the post edit interface and I found it – a pannel “Yet Another Stars Rating”. In this pannel there is an option with name “Select ItemType”. It was clear to me that this post has specific configuration for its Rich Snippet type. The value of the select box showed “BlogPosting”, even though in the database the value is “Other”. I assume it is a fallback of the select dom element, since there is no option “Other” and it selects the first option in the select tag.

I see two problems:
1. I do not remember ever configuring this option on a post level
2. A value in the database “Other” defaults to “BlogPosting” in this options select

I found in the wp_postmeta a record for every post in the system containing this data

meta_key: yasr_overall_rating
meta_value: Other

Now I understand how YASR plugin stores its data – on global level, and on post level. I solved my problem by executing

UPDATE wp_postmeta SET meta_value = 'CreativeWorkSeries' WHERE wp_postmeta.meta_key = 'yasr_review_type' AND wp_postmeta.meta_value != 'CreativeWorkSeries'

and it worked. Now the ld+json uses “@type”:”CreativeWorkSeries”

All best
Svet