The problem is definitely still happening with version 7.1.5 and it also happens with 7.1.4 but we’re not experiencing it with version 7.1.0 (which is what we are using at the moment). I suppose that those edits introduced to fix the other problem, have caused a regression of the issue we had in the past with mPDF temp folders.
Are these temporary folders still under the /uploads/ path? We are using a S3 bucket as cdn for uploads, hence we have a plugin which handles rewrites and redirects when uploading/reading from the wp uploads paths. I suppose that your code gets confused when dealing with the cdn, though I can see several folders under /complianz/ in the S3 bucket, including 2 fonts under this path /uploads/complianz/tmp/SOME_HASH_CODE/mpdf/ttfontdata/
I am not sure precisely what caused the conflicts with mPDF, but if you have a look at the old ticket you can find more info about our setup and what has been done on your side in order to avoid problems when someone uses an external cdn. It feels that the files are initially stored correctly in the cdn, but then when mPDF tries to read them it doesn’t look into the cdn but in the default wp folders…
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.
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:
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?
I updated the plugin to the latest version and it does indeed seem to work correctly in our enviornment. 🙂
I am not sure what I was looking at, I thought I downloaded the latest version from the WP repo, but I must have clicked the wrong thing at some point.
Apologies for the misunderstanding, and many thanks for your help!
Hello Rogier! sorry for the belated reply but I’ve been off work.
I’ve just tested that branch on my local environment (connected to the same bucket) and I managed to generate the pdf file by clicking from the “Proof of consent” page.
I assume it will work when triggered by the cron job too.
For reference, it placed the file under
/uploads/complianz/snapshots/
actually, I am now wondering, if it will generate one pdf per day with the cron, will it keep them all or is it going to delete the oldest and keep only a few?
I am not aware of any file type restriction on the bucket, but it does feel like the problem is that Mpdf is not able to write its cached/temp stuff into the bucket.
Though it seems quite odd that the rest of the plugin’s folders are being created/accessed without problems… any idea about what could be different?
by the way, is the number in the tmp sub-folder a timestamp? or is it always the same? If it’s always the same I could try to manually upload that font, but I have a feeling that the tmp sub-folder will be different for every run…
After some investigation I’ve realised that vgo() is a method found in ActiveCampaign tracking scripts.
The problem is that we use ActiveCampaign only to embed a form, and we haven’t enabled the tracking logic, so that js library is not loaded. But when I selected AC plugin during the Wizard setup, Complianz was assuming that it had to fire that script after the cookies are accepted.
So I have now disabled Active Campaign from the Integrations section, and I just mention it in the list of Services. I think that would be enough for GDPR because the data is sent to AC only if the user actively submits the form to subscribe to the newsletter. I think there is no need to block anything before consent.
though if possible, it would probably be better if Complianz’ script had a check for the existence of vgo() before trying to fire it, as it’s just an optional feature of Active Campaign. 😉
so in the end I’ve realised that the file was being cached by Cloudfront before hitting the cdn. Now I’ve tweaked a couple of settings and the frontend popup is picking up my custom styles correctly.
though I can still see that error about the mime / missing stylesheet… I’ve tried deactivating the plugin and the error doesn’t show up. I can see it’s loading this file correctly as well:
