WB 2.8 Fehlermeldungen (war xhtml strict)

[WebBird]

I use the default settings if possible. So this setting is missing by default.

Maybe WB should check required settings instead of letting PHP throw errors.

[ruebenwurzel]

Hallo,

http://www.php.net/manual/de/datetime.configuration.php#ini.date.timezone

Also so wie ich das sehe ein PHP 5.1 aufwärts problem, wenn in der php.ini kein Wert für date.timezone gesetzt ist. Das hat also mit WB schon mal gar nix zu tun, noch dazu weil WB 2.8 folgende Mindestvoraussetzun g hat:

WebsiteBaker 2.8 will run under PHP 4.4.9 as minimum requirement, but PHP 5.2 is strongly recommanded.

Über was man aber nachdenken sollte wäre das ersetzen von mktime() durch time() in der time_formats.php und der date_formats.php. Kann jemand von den php gurus da mal drüberschauen, ob das irgendwelche negative Auswertungen hat?

Dadurch läuft WB bei korrekt konfigurierter (also mit Wert bei date.timezone) php 5.1 (und größer) version sogar mit E_ALL + STRICT ohne Fehlermeldungen.

Matthias

[aldus]

hm ... dann kann man es auch gleich endstauben  ...

Code: [Select]

<?php
$mktime = time()+ ((isset($user_time) AND $user_time == true) ? TIMEZONE : DEFAULT_TIMEZONE);
Hm ... irgendwie stört mich das die Variable genauso heisst wie die Funktion ...

Hm ... bliebe noch die wb-setup.php von jscalendar ...

Gruß
Aldus

[WebBird]

Also so wie ich das sehe ein PHP 5.1 aufwärts problem, wenn in der php.ini kein Wert für date.timezone gesetzt ist. Das hat also mit WB schon mal gar nix zu tun, noch dazu weil WB 2.8 folgende Mindestvoraussetzun g hat:

Meine Meinung dazu ist: Wenn man einen Fehler unterbinden kann, sollte man es tun - auch dann, wenn man eigentlich gar nicht "Schuld" ist. Zumal Fehlermeldungen ja nur irritieren, von der abschreckenden Wirkung bei Neulingen mal ganz zu schweigen. ("Ich hab das Ding installiert und wurde gleich mit Fehlermeldungen überfallen, nee laß mal...")

Jaaa, ich weiß, in diesem Fall tauchen die Meldungen nur mit STRICT auf... aber dafür ist die Lösung auch ganz einfach. Halt gucken, ob die Einstellung in der PHP.ini vorhanden ist, ansonsten passend setzen. Ist 'ne geringfügigere Änderung als alle Vorkommen von date() und mktime() zu überarbeiten. (Es sei denn, man will das ohnehin tun.)

Die Mindestvoraussetzun g ist da IMHO keine Ausrede, weil wir von einer NEUEREN PHP-Version sprechen, und nicht von einer ÄLTEREN. Wenn jetzt die Meldung mit 4.4.5 gekommen wär, okay... aber sie kommt mit einer 5.2.5 Standardinstallatio n (unter Windows). Also da find ich dann schon, daß man da was machen sollte.

[Ruud]

Über was man aber nachdenken sollte wäre das ersetzen von mktime() durch time() in der time_formats.php und der date_formats.php. Kann jemand von den php gurus da mal drüberschauen, ob das irgendwelche negative Auswertungen hat?

No, on this page it actually is only used to present the current time in the selection list for date end time formats.
I tried, and time() works fine in there.

PS: this is an open bug in PHP. Calling mktime without parameters is generating a strict error: http://bugs.php.net/bug.php?id=47084

Ruud

[Ruud]

....Halt gucken, ob die Einstellung in der PHP.ini vorhanden ist, ansonsten passend setzen....

To what value would you suggest to set it?

Europe/Berlin
Europe/Amsterdam
Australia/Perth
Asia/Kathmandu
Antarctica/South_Pole
or....

[WebBird]

Of course, a default can't respect all possible settings. But I think it's better so set the timezone to GMT or something, maybe depending on the current locale, than letting PHP throw a bunch of error messages.

Edit: I think the TZ setting is not really important in most cases where mktime() and date() are used.

[susigross]

To what value would you suggest to set it?

Set it to the same value as it is set in the backend in Settings - Default settings - Timezone

[ruebenwurzel]

Hallo,

was ist denn das schon wieder für ein Sprachenwirrwarr  

Also um sich seinen Server mit php 5.1 aufwärts korrekt einzustellen genügt eine Zeile in der .htaccess

Code: [Select]

