aglyons

This is a false positive. The CVE that was reported was for ver <=1.5.9 yet patchstack for some reason is tagging the latest version and earlier (<=1.6.1).

Even the patchstack url refers to v 1.5.9 not 1.6.1! I couldn’t find any way to report this error to patchstack.

https://patchstack.com/database/vulnerability/twenty20/twenty20-image-before-after-1-5-9-contributor-stored-xss

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-4580

So I have discovered that even though that switch is in place, the other sections’ code blocks will retain the global settings unless you add something in those blocks. Leaving them blank does not mean that the per-page setting will remove the global code.

I had to add <script></script> in order to disable the global content and replace it with the per-page content.

Is this by design?

Not possible. Square is using a JScript to create an iframe. iframes are completely separate pages and don’t interact with the ‘parent’ page the same way a div or other container would.

I have been on at Square for YEARS to fix the issues they have. So far everything is on deaf ears.

possible quick fix

Apparently this is happening because the file /wp-includes/pluggable which contains the function doesn't get loaded until after the plugins are loaded.

Indeed it is. So wrap whichever thing you're doing in a function, and hook it onto the plugins_loaded or init hook. (see the wp-settings.php file)

Example:

add_action('init','do_stuff');
function do_stuff(){
  $current_user = wp_get_current_user();
  // ...
}

It appears you are also not compatible with Oxygen Builder.

I get the same problem even trying to access certain pages in WP-Admin

So this sucks, pretty much forced to buy into the pro version just to see logs showing errors that I feel are being caused by the plugin itself.

Where are the logs for WP MAIL SMTP to help diagnose what is going wrong?

The iThemes people are asking me for some details to help figure out why emails are failing.

The 127.0.0.1 is a loopback request, but the above error indicates that for some reason your server has the plugin blocked from accessing wp_mail, which is what sends all site emails via the mailing plugin(s) you are using.

Can you check the WP Mail SMTP error logs?

• This reply was modified 3 years, 9 months ago by aglyons.

Yes, I am using PHP 7.4.15.

But, I’ve been seeing this issue for some time now well before that upgrade.

Sorry, I meant this message for iThemes but if anyone can offer advice I’ll take it. Thakns

I’ve seen this error message on the WP Health page

Missing table: wp_wpmailsmtp_tasks_meta

WP Mail SMTP is using custom database tables for some of its features. In order to work properly, the custom tables should be created, and it seems they are missing. Please try to re-install the WP Mail SMTP plugin. If this issue persists, please contact our support.

I removed and re-installed the plugin. The table is still not there in the DB.

Just ran into this myself.

Can we get an update to the plugin that clears this up without going through the under the hood steps and retaining the config that is in place?

Currently running 2.5.1

where are you hosted?

I determined that my servers NGINX clickjacking protection was adding that header. Once I turned that off for the Mautic domain it started working just fine.

1) Do you additionally have tracking for logged-in users excluded in Site Kit?
Logged in users are excluded in SK

2) Is the view with the IP filter configured also in Site Kit?
YES, The view connected has the filter by IP address enabled

3) From which reports in Analytics did you notice the discrepancy?
Realtime view. I can literally watch myself browse my site.

We really appreciate your report and look forward to looking into this further.

Again, I will say that this is a problem with the default Sk settings. I should also add that Optimize does notice that Tag Manager is installed and injecting the scripts for it which disables that connection from adding the code. It appears that the Analytics portion of SK does not do this which can end up duplicating tracking code.

v1.5.0

didn’t seem to make a difference.

I should add. Most WP users have some kind of caching running on their site. I would suggest that you make caching an option in the settings. Having multiple caching or minification plugins can cause issues. Throw in server-side caching and it can turn into a nightmare trying to troubleshoot issues.