piccart

hello @leonardotamion !

just wondering if there are news about this matter?

Otherwise I am thinking to create a temporary fork on our repository and remove those lines of code…

thanks!

hello @daniub

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.

Hello @daniub

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 ( file_exists( $file ) && apply_filters( 'cmplz_video_placeholder_convert_to_webp', true ) ) {

Hello @daniub

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?

hello @rogierlankhorst , sorry for the belated reply!

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!

ok great!

could you ping me here when you merge the fix into the main plugin?

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?

Hello Rogier, and thanks for your prompt reply!

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…

Hello @jarnovos

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. ??

Hello again!

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:

/content/plugins/complianz-gdpr/assets/css/cookieblocker.min.css?ver=6.4.2

what other stylesheet could be erroring out?

I’ve also noticed that when I click to Accept the cookies, it throws another error in the console

“Uncaught ReferenceError: vgo is not defined”

hello @jarnovos and thanks for your reply!

Unfortunately the website is on staging and it’s not public at the moment…

Though I can see the css file is actually being loaded in frontend and therefore it doesn’t seem to be the origin of the error.

/uploads/complianz/css/banner-1-optin.css?v=27

Is the plugin loading other css files which might be erroring out?

Maybe the problem is the fact that if I click on the link to see the included file, it contains the default colours rather than my custom colours. That could suggests an issue when generating the styles maybe? or do you load the customisations from a separate file?

I investigated a bit more and I did find the css files into our CDN at this path:

/uploads/complianz/css/banner-1-optin.css

I can also see the the stylesheet is included in the head in frontend and the url is correctly pointing to the CDN.

The url has a version appended, but if I paste that url in my browser I can see the content of the file. And the css rules in there don’t contain my colours, but rather they have the default ones.

In admin I can see it’s including the file banner-preview-1-optin.css and, oddly enough, it does contain our customised colours but the preview is still showing with the default colours…

hello! my apologies for the belated reply…

after your last reply I had a better look at your suggestion and I actually tested it and in the end I’ve decided to use that approach.

I am sorry but I’ve been mislead by the naming “headless” and I initially misunderstood the directions on the page you linked. So it all sounded too convoluted for my needs.

but in the end I’ve realised it was just about copying that very same single line you provided in your first reply, and pasting into wp-config.php. And it didn’t have any other effects that to remove those 2 fields.

it’s a bit of an uncommon way to disable some options but it worked perfectly!

thanks!

Hello Sybre and thanks for helping!

the “headless” route seems a bit too complex and prone to mistakes… And all I want is that those fields are not displayed in the admin page, because they will be confusing if I also add my own custom fields with similar names and different purpose.

so in the end I’ve used a dirty workaround which literally just hides the fields from the backend by wrapping them into a div set to display:none.

add_action('the_seo_framework_before_author_fields', function() {
    echo '<div style="display:none">';
});
add_action('the_seo_framework_after_author_fields', function() {
    echo '</div>';
});

Would be better if there was a filter to actually skip those fields, but for now this works well enough for my needs.

cheers!

hello!

sorry for the belated reply but I initially read your answer when I was in a hurry and then I forgot to come back…

Enabling the “Protected Content” option has indeed activated the use of elasticsearch in WP Admin. Thanks!

I would suggest maybe to write something about it in the description of that option so that it’s obvious that it is also what’s needed in order to use elasticsearch at all in the admin.

p.s. I’ve also rated the plugin! ??