I noticed that when a post contains an embedded youtube video, the frontend page is blank. There is no html at all, just an empty head and body.
This happens even if I have previously accepted the cookies from another page.
The videos are embedded by placing the url into the tinyMCE (classic) editor, but I tried to put the iframe code manually into the content and it gives the same result.
there is no error in the console (nor on the server logs).
if I check to “disable complianz on this page” then the page loads normally.
I have set up the youtube service and cookies by following the wizard’s defaults. Is there something that I might be missing?
thanks!
This topic was modified 11 months, 1 week ago by piccart.
unfortunately I can’t provide a link because it’s a client’s website and I prefer not to share it here.
in any case, there wouldn’t be much to see because as I said the page’s html is completely empty.
the page loads normally if I remove the embedded video or if I check “disable Complianz on this page”.
I also can’t see any error in the server logs. The page seems to load correctly on server side, but then it’s emptied on the client side.
I tried with different videos and the result is the same. The video url is just pasted in the post editor and the embed code is generated by wp in the default way. The only thing a bit peculiar maybe is that we’re using the classic editor rather than Gutenberg.
I didn’t try to disable the integration with Youtube from the Wizard because if possible I would like to keep it so that youtube cookies are eventually blocked. I assume that if I disable the integration then when someone clicks to reject all cookies complianz won’t really block youtube’s, would it?
ok I have traced back the problem and I’ve figured out that it’s caused by Complianz logic to generate the image placeholder for the video.
in particular it’s the function cmplz_create_webp() when it’s triggered by this bit of code at line 1798 of the file functions.php in your plugin’s root folder:
Within that function it then tries to save the newly generated file:
and at that point it uses WP_Image_Editor workflow and ends up crashing when it fires the method make_image(). I don’t know why but it seems that it crashes as soon as it fires ob_start()
I am not sure why it would happen, but for reference we use an S3 bucket as CDN for media, integrated using the plugin “humanmade/s3-uploads”, and we have image GD on the server.
though we don’t have problems with images or attachments when within normal workflows. In fact, if I comment out that bit of code from the first screenshot, the page loads normally and it also shows a placeholder correctly generated from the video. I mean that it’s not a default/general image, it’s a screenshot from the video itself. It’s just a jpg rather than a webp.
At this point I am wondering if you could just add a filter within that first conditional, so we can eventually skip that logic. Something like:
if it depends on wp_image_editor, what’s the php configuration? Can you please share with us some details like (memory_limit // max_execution_time // output_buffering )?
to be honest it feels more like a permission issue or some conflict with the fact that we’re using a S3 bucket for media (integrated with the plugin “humanmade/s3-uploads”).
The website is hosted on Heroku by the way, and we’re using php8.1, memory limit is 128M and 30s max execution. But we don’t have any php error logged on the server when loading the page.
And the previous part of your code is generating the placeholder image and storing it without problems, hence the system seems to have the “power” to handle that. The problem arises only when it tries to convert that image to webp and then tries to store it with a different workflow.
I feel that the second workflow, when fired at that point in the code stack, is conflicting with the S3 integration and it’s ending up trying to store the image incorrectly.
Thank you for your patience. The dev team has reviewed the entire thread, and first, we want to express our gratitude for your collaboration and contributions to our open-source plugin!
The dev team has asked if you could submit a pull request on our GitHub, so they can take a closer look.