trek7k

The button is def. annoying and useless. Sounds like you don’t want to do any manual coding, and that’s fair. If you change your mind, and for others looking for a solution, you can add this to functions.php in your theme. Here’s the code.

add_action('admin_head', 'my_custom_admin_style');
function my_custom_admin_style() {
  echo '<style>
	div#webpushr_13fw3_switch-mode {
		display: none;
	}
  </style>';
}

OK, I see the checkbox that says “Preview Article” in the right sidebar in the editor. However after clicking publish there is a red warning error box at the top of the edit post page that just says “undefined.” Still not sure what is going on but I was able to answer my initial question. ??

Also experiencing this message. Also, when clicking the “Test Cloudfront Distribution” button I get “Test Failed.”

In my case it seems to be failing due to a problem with Guzzle. Any way to bump the included Guzzle to the latest version? Seems to be a conflict with the version of Guzzle included in another plugin we have to use. W3TC Guzzle version = 6.5.8 I think; latest Guzzle version is 7.8.1

• This reply was modified 7 months, 3 weeks ago by trek7k.

Sounds like maybe you’re looking for something like this:

$args = array(
‘category_name’ => ‘general’,
‘meta_key’ => ‘_yoast_wpseo_is_cornerstone’,
‘meta_value’ => ‘1’
);
$query = new WP_Query( $args );

Will do, thanks.

Upon further testing, the cross origin taint error eventually pops up on the final panel even on the templates that use only stock images hosted by google.

To confirm our web and image server are not causing the issue, we tested stripping out all references to any images stored on our own servers, including the logo files etc. Even opening the file locally, the final panel generates the error. ??

This is the HTML that was tested locally, and that continues to produce the error.

https://pastebin.com/bsLTLjJt

Will be investigating and sharing anything we find on our end in case others have a similar issue.

Tried publishing one of the story templates as is, and the errors disappear. It seems it is the images in our story that are supposedly cross origin tainting the canvas. The images are hosted on a subdomain (images.example.com) so not on the same server as the page, however the template stories also use images stored on another server (wp.stories.google) and do not throw the error.

It *could* be an issue with the headers returned by S3 so that’s the next area to investigate. A lot of sites use Amazon S3 for image hosting so I’m surprised others have not run into this yet…

Bummer, thanks anyway. Like I said, we checked to make sure that the headers are configured correctly (Access-Control-Allow-Origin etc.) so if you can think of any reason that the canvas could become tainted with cross-origin data, please let me know. It does seem like this is something specific to our server setup since others have not noted this issue with the web stories plugin.

Have deactivated all plugins except web stories, and have switched to fresh twentytwentyone theme on dev server and are still getting the JS errors.

Looking at the source generated by the web story, it seems unlikely the theme or any plugin would be causing this since none of our site CSS/JS/etc. is being included or referenced in the HTML, even with everything activated. Everything appears to be coming from ampproject and stories.google.

Both our live and production sites are hosted by AWS, and obviously there are a ton of configuration variables involved there. Could it be something at the server level that is mixing origins, possibly in the headers?

I can’t disable it on the production site, but have done so on our development server. I have sent that information via the form Bethany linked above.

The error seems to persist even with W3TC turned off.

Edit: As a bit of additional info, the production site sits behind Cloudflare, however the development site does not so there shouldn’t be any caching or CDN interference there. We initially thought Cloudflare might be causing the issue, however we are seeing the same JS errors in both environments.

• This reply was modified 2 years, 10 months ago by trek7k. Reason: additional info

Thank you Bethany, I have provided the info via the form.

Plus one for this feature. Good and simple suggestion to make reusable blocks appear different from regular blocks to avoid accidentally editing them (unless you want to).

We use reusable blocks in a couple different ways, and maybe there’s a better way to do this.

The first way is for blocks that never change — say an editorial disclaimer added to an opinion article. This is a straightforward use and doesn’t give us any issues.

The other way is we use reusable blocks is as templates, for example when we insert affiliate links at the end of an article. Since the links are different for every article (but the formatting is not), we end up converting the reusable block to a regular block before modifying the links… that is, if we remember to do so. If we don’t remember, we have to undo the changes, save the block, remove it (since the ‘convert to regular block’ option disappears after editing), then re-add it, convert to a regular block, and then make the modifications again. It’s seriously a minutes-long process.

My idea is to add some kind of warning when you click to edit a reusable block. “Do you want to modify this reusable block, or convert to a regular block?” That would make things super clear and prevent accidental modifications.

Or maybe we should be using the template system somehow, rather than reusable blocks, for this type of situation?

Thanks. We’ve re-tried many times over the past few months and the issue persists, at least for us. Sticking to an outdated version of the plugin.

I’m getting this message too. Looking at the logs it’s a memory allocation error (allowed memory size exhausted). Tried increasing WP_MAX_MEMORY_LIMIT a couple times, up to 2048M on a test server and it still dies.

Looks like the script is doing a database update or modification that’s running out of memory. We have big post and user tables (535K and 431K records, respectively) which is likely a contributing factor.

Would love to get suggestions for a workaround… Thanks!

??