Closed (fixed)
Project:
Cookiebot - Cookie consent, Cookie monitoring and Cookie control
Version:
8.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
12 Nov 2019 at 17:39 UTC
Updated:
25 Feb 2020 at 13:44 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
anybodyComment #3
anybodyI'll start with the development of this feature soon.
Comment #4
anybodyPatch attached, please review! This patch is based on #3098778: Add schema (& translatability) #3 so that patch cookiebot_add_schema-3098778-3.patch has to be applied before!
Comment #5
anybodyComment #6
anybodyComment #7
anybodyComment #8
anybodyThis is what the form looks like:
Comment #9
anybodyTODOs:
Comment #10
a.milkovskyLet's create a template instead of saving HTML in the database. The "Please accept marketing cookies" text can be stored in the config.
Comment #11
anybodyThank you @a.milkovsky for your feedback! Yes that's a good idea. I'd suggest to put this into the database, otherwise it would be much less flexible because of the splitting, do you agree?
Please <a href="!cookiebot_renew" class="cookieconsent-optout-marketing__cookiebot-renew">accept marketing-cookies</a> to view this embedded content from <a href="!cookiebot_from_src_url" target="_blank" class="cookieconsent-optout-marketing__from-src-url">!cookiebot_from_src_url</a>Attached is a new patch which fixed the points from #9 and wraps and explains the form elements a bit better.
I'll add a new patch after your reply containing the template.
Comment #12
anybodyCompletely new patch attached based on #5 from #3098778: Add schema (& translatability) (can we please get that done do proceed in other issues first?).
I now implemented your suggestions from #10.
Please review.
Comment #13
anybodyComment #14
anybodyI decided to add a complete patch now, which includes Patch from #3098778: Add schema (& translatability)-#5 now and will be easier to test.
It also contains a further change of
from #14 which is required due to the change to boolean. Before the code was strictly compared to !== 1 which fails with a boolean schema.
Comment #15
arnested commentedIs there any reason this only handles the marketing category?
Comment #16
arnested commentedAlso the latest patch removes the
asyncattribute again :)Comment #17
anybodyHi @arnested,
thank you for your feedback!
#15 will of course be resolved with a final patch. It was created while the other issue was in work. Sorry. Thank you for the hint.
#16:
Yes, I also thought a lot about it. Looking into the cookiebot automatic code, the data-src automatism always sets this category. Blocked sources will 99,9% be Marketing, I can't imagine many cases where an iframe or video is "statistics" or "preferences".
We could also add a separate text for each type or remove the type completely / match all, but as of YAGNI I'd only add what is currently needed. It will be simple to add the same for other categories when needed.
Comment #18
arnested commentedThat's fine, @Anybody.
I just made me wonder.
On our company website we have some iframes from our Vimeo account that we have put into "statistics". But that is with the manual mode. If auto-blocking mode always chooses marketing then I can see why going with that (for now) is fine.
Comment #19
anybodyWould you like to use that feature for statistics? (look at the JS code) or would you solve it differently anyway?
Comment #20
arnested commentedWe only use the manual mode and we have added the fallback/placeholder stuff to our templates ourselves. I think we'll prefer to keep control this way despite being a bit more work. So I think keeping it marketing only is a reasonable choice given it will be sufficient for auto-blocking mode.
Comment #21
a.milkovskyLooks good. What about puting entire message with HTML into a template? The same way as in eu_cookie_compliance.
Comment #22
anybodyWell I think that's a huge disadvantage for users and from my perspective content doesn't belong into template. It would require every page owner / admin to know about theming to change the texts and placeholders.
The text and the placeholders are definitely config, I think and I would suggest to leave this as it is as a good compromise. Anyway, it's just my opinition and I think there is no "real truth" :)
Comment #23
anybodyAny more feedback? Can we set this RTBC and commit to dev?
Comment #24
anybodyNote to myself: Before commit I have to recheck, why these lines were removed and if it was intended or by mistake:
Comment #25
anybodyFinal patch now with correction from #24 and basic CSS for the placeholder message.
Please review and test. This now includes #3098778: Add schema (& translatability) which is also essential for the message to be translatable. This way it will be easier to ship.
Comment #26
anybodyComment #27
anybodyNot my day, I selected the wrong patch, sorry. Now here we go.
Comment #30
anybodyCodesniffer fixes.
Comment #32
anybodyD8 Codestyle fixes and Drupal 7 backport attached.
Comment #33
anybodyComment #35
anybodyD7 version is failing, because it is based on #3100878: Backport important functionality to Drupal 7 which should be committed first. Afterwards we should proceed with the backport here.
Comment #37
anybodyI committed #3100878: Backport important functionality to Drupal 7 to 7.x-1.x so we can now proceed with these improvements / backports to 7.x!
Comment #38
anybodyOk the Drupal 7 version is also ready. The remaining 4 codesniffer entries are OK and intended, because it's a reset for inline styles set. Ready for RTBC! :)
Comment #39
thomas.frobieterComment #42
anybodyCommitted to dev in 7.x and 8.x - thank you all!