n3t Cookie Consent beeinflusst Ausgabe von Template custom.css im <head>?

    Joomla Version
    6
    PHP Version
    PHP 8.4.x
    Hoster
    egal

    ich verwende auf einer Joomla-6.1.2-Website das n3t Cookie Consent Plugin zusammen mit Astroid Framework und dem Template tp_power.

    Mir ist aufgefallen, dass das Aktivieren von n3t die Ausgabe einer Template-CSS-Datei im HTML-Head verändert.

    Mit aktiviertem n3t wird ausgegeben:

    <link href="/media/templates/site/tp_power/css/custom.css?3.4.3"
    rel="stylesheet" type="text/css" />

    Wenn n3t deaktiviert wird, verschwindet diese Zeile vollständig aus dem HTML-Quelltext.

    Die Datei selbst gehört zum Template und wurde von mir nicht über n3t eingebunden.

    Ich habe außerdem die Reihenfolge der System-Plugins getestet. Auch wenn Astroid vor n3t bzw. n3t vor Astroid ausgeführt wird, bleibt das Verhalten unverändert.

    In den erweiterten n3t-Einstellungen sind folgende Felder leer:

    • Benutzerdefinierte Stile
    • Skript initialisieren
    • Geladenes Skript
    • Erstes Aktionsskript

    Meine Frage: Kann n3t Cookie Consent die Joomla-Ausgabe bzw. Registrierung von Template-Assets wie custom.css beeinflussen? Falls ja, wodurch und ist dieses Verhalten bei Joomla 6 vorgesehen oder warum ist es so?

    Ich habe auch im Forum bei n3t die Frage gestellt. Hier der Link zur Nachverfolgung für alle die n3t nutzen:

    n3t Cookie Consent affects custom.css output in Joomla6 | n3t Joomla! works support forum
    Hello, I am using Joomla 6.1.2 with the Astroid Framework and the tp_power template. I noticed a strange behavior when the n3t Cookie Consent plugin is…
    n3t.boards.net
    Zitat von Stef

    Funktioniert es mit dem Cassiopeia?
    Was sagt denn der Astroid-Framework Support?

    Muss ich testen. Wenn es dort nicht passiert melde ich noch an den Astroid Support.

    Gerade getestet. Es verhält sich bei Cassiopeia genauso.

    Stef Danke für den Tipp. Hatte es mit Cassiopeia tatsächlich nicht ausprobiert.

    Bei 6.1.3 ist es auch so. Was mich einfach wundert ist, dass die custom.css in den Quelltext geladen wird. Das ist bei Cassiopeia nicht der Fall aber da greift ja auch die user.css. Somit ist es bei Cassiopeia wieder anders.

    Dieser Beitrag (nur dieser) wird auf meinem Firefox als gefährlich eingestuft:

    Diese Seite wurde blockiert, da sie möglicherweise unsicher ist. Das Ziel der Weiterleitung ist unbekannt und könnte ein Sicherheits- oder Datenschutzrisiko darstellen: n3t Cookie Consent beeinflusst Ausgabe von Template custom.css im <head>? Zu deiner Sicherheit hat Ghostery diese Seite automatisch blockiert.

    -OJ- Danke aber so machen wir das im Astroid Team nicht. Deine Anpassungen oder Änderungen solltest du ausführlich beschreiben (like Github). Hierzu ist eine Gegenüberstellung beider php Dateien mit den markierten Änderungen üblich. Einfach blind hier eine Datei (ohne dir zu nahe treten zu wollen) auszutauschen ohne weiter Angaben, ist nicht zielführend. Klar könnte ich jetzt beide 1:1 vergleichen aber du hast doch die Änderungen direkt und ersparst anderen die Suche.

    Nett gemeint aber bitte versteh mich an der Stelle auch.

    Falls du davon ausgehst, dass es sich um einen Astroid Bug handelt, dann solltest du dies auch bei Github melden. Wobei ich das dann auch gerne für dich übernehme. Da dies aber lediglich bei net auftritt und in SEO relevante Dinge eingreift, sehe ich hier erst mal keinen Handlungsbedarf in Sachen Astroid.

    Wie siehst du das?

    WM-Loose Ich habe zurzeit keine Installation mit Astroid zur Verfügung, auf der ich das direkt testen kann. Das Verhalten kam mir aber von einer anderen Sache bekannt vor. Deshalb habe ich mir die Dateien von n3t Cookie Consent 4.5.1 und Astroid Framework 3.4.3 einmal angesehen und bin dabei in Astroids Document.php fündig geworden.

    Die ausgegebene Datei

    HTTP
    <link href="/media/templates/site/tp_power/css/custom.css?3.4.3" ...>

    kommt eindeutig aus Astroid, nicht aus n3t.

    Astroid prüft in Document.php innerhalb von astroidCustomCSS(), ob eine custom.css vorhanden ist. Diese wird allerdings nicht über den normalen Joomla WebAssetManager eingebunden, sondern über Astroids eigenes addLink() -System und später über den Astroid-Renderprozess ausgegeben. n3t greift seinerseits bei onBeforeCompileHead() in die Head-Verarbeitung ein und lädt dort eigene CSS-/JS-Dateien sowie Inline-CSS. Zusätzlich wird bei onAfterRender() noch einmal der fertige HTML-Body bearbeitet.

    Mein Verdacht ist daher, dass n3t die custom.css nicht selbst lädt, sondern durch seine Head-/Render-Verarbeitung einen Astroid-Codepfad bzw. Dokumentzustand beeinflusst, durch den die bereits von Astroid registrierte custom.css ausgegeben wird. Ich habe deshalb lediglich den entsprechenden Bereich in der Document.php angepasst und die Datei zum Testen zur Verfügung gestellt. Statt Astroids eigenem

    PHP
    $this->addLink(
    $this->_systemUrl('css/custom.css') . '?' . Helper::frameworkVersion()
);

    wird die custom.css testweise direkt über den Joomla WebAssetManager registriert:

    PHP
    $this->getWA()->registerAndUseStyle(
    'astroid.custom',
    $this->_systemUrl('css/custom.css', false),
    ['version' => Helper::frameworkVersion()]
);

    Damit läuft die custom.css nicht mehr über Astroids eigenen späten addLink() - -Mechanismus, sondern über die normale Joomla-Asset-Verarbeitung.

    Mehr hatte ich bei der Bereitstellung der Datei zunächst auch nicht dazu geschrieben. Das war schlicht aus Zeitgründen so und sollte in erster Linie ein Test sein, ob genau diese Stelle mit dem Verhalten zusammenhängt. Wenn die custom.css mit dem Patch unabhängig davon geladen wird, ob n3t aktiviert oder deaktiviert ist, wäre das ein Hinweis auf eine Wechselwirkung zwischen Astroids eigenem CSS-Rendering und Joomla/n3t.

    Der Patch ist deshalb ausdrücklich erst einmal als Test bzw. Diagnose gedacht und nicht als bereits bestätigte endgültige Lösung. Also bitte testen...

    Zitat von WM-Loose

    Wie siehst du das?

    Also, ein direkter Bug, den man jetzt schon so melden könnte, ist das meiner Meinung nach noch nicht. Zuerst müsste überhaupt getestet werden, ob die Änderung in der Document.php das Problem tatsächlich löst.

    Mit dem Satz „Da dies aber lediglich bei net auftritt und in SEO relevante Dinge eingreift, sehe ich hier erst mal keinen Handlungsbedarf in Sachen Astroid.“ kann ich ehrlich gesagt nichts anfangen. Meinst du mit „net“ die TLD .net oder war etwas anderes gemeint?

    Ansonsten sehe ich es natürlich auch so, dass man nicht einfach blind irgendwelche Dateien installieren oder überschreiben sollte. Ich hatte dich allerdings für erfahren genug gehalten, mit so einer Testdatei entsprechend vorsichtig umzugehen, also vorher ein Backup zu machen und das Ganze nur testweise einzusetzen. Wie schon gesagt: Ich kann es zurzeit selbst nicht testen, weil ich aktuell keine Installation mit dem Astroid Framework zur Verfügung habe. Deshalb ist die angepasste Datei auch ausdrücklich nur als Test gedacht, um zu prüfen, ob genau diese Stelle mit dem Verhalten zusammenhängt.

    -OJ- Danke dir.

    ich werde das prüfen.

    Bin aber der Meinung, dass eine Cookie Erweiterung in der Form nicht ins System eingreifen sollte.

    Wir werden mit ziemlicher Sicherheit wegen n3t hier keine raumgreifenden Änderungen im Astroid Framework durchführen, da es genug alternative Erweiterungen gibt, bei denen dieses Problem nicht auftritt. Eventuell wäre es dann sinnvoller im Astroid selbst geeignete Cookie Funktionalitäten zu integrieren. Mal schaun...

    Die vorhandenen Möglichkeiten sind ja schon integriert aber man muss es wirklich noch erweitern, denn das was da ist, ist echt zu wenig:

    Cookie Consent | Astroid Framework
    The Cookie Consent feature in Astroid Framework allows you to display a notification banner informing users about cookie usage and collecting their…
    docs.astroidframe.work

    Nochmals danke für die ausführliche Analyse.