Robert

I’m running v1.8.11 with WordPress 4.9 and received 20+ e-mail within one minute about “Oembed_cache status” like this:

Event: Post Update
Website: <redacted>
IP Address: 207.46.13.178
Date/Time: November 16, 2017 2:03 pm

Message: Oembed_cache status has been changed; details: ID: 17972,Old status: new,New status: publish,Title:

I’d never seen this before thought my site was hacked until I found this thread.

I unchecked the “oembed_cache” entry in Sucuri Security -> Settings -> Alerts -> Post-Type Alerts -> Oembed Cache.

Hopefully that will resolve it.

My site is also on WP Engine and have the same PHP 7 compatibility error report. CloudFlare plugin is the only stopping me from upgrading.

I changed the Tweet and Pin It buttons to Twitter and Pinterest. It now displays fine in AMP.

Thanks!

I fixed it by adding the script before the closing /head tag in my single.php custom template:

<script async custom-element="amp-ad" src="https://cdn.ampproject.org/v0/amp-ad-0.1.js"></script>
</head>

Chrome Developer Tools console now shows no warnings or errors.

It might be a production bug per this recent thread: https://github.com/ampproject/amphtml/issues/5025

My site previously had no AMP validation issues or warnings in the Chrome Developer’s Tool console. There are no validation errors in my Google Search Console. Adsense AMP Ads seem to be working fine.

Need to wait for the plugin experts to weigh in.

I’m getting the same validation error. The AMP Ad documentation states:

“Required Script:
<script async custom-element=”amp-ad” src=”https://cdn.ampproject.org/v0/amp-ad-0.1.js”></script&gt; Note: amp-ad may still work without this script, but we highly recommend it for future compatibility”

The plugin used to include the script. Seems to be the result of recent plugin updates and waiting for the validation tools to catch up.

If sending e-mail from yourdomain.com you should configure a SPF DNS record, DKIM keys and DMARC DNS record to avoid being flagged as SPAM.

If using Google Apps for Work Gmail see https://support.google.com/a/answer/2466580?hl=en&ref_topic=2759254.

Re-read the WP Engine notice. The vulnerability is for versions prior to Yoast SEO 3.2.5.

Wordfence practices Responsible Disclosure but this issue & fix isn’t mentioned in the Yoast 3.2.5 release notes. How convenient.

Source details are here:
Vulnerability in Yoast SEO 3.2.4 for WordPress: https://www.wordfence.com/blog/2016/05/yoast-seo-vulnerability/

I’m using the CloudFlare plugin. Correction to my original statement, disabling HTTPS protocol rewriting and/or disabling the plugin didn’t work.

I opened a ticket with CloudFlare Support who said to create a Page Rule and turn off all CloudFlare options.

The AMP Page Rule on my CloudFlare account is:

https://www.mysite.com/*/amp/*
with the following rules:
ByPass Cache
Apps (All CloudFlare Apps) – Off
Performance (Auto Minify and Polish) – Off
Mirage 2 – Off
Railgun – Off
Security – Off
SSL – Full SSL (Strict) (note: my site is full SSL/HTTPS)
Security Level – Default
Browser Integrity Check – Default

The above Page Rule with the CloudFlare plugin enabled and HTTPS Protocol Rewriting turned Off is working fine with no AMP validation errors in Google Search Console.

I suspect that Minify and Polish could be enabled but haven’t experimented.

See Cloudflare (and maybe other) CDN breaking AMP pages #2380 discussion on GitHub with some CloudFlare employees.

I had the same problem. Disabling the CloudFlare plugin solved it.

Initially I was getting validation errors on the AMP scripts included by the Automattic plugin, example:

“The attribute ‘src’ in tag ‘amp-iframe extension .js script’ is set to the invalid value ‘//cdn.ampproject.org/v0/amp-iframe-0.1.js’.”

because the following scripts had protocol relative URLs lacking http: or https: as follows:

