Hi, I’m the developer of WPSSO.
It sounds like there might be a PHP or WordPress issue here, and knowing exactly what the issue is would allow you to contact the theme or plugin developer that can fix that issue for you (it may be this plugin or another). You can enable logging of PHP and WordPress errors by defining the WP_DEBUG constant as true in your wp-config.php file. You can also activate the Query Monitor plugin, which may detect the issue, but it can’t detect everything, which is why people often use both (the WP_DEBUG constant and activate the Query Monitor plugin). You can find more information here: https://wpsso.com/docs/plugins/wpsso/installation/troubleshooting-guide/
Hopefully there’s an error available, and if there is, please copy-paste the text of that error in a reply.
js.
@jsmoriss Thanks for the information!
@becosfx Could you notify us of your findings?
If you could provide your Site Health information, then we can check for any conflicts from our side. You can share privately if you prefer. Thanks!
Thread Starter
cosbe
(@becosfx)
Thank you for your input. We’re in a very busy period just now. I will do these check-ups as soon as time allows and report back. Thank you!
-
This reply was modified 5 years, 7 months ago by
cosbe.
Thread Starter
cosbe
(@becosfx)
@luckynasan I filled the Site Health privately. Thank you!
@becosfx Thank you for providing your Site Health info. Does this issue occur if you temporarily disable the WPSSO Core plugin? We’ll try to do some testing on our end to see why the story doesn’t preview on the frontend of the site.
Thread Starter
cosbe
(@becosfx)
@luckynasan Thank you for your insight.
@jsmoriss Indeed, deactivating the WPSSO Core made the story visible!
Now, the Core is needed for the whole SSO engine to work. What is your advice?
Thank you for your support!
Thread Starter
cosbe
(@becosfx)
@jsmoriss I installed Querry Monitor but when the story is loaded, the top bar is not displayed. So, no information here.
The WP_DEBUG does not show anything when loading the story page.
I don’t know if this is of any help.
@jsmoriss I was able to produce the issue with WPSSO Core standard. This was in the PHP_errorlog:
WpssoSsmFilters::strip_schema_microdata v2.6.1 = nothing to do: “<body ” string not found in WordPress ‘template_redirect’ buffer for sunskitchen.biz/web-stories/title/
The WPSSO SSM add-on creates an output buffer to remove old/outdated microdata markup. That warning simply states that it could not do anything because the output buffer did not contain a ‘<body ‘ tag. All WordPress webpages include a body tag with attributes so this is a valid warning.
js.
@jsmoriss Here is a little more information. With WooCommerce and WPSSO Core activated without any other WPSSP add-ons, the story embedded successfully on the site.
When WPSSO Strip Schema Microdata was activated a ‘0’ displayed instead.
Here is the debug log error:
[15-Oct-2020 19:46:10 UTC] WpssoWcmd::wpsso_init_plugin error: The WPSSO Product Metadata for WooCommerce version 1.5.1 add-on requires the WooCommerce plugin — please activate the missing plugin.
Please let us know if there is more information needed.
Thread Starter
cosbe
(@becosfx)
@jsmoriss I confirm that deactivating only the WPSSO Strip Schema Microdata made the story visible! Can we hope for a fix?
@luckynasan Thank you!
I’m happy to help, but this is not a bug:
WpssoSsmFilters::strip_schema_microdata v2.6.1 = nothing to do: “<body ” string not found in WordPress ‘template_redirect’ buffer for sunskitchen.biz/web-stories/title/
The webpage that WPSSO SSM received from WordPress / PHP does not contain a body tag, and WPSSO SSM is letting you know. If the webpage is empty, as you say, then yes, it would be missing a body tag.
Note that WPSSO SSM uses a PHP output buffer to modify the webpage, which is a common technique with caching plugins, for example. WordPress plugins and themes should NOT use the PHP output buffer unless they have a very, very good reason for doing so – for example, caching plugins copy the final webpage output to a file or to an object cache, or a plugin like WPSSO SSM that must modify the final webpage output. Using the PHP output buffer is generally not recommended, unless absolutely required, and to avoid any issues, should almost always be used with a callback. See here for more info: https://www.php.net/manual/en/function.ob-start.php
The issue you are seeing is probably caused by this plugin using the PHP output buffer without any callbacks:
plugins/web-stories$ grep -R ob_start .
./includes/Story_Renderer/Embed.php: ob_start();
./includes/Story_Renderer/HTML.php: ob_start();
./includes/Story_Renderer/HTML.php: ob_start();
./includes/Story_Renderer/Image.php: ob_start();
js.
Thread Starter
cosbe
(@becosfx)
@jsmoriss Understood. But I kinda like the stories now, and I want to keep it live. Will I miss the Strip Microdata?
@luckynasan Could these two plugins live together at some point?
Thank you all for your support!
> The issue you are seeing is probably caused by this plugin using the PHP output buffer without any callbacks:
@jsmoriss I’m very certain that this is not the case. In my testing, a simple code like this breaks your plugin:
// somewhere in a theme or plugin.
add_filter(
'template_include',
function() {
return 'path/to/template.php';
}
);
// in template.php
echo '<html><head></head><body></body></html>';
This is NOT related to output buffering.
@swissspidy I’m not sure what you mean by breaking. If the webpage output contains an invalid body tag (as would be the case if the output buffer is empty or the body tag is incomplete), an HTML comment is added to the output buffer to signal the issue.
js.
