overengineer

Thank you for the detailed and honest review (and also for updating it after discovering that regions don’t need to be selected manually). We genuinely appreciate that.

A few points we’d like to clarify:

• The plugin ships with English fields already populated by default. The AI translation feature then uses those existing values (including your own edits) into the target language using the AI provider/model you’ve selected. So even if the fields appear empty when adding a new language, they can still be translated using the values from the default language.
• Manual cookie configuration is indeed time-consuming, and I agree it’s one of the biggest pain points at the moment. We do have an automated cookie scanning feature planned in our roadmap (GitHub issue #141), although we can’t provide an ETA yet.
• Countries are configured separately because this feature is closely tied to Google Consent Mode (GCM) requirements. As you pointed out, selecting regions is optional unless you specifically need to target only certain areas within a country, not when adding the entire country itself. That said, your comments about the UX are completely fair, and we’ll definitely consider ways to make the process more intuitive.

By the way, the JSON export → Claude → import was honestly a pretty creative workaround to speed up the setup process.

We’re actively listening to this type of feedback and always looking for ways to improve the overall experience, while still maintaining the flexibility and level of control the plugin provides.

Thanks again for giving the plugin another shot, even if the setup process felt overwhelming. That means a lot.

@helmutpecher Hello there!

We’re not currently aware of any specific issue between our plugin and Google Site Kit, so it would really help if you could share a bit more detail about what’s happening.

Could you elaborate on what exactly isn’t working?

If you’re comfortable sharing, a URL where we can see the issue would be extremely helpful as well.

Also, if you can, please open a bug report on GitHub so we can properly track and investigate this. Alternatively, you can fill out our bug report template here:

**Describe the bug**
A clear and concise description of what the bug is.

**Steps to reproduce**
Detailed steps to reproduce the behavior:
1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

**Expected behavior**
A clear and concise description of what you expected to happen.

**Screenshots**
If applicable, add screenshots to help explain your problem.

**Environment (please complete the following information):**
 - Browser: [e.g. Chrome, Firefox]
 - Plugin version: [e.g. 1.7.0]
 - WordPress version: [e.g. 6.7.1]
 - PHP version: [e.g. 8.1]

**Server logs**
If applicable, include any server logs that could be related to this issue.

**Browser console logs**
If applicable, include any warnings/errors in your browser’s console. You can open the Console panel in Google Chrome, using ⌘ + ⌥ + J on macOS, or CTRL + Shift + J on Windows/Linux.

Hi, @sandroulaki!

Thanks for reaching out!

From what you’ve shared, the code snippet doesn’t seem to be coming from our plugin. The reference to “PYS” strongly suggests it’s related to the PixelYourSite plugin, which integrates tracking pixels and scripts.

To help us investigate further, would you be okay sharing the URL of the affected site? That would allow us to take a closer look and confirm what’s going on.

@nicmare Hey, thanks for reaching out! The plugin is actively maintained. Those deprecation warnings come from a third-party dependency we use. They’re on our radar and will be addressed in a future release, though they’re lower priority as they don’t affect functionality.

@nicmare Hi, thanks for bringing this to our attention!

You’re right, bumping the pressidium/cookies block to API version 3 will ensure full compatibility with the iframe editor.

I’ve opened a GitHub issue (#190) to track this. We’ll address it in the next version of the plugin.

Thanks for taking the time to report it!

Hey @eusebiuoprinoiu,

Thank you so much for taking the time to share your feedback.

The idea of having a “Rest of the World” region is a great one. Something similar has been suggested before, and I agree that it’d simplify configuration for many websites. While we can’t give a concrete timeline, it’s definitely on our radar and something we’ll look into at some point in the future.

We’re also happy to let you know that we’re actively working on migrating to orestbida/cookieconsent v3. That update should be available soon.

Hey @anseric,

Thanks for reaching out and apologies for the late reply, I’ve been catching up after the holiday break.

Pressidium Cookie Consent does not have any special integrations with caching plugins, regardless of whether it’s running on Pressidium or another hosting provider. In general, caching plugins are supported, but JavaScript optimization features (such as JS minification, concatenation, or similar optimizations) can sometimes interfere with the way our plugin operates.

In the past, a few users have reported conflicts that were resolved by either:

• Disabling JavaScript optimization features in the caching plugin, or
• Excluding the Pressidium Cookie Consent plugin’s JS files from being optimized

That said, we haven’t had any reports of our plugin breaking a caching plugin, so this is something we’d definitely like to look into further.

If it’s possible, could you please share a few details about your setup?

• WordPress version
• PHP version
• Caching plugin name and version
• The exact steps to reproduce the issue

With that information, we should be able to dig deeper and see what’s going on.

Hey @texnologia,

Thank you for using Pressidium Cookie Consent and for reporting this issue.

[…] i understand that this must be related to the database. and more specifically this has to be related to emojis

Ιn short the database encoding needs to be converted to utf8mb4 […]

This is unlikely to be the issue, as the plugin supports both utf8mb4 and utf8 character sets. The main difference is that utf8 (an alias of utf8mb3) supports up to three bytes per character, whereas utf8mb4 supports four, which is required for native emoji storage. However, the plugin converts emoji characters to their HTML entity equivalents before saving, so it functions correctly even on databases using the utf8 charset. This has been the case since version 1.1.2.

Refer to:

• The Emoji class
• GitHub issue #15

Settings are not saved when i make changes.

Could you please provide a bit more information so we can better understand the issue?

If possible, please submit a bug report on the plugin’s GitHub repository. Alternatively, just fill out the template below and share it here in your reply.

Describe the bug
A clear and concise description of what the bug is.

Steps to reproduce
Detailed steps to reproduce the behavior:

1. Go to ‘…’
2. Click on ‘….’
3. Scroll down to ‘….’
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Environment (please complete the following information):

• Browser: [e.g. Chrome, Firefox]
• Plugin version: [e.g. 1.9.1]
• WordPress version: [e.g. 6.9]
• PHP version: [e.g. 8.1]

Server logs
If applicable, include any server logs that could be related to this issue.

Browser console logs
If applicable, include any warnings/errors in your browser’s console. You can open the Console panel in Google Chrome, using ⌘ + ⌥ + J on macOS, or CTRL + Shift + J on Windows/Linux.

Additional context
Add any other context about the problem here.