Offen w3c meldet Fehler

[micon]

Mein JTL-Shop 3 wird mit haufenweise Fehlermeldungen "beschenkt", alle in dieser Art:

Error Line 5, Column 50: end tag for "meta" omitted, but OMITTAG NO was specified
<meta http-equiv="content-language" content="de">
You may have neglected to close an element, or perhaps you meant to "self-close" an element, that is, ending it with "/>" instead of ">"

Es wird die schließende Klammer der Tags bemängelt: "/>" instead of ">"

Obwohl im Template (ich verwende JTL3-Tiny) zum Beispiel in der header.tpl folgendes korrekt steht:
<meta name="copyright" content="{$meta_copyright}" />
Gibt der Shop den fehlerhaften Tag aus:
<meta name="copyright" content="2011 by Tisch und Trend 24">

Und das bei allen Tags, auch >img .... > statt <img .... />, <input ....> statt <input .... /> usw.

Woran kann das liegen?

 

[casim]

AW: w3c meldet Fehler

zu 99,999% an einem Plugin welches pQuery nutzt ... bekannt ... liegt an pQuery ... hinnehmen ... nicht beachten

 

[micon]

AW: w3c meldet Fehler

... hinnehmen ... nicht beachten

Möchte ich aber nicht hinnehmen, sondern korrigieren.
Hat jemand ne Ahnung, welches Plugin das sein könnte und wie der Fehler zu beheben ist?

Ich nutze derzeit folgende Plugins:

Category Classes Aktiviert 1.01
Exportformat Google Base Aktiviert 1.00
iPayment Zahlungsplugin Aktiviert 1.01
JTL Backup Aktiviert 1.02
Smarty Debug Aktiviert 1.00
Template Cache Loescher Aktiviert 1.02

 

[casim]

AW: w3c meldet Fehler

der Fehler kann derzeit nicht behoben werden und 98,7% aller Plugins nutzen die pQuery-Methode

wenn du mit dem "Fehler" nicht leben kannst, dann muss du dich von nahezu sämtlichen Plugins verabschieden

 

[Nento]

AW: w3c meldet Fehler

Gibt es hier schon einen neues Ansatz?
Man muss das doch irgendwie lösen können.

zB wenn Plugin aktiv = \ / oder wie auch immer man ihm sagen kann das er das Zeichen ignorieren soll.
Gibt es hier einen Weiterführen Link?

Danke für's Feedback

 

[casim]

AW: w3c meldet Fehler

der fehler innerhalb pQuery wurde seitens google noch nicht behoben

 

[Nento]

AW: w3c meldet Fehler

Hast du mal nen Link zur Bibliothek jquery !?! pquery
Ajax oder was soll das sein?

 

[casim]

AW: w3c meldet Fehler

phpquery - phpQuery - jQuery port to PHP - Google Project Hosting

bitte schön

 

[Nento]

AW: w3c meldet Fehler

Danke schön 🙂

 

[Kreativkonzentrat]

AW: w3c meldet Fehler

der fehler innerhalb pQuery wurde seitens google noch nicht behoben

Das ist so nicht ganz richtig - unseren Tests nach ist der Verursacher ist hier die PHP-Funktion saveHTML().
Eine Diskussion zum Thema findet man z.B. unter Why doesn't PHP DOM include slash on self closing tags? - Stack Overflow.

Nun gibt es 3 Abhilfen:
1. Ignorieren - stört nämlich nicht.
2. HTML5-Doctype nutzen
3. PHP-Query modifizieren.

Dazu in includes/lib/phpQuery/phpquery.class.php Zeile 760
von

$markup = $this->isXML
     ? $this->document->saveXML()
     : $this->document->saveHTML();

nach

$search = array('/<link([^>]*)>/i',  '/<meta([^>]*)>/i', '/<br([^>]*)>/i',  '/<img([^>]*)>/i', '/<base([^>]*)>/i',  '/<input([^>]*)>/i');
$replace = array('<link$1/>',  '<meta$1/>', '<br$1/>', '<img$1/>', '<base$1/>', '<input$1/>');
$markup = $this->isXML
     ? $this->document->saveXML()
     : preg_replace($search, $replace, $this->document->saveHTML());

ändern. Nicht elegant und natürlich nicht updatesicher, aber funktional. Entfernt aus einem unserer Testshops ca. 50 Validierungsfehler auf der Startseite.

 

[Nento]

AW: w3c meldet Fehler

Ich Danke Dir sehr für's Teilen

Ein dickes fettes DANKE von mir 😉

 

[Kreativkonzentrat]

AW: w3c meldet Fehler

Achso, und die 4. Option:
Tidy-Quellcode-Reparatur aktivieren. Unserer Erfahrung nach macht das aber mehr Probleme als dass es hilft (vor allem mit dem Konfigurator).

 

[casim]

AW: w3c meldet Fehler

Danke Nils,

von Option 4 würde ich auch dringendst abraten ... imho sollte JTL sogar diesen "Schalter" wieder entfernen, denn ich habe ihn mehr mit Fluch wie mit Segen kennen gelernt.

Option 2 denke ich, ist auch nur suboptimal, denn der doctype wird ja zentral in der header.tpl für alle Seiten definiert. Ändert man diesen auf HTML5 und hat dann eine Seite, die nicht durch pQuery überarbeitet wurde aber xHTML-Tags enthält, passt da wieder der doctype nicht.

Option 3 wäre angebracht, wenn dies in ein JTL-Update einfließen würde.

Daher mein persönliches Resümee - Option 1