Pawel Slabiak

And just as mysteriously as it stopped working, Pubmed Reflist is back to displaying results. Perhaps the issue was caused by the queried database and not by the plugin.

• This reply was modified 1 year, 11 months ago by Pawel Slabiak.

Thank you so much for the direction and the example code, Pascal. I appreciate your taking the time to sketch this out. I’ll post back here if I’m stuck or have the sanitizer working, whichever comes first.

Awesome—thank you for all this info, Pascal!

Thank you for this context, Pascal. Unfortunately the cost of increasing the amount of PHP memory is prohibitive to us, so this is not something we’re going to be able to try.

@shetheliving, @swissspidy, thank you for looking into this. We’ve taken down the web stories block and will monitor the issue on GitHub.

• This reply was modified 3 years, 6 months ago by Pawel Slabiak.

Thank you, Bethany, for looking into this. Sounds good—let’s put a pin in this for now and revisit if the issue recurs.

Many thanks!

Hi @shetheliving, sorry for the delay and thank you for following up.

Yes, we have consulted with our host and done additional troubleshooting. We have not been able to resolve the issue but have stumbled on a weird workaround.

Our hosting provider has looked at the server logs and zeroed in on a couple of entries that, according to the host, indicate that the plugin exceeded the amount of memory allocated to PHP. Our hosting plan has a 256MB limit on PHP memory.

Here’s the relevant log info that the host has made available, slightly cleaned up to make it suitable for sharing on a public forum (the site’s document root and IP address have been replaced):

PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 98304 bytes) in /wp-includes/wp-db.php on line 2022" while reading response header from upstream, client: 203.0.113.255, server: cai2r.net, request: "POST /wp-json/web-stories/v1/web-story/6364/?_fields=status%2Cslug%2Clink%2Cfeatured_media_url%2Cpreview_link%2Cedit_link%2Cembed_post_link&_locale=user HTTP/1.0", referrer: "https://cai2r.net/wp-admin/post.php?post=6364&action=edit

To be clear, the hosting provider has not concluded that the plugin requires more memory than available, but said that that’s what the logs suggest.

The host recommended that we check whether the issue is reproduced when Web Stories is the only active plugin, and then also check with other themes. We did so and the results of this troubleshooting are the following:

• Failure to save persists when Web Stories is the only active plugin.
• Failure to save seems to persist on other themes (we checked with Twenty Twenty-One and Eksell) but only up to a point. Eventually, the plugin succeeded in saving the story poster but it was difficult to tell at what point the save occurred.

The host also suggested that we turn on its performance monitoring tool, meant to “track and analyze slow transactions and database queries, external requests, and WordPress plugins and hooks,” and share the outcomes with you (we haven’t done this yet).

Meanwhile, we’ve come upon a weird workaround by duplicating the story draft. The duplicated draft exhibited none of the problems that afflict the original one: neither with saving page-level information nor with saving document-level information. This allowed us to move forward and publish the story but it does not explain or solve the issues with the original draft.

Any thoughts about how you’d like to proceed from here?

• This reply was modified 3 years, 6 months ago by Pawel Slabiak.
• This reply was modified 3 years, 6 months ago by Pawel Slabiak.
• This reply was modified 3 years, 6 months ago by Pawel Slabiak.

Thank you, Bethany.
I’ll be back with an update sometime today or tomorrow.

Hi Bethany,
Thank you for looking into this.

Yes, the console is showing some errors. A couple of GET errors on page load, and when the editor is prompted to save, a couple of POST errors and one uncaught error. Here’s a screenshot of the console on my end.

The “Failed to save story” message is shown every time the editor attempts to autosave or is prompted to save (and the attempt to save doesn’t reach an end, just continues). Even so, page-level info frequently does save, but document-level info appears not to.

Understood—thank you!

Thank you for explaining that. Is there any way to advocate for this enhancement or potentially contribute to it?

Thanks!

Thank you for looking into this.
We’ve submitted the form with site health info and hosting info.

Let me know if there’s anything else I can do to help.

Thank you for looking into this.

Indeed, on our end the black overlay also disappears upon pressing the escape key or clicking anywhere on the overlay.

Using a staging environment, we have also verified the following:

• The behavior persists when all plugins except Web Stories are deactivated.
• The behavior persists when the child theme is deactivated (the parent theme is Twenty Twenty).
• The behavior persists on the parent theme when all custom CSS is removed from the theme customizer.
• The behavior persists on fresh activations of other themes (we tested with Twenty Twenty-One and Eksell).

The site is running WordPress 5.8 with PhP 7.4.21.

Much appreciating any other ideas.

• This reply was modified 3 years, 6 months ago by Pawel Slabiak.
• This reply was modified 3 years, 6 months ago by Pawel Slabiak.

Thanks again, @stilman-davis.
The code I describe in a previous post in this thread actually does work when placed in functions.php.

I have no idea why the code did not work for me when I first wrote it. Perhaps a typo snuck in.

I only realized this after using other methods for blocking meta output (like CSS or the ‘twentytwenty_post_meta_location_single_top’ hook) and not liking them in the end, even though they worked.

So I looked at the template-tags.php again and wrote the bit below into functions.php in the child theme. Works perfectly.

function bemy_cpt_without_meta_output($disallowed_post_types) {
	$disallowed_post_types[] = 'qualia';
	return $disallowed_post_types;
} //do not output meta on custom posts of type 'qualia'
add_filter( 'twentytwenty_disallowed_post_types_for_meta_output', 'bemy_cpt_without_meta_output' );

Apart from the arbitrary name of the callback function, this seems to be identical to what I had written before to seemingly no effect. ˉ\_(ツ)_/ˉ

An acceptable workaround in my case has been to deactivate the plugin and append a north-east arrow character to all external links by targeting them with CSS:

/* Append NE arrow (unicode nr. U+2197) to all links except ones that begin with "https://mydomain" */
a:not([href^="https://mydomain"])::after {
	content: "\2197";
	display: inline-block;
}
/* remove arrow from links to page anchors */
a[href^="#"]::after {
	content: none;
}
/* remove arrow from relative links */
a[href^="/"]::after {
	content: none;
}
/* remove arrow from links to URIs that begin with "https://twitter" (in my case, the "Tweet This" buttons) */
a[href^="https://twitter"]::after {
	content: none;
}

Styling can also easily be done with an icon font:

a:not([href^="https://mydomain"])::after {
	content: "\00a0 \f08e"; /* non-breaking space followed by external link icon */
	font-family: "FontAwesome";
	display: inline-block;
}

However, this is not a solution to the original problem of how the styling introduced by External Links and stripped by the AMP plugin may be successfully reintroduced after tree-shaking. A fix to that issue would still be welcome.

• This reply was modified 4 years, 5 months ago by Pawel Slabiak.
• This reply was modified 4 years, 5 months ago by Pawel Slabiak.