WB 2.8 Fehlermeldungen (war xhtml strict)

[StudioVerlag]

Wird WB 2.8 xhtml strict erlauben, also zumindest im Core und den mitgelieferten Modulen?
Das Backend und der Editor interessieren in diesem Falle nicht.
Für die wenigen noch verbliebenen WB 2.7-Projekte hatte ich den Eignern die Hoffnung gemacht, daß dies wahrscheinlich so kommen wird. Wenn nicht, muß ich die Inhalte portieren, also weg von WB. In der Ferienzeit könnte ich das noch so nebenbei erledigen. Danach wär's der Horror.
Gruß, Hans>NUL

[ruebenwurzel]

Hallo,

was meinst du damit konkret? Wenn du auf deinen anderen Thread mit dem Form modul anspielst, nein, das form modul ist noch nicht XHTML strict. Alles andere sollte gehen (wie auch schon in WB 2.7). Für Module außerhalb des cores kann ich keine Aussage machen. Aber für das backend wird es möglich sein ein XHTML strict Theme zu entwickeln (wenn denn einer das will).

Matthias

[StudioVerlag]

Nee, auf den alten Thread wollte ich bewußt nicht eingehen.
Habe schon gesehen, daß das Form modul auf 2.9 verschoben wurde.

Nee. bei den gegebenen Projekten werden nur wysiwyg und news genutzt, alles andere sind fremde aber eingebundene eigenständige Anwendungen. Ein Form-Modul wird nicht genutzt.

Wichtig wäre mir, daß wo auch immer z.B. Kommentarfunktionen integraler Bestandteil eines Modules sind (News ?), dort auf jeden Fall Kompatibilität (strict) gegeben sein sollte. Sprich, News=strict, aber im Kommentar dann nicht, das sollte nicht sein. Sonst verlangen die Eigner "die Wende".

Ob's mit dem News-Modul diesbezüglich überhaupt Probleme gab, weiß ich nicht. Es gab und gibt nur die genannte Vorgabe.

Alles andere, wenn irgendwer drauf besteht, läßt sich ja -wenn nötig auch mit Hilfe des Forums- zurechtbiegen.
Gruß, Hans>NUL

Edit: In einem anderen Thread gab's das Thema underscore (show_menu) in CSS.
Soweit ich bisher weiß, spielt es nur wg. Rückwärtskompatibil ität beim IE eine Rolle.
Nach W3C war underscore am Anfang gemeint, was aber mit underscore innerhalb eines Begriffs wohl nix zu tun hat, auch wenn mein Validator kreischt.
<edit> Vielleicht geht's auch über ein "CSS Redefine" -NOCH keine Ahnung </edit>
Habe mich bisher noch nicht entsprechend informiert, also alles noch "ungelegte Eier"

[StudioVerlag]

Edit 2: Mit dem "Andenken" des underscore-Problems gab es 'ne kleine Recherche.
Um keinen neuen Thread aufzumachen ein paar Stichworte:
+CSS +redefine
+"css preprocessor"
Man kann also nützliche und flexible Brücken bauen.
Gruß, Hans>NUL

[ruebenwurzel]

Hallo,

RC1 wird innerhalb der nächsten Tagen (vielleicht sogar Stunden  ) veröffentlicht. Am besten du testest es dann gleich (im speziellen news mit comment halt), wenn es da was zu fixen gibt kann das ja bis zum Final noch gemacht werden. Oft sind es ja nur Kleinigkeiten.

Matthias

[StudioVerlag]

Mache ich gern und sowieso 
Ihr habt ja noch mit "Styling TEXT_READ_MORE not allowed nor page CSS settings" zu tun 
Besser noch ein paar Tage warten (da kommt's jetzt auch nimmer drauf an), als zu böse Überraschungen erleben.
Gruß, Hans>NUL

[chio]

Gruß, Hans>NUL

Mich irritiert immer, dass dein Nick "Hans>NULL" lautet, du aber unter deine Posts häufig "Hans>NUL" schreibst. Bist du schizophren? Oder willst du das Forum überlisten?

Falls du _nicht_ zwei Personen bist, würde ich dich bitten, in Zukunft GANZ GENAU auf die Schreibweise zu achten und vor allem deinen Nick richtig und valid zu schreiben.
Sonst bin ich verwirrt.

[StudioVerlag]

Bin noch nicht beim Testen von Modulen. Erstmal "nacktes" Template ohne css.
Sehe ein Problem, wenn auch nicht 2.8 spezifisch
und zwar einen Konflikt zwischen Barrierefrei und xhtml (hier nicht mal strict):
über
register_frontend_m odfiles
wird ein JS eingebunden, anscheinend aber ohne <NOSCRIPT>
------------ so scheint's zu klappen ------------------
<?php    if(function_exists('register_frontend_m odfiles')) {
    register_frontend_m odfiles('css');
    register_frontend_m odfiles('js');
echo    "<noscript> </noscript>";
} ?>
------------- ergibt für die Droplets --------------------
<script type="text/javascript" src="http://127.0.0.1:4001/wb28rc1/modules/droplets/js/mdcr.js"></script>
<noscript> </noscript>

Soweit so gut, wird aber vom Validator bemängelt, da <noscript> dort (HEAD) nix zu suchen hat.

<edit>
Die einzige Lösung scheint zu sein. zukünftig den JS-Part nicht mehr im HEAD "auszulagern".
Das Laden erst zu Ende der Seite habe ich nicht geprüft.
</edit>
Gruß, Hans>NUL (Hans>NULL)

[Ruud]

So let me understand this right..

You use a template, in strict mode, where you code some errors in the template, and then you report the errors?

Ruud

[StudioVerlag]

in strict mode

Currently xhtml-Transitional

The validator accepts no <noscript> in <Head>
WAI  (Accessibility) requires <noscript>

Regards, Hans>NUL

[Ruud]

But this is a problem between different validators, different definitions, different rules.

We could have a try, but I am afraid WebsiteBaker cannot solve that problem. 

Ruud

[StudioVerlag]

The My only solution: js is not in the head position
Regards, Hans>NUL

Edit: So ist es z.Z. gelöst

Code: [Select]

 <?php    if(function_exists(&#39;register_frontend_modfiles&#39;)) {
    register_frontend_modfiles(&#39;css&#39;);
} ?>
</head>
 <body>
  <?php    if(function_exists(&#39;register_frontend_modfiles&#39;)) {
    register_frontend_modfiles(&#39;js&#39;); 
echo    "<noscript> </noscript>";
} ?>
Schauen wir mal, ob es je nach Konstellation noch Probleme gibt. Bisher funktioniert's

Edit2:
<noscript> außerhalb des HEAD zu setzen und JS im Head zu lassen soll auch erlaubt (W3C) sein. Habe es aber noch nicht getestet, ob das in WB funktioniert.

[StudioVerlag]

modules/news/frontend.css
Validator für Barrierefreiheit jammert:
The text size is fixed by "font-size:(CSS).

Für Barrierefreiheit ist normalerweise EINE CSS für die Ausgabe zuständig, also kein Problem, sondern nur eine Aufgabe.
Stellt sich die Frage beim NEWS-Module (frontend.css), wie handhaben, daß es nicht in eine persönliche Lösung/Anpassung mündet?
Gruß, Hans>NUL

[StudioVerlag]

 News-Modul
 
 Add.php
 <td rowspan="3" style="display: [DISPLAY_IMAGE]"><img src="[GROUP_IMAGE]" alt="[GROUP_TITLE]" /></td>
 Betrifft; img src="[GROUP_IMAGE]"
 Existiert kein Gruppen-Image zeigt der Validator "" als fehlerhaft an. (Für alt trifft das in der Regel auch zu)
 Lösung If kein Inhalt, dann auch keine Ausgabe --oder so ?  
 
 Add.php oder/und modify_post.php
 Die Zeichen >> machen Probleme (unerwartete Zeichen) müssen wohl weg  
Triit auf bei, html-Output:
<tr style="display: none">
<td valign="top"><a href="http://127.0.0.1:4001/wb28rc1/pages/home.php">Heimatseite</a> >> <a href="http://127.0.0.1:4001/wb28rc1/pages/home.php?g=0"></a></td>
</tr>
 
 
 Ein weiterer HTML-Output:
 <h2>Kommentare</h2>
<table cellpadding="2" cellspacing="0" border="0" width="98%">Keine gefunden<br /></table>
Das <br /> innerhalb der Tabelle scheint nicht erlaubt

Das Ganze ist bei Ansicht der kompletten News (>Weiterlesen) sichtbar.
Getestet wird mit "nacktem" Template ohne irgendeine Standard-CSS,
und noch unter Transitional.

Gruß, Hans>NUL

[ruebenwurzel]

Hallo,

Ein weiterer HTML-Output:
 <h2>Kommentare</h2>
<table cellpadding="2" cellspacing="0" border="0" width="98%">Keine gefunden<br /></table>
Das <br /> innerhalb der Tabelle scheint nicht erlaubt

Das Problem ist nicht das <br />. Es fehlt da einfach innerhalb des <table>... </table> die notwendigen <tr><td>....</td></tr>.

Das ist tatsächlich ein kleiner bug in der view.php, der aber schnell behoben sein dürfte. Das wird in RC2 gefixt sein.

Add.php
 <td rowspan="3" style="display: [DISPLAY_IMAGE]"><img src="[GROUP_IMAGE]" alt="[GROUP_TITLE]" /></td>
 Betrifft; img src="[GROUP_IMAGE]"
 Existiert kein Gruppen-Image zeigt der Validator "" als fehlerhaft an. (Für alt trifft das in der Regel auch zu)

Auch das sollte machbar sein. Wird aber auch besser durch die view.php gefixt. Hier kann man sowohl für das Bild als auch für das alt tag ja einen alternativen Wert (noimage.jpg oder sonstwas) angeben.

Die Zeichen >> machen Probleme (unerwartete Zeichen) müssen wohl weg  huh
Triit auf bei, html-Output:
<tr style="display: none">
<td valign="top"><a href="http://127.0.0.1:4001/wb28rc1/pages/home.php">Heimatseite</a> >> <a href="http://127.0.0.1:4001/wb28rc1/pages/home.php?g=0"></a></td>
</tr>

Das kann ich nicht nachvollziehen. Scheint ein Problem deines Validators zu sein.

Grundsätzlich sind das aber alles Dinge, die auch schon in WB 2.7 so vorhanden waren. Erstaunt mich, dass das jetzt erst auf den Tisch kommt. 

Matthias

[susigross]

Das kann ich nicht nachvollziehen. Scheint ein Problem deines Validators zu sein.

Sinnvoll wäre schon , statt > &gt; zu schreiben.

Grundsätzlich sind das aber alles Dinge, die auch schon in WB 2.7 so vorhanden waren. Erstaunt mich, dass das jetzt erst auf den Tisch kommt.  grin

Also ohne polemisch zu werden, aber nachdem ich die Erfahrung gemacht habe, welcher Aufwand es manchmal ist, einen Bug so überzeugend zu dokumentieren, dass er gefixt wird, habe ich das auch stecken gelassen.
Man hat halt gehofft, das die Entwickler das schon selbst sehen werden, wenn sie eh den Code überarbeiten.

[ruebenwurzel]

Hallo,

Sinnvoll wäre schon , statt > &gt; zu schreiben.

Tja ein Blick in die view.php schafft Aufklärung  . Da steht &gt; drin. Deswegen kann ich es ja nicht nachvollziehen. Kann ja auch sein, dass der Validator einen Fehler hat. Diesen Teilen, egal welche man nutzt, wird blind unterstellt, dass sie fehlerfrei sind. Erstaunlich nur, dass sie oft unterschiedliche Ergebnisse auswerfen.

Lieber versuchen sauber zu programmieren halt ich für die bessere Lösung, wenn dann die validatoren auch noch mitspielen, um so besser. Aber eine Programmierung nur aus dem Ergebnis eines Validators abzuleiten damit überbewertet man diese Teile eindeutig.

Man hat halt gehofft, das die Entwickler das schon selbst sehen werden, wenn sie eh den Code überarbeiten.

Ehrt mich, dass du soviel Vertrauen in die Entwickler hast. Leider ist es in der Praxis etwas anders. Aber wenn das nichtmal tausenden Usern bisher aufgefallen ist, wie sollen es dann ausgerechnet den paar wenigen Entwickler ins Auge springen.

Matthias

[WebBird]

Add.php oder/und modify_post.php
 Die Zeichen >> machen Probleme (unerwartete Zeichen) müssen wohl weg  
Triit auf bei, html-Output:
<tr style="display: none">
<td valign="top"><a href="http://127.0.0.1:4001/wb28rc1/pages/home.php">Heimatseite</a> >> <a href="http://127.0.0.1:4001/wb28rc1/pages/home.php?g=0"></a></td>
</tr>

Äh, wo steht'n des?

Edit: In der add.php steht in Zeile 57 tatsächlich das hier:

<td valign="top"><a href="[BACK]">[PAGE_TITLE]</a> >> <a href="[BACK]?g=[GROUP_ID]">[GROUP_TITLE]</a></td>

Also nix &gt;

Trunk ... äh ... hab ich vergessen.

[WebBird]

Gehört hier eigentlich nicht her, aber da ruebi hier mitliest...

Ich krieg' in der Einstellung E_ALL+STRICT die Meldung:

Strict Standards: date() [function.date]: It is not safe to rely on the system's timezone settings. Please use the date.timezone setting, the TZ environment variable or the date_default_timezo ne_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Paris' for '2.0/DST' instead in C:\_daten\apache\htdocs\_projects\wb28\include\jscalendar\wb-setup.php on line 50

Ticket aufmachen?

[ruebenwurzel]

@webbird

falsch ich jetzt quatsch rede bitte ignorieren. Gibt es da nicht Unterschiede in verschiedenen PHP Versionen bezüglich date...

Ticket aufmachen?

besser ist das, da wird es schon nicht vergessen und die devs können sich das mal genauer anschauen.

Matthias

[WebBird]

Also ohne polemisch zu werden, aber nachdem ich die Erfahrung gemacht habe, welcher Aufwand es manchmal ist, einen Bug so überzeugend zu dokumentieren, dass er gefixt wird, habe ich das auch stecken gelassen.

Aus eigener Erfahrung als Entwickler: Ganz oft (eigentlich fast immer *g*) fehlen bei den ersten Fehlermeldungen einfach die genauen Informationen, wie man den Fehler reproduzieren kann. Und je komplexer die Anwendung, desto mehr Möglichkeiten gibt es ja, sie zu verwenden.

Der Entwickler testet in der Regel den Weg, den er vorgesehen hat, und in der Umgebung, die er halt hat. Das bedeutet ja nicht zwangsläufig, daß auch der Anwender die Anwendung exakt so benutzt oder exakt die Umgebung hat. (Dann würde es ja funktionieren.)

Je genauer also die Beschreibung, was zu tun ist, um den Fehlerfall zu bekommen, desto besser. Also z. B. "Nach dem Hinzufügen des Moduls auf X, dann auf Y klicken. Wenn man nun im Feld XY 'bla' eingibt, bekommt man die Fehlermeldung 'pfui'."

Rückfragen und Antworten wie "Sorry, aber ich kann das Problem nicht nachvollziehen" entstehen ja nicht aus purer Gehässigkeit des Entwicklers.

[WebBird]

Gibt es da nicht Unterschiede in verschiedenen PHP Versionen bezüglich date...

Bestimmt. Aber das ist jetzt PHP5, da sollte das doch mit 2.8...

Is' aber auch nur mit STRICT.

Ich mach'n Ticket auf.

Edit: Ticket #741

[susigross]

Gehört hier eigentlich nicht her, aber da ruebi hier mitliest...

Ich krieg' in der Einstellung E_ALL+STRICT die Meldung:

Strict Standards: date() [function.date]: It is not safe to rely on the system's timezone settings. Please use the date.timezone setting, the TZ environment variable or the date_default_timezo ne_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Paris' for '2.0/DST' instead in C:\_daten\apache\htdocs\_projects\wb28\include\jscalendar\wb-setup.php on line 50

Ticket aufmachen?

Also in der WB 2.7 betraf das vielleicht 20 Kernel-Dateien. Man sollte eigentlich erwarten, daß die Entwickler ihr Produkt mal mit eingeschalteter Fehlerüberwachung laufen lassen, bevor sie es auf die Menschheit loslassen 

[StudioVerlag]

Zur Erinnerung, "ruebenwurzel" hatte mich gebeten zu testen (News),
Beschränkt ist der Test auf Core mit den Modulen wysiwyg und news (ausgenommen Form etc)

Bei Unklarheiten werde ich Fehler auf Reproduzierbarkeit testen. Sollte es Fehlinterpretatione n oder zu unterschiedlichen Ergebnissen durch die  Prüfmittel (Validator) kommen, bekommen wir das wenn nötig auch zusammen (Forum)  in den Griff.

Warum einige Dinge erst jetzt auffallen hat WebBird schon geäußert.
Ich selbst versuche nur etwas systematisch zu prüfen und weil's eben WB2.8 ist, was ein Meilenstein werden sollte -naja und weil ich hoffe, daß ich nicht die ganzen Domains umschrauben muß (Drohuing im Hintergrund)

@ruebenwurzel
Ich gucke mir alles nochmal heute abend und morgen früh an.

Gruß, Hans>NUL

Edit: Wie man sieht betreffen einige Dinge nicht xhtml-strict, sondern gehören eigentlich nach Wb2.8 RC1.
Da aber bei der Fehlersuche "aufbohren" angesagt ist, kommt man wohl nicht um ein schrittweises Vorgehen herum.

Geprüft wird mit unterschiedlicher html/css Softw. bzw. Diensten. Dabei wird nach Prüfung der html/css - Eigenschaften eine Prüfung nach WAI usw. vorgenommen. So sieht man dann auch, ob ein Fehler möglicherweise schon länger (wb2.7 xhtm-transitional) existiert.

[Ruud]

Gehört hier eigentlich nicht her, aber da ruebi hier mitliest...

Ich krieg' in der Einstellung E_ALL+STRICT die Meldung:

Strict Standards: date() [function.date]: It is not safe to rely on the system's timezone settings. Please use the date.timezone setting, the TZ environment variable or the date_default_timezo ne_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Paris' for '2.0/DST' instead in C:\_daten\apache\htdocs\_projects\wb28\include\jscalendar\wb-setup.php on line 50

Ticket aufmachen?

Also in der WB 2.7 betraf das vielleicht 20 Kernel-Dateien. Man sollte eigentlich erwarten, daß die Entwickler ihr Produkt mal mit eingeschalteter Fehlerüberwachung laufen lassen, bevor sie es auf die Menschheit loslassen 

This message is caused by a bad setting (non setting) in your PHP.INI.
If you define your timezone in there, PHP is happy.
Now PHP is not sure where you are (default there is no timezone set, and the machines timezone setting is used)m and it is just informing you about that.
Correct your PHP configuration, and the "errors" will disappear.

Ruud