Duplicate generation of Marketing and Analytics options

Description

Hey Finsweets, everytime I update Consent Pro component it generates those marketing and analytics options again. I saw the issue was discussed once here but I could not see where it actually led and I can’t find the problem myself. Anyone willing to take a look? :slight_smile: Massive thanks for any advice.

Site URL

Hey @welcome!

Great news - your implementation looks correct based on the HTML analysis! We can see your Consent Pro component is properly set up with all the right fs-consent-element attributes and the marketing and analytics categories are showing exactly as they should in the preferences form.

This category regeneration issue isn’t something we see discussed much in the community, but we can help clarify what should be happening and how to test it.

The marketing and analytics options in Consent Pro should not automatically regenerate after component updates unless:

  1. The component itself is being re-generated from scratch
  2. You’re resetting the consent states through the API
  3. There’s been a change in the app configuration that affects categories

To verify if this is expected behavior or a bug, try these steps:

  1. Check the Consent Pro API state:
window.FinsweetConsentPro = window.FinsweetConsentPro || [];
window.FinsweetConsentPro.push([
  'consent',
  (instance) => {
    console.log('Current consent state:', instance.getStore());
  }
]);
  1. Review your update process:

    • Are you updating the component through the Consent Pro app?
    • Are you manually editing the component elements?
    • Are you copying/pasting the component?
  2. Check the component structure:

    • Ensure all elements stay within the fs-consent_component wrapper
    • Verify that required attributes aren’t being removed during updates

Categories should persist their state unless explicitly reset. If marketing and analytics options are reappearing after every component update when you don’t want them to, this could indicate the component is being fully regenerated rather than updated, or user consent states are being cleared during the process.

Could you clarify what specific update process you’re using when this happens? That would help narrow down whether this is expected behavior or needs investigation :thinking:

If you need more technical assistance, @Support-Luis, @Support-Pedro or @jesse.muiruri can help further investigate this issue.

Heya, thanks for blazing fast response. I ran the log and it seems that categories persist correctly in the API state, but keep reappearing visually after component updates.

I was always updating the component throught the app, when it generated the duplicate categories I deleted them, cleared the unused styles, updated the component and it happened again.

The component structure stays the same, I have Consent Pro on two other websites, one of which was made as Cookie consent and one is already Consent pro and I never had the issue there..

What does it say to you? :slight_smile:
Cheers and thanks !

Hello support - any news on this case? I realized I probably did not answer fully - so to the question 2:

  • yes I updated the component through the app
  • I was manually editing - the classes I wanted designed using my variables, I changed mostly from rems to ems, sized the elements my way etc
  • I was not copying/pasting the component - I deleted it first when I experienced the bug, then created via app again and then only deleted the duplicit parts and repeated
    • I did not touch the component structure
  • no attributes were removed

hope this helps :slight_smile:
thanks

Hey @welcome!

This seems like a big :thinking:

Do you remember whether the consent elements were selected before any changes were made to the settings?

We are currently working on an update. I’ll see that this bug is addressed for future releases.

Apologies for the inconvenience.

Hey Luis! Thanks for bumping back :slight_smile:

Once I created the component, I did not change the settings, only styling, but:

I had my head around that several times during weekend. I tried recreating the component several times - deleted the component, disconnected the app, deleted the interactions, cleared cache, published again, connected the app, set the options, created the component, set the cookie scripts.. and I noticed that the problem persisted when I used custom toggles option.

This morning, when I cleared the unused classes after deleting the component, there was still fs-consent_prefs_checkbox, fs-consent_prefs_checkbox 2… 3 … etc classes that were not cleared, but in the same time they were not traceable anywhere, on any page, any component etc.

I renamed them to dummy class names x, y, z etc, connected the app again and created the component, now trying it without the custom toggles.

Now it seems to be working.

Was a bit annoying because I had to reschedule the pre-launch client meeting we planned, cause I wanted to make sure it will be working properly (the client is a therapist and relies on GDPR compliance critically).

We would love to launch the website this week. I prefer custom toggles over classic checkboxes, hope you can guys make it work somehow.

Cheers from Norway! :slight_smile:

Thank you for the detailed response @welcome!

I’ve passed this on to the team so we can have a deeper look into the issue.

I’ll update you on the progress :flexed_biceps: