Fehler statt Inhalt: "missing head area"

WebsiteBaker Support (2.13.x) > Hilfe & Support (deutsch)

<< < (3/3)

sternchen8875:
da ist kein Fehler zu sehen - wäre auch zu einfach gewesen :-(

Da du offensichtlich nicht möchtest, das jemand direkt und live drauf schaut, hab ich mir den Filter noch mal angeschaut. Vielleicht hilft dir das bei der Problemsuche

Der Outputfilter startet bei jedem Klick im Frontend, alles, was dort ausgegeben werden soll, muß diese Filter einmal durchlaufen. Dabei werden dann z.b. Mailadressen verschlüsselt, WbLinks aufgelöst oder Droplets abgearbeitet.
Der Filter CSStoHead sucht in der gesamten Ausgabe nach Codezeilen, die einen Link enthalten zu Dateien, die über diese Methode eingebunden werden, also nach der Kombination (\<link[^>]*?"(text\/css|stylesheet)"[^>]*?\/?\> oder eben nach einem abgeschlossenem style-Block, also <style[^>]*?\>.*?\<\/style\>, aber eben keine Inline-Style's

Findet er solchen Code in der Ausgabe, möchte er ihn in den Head-Bereich verschieben, wo er lt. Definition eben hingehört. dazu sucht der Filter die Struktur der index.php des genutzten Templates durch, wo es zwei mögliche Bereiche gibt, 1: innerhalb von <head></head>, dann 2. innerhalb von <body></body>
Jeder mögliche Treffer sollte dann direkt in die Zeile vor dem schließendem </head> geschoben werden.

Findet er aber diese zwei Bereiche nicht, weil z.b. die Code-Struktur der geplanten Ausgabe dieses unmöglich macht, erscheint der o.g. Fehler "malformed document created, missing head area", heißt: der Filter findet das schließende </head> nicht.

Ursachen dafür sind vielfältig, die einfachste und verständlichste Variante wäre das Einlesen einer zweiten Datei, die ebenfall eine HTML-Seitenstruktur aufweist. Eine andere Möglichkeit wäre die Verwendung von Uralt-Modulen oder Uralt-Droplets. Früher war es nämlich üblich, Links z.b. zu CSS-Dateien direkt in die Ausgabe eines Moduls zu schreiben. Stammt aus Zeiten, wo es die Funktion register_frontend_c ss() noch nicht gab. Gilt dann analog für Droplets.

Und dann wäre eben noch die Validität der Ausgabe. Jeder kennt es, jeder hat es schon mal gesehen: hab ich einen Syntax-Fehler in meinem Template (und das schließt die Ausgabe einzelner Blöcke mit ein, erscheint mein Inhalt oder auch nur eine Fehlermeldung an völlig anderer Stelle, abhängig vom Abbruch mal ganz oben oder ganz unten, aber oft eben "out of content" und damit außerhalb von <head> oder von <body>. Gutes Beispiel sind deine Validierungen, die auf nicht geschlossene Div's in Folge des Scriptabbruches hinweisen.
Je nach Stelle hat man dann auch mal zwei <head>-Bereiche

Als "Profi" hab ich nun meine Methoden, nach solchen Stellen zu suchen, die haben aber auch das Risiko, die gesamte webseite zu zerschießen, wenn sie falsch angewandt werden. Haben aber auch den Vorteil, das die Ursache in kürzester Zeit gefunden werden kann, ich denk, ich bräuchte keine 5 min mit einer Live-Ansicht, um das Problem zu finden.

Als Laie würde ich jetzt die Newsbeiträge deaktivieren. Zuerst das gesamte NewsModul über die Zeitsteuerung deaktivieren (Eingabe eines Datums aus der Vergangenheit in der Sektion-Verwaltung dieser Seite. Dann probieren

Lt Code der index.php des Templates verwendest du eine Abfrage auf Content im Block2. Lt Quellcode der Fehlerseite wird solch Block2 auch genutzt. Diesen Inhalt mal dem Block1 zuweisen (gleiches Bild). Auch wieder probieren.

Wird in einem der beiden Test's der Rest des Content angezeigt, ist der Fehler eingekreist, entweder auf das News-Modul oder auf den Code des Block2

Ist nun das News-Modul der auslöser, kannst du nach und nach jeden News-Beitrag inaktiv schalten. Einer davon wird das Problem auslösen (denk ich)

hgs:

--- Quote from: sabo-! on August 14, 2023, 04:05:13 PM ---Hallo Diemar,

vielen Dank für Deine Antwort.
Möchtest Du über PN einen Login zur Website, um Dir das anzusehen?

Viele Grüße
Sabo

--- End quote ---

Ich vermute dass ist überlesen worden, also sabo-!

eine PM an sternchen8875

und das Problem ist schnell erkannt und gebannt.

sternchen8875:
PM ist angekommen, Problem ist gesehen und erkannt - PHP-Version und Code passen nicht zusammen

einfachste Lösung wäre das Hochsetzen der PHP-Version auf PHP 8.1.x. Vielleicht kannst du das kurzfristig arrangieren.

P.S.: die neueste WB-Version 2.13.4 ist ein paar Stunden vor dem Release. Die läuft dann mit allen PHP 8.2er Versionen.
Wenn du mir die FTP-Zugangsdaten zukommen läßt, würde ich dieses Upgrade dann gleich mit erledigen, aber dann sollte es schon eine PHP 8.2.x sein

Navigation

[0] Message Index

[*] Previous page

Go to full version