monocode
Forum Replies Created
-
Hi
We noticed you implemented a fix by using a new domain instead of using the subdomain.
We we wondering if you are satisfied with your solution or if you would like us to look further into this problem?Best regards
Team AppSaloonHi @waveout
At this moment the latest WordPress version the plugin was tested with is 6.0.0.
While we cannot guarantee the plugin will work correct with WordPress 6.0.1 we don’t expect any issues.
The latest WordPress update is a minor release which would not impact the the plugin.Best regards
Hi
It’s only prevented during the initial page load.
Using the DevTools we can resend the (/wp-admin/admin-ajax.php?action=seopress_do_real_preview) request.
Then it finishes within 600 ms and SEOPress is able the parse / crawl the HTML and correctly fill out the meta box.No, there are no errors in the console tab.
No, no htpasswd or specific security is active for this website.
Could this be a JavaScript race condition since a second XHR request is working fine?
Best regards
Hi
Thanks for the feedback.
We’ve added this snippet in the functions.php file:
function sp_real_preview_remote($args) { $args = array('blocking' => true,'timeout' => 5,'cookies' => $args['cookies'],'sslverify' => false); return $args; } add_filter('seopress_real_preview_remote', 'sp_real_preview_remote');Now, the /wp-admin/admin-ajax.php?action=seopress_do_real_preview XHR request takes 5 seconds instead of 30 seconds to complete.
But the wp_remote_get function used in the seopress_do_real_preview function still results in a timeout.
Therefore the XHR result is this one:Result: {"success":true,"data":{"title":"To get your Google snippet preview, publish your post!"}}We are using Local (localwp.com) for local development.
For our production websites we use SpinupWP (spinupwp.com) + DigitalOcean droplets.Both using NGINX as web server.
Reloading the edit page with the DevTools opened doesn’t result in noteworthy
error / warning messages in the console.Best regards
Hi Dan,
This issue was resolved with release 3.11.0 on 23 Jul, 2021.
https://github.com/CybotAS/CookiebotWP/releases/tag/v.3.11.0We removed the PHP-DI dependency because we had to use an outdated version to maintain compatibility with older PHP versions. This caused some issues with PHP 8 instead. So we replaced the entire thing with a custom lightweight class to handle dependency injection across the plugin code.
With the removal of PHP-DI, the Cookiebot plugin no longer contains any Composer dependencies.
Kind regards,
Team AppSaloon
Hi @dan14
Which version of the plugin are you currently using? In the latest version of Cookiebot (3.11.0), we removed the dated PHP-DI dependency from the plugin code. This is the same dependency that was causing the deprecation notice from your earlier support ticket – alongside some other conflicts and bugs. If you are still experiencing this exact issue, you’re most likely using an older version of Cookiebot.
However, if you have examples of other warnings, notices or errors stemming from a compatibility issue with PHP8, or a bug in the plugin code, I’d gladly fix these issues.
Regarding your first issue, that’s something I have no first-hand experience with. Did you manage to find what was causing the issue by disabling your browser extensions, as suggested by @nazaqatcybot? If the issue is with the Cookiebot plugin, I’d be happy to look into it! In that case, It would be very helpful if you could provide some more details about how to reproduce the issue.
We do try to fix bugs that get identified sooner rather than later, so thank you for helping us out by reporting those bugs. Regarding updates, some big improvements are in the works for the Cookiebot plugin code. We’re basically cleaning up the entire codebase to make everything more maintainable. This will reduce the number of unexpected bugs in the future, as well as allow us to increase the functionality more easily. Although it is still a work in progress, you can check out the relevant GitHub issue, as well as the accompanying feature branch.
Kind regards,
Team AppSaloon
Hi @ace0wp0syn
First of all, thank you for your suggestion.
Looking at the external scripts that are loaded from consent.cookiebot.com, there’s “cd.js” and “uc.js”.
Notice how “cd.js” is actually loaded from
https://consent.cookiebot.com/<cookiebot_id>/cd.js. This means that the actual text content of this file will be different for every installation of the CookieBot plugin. The only way to verify this file’s content would be to create an option field where the site admin can configure the expected hash for this script.On the other hand, “uc.js” is always getting loaded from the same URL. However, this URL lacks a version indicator. This most likely means that the “uc.js” text content might get updated at any point in the future. This means that if we implement the subresource integrity check, an update to the external “uc.js” script would break all CookieBot plugin installations.
As far as I know, there’s no sensible way to implement the subresource integrity feature for either of those scripts. Unless I’m missing something,
this feature only works for static and versioned resources.If you have any objections, please feel free to bring them up. I would love to learn I’m wrong about this.
Kind regards,
Team AppSaloon
- This reply was modified 4 years, 6 months ago by monocode.
Hi Dan,
The Cookiebot plugin uses an older version of the php-di dependency in order to support older versions of PHP.
Can you please elaborate on which WordPress functions you’ve been having issues with? Usually a deprecation message won’t cause any problems.
Kind Regards,
Team AppSaloon
I was unable to reproduce this issue with WordPress version 5.7.1 and Cookiebot version 3.10.1: The [cookie_declaration] shortcode displays correctly.
Tested on an empty WordPress site with no other active plugins and a default theme.
Is it possible that other plugins are interfering?
Kind regards,
Team AppSaloonHi @ierpe,
I could not reproduce this issue using the “Cookie Declaration” block, and the twentytwentyone theme on a clean wordpress install. The declaration content appears right where it’s supposed to. (when logged in and when logged out)
May I ask which theme you are using on your website?
If you haven’t tried it yet, I would suggest also using the “Cookie Declaration” block on the page editor.Kind regards,
Team AppSaloon
Hi @larsica
This issue should have been resolved in the latest release of the CookieBot plugin. You can view the changes [here](https://github.com/CybotAS/CookiebotWP/pull/204).
Can you confirm that the latest version resolves the issue for you?
Kind regards,
Team AppSaloon
Hi Martin,
Are you still having this issue or did you manage to resolve it?
I did a small test today where I installed cookiebot and happyforms on a clean wordpress site. I couldn’t reproduce this issue, because I am able to submit the forms.
As Filipe said, this issue is probably caused by the double cookiebot setup.Kind regards,
Team AppSaloon
@tsteur which version of Matomo Analytics caused the critical error? We tried to reproduce the issue with version 4.1.1 as well as 4.1.0, but we could not reproduce this issue. Can you also explain where the issue occurs? Is it in the front-end or in the back-end? Any specific page or steps to reproduce?
Kind regards,
Team AppSaloon
Hi
That’s nice.
Thanks.Best regards