<script custom-element=”amp-iframe” src=”//cdn.ampproject.org/v0/amp-iframe-0.1.js” async></script>
<script custom-element=”amp-analytics” src=”//cdn.ampproject.org/v0/amp-analytics-0.1.js” async></script>
<script src=”//cdn.ampproject.org/v0.js” async></script>

Turning off the CloudFlare plugin protocol rewriting option didn’t work. Disabling the plugin worked! Now the URLs are:

<script custom-element=”amp-iframe” src=”https://cdn.ampproject.org/v0/amp-iframe-0.1.js” async></script>
<script custom-element=”amp-analytics” src=”https://cdn.ampproject.org/v0/amp-analytics-0.1.js” async></script>
<script src=”https://cdn.ampproject.org/v0.js” async></script>

which resolves the validation errors. BTW my site is full SSL/HTTPS.

More info after experimenting.

I modified adblock-notify-files.php to use the /cache folder instead of /uploads for all occurrences of wp_upload_dir():

$uploadDir = wp_upload_dir();
$uploadDir[ 'basedir' ] = '/nas/content/staging/mysite/wp-content/cache/';
$uploadDir[ 'baseurl' ] = 'https://mysite.staging.wpengine.com/wp-content/cache/';

Two random name zero byte size .css and .js files were created with 664 (-rw-r–r–) permissions. Still the wrong permissions.

I reset all file permissions from the WP Engine admin panel, then checked the /wp-content/cache/an-temp/ file permissions. Now the two zero byte .css and .js files had the necessary 644 (-rw-rw-r–) Group write permissions!

Back to the Adblock Notify Settings page and click Save Changes without modifying any other settings or flushing files. The same two files now had 664 (-rw-r–r–) permissions. ??

Unless I’ve missed something in my hack on the /an-temp folder location, I’m wondering if the right credentials are being pulled when creating the random files?

Thanks

I found the problem! My hosting provider enforces strict file permissions for security (https://wpengine.com/support/file-permissions/) that cannot be changed (I tried anyway but was denied).

I do see two zero byte size files /wp-content/uploads/an-temp/ named <randomstring1>.css and <randomstring2>.js with file permissions 664 (-rw-r–r–) which prevents the plugin from writing to the files based on the lack of Group write permissions. 664 permissions are enforced for all files in the /uploads directory.

Feature Request:
A different strategy for creating local files does work on WP Engine is used by the Autoptimize plugin for serving it’s cached files. Autoptimize creates cached .js and .css files in the /wp-content/cache/autoptimize/css and /wp-content/cache/autoptimize/js which all have 644 (-rw-rw-r–) Group write permissions as set by my hosting provider.

The Autoptimize FAQ explains how the cache file directory location is configurable.

Hope you’ll consider the temp folder location configurable option.

Thanks!

Hi,
I changed the ad wrapper div container IDs to <div class=”custom1″>, etc. and set the Advert selectors to “.custom1, .custom2” (no quotes) in addition to Steps 2, 3 and 4 in your instructions.

With Adblock Plus enabled in both Firefox and Chrome the ads are blocked but the modal box is not displayed. Also enabled pop-ups in Firefox.

Modal box, cookies and Random selectors & files are enabled.

The Firebug DOM inspector shows that custom1 and custom2 classes have a clientHeight of zero.

I do see the Adblock Notify code after the </footer>:`
<div id="3K9OoFTSc6K6" class="8id89tbAkHTG" style="background:#dddddd;"></div> <script type="text/javascript">/* <![CDATA[ */var anOptions ={"anOptionChoice":"2","anOptionStats":"1","anOptionAdsSelectors":".custom1,.custom2","anOptionCookie":"1","anOptionCookieLife":"30","anModalTitle":"Adblocker detected!" ... snipped for brevity.

I can provide a WordPress admin login if I can contact you offline.

Thanks

Version 2.4.1 fixed it! Looks great!
Thanks

Email is working after creating a new Gmail App Password and pasting it in the configuration settings. I got the idea from another support thread.

Thanks