WebsiteBaker Support (2.8.x) > Diskussion über WB (closed)
WB 2.8 Fehlermeldungen (war xhtml strict)
susigross:
--- Quote ---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).
--- End quote ---
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,
--- Quote from: Hans->Null Post #1 ---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.
--- End quote ---
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 ...).
--- Quote from: Hans->Null Post #1 ---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.
--- End quote ---
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:
--- Quote from: FrankH on July 13, 2009, 05:34:19 PM ---
--- Quote ---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).
--- End quote ---
Es gibt aber Leute, die haben WB auf irgendwelchen Billigangeboten gehostet, wo sie nicht mal ne .htaccess verwenden dürfen.
--- End quote ---
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 :wink:
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 :wink:
--- Quote from: Hans->Null ---Javascript macht keine Probleme (mehr), ist also WAI-konform.
--- End quote ---
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?
--- Quote from: Hans->Null ---Die Diskussionen um Richtlinien für Module und mehr waren wohl hoffentlich "nicht für die Katz"?
--- End quote ---
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 :wink:
Doc
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version