- Joomla Version
- 5 und 6
- PHP Version
- PHP 8.4.x
- Hoster
- egal
Das dritte Update in einer Woche.
Keine Angabe ob es sicherheitskritisch ist oder was auch immer.
So kann man auch entwickeln, indem man User als Testkunden nutzt.
Sorry aber es nervt.
Das dritte Update in einer Woche.
Keine Angabe ob es sicherheitskritisch ist oder was auch immer.
So kann man auch entwickeln, indem man User als Testkunden nutzt.
Sorry aber es nervt.
Im Plugin selbst gibt's einen Changelog:
Version 3.3.0
- Neu: Option "Banner im Shadow DOM rendern" (Standard: aus) - das Banner läuft in einem eigenen, von der restlichen Seite abgeschirmten Bereich; Theme-CSS und Banner-CSS können sich nicht mehr gegenseitig beeinflussen
- Neu: Kontrastprüfung im Backend — die eingestellten Bannerfarben werden gegen den gewählten Stil gerechnet, zu geringe Kontraste werden angezeigt
- Neu: Eine geleerte Button-Textfarbe wählt automatisch Schwarz oder Weiß, je nachdem, was besser auf der Buttonfarbe kontrastiert
- Geändert: Die mitgelieferte Cookie-Datenbank wird im Backend nicht mehr als Liste angezeigt; Statuszeile und Aktualisieren-Button bleiben erhalten
- Geändert: Die Backend-Hinweise zur Cookie-Datenbank nennen keine Server-Adresse mehr
- Behoben: Auf Servern mit strengem Sicherheitsfilter ließ sich die Plugin-Konfiguration nicht speichern (Fehler 400) - der Inhalt des CSP-Felds wird für die Übertragung jetzt automatisch verpackt
- Behoben: Der klassische Banner (granulare Einwilligung aus) erscheint jetzt an der eingestellten Position, auch wenn kein Info- oder Impressum-Link hinterlegt ist
- Behoben: Mussten sehr viele fremde Cookies auf einmal gelöscht werden, konnte die Server-Antwort hinter einem Proxy zu groß werden und eine Fehlerseite (502) auslösen; das Löschen verteilt sich jetzt bei Bedarf auf mehrere Seitenaufrufe
- Behoben: Konnte der Aktualisierungs-Zeitpunkt der Cookie-Datenbank nicht gespeichert werden, versuchte das Plugin die Aktualisierung bei jedem Seitenaufruf erneut und bremste die Seite aus; die Aktualisierung wird dann jetzt ausgesetzt
- Barrierefreiheit: Kategorie- und Cookie-Schalter tragen ihre Beschriftung jetzt als echten Text - Prüfwerkzeuge melden keine leeren Beschriftungen mehr
- Barrierefreiheit: Das Banner meldet Rolle, Sprache und Titel bereits im ausgelieferten HTML; die Banner-Überschrift ist eine echte Überschrift
- Barrierefreiheit: Blockierte Einbettungen erhalten automatisch einen Titel mit dem Namen des Anbieters - auch nachträglich eingefügte
- Barrierefreiheit: Die Kategorienliste ist als benannte Gruppe ausgezeichnet; doppelte Tooltips auf den Schaltern entfallen
- Barrierefreiheit: Die Tastaturbedienung im Layout "Stepper" ist durchgehend geschlossen; unsichtbare Bedienelemente werden übersprungen
- Barrierefreiheit: ESC schließt den geöffneten Detailbereich und ein wiedergeöffnetes Banner
- Barrierefreiheit: Der Farbkontrast der Banner-Buttons bleibt beim Überfahren mit der Maus erhalten
- Barrierefreiheit: Die Aufklapp-Pfeile der Kategorien erfüllen die Mindest-Zielgröße für Bedienelemente
- Barrierefreiheit: Eine Ansage-Region meldet Screenreadern das Ergebnis der Cookie-Prüfung, das Speichern und das Nachladen von Einbettungen; hinter dem modalen Banner ist die Seite inaktiv
- Barrierefreiheit: Nach dem Speichern kehrt der Fokus mit einer "Auswahl gespeichert"-Ansage zum Einstellungen-Button zurück
- Barrierefreiheit: Der Essenziell-Schalter ist per Tastatur auffindbar und trägt ein sichtbares "Immer aktiv"-Badge; Cookie-Schalter heißen jetzt "… erlauben" und nennen Beschreibung, Anbieter und Speicherdauer mit
- Barrierefreiheit: Alle Bedienelemente erfüllen die Mindest-Zielgröße, von Besuchern eingestellte Textabstände werden respektiert und im Windows-Kontrastmodus bleiben die Schalterzustände unterscheidbar
- Barrierefreiheit: Alle Stil-Farben (hell und dunkel) sind auf WCAG-AA-Kontraste nachgerechnet und wo nötig angepasst
Alles anzeigen
Denke, nur "schöner wohnen"....
Im Changelog sieht man die Änderungen nur, wenn man bereits das Update gemacht hat.
Schöner wäre es, wenn der Entwickler auf seiner Website über die Änderungen in der Version / dem Update aufklärt.
Im Changelog sieht man die Änderungen nur, wenn man bereits das Update gemacht hat.
Schöner wäre es, wenn der Entwickler auf seiner Website über die Änderungen in der Version / dem Update aufklärt.
Genau das ist das Problem.
Also die neue Version kann ich überhaupt nicht nutzen, da sie nur stupide am Ende der Seite rangepappt wird. Ich müsste einen entsprechenden Override erstellen, damit der Banner auch wirklich "Sticky" ist.
Das nervt und ich will das nicht bei über 80 Seiten machen.
Die alte Version funktioniert nach wie vor noch - sobald man auf die neue geht dann naja.
Darf ich fragen, mit welchem Template (Framework) das passiert?
Mit Cassiopeia stelle ich keine Veränderung im Verhalten fest.
Also die neue Version kann ich überhaupt nicht nutzen, da sie nur stupide am Ende der Seite rangepappt wird. Ich müsste einen entsprechenden Override erstellen, damit der Banner auch wirklich "Sticky" ist.
Das nervt und ich will das nicht bei über 80 Seiten machen.
Die alte Version funktioniert nach wie vor noch - sobald man auf die neue geht dann naja.
Wieso nicht einfach unten in den Fuss ein Link zum öffnen des Banners?
Sticky nervt doch nur und beeinträchtigt kleine Displaygrößen. Ja, der Link ist möglich mit dem entsprechenden Aufruf:
Wieso nicht einfach unten in den Fuss ein Link zum öffnen des Banners?
Sticky nervt doch nur und beeinträchtigt kleine Displaygrößen. Ja, der Link ist möglich mit dem entsprechenden Aufruf:
Sorry falscher Code. Hatte den von einem anderen Cookiebanner verwendet. Richtig muss es so lauten für den Link:
/?cookiehint=set
Das steht aber auch im Plugin beschrieben. Sorry für den falschen Code. Der war für n3tcookieconsent.
Alles funktioniert, nur nicht im Browser mit uBlock Spambot Plugin.
Und gensu dazu hat mir ein dienstbarer Geist ein Plugin geschrieben.
Dieses Plugin ist updatesicher und verändert die Namen der JS Skripte, sodass uBlock nicht mehr meckern kann.
Diese Beschreibung gehört dazu:
The Astroid Framework includes its own Cookie Consent functionality. On some privacy-oriented browsers, the Cookie Consent button may appear but does not work.
The problem can be caused by uBlock Origin, specifically the EasyList – Cookie Notices / Fanboy's Cookiemonster filter list.
For example, uBlock Origin may block the Astroid JavaScript file:
The uBlock Origin logger reports a filter similar to:
from:
The important point is that the script itself is valid and accessible. It is blocked because its filename contains cookieconsent, which is recognized as a cookie-notice script by the filter list.
This can result in the following browser console message:
Loading failed for the <script> with source
"https://example.com/media/astroid/js/cookieconsent.min.js"
The problem may not occur in all browsers. For example, the same Joomla website can work normally in Firefox or Chromium while the Cookie Consent button is broken in a browser using uBlock Origin with the affected filter list.
Instead of modifying the Astroid Framework files, a small Joomla System Plugin can provide the same JavaScript through a neutral URL.
This has two important advantages:
The plugin uses the existing Astroid Cookie Consent JavaScript rather than maintaining a modified copy of it.
The original file remains:
The plugin additionally makes the same file available through a neutral Joomla URL, for example:
Thus the browser receives the same Cookie Consent JavaScript, but uBlock Origin no longer sees the filename cookieconsent.min.js in the requested resource.
A direct modification of:
or of the Astroid source code would work around the problem, but it is not a good long-term solution.
An Astroid update could overwrite the modification.
A separate Joomla System Plugin keeps the workaround independent from the template/framework and therefore makes it update-safe.
The plugin performs the following tasks:
Consequently, when Astroid updates its Cookie Consent implementation, the plugin continues to use the currently installed Astroid file.
No duplicate JavaScript implementation needs to be maintained.
Install the plugin through the Joomla administrator:
System → Install → Extensions
Upload the plugin ZIP package and install it.
Then go to:
System → Plugins
Find:
System – Cookie Consent Fix
and enable it.
After enabling the plugin, clear the Joomla/browser cache if necessary and reload the website.
The problem should be tested with uBlock Origin enabled.
Open the website with:
Open the browser developer tools and check the Network tab.
The Cookie Consent JavaScript should now be loaded through the neutral Joomla URL instead of being blocked because of the cookieconsent.min.js filename.
The Cookie Consent button should then operate normally.
The uBlock Origin Logger is useful for diagnosing this problem.
With uBlock Origin enabled, open:
uBlock Origin → Logger
Reload the website and look for:
A blocked request may look similar to:
This confirms that the request is being blocked by the cookie-notice filter rather than by Joomla, Astroid, the web server, or a missing JavaScript file.
This workaround does not disable uBlock Origin and does not require visitors to create an exception for the website.
It only changes the way the existing Astroid JavaScript is delivered.
The Cookie Consent functionality itself remains the Astroid implementation.
The purpose of the plugin is therefore not to bypass privacy protection in general, but to prevent a legitimate, first-party Cookie Consent script from being incorrectly classified and blocked solely because of its filename.
After installing the plugin, the same Astroid-based website can provide a working Cookie Consent dialog even when uBlock Origin's cookie-notice filters are enabled.
The Astroid Framework remains unmodified, making the solution suitable for websites that receive regular Astroid updates.
Example environment in which the problem was identified:
The exact browser behaviour depends on the installed uBlock Origin filter lists and their current versions.
franke12359 Keine Ahnung was da nicht funktionieren soll.
Wir haben viele Seiten in dieser Kombi und es gibt keine Probleme.
Wäre deine Fehlerbeschreibung genauer als ein Satz, könnte man es vielleicht nachvollziehen:
ZitatAlles funktioniert, nur nicht im Browser mit uBlock Spambot Plugin.
uBlock verhindert das Laden von /media/astroid/js/cookieconsent.min.js
Damit wird verhindert das der OK Knopf wirksam wird und der nervige Hinweis bleibt dauerhaft.
das Plugin benennt für den Browser diese Datei um, sodass uBlock nicht mehr blockiert.
In der englischen Beschreibung darunter wurde alles genau erklärt.
Ohne uBlock funktioniert es auch so, jedoch wissen viele Nutzer nicht das sie diesen Werbeblocker benutzen und für diese ist die Seite dan kaputt.
Ich habe nun bei einer meiner Webseiten (alles Cassiopeia) das Problem auch:
Auf dem Smartphone (Android) wird der Cookie-Dialog unten irgendwo angezeigt.
(Simulieren mit dem Browser klappt nicht)