php_value date.timezone 'Europe/Berlin'
Die kann sich ja jeder setzen wie er will. Problem gerade bei billighostern kann ja auch sein, dass der Server gar nicht in der TZ steht (USA) in der die Seite veröffentlicht wird (Europa). Kann also sein, dass trotz gesetztem Wert in der php.ini die TZ nich passt. Da muss man dann sowieso eine Anpassung per .htaccess machen, oder seh ich das falsch.

Wenn wir jetzt noch mktime() durch time() ersetzen (wird nur in den zwei oben genannten Dateien eingesetzt im core) dann herscht sogar bei E_ALL&STRICT Ruhe.

Das sollte doch machbar sein oder.

Matthias

Edit: und schon erledigt, danke aldus http://project.websitebaker2.org/changeset/1059

[aldus]

Nächste Runde ...
Bei "wb/include/jscalendar/wb-setup.php" sollte es mit "gmdate" anstatt "date" gehen ... Zeile 50 ...

Code: [Select]

<?php
    // today
    $jscal_today = gmdate(&#39;Y/m/d&#39;);

Da bei mir lokal eh nicht gemosert wird (php.ini eintrag vorhanden; waren die Jungs von MAMP) könnte
das mal einer der Anderen probieren ...

Gruß
Aldus

[susigross]

Also um sich seinen Server mit php 5.1 aufwärts korrekt einzustellen genügt eine Zeile in der .htaccess

Code:

php_value date.timezone 'Europe/Berlin'


Die kann sich ja jeder setzen wie er will. Problem gerade bei billighostern kann ja auch sein, dass der Server gar nicht in der TZ steht (USA) in der die Seite veröffentlicht wird (Europa).

Es gibt aber Leute, die haben WB auf irgendwelchen Billigangeboten gehostet, wo sie nicht mal ne .htaccess verwenden dürfen. Soll WB nun für alle sein oder sollen bestimmte Nutzerkreise von der Nutzung ausgeschlossen werden?
Was ist dabei, die Einstellungen aus dem Backend auszulesen und dann auch zu verwenden? Wozu werden sie denn überhaupt im Backend gemacht?
Oder anders: Warum soll WB so umständlich sein, dass die TZ an 2 verschiedenen Stellen eingegeben werden muss?

[doc]

Hi,

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.

Um WB wirklich fit für XHTML strict zu machen, müsste man noch einiges am Core fixen und vor allem alle mitgelieferten Module überarbeiten. Mit der Veröffentlichung des "Release Candidate" wird eigentlich ein "Feature Freeze" eingeleutet, sprich nur noch "Bugs gefixt".

Überarbeitet werden müssten u.a. (Liste nicht vollständig):
 - Output und CSS aller mitgelieferten Module (Form, News ...)
 - Die Standardmenü Funktion: show_menu (target)
 - Das Handling wie WB mit Target Attributen umgeht (Doctype müsste geprüft werden und je nachdem z.B. target etc. erlauben oder auch nicht)
 - Einbinden von Javascript sollte über [CDATA] Blöcke realisiert werden (frontend_function, jQuery ...)

Auch der Standard WYSIWYG Editor (FCK) wird erst in Version 3.0 XHTML strict unterstützen. Sehe ich mir die Latte der nötigen Änderungen an, bezweifle ich, dass Aufwand und Nutzen für WB 2.8 gerecht fertigt sind.

Wenn XHTML strict und Barrierefreiheit für WB wichtig ist, sollte man ein Commitment diesbezüglich mit Nennung einer möglichen (bzw. frühest möglichen) WB-Version abgeben. Dann hätte man auch Zeit Module etc. zu überarbeiten und eben nicht nur einen "ersten halbherzigen" Schritt in diese Richtung zu gehen (sprich 2 von 6 Modulen könnens, show_menu kanns nicht aber mit show_menu2 wärs möglich ...).

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.

Also, ich würde an Deiner Stelle die Ferienzeit nutzen und die verbleibenden Seiten portieren, wenn XHTML strict ein "must have" Kriterium Deiner Kunden ist, welches mit WB 2.8 Final erfüllt sein sollte/muss.

Gruss Doc

[WebBird]

Also um sich seinen Server mit php 5.1 aufwärts korrekt einzustellen genügt eine Zeile in der .htaccess

Code:

php_value date.timezone 'Europe/Berlin'


Die kann sich ja jeder setzen wie er will. Problem gerade bei billighostern kann ja auch sein, dass der Server gar nicht in der TZ steht (USA) in der die Seite veröffentlicht wird (Europa).

Es gibt aber Leute, die haben WB auf irgendwelchen Billigangeboten gehostet, wo sie nicht mal ne .htaccess verwenden dürfen.

Ich geh auch immer vom schlimmsten Fall aus, und das ist der, daß der Anwender einfach nicht die notwendigen Rechte hat. (Abgesehen von denen, die gar nicht erst kapieren, was man von ihnen will. Nicht alle WB-User sind technisch versiert.) Daher finde ich es selbstverständlich, als "letzten Fallback/Notlösung" irgendeinen sinnvollen Default zu nehmen, wenn ich denn dadurch vermeiden kann, daß es blöde Fehlermeldungen gibt.

In diesem Fall ist es doch so, daß die Funktionen date() und mktime() schlichtweg "irgendeinen Wert" haben wollen. Letztlich muß sich WB doch nur einen setzen, von dem es "weiß", daß dabei wenigstens was Sinnvolles rauskommt. Mit GMT kann man da nichts falsch machen - und mit dem Fallback auf die Backend-Settings auch nicht.

PHP scheint ja intern auch "irgendeinen Wert" zu nehmen, denn es funktioniert ja alles so weit - bis auf die Fehlermeldung halt. Was spricht also dagegen, diese zu vermeiden, indem man es genauso macht, und gut ist?

Ich verstehe nicht, warum da jetzt so ein Aufstand drum gemacht wird.

[StudioVerlag]

@doc
Wie angeführt reicht es für WYSIWYG  und NEWS, ein anderer Editor wird außerdem genutzt.
Das Target-Problem wird per JS gelöst (alle externen Links erzeugen autom. ein neues Fenster)
Javascript macht keine Probleme (mehr),  ist also WAI-konform.
Die Menus haben bisher NOCH keine Probleme verursacht.
Andere noch vorhandene Fehler sind möglicherweise xhtml/css-fehler, die im Browser evtl. nicht sichtbar sind und durch 'nen xhtml-Validator rutschen, aber beim WAI-Test durchfallen, wie z.B. bei frontend.css wo man em statt px setzen sollte.
Bisher ist auch noch nicht auf strict getestet worden, sondern nur auf grobe Bugs, die auch bei transitional sichtbar werden.

Wenn die ersten Schritte in diese Richtung gegangen sind, kann man nach und nach  die existierenden Module und mehr anpassen. Die Diskussionen um Richtlinien für Module und mehr waren wohl hoffentlich "nicht für die Katz"?

Gruß, Hans>NUL

[doc]

@Hans-Null:
Na dann ist der Topic dieses Threads wohl etwas irreführend, die Antwort würde derzeit wohl NEIN lauten  

Eine mögliche Antwort auf die Frage im Topic: Erste Schritte in Richtung XHTML Strict wurden mit WB 2.8 realisiert, vollständigen XHTML Strict Support kann es frühestens in einer zukünftigen WB Versionen geben. Vorausgesetzt, HTML 5 ist dann nicht bereits das Mass aller Dinge 

Javascript macht keine Probleme (mehr),  ist also WAI-konform.

Ob man das Target-Problem mit Javascript lösen sollte - nun ja. Wie ist denn die Einbindung von JS/CSS Code im Head gelöst? Wird je nach Doctyp (XHTML Strict/Transitional) CDATA oder <script> für die Einbindung verwendet - oder wie kann ich mir das vorstellen?

Die Diskussionen um Richtlinien für Module und mehr waren wohl hoffentlich "nicht für die Katz"?

Um Veränderungen herbeizuführen, sind Diskussionen ein guter Startpunkt, letztendlich müssen Veränderungen aber auch umgesetzt und gelebt werden, was der aktiven Mitarbeit vieler Bedarf. Naja, die Zukunft wird es zeigen  

Doc

[StudioVerlag]

@doc

Ob man das Target-Problem mit Javascript lösen sollte - nun ja

Ja, weil es WAI-und xhtml-strict konform ist und zudem die, die's vermissen, den _target - Effekt halt weiterbenutzen können.
Es tut also niemandem, auch Puristen nicht, weh. Es klappt so mit Braillzeile und Screenreader.

JS/CSS Code im Head

Wird wie angegeben eingebunden. Der einzige Unterschied ist ja nur die Position.

Natürlich gibt's auch Alternativen:
Replacing <noscript> with accessible, unobtrusive DOM/JavaScript
Nur, warum das Leben komplizierter machen...  

Gruß, Hans>NUL

[StudioVerlag]

@ruebenwurzel
"Das kann ich nicht nachvollziehen. Scheint ein Problem deines Validators zu sein."
<edit> Die Fehler kann man auch ohne Validator als solche erkennen </edit>

1.) Wie gehabt  "src" + "alt" attribute (nix drin)
<td rowspan="3" style="display: none"><img src="" alt="" /></td>
2.) >> (Found the character '>' with no previous character '<' )
<edit>

Code: [Select]

Der fehler wird mit folgender Änderung in add.php beseitigt:
57: <td valign="top"><a href="[BACK]">[PAGE_TITLE]</a> &gt;&gt; <a href="[BACK]?g=[GROUP_ID]">[GROUP_TITLE]</a></td>
<td valign="top"><a href="[BACK]">[PAGE_TITLE] &gt;&gt;</a>  <a href="[BACK]?g=[GROUP_ID]">[GROUP_TITLE]</a></td>
Dummerweise ließ sich WB per De- und Neuinstallation des News-Modules nicht dazu bewegen die Änderung zu übernehmen. Erst die Neuinstallation von WB brachte das gewünschte Ergebnis. Sehr viel Zeit vergeigt.
</edit>

Betrifft
News-Modul
WB 2.8 RC1 trunk-r1059
Installiert auf Portable

WAI-Anpassung gemacht:
font-size: von Pixel auf em umgestellt
in frontend.css

Gruß, Hans NUL

[Luisehahne]

Wenns irgendwelche Probleme mit vailden Code im Backend gibt, die Pagelisttree ausgenommen, bitte Bescheid geben. Rom ist auch nicht in einem Tag erbaut. Und vielleicht schaffen wir das WB 2.8 bis zur Final komplett valide und Strict zu bekommen.

Dietmar

[StudioVerlag]

Final komplett valide und Strict

Ich wäre schon froh, wenn die o.a. Änderung/en in einem neuen trunk einfließen würden.
Immer 'nen neuen trunk zu saugen und dann die eigenen Korrekturen jedesmal einzupflegen verleidet einem die Arbeit.

Aber es gibt auch eine gute Meldung meinerseits: Die Kommentarfunktion des News-Moduls scheint keinen xhtml-fehler zu enthalten. WAI findet auch nix. Bleibt das Einpflegen der genannten Korrektur/en.

Gruß, Hans>NUL

[Luisehahne]

  Das wusste ich ,wenn du aber schon was entdeckt hast was  und wie beseitigt werden muss, dann lass es mich wissen

Dietmar

[StudioVerlag]

Fragen zum Form-Modul (Es geht nur um xHTML-Fehler!)
Warum ist keine Hilfe dem Modul beigefügt?
Kurztext: Größenangabe (z.Z. 80 eingetragen)
Auswahlliste: Größenangabe
Langtext: Warum im Kurztext Längenangabe und im Langtext nicht ?

So wie das aussieht werden auch hier bei einigen Attributen keine Werte ("") angezeigt.
Möchte den Test mit ausgefüllten Feldern wiederholen.
<edit>
Aus Programmierersicht sind diese fehlenden Werte erstmal KEINE Fehler -LOGO
</edit>
Gruß, Hans>NUL

[ruebenwurzel]

@hans>null

bis auf die Geschichte mit src und alt sollte jetzt alles soweit gefixt sein im News Modul. Bitte die letzte SVN Version mal probieren.

Matthias

[StudioVerlag]

@ruebenwurzel

Verwendet wurde trunk-r1065 (+ eigene frontend.css)
Nachricht + Kommentar

Wie auch immer Du's als Programmierer gelöst hast, es klappt!  
Heißt: Kein xHTML-Fehler oder WAI laber, laber. (Transitional)

Werdet Ihr die andere "Geschichte" im nächsten RC angehen, ist da was geplant?

Noch eine Anmerkung.
Es überraschte mich, daß keine Warnmeldung bei Cookie-Abschaltung ausgegeben wird.
Für einen Admin im Backend ist die Voraussetzung klar, aber bei einem Kommentator?

Hoffen wir, daß ich ausreichend getestet habe. Gucke mir auch noch ein paar andere Teile an.

<edit>
Habe den nicht so strengen W3CCheck gemacht:
Beanstandet wird NUR noch
Attribute "target" exists, but can not be used for this element
http://127.0.0.1:4001/wb28rc1" target="_top"  class="menu_default"> Home </a>
-----------------------------------------------------------------------------------------------------------------
Attribute "height" exists, but can not be used for this element
<td height="30"><h1>Nachrichten</h1></td>
</edit>

Gruß, Hans>NUL

[doc]

@Hans:
Das Problem mit

Code: [Select]

target="_top"  class="menu_default" kann wie bereits in einer früheren Post erwähnt über show_menu2 gelöst werden (auch ohne an Coredateien zu frickeln). Dazu show_menu2 einfach mit den Parametern wie z.B. in den Template Guidelines (Figure 5)) gezeigt aufrufen und den Teil

Code: [Select]

target="[target]" weglassen. Für show_menu müsste man dieses Feature durch ändern der Corefiles hinzufügen.

Doc

[StudioVerlag]

Stimmt.
Ich werde in den beiden Testtemplates SM gegen SM2 tauschen.
Danke.
Gruß, Hans>NUL