WebsiteBaker Community Forum
WebsiteBaker Support (2.8.x) => 
Hilfe & Support (deutsch) => General Help & Support => Diskussion über WB (closed) => Topic started by: StudioVerlag on July 08, 2009, 10:57:28 PM
-
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
-
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
-
Nee, auf den alten Thread wollte ich bewußt nicht eingehen. :roll:
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"
-
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
-
Hallo,
RC1 wird innerhalb der nächsten Tagen (vielleicht sogar Stunden :-D) 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
-
Mache ich gern und sowieso :-D
Ihr habt ja noch mit "Styling TEXT_READ_MORE not allowed nor page CSS settings" zu tun :evil:
Besser noch ein paar Tage warten (da kommt's jetzt auch nimmer drauf an), als zu böse Überraschungen erleben.
Gruß, Hans>NUL
-
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.
-
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)
-
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
-
in strict mode
Currently xhtml-Transitional
The validator accepts no <noscript> in <Head>
WAI (Accessibility) requires <noscript>
Regards, Hans>NUL
-
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. 8-)
Ruud
-
The My only solution: js is not in the head position
Regards, Hans>NUL
Edit: So ist es z.Z. gelöst
<?php if(function_exists('register_frontend_modfiles')) {
register_frontend_modfiles('css');
} ?>
</head>
<body>
<?php if(function_exists('register_frontend_modfiles')) {
register_frontend_modfiles('js');
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.
-
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
-
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 ? :lol:
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
-
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. :-D
Matthias
-
Das kann ich nicht nachvollziehen. Scheint ein Problem deines Validators zu sein.
Sinnvoll wäre schon , statt > > 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.
-
Hallo,
Sinnvoll wäre schon , statt > > zu schreiben.
Tja ein Blick in die view.php schafft Aufklärung :-D. Da steht > 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
-
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 >
Trunk ... äh ... hab ich vergessen. ;)
-
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?
-
@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
-
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. ;)
-
Gibt es da nicht Unterschiede in verschiedenen PHP Versionen bezüglich date...
Bestimmt. :-D 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
-
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 :wink:
-
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.
-
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 :wink:
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
-
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. :roll:
-
Hallo,
http://www.php.net/manual/de/datetime.configuration.php#ini.date.timezone (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
-
hm ... dann kann man es auch gleich endstauben :-D ...
<?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
-
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. :wink: 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. :-D 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.
-
Ü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
-
....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....
-
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.
-
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
-
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
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 (http://project.websitebaker2.org/changeset/1059)
-
Nächste Runde ...
Bei "wb/include/jscalendar/wb-setup.php" sollte es mit "gmdate" anstatt "date" gehen ... Zeile 50 ...
<?php
// today
$jscal_today = gmdate('Y/m/d');
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
-
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?
-
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
-
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. :|
-
@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
-
@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:
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 :wink:
Doc
-
@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... :lol:
Gruß, Hans>NUL
-
@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>
Der fehler wird mit folgender Änderung in add.php beseitigt:
57: <td valign="top"><a href="[BACK]">[PAGE_TITLE]</a> >> <a href="[BACK]?g=[GROUP_ID]">[GROUP_TITLE]</a></td>
<td valign="top"><a href="[BACK]">[PAGE_TITLE] >></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
-
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
-
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
-
:evil: Das wusste ich ,wenn du aber schon was entdeckt hast was und wie beseitigt werden muss, dann lass es mich wissen
Dietmar
-
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
-
@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
-
@ruebenwurzel
Verwendet wurde trunk-r1065 (+ eigene frontend.css)
Nachricht + Kommentar
Wie auch immer Du's als Programmierer gelöst hast, es klappt! :-D
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
-
@Hans:
Das Problem mit 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) (http://addons.WebsiteBaker.org/media/template_guidelines.pdf)) gezeigt aufrufen und den Teil target="[target]" weglassen. Für show_menu müsste man dieses Feature durch ändern der Corefiles hinzufügen.
Doc
-
Stimmt.
Ich werde in den beiden Testtemplates SM gegen SM2 tauschen.
Danke.
Gruß, Hans>NUL
-
SM2 ist auf jeden Fall empfehlenswerter.
Außerdem könnte SM2 leicht erweitert werden, wenn man einiges im Core erweitert.
Gruß,
Stefek
-
@Hans:
Das Target-Problem wird per JS gelöst (alle externen Links erzeugen autom. ein neues Fenster)
Und prüft man im Template den verwendeten Doctype, könnte man zwei show_menu2 Aufrufe integrieren. Für XHTML Strict halt ohne target="[target]", für andere Doctyp mit target="[target]". So hätte man abhängig vom verwendeten Doctyp auch ohne Javascript valides HTML :wink:
Doc
-
@doc
Ich weiß, es ist die feinere Art, besser als manches JS-Gefrickelie, doch JS hat sich in den von mir angewandten Feldern bisher bewährt, haben sich doch auch hier Standards gebildet (ECMA).
Bisher hatte ich das Arbeiten mit Doctype wg. mögl. fehlender Crossbrowsertauglic hkeit vermieden, und mich nicht weiter damit beschäftigt. Da mittlerweile aber keine Probleme mehr zu befürchten sind, sollte ich wohl so langsam wieder mal umdenken. Alles was man längerfristig aussperrt kann zur Wissenslücke werden.
Wenn's Ressourcensparende und schneller Alternativen gibt, nutze ich die meistens auch.
Gruß, Hans>NUL
-
Hi,
und wenn mal mit WB 3.0 vollständiger Support für XHTML 1.0 Strict möglich ist, würde es mich nicht wundern, wenn das W3C nach ca. 15 Jahren frickeln an HTML 5 einen ersten Entwurf verabschiedet. XHTML 2 (http://www.w3.org/News/2009#item119) scheint diesbezüglich nicht mehr die grössten Prioritäten zu haben (zumindest was den Etar angeht) :-D
Doc
-
So langsam weiss man nicht mehr worum es hier ging.
@Hans>NULL
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.
Gebt mir nochmal ein paar Infos, dann brauche ich nicht alles zu lesen. Ich habe übrigens bei Trunk SVN 985 angefangen. Mein Rechner läuft langsam über.
Dietmar
-
@doc
XHTML 1.0 Strict ist mir wg. der Nähe zu XML wichtig. "Ab zur XML-Umgebung" geht ohne Schwierigkeiten. Von dort aus "geht alles".
XHTML 1.1 macht Probleme mit Barrierefreiheit (Auch wenn die Probleme eher in den Monopolen des Geräte-Marktes für Eingeschränkte Nutzer zu sehen sind)
HTML 5 betrachte ich vorerst noch als weiteren Output für Websites (wie XML>xhtml).
Teilweise können's die Browser schon ( z.B. canvas )
@Luisehahne
So langsam weiss man nicht mehr worum es hier ging.
Oine Saite vorher steht's :-D
Also Schritt für Schritt...
Ach, gaaanz vergessen GEWONNEN: Changeset 839 :-D
Gruß, Hans>NUL
-
Hi,
Code von Hans aus Post 11 in diesem Thread:
<body>
<?php
if(function_exists('register_frontend_modfiles')) {
register_frontend_modfiles('js');
echo "<noscript></noscript>";
} ?>
...Was ist mit Javascript Dateien, die im Head eingebunden werden müssen damit Sie funktionieren? Gibt zwar nur wenige, aber es gibt Sie.
Kann auch Deine Fehlermeldung mit Einbindung von externen JS Dateien mittels <script type="text/javascript" src="xxx.js"></script> nicht nachvollziehen. Der W3C Validator (http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fhelp.WebsiteBaker.org%2Fpages%2Fde%2Fadvanced-doku.php) meckert die verlinkte Seite (trotz JS Einbindung im head) nicht an (XHTML 1.0 Transitional, übrigens seit WB 2.7 so). Auch beim Umschalten auf Strict meckert er nicht über das <script> im Head. Auf W3C (http://www.w3.org/TR/2003/WD-xhtml2-20030506/mod-scripting.html#sec_16.2.3.) wurde ich diesbezüglich auch nicht fündig, auf dieser Seite (http://www.evotech.net/blog/2007/05/including-javascript-in-xhtml/) auch nicht.
Doc
-
Hallo,
vielleicht eine Idee für künftige Versionen:
frontend.js wie bisher im head einbinden
neue funktion für eine eine frontend_body.js integrieren, die das js dann vor </body> einbindet.
Damit dürften dann alle Optionen abgedeckt sein.
Matthias
-
Was ist mit Javascript Dateien, die im Head eingebunden werden müssen damit Sie funktionieren? Gibt zwar nur wenige, aber es gibt Sie.
Na das ist doch mit jquery alles kein Problem mehr. Da kann ich doch jede beliebige Datei nachträglich in den Header befördern mit $.insert
Man muß über das Template lediglich die beiden folgende Dateien in den Header laden, alle anderen kann man dann in seinem Modul nachladen.
jquery-1.3.2.js
jquery.insert.js
-
Was ist mit Javascript Dateien, die im Head eingebunden werden müssen damit Sie funktionieren? Gibt zwar nur wenige, aber es gibt Sie.
Kann aber nur passieren, wenn mitten im Quelltext functionen aufgerufen werden, die dort enthalten sind. Also Umsteigen, Gedanken machen, sich von Alten lösen. Stillstand bedeuted Rückstand. Nach vorne schauen, sagt euch ein 58 Jahre alter Sack.
Dietmar
-
Was ist mit Javascript Dateien, die im Head eingebunden werden müssen damit Sie funktionieren? Gibt zwar nur wenige, aber es gibt Sie.
Kann aber nur passieren, wenn mitten im Quelltext functionen aufgerufen werden, die dort enthalten sind.
Ja der Anfang vom Modul ist dann aber wohl auch schon mitten im Quelltext, oder?
-
Hatte ja das Problem mit dem Umsetzen einiger Adminfiles in Templates. Habe dann allen Javascript Code der im Quelltext stand ausgelagert. Wenn du es geschickt anfängst, brauchst du kein Javascript irgendwo mittendrin. man muss eben halt umdenken. Ist schwer, das weiss ich natürlich. Das ist genauso, die Umdenke in den 70ern Jahren, wo die Älternen dann sagten, "das ist Schweinekram". Da denkt heute keiner mehr drüber nach.
Dietmar
-
Habe dann allen Javascript Code der im Quelltext stand ausgelagert. Wenn du es geschickt anfängst, brauchst du kein Javascript irgendwo mittendrin. man muss eben halt umdenken. Ist schwer, das weiss ich natürlich.
Ich glaube du bist da wieder ein wenig neben dem Thema, Dietmar.
Wir sind uns wohl einig, dass JS am besten in externen Dateien aufgehoben ist.
Das Problem, wleches doc ansprach, war, das diese Dateien nachträglich in den Header geladen werden müssen.
Ich verstehe nicht, was deine Phrasen damit zu tun haben.
-
Eben deswegen. Warum in den Header? Du kannst alles nach unten packen. Nichts ist mit jquery und seiner callbackfunction unmöglich. Wir müssen umdenken.
Aber ob oben oder unten, ist doch eigentlich unwichtig, es muss funktionieren. Das mag eben jeder für sich entscheiden. Du kannst ja auch mit Javascript unten, ein Jsavascriptfile oben setzen.
Dietmar
P.S. :? Keiner versteht mich
-
Hi,
denke auch, dass hier etwas am Thema vorbeigeredet wird :wink:
Dachte Hans>NULL ging es darum, dass der Validator bei XHTML meckert, wenn externe Scripte im Head-Bereiche eingebunden werden. Das konnte ich aber so nicht nachvollziehen siehe z.B. WB Hilfeseite (http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fhelp.WebsiteBaker.org%2Fpages%2Fde%2Fadvanced-doku.php). Dort wird externes JS im <head> Abschnitt eingebunden, dem W3C Validator ist es wurscht.
Also es geht nicht darum, alte JS-Scripte umzubauen oder sonstiges. Ich persönlich binde alles im Head ein oder lade JS per jQuery nach und hatte bisher noch nie Probleme mit dem W3C Validator und XHTML Transitional 1.0.
Doc
-
Jau, Bin gerade dabei alles hier durchzulesen. Ziemlich durcheinander und unüberschaubar.
Dietmar
-
Hallo,
==offtopic==
Hab das Thema mal geteilt, die login geschichte ist jetzt hier zu finden:
https://forum.WebsiteBaker.org/index.php/topic,14509.0.html
==ende offtopic==
Matthias
-
@doc
Erstmal zur Klärung eines Mißverständnisses, zudem ich anscheinend durch die nichtspezifische Nennung des Begriffs VALIDATOR beitrage.
Geprüft wird in der Reihenfolge:
1.) Prüfung auf Fehler in xhtml-strict/transitional
(css im Template und Editor bleiben in der ersten Phase draussen)
Die Prüfung geschieht mit eigener Software, W3C, Validome und anderen.
2.) Prüfung nach WAI -Mit eigener Software und Online-Tools auf eigenem Server
(http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/)
Erst bei der Templateerstellung kommt dann noch BITV dazu
(Später dann Tests auf Screenreader, Lesesoftware usw. was aber mit WB nix mehr zu tun hat)
Das "<noscript></noscript>"-Problem wird bei der Prüfung nach WAi angezeigt
W3C zeigt "This document was successfully checked as XHTML 1.0 Transitional!"
Das "<noscript></noscript>"-Problem wird im Netz auch diskutiert.
Soll heißen, auch WB 2.7 war möglicherweise trotz "transitional" nicht WAI-gerecht, was ich aber nicht getestet habe.
Da wir aber mit WB 2.8 auch ein wenig aufräumen wollten, wo notwenig und machbar, und nicht weiter alte Probleme mitschleppen wollen (wir sind ja nicht MS) kommt's halt jetzt auf den Tisch. (Meine Mosereien kamen nicht aus schlechter Laune heraus, auch wenn man über den Stil streiten kann.)
Außerdem stelle ich meine "Feststellungen" bei der Fehlersuche gleichzeitig zur Disposition. Viele Werkzeuge sind ja nicht automatisch gleichbedeutend mit Qualität -auch wenn ich viel Zeit für die Auswahl aufgebracht habe. Praktisch läuft's so ab, daß auf Fehleranzeigen sehr oft das Nachlesen in den Dokus folgt. Wenn ich einem möglichen "false positiv" aufsitze ist das m.E. nicht nur für mich sinnvoll zu erkennen, sondern nutzt auch anderen.
Gruß, Hans>NUL
-
Hi,
Erstmal zur Klärung eines Mißverständnisses, zudem ich anscheinend durch die nichtspezifische Nennung des Begriffs VALIDATOR beitrage.
Nicht nur dadurch, auch durch den Topic (xhtml strict) und durch die Tatsache, dass in diesem Thread so nebenbei auch noch über andere Sachen "getratscht" wird :wink:
Zwecks Validatoren, da sollten Online-Validatoren verwendet werden, die jedem zugänglich sind. Wenn eigenes CSS oder Template, bitte posten und gegen dieses validieren, damit ALLE die gleiche Basis haben.
Denke Firefox mit dem Plugin "Webdeveloper Toolbar" ist ein guter Startpunkt. Dort sind folgende Validatoren verlinkt:
CSS: http://jigsaw.w3.org/css-validator/
HTML: http://validator.w3.org/
Section 508 / WAI: http://www.contentquality.com/
Sollten die verwendeten Validatoren von den oben genannten abweichen, müssen diese Explizit genannt werden. Anonsten hat man 20 verschieden Baselines, nichts ist nachvollziehbar und die paar aktiven Devs dürften dann auch schnell die Lust verlieren, allen Unkenruf nachzurennen :wink:
Doc
-
@doc
Na, dann nimm doch Online-Validatoren.
Die zusätzliche Software -habe ich an anderer Stelle im Forum gelistet, wenn's keinen interesssiert ist's nicht mein Problem- ist auch kostenlos. Man braucht sie nur downloaden und installieren.
WB 2.8 Accessibility Check (Tools) (https://forum.WebsiteBaker.org/index.php/topic,14172.0.html)
Man kann aber auch ohne Software Testen, so wie bei BITV (das sind in Deutschland nämlich nur (teure) Empfehlungen).
Bezgl. WAI siehe das Datum: 1999 !
Gruß, Hans>NUL
Edit: Wie schon gesagt ist das Problem im Netz bekannt. Da ist das Streiten um Validatoren doch überflüssig. Ich gehe sowieso nur Fehlern nach, wo man auf Standards und Dokus zurückgreifen kann. Alles andere würde wie von Dir befürchtet in eine nicht mehr handhabbare Situation führen.
Edit 2: Was den Thread betrifft- Der geht auf auf (in etwa) Form xhtml strict kompatible? zurück (Nov. 2008) zurück und findet hier in v2.8 seine Fortsetzung, wenn auch unter etwas anderen Voraussetzungen. Bin ja nicht der einzige der mal wechselt oder wecheln muß (siehe Cookie-Beitrag)
-
Ich nehme immer den Lokalen Validator von FF, der zeigt mehr an als der Online. WAI ist super, da gibst Error, die mir so nie aufgefallen wären und auch W3.org/check nicht angezeigt werden.
Im Grunde genommen wolle nwir alle dasselbe, auch wenn wir manchmal aneinander vorbei reden
Dietmar
-
@Hans
Die zusätzliche Software -habe ich an anderer Stelle im Forum gelistet, wenn's keinen interesssiert ist's nicht mein Problem- ist auch kostenlos. Man braucht sie nur downloaden und installieren.
Jo, nur hilft es nicht wirklich diese Liste woanders zu posten und hier stillschweigend als gegeben vorauszusetzen. Ein Link auf diese Liste hätte manches "Missverständnis" vermieden.
Bin ja nicht der einzige der mal wechselt oder wecheln muß (siehe Cookie-Beitrag)
Zum Cookie-Beitrag gibt es auch aktuellere Infos.
Doc
-
und hier stillschweigend als gegeben vorauszusetzen
Ja, da muß ich Dir zustimmen. Werde den Status mit solchen Mitteilungen ergänzen.
Dann wäre es, bis auf die Gesprächskultur und einigen anderen Kleinigkeiten, fast wie in meinen fachbezogenen Mailing-Listen. Heißt: Streng neutral und über's Wetter darf auch nix gesagt werden :-D
Für die Entwickler wäre es das Paradies
Doch bei solch' strengen Regeln würde sich das Forum hier wohl selbst zerlegen. :evil:
Gruß, Hans>NUL
Edit: Man kann es auch anders sehen. Die Liste ist JETZT versteckt, sie war sehr frühzeitig veröffentlicht, und wie schon gesagt, man braucht DIESE Tools nicht zwingend auf eigenem Rechner. Es erleichtert nur die Fehlersuche. Recherchieren gehört weiterhin zur Sorgfaltsplicht.
-
Betrifft
News-Modul
WB 2.8 RC1 trunk-r1068
Installiert auf Portable
News-Inhalt ist mit Kommentar versehen
WAI-Anpassung gemacht:
font-size: von Pixel auf em umgestellt
in frontend.css
Beanstandung:
1.) Wie gehabt "src" + "alt" attribute (leer)
<td rowspan="3" style="display: none"><img src="" alt="" /></td>
XHTML ist OK
Test nach WAI beanstandet diesen Zustand.
Dieser Fehler wird z.B. auch angezeigt, wenn die Felder im Header nicht mit Angaben versehen werden, also Beschreibung, Keywords etc. In Modulen mit Eintragsfeldern (wie Form) gibt es möglicherweise auch dieses Problem. Man müßte also bei fehlendem Inhalt die entsprechenden PHP-Befehle unterbinden, damit das nicht im html-Output erscheint, wäre da mein erster Gedanke.
(Mit "Rübenwurzel" absprechen, bitte)
Zur Zeit steht auch noch "das Wie" einer endgültigen Einbindung von JS aus. (Siehe das "<noscript></noscript>"-Problem), zumal man aus Performance-Gründen JS auch am Ende einer Seite einbinden/laden könnte. Da sind u.U. auch noch die JQuery-Spezies gefragt.
Eine für mich vorläufige funktionierende Lösung gibt's HIER (https://forum.WebsiteBaker.org/index.php/topic,14431.msg90428.html#msg90428)
Probleme, die sich durch Verwendung von SM statt SM2 ergaben, werde ich noch beseitigen.
Gruß, Hans>NUL
-
Hallo Hans>NUL,
Stimmt WAI meckert die fehlenden von dir beschriebenen Meta Tags an.
Zum 1. Punkt, ich nehme auch gerne die em, meine aber irgendwo gelesen zu haben, dass das auf pixel umgerechnet wird wegen der Bildschrimanzeige, macht dann wahrscheinlich der BRowser, was aber dann wieder Zeit kostet, nicht viel aber immerhin, es kann sich zusammen läppern. Was sagst du dazu?
Dietmar
-
Das Problem ist, daß Media Screenreader und Braille unterschiedliche css im Template-Verzeichnis bekommen. Wie da die frontend anpassen? Im Moment bin nicht mehr so konzentriert um entsprechende Wege und Lösungen zu sehen.
Heute ist wohl erstmal Feierabend. Ich seh garnix mehr, merke ich gerade :?
Werde wohl schauen ob das über @import in die jeweiligen CSS gelöst werden kann. Aber erst spädrrr.
Ob das nun eine individuelle Lösung wird und bleibt muß man dann sehen.
Gruß, Hans>NUL
-
Zum 1. Punkt, ich nehme auch gerne die em, meine aber irgendwo gelesen zu haben, dass das auf pixel umgerechnet wird wegen der Bildschrimanzeige, macht dann wahrscheinlich der BRowser, was aber dann wieder Zeit kostet, nicht viel aber immerhin, es kann sich zusammen läppern. Was sagst du dazu?
Bei em kann der User sich selbst die Schriftgröße einstellen, indem er sie einfach im Browser anpasst, bei Pixel geht das nicht, weswegen man die nicht nehmen sollte.
-
Ahm, mit Trunk 1071 gibt's immer noch mktime() Fehlermeldungen, nämlich wenn man ein Modul installieren will.
Strict Standards: mktime() [function.mktime]: 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\pclzip\pclzip.lib.php on line 4296
Nur zur Info.
-
Wird sofort kontrolliert.
Dietmar
-
Hi,
komisch, bei mir nicht. Gerade getestet und erro.log geholt.
Dietmar
-
Macht doch einfach an geeigneter Stelle:
if ( empty( ini_get('date.timezone') ) ) {
date_default_timezone_set('Europe/Zurich');
}
Wer's ganz hübsch machen will, nimmt die WB-Einstellung als Basis und holt dazu die richtige timezone. ;)
-
Hi,
komisch, bei mir nicht. Gerade getestet und erro.log geholt.
Dietmar
Bist Du sicher, daß Du keine date.timezone in der php.ini stehen hast?
-
Ich kann dir nur sagen, dass bisher alle mktime Fehler bei mir in der Error.log angezeigt wurden und deswegen bereits zusätzliche Bereinigungen stattgefunden haben. Habe jetzt auf Grund deiner Fehlermeldung noch was gefunden.
Dietmar
-
Hallo,
include\pclzip\pclzip.lib.php on line 4296
pclzip ist ein third party script, das wir eigentlich unverändert übernehmen. Wir können das jetzt zwar reinmachen, aber vermutlich beim nächsten updtate der pclzip libraries denkt da dann keiner mehr dran.
Also: bitte Fehler bei den Entwicklern von pclzip librariers melden, dass die das für kommende Versionen fixen.
Matthias
-
Ja, seh ich ein, daher ja auch der Vorschlag mit dem ini_set(). :wink:
-
Hallo,
Ja, seh ich ein, daher ja auch der Vorschlag mit dem ini_set().
:? :? :?
Nicht alles durcheinanderwerfen .
1.) mktime() sollte ersetzt werden unabhängig von date.timezone
2.) date.timezone müsste ja in jedem script zur Verfügung stehen, viel spass dann beim einfügen in alle files, da ist die .htaccess Geschichte eindeutig im Vorteil.
aber:
Im Zusammenhang mit dem delimiter stoßen wir ja an diesselbe Problematik. Deswegen sollte in einer künftigen Version (WB 2.8 hat feature freeze!!!!) vielleicht folgendes eingebaut werden:
1.) eine Variable für Delimiter, die an zentraler Stelle (config.php oder als Datenbankeintrag für die WB-Settings) dem User alle Möglichkeiten läßt (&, &, ;) was er einsetzen will.
2.) eine weitere Variable für die Date.timezone in der der User in den WB-settings wählen kann z.B. zwischen default (=WB Timezone) oder halt benutzerdefiniert (dropdown mit anderen Möglichkeiten).
Matthias
-
Nur das Porblem kann werden
daher ja auch der Vorschlag mit dem ini_set().
bei mir scheint das gesperrt zu sein.
eine Variable für Delimiter, die an zentraler Stelle
ist dann sinnvoll
Dietmar
-
2.) date.timezone müsste ja in jedem script zur Verfügung stehen, viel spass dann beim einfügen in alle files, da ist die .htaccess Geschichte eindeutig im Vorteil.
Einer von uns ist im falschen Film. ;)
Wenn man als allererstes - sprich wohl in der index.php - prüft, ob date.timezone gesetzt ist, und dies dann mit date_default_timezo ne_set() nachholt, falls das nicht der Fall ist, müßten alle Libraries (die erst später geladen werden!) damit glücklich sein!
-
Als ich ini_set() sagte, meinte ich date_default_timezo ne_set(). *hust*
-
Ist schon klar, nur dafür brauche ic hja die ini_set, und die setzt bei mir nichts. Frage jetzt mal bei meinem Hoster nach.
Gruss
Dietmar
-
Mit trunk-r1071 funktioniert "Feld anlegen" nicht mehr.
Bei trunk-r1068 klappte das noch.
Installation wie gehabt auf Portable
Habe die Installationen beide wiederholt vorgenommen, doch leider.... :oops:
Gruß, Hans>NUL
Edit: "Form modul" ist gemeint.
-
Du meinst bestimmt Form modul
Dietmar
-
Ist schon klar, nur dafür brauche ic hja die ini_set, und die setzt bei mir nichts. Frage jetzt mal bei meinem Hoster nach.
Äh, ja? Wieso? Oder meinst Du ini_get()?
-
@Luisehahne
Ja, wollte ich noch nachtragen, aber meine Cookies sind immer so schnell wech :?
(Schon wieder, oh neeee)
Ja, das "Form modul" isses.
Gruß, Hans>NUL
-
Folgendes ist passiert. Man muss wohl unterscheiden, dass was man auf dem Bildschirm angezeigt wird und gescheckt wird und das was im Hintergrund passiert. Es waren in der add_field auch die & gesetzt.
Habe die rausgenommen und schon funktionierte es. Meine lokalen php.ini Einstellungen sind wohl anders als aufm -Web. Habe ich aber noch nicht überprüft. Auf jeden Fall & wieder zu & umgewandelt und schon konnte ich wieder Felder anlegen.
Der Teufel steckt im Detail. inwieweit die ini_set am Anfang raus muss, wird die Praxis zeigen. Bei mir hat sie keinen Einfluss. Aber jeder Hoster ist ja anders. Nur dann wissen wir sofort woran es liegt.
Dietmar
-
Zur Zeit ist alles auf dem WB-Portable installiert.
Mit RC2 werde ich es wohl auch auf Linux rüberschieben (apache/php als cgi)
Bisher hat 2.7 in beiden Fällen funktioniert, mit 2.8 sollten keine neuén Probleme auftauchen.
Auf "vernünftigem" Host zumindest.
Gruß, Hans>NUL
-
Möpchte mich schon im Voraus für eure Hilfe und Tests bedanken. Sieht doch schon gut aus, auch wenn das Ein oder Andere wieder zurückgenommen werden muss. Aber dafür ist die Testphase ja da.
Dietmar
-
Hallo,
so jetzt nochmal zu der & Geschichte. Wie Chio weiter oben ja schon angedeutet hat, scheint das nicht auf allen Servern zu gehen. Siehe auch Fehler Hans>NULL, kann es hier auch reproduzieren. Deswegen hab ich die ganze Geschichte wieder rausgenommen. http://project.websitebaker2.org/changeset/1074 (http://project.websitebaker2.org/changeset/1074)
Matthias
-
Hallo,
Vielleicht kann das noch jemand testen, da wir ja noch in der Testphase sind. Alle die & die in denScripten stehen, die was abspeichern ohne auf dem Bildschirm angezeigt zu werden, sollten mit & gestezt werden.
Alle & die auf dem Bildschirm dargestellt werden sollten als & im Source gesetzt werden, weil ja da noch eine Umwandlung erfolgt.
Ich hatte diesbezüglich bei allen Urls in der Adressleiste immer korrekt das & stehen.
Klar warm soll ein & was im Hintergund verarbeitet wird umgewandelt werden. Ein & bleibt ein & und deswegen der Fehler, während das oben beschriebene ja noch das htmlentities oder back durchläuft. Also & wird zu &.
Ich weiss jetzt nicht, ob meine Logik verständlich war. Vielleicht findet jemand anders eine leichtere Erklärung.
Dietmar
-
Betrifft Captcha (hier "Form modul")
trunk-r1075
WAI beanstandet das Antwort-/Ergebniskästchen:
<td><input type="text" name="captcha" maxlength="10" style="width:20px;" /></td>
The "id" attribute is not specified in <input type="text">. Associate <input type="text"> with <label> so that the text input field label becomes clickable.
Es könnte also Verwirrung bei der Eingabe geben.
Da ich Tests mit Screenreader etc erst später mache, kann ich nicht beurteilen ob's wirklich Probleme bei der Eingabe geben wird. Jedenfalls wird's unter Priority level 2 angemeckert.
Mir wäre lieber, wenn's überhaupt keine WAI-Fehler gäbe, damit man sich später nur noch beim Design auf Usability konzentrieren kann und braucht.
Gruß, Hans>NUL
-
Guten Morgen,
Ja stimmt auch, aber eins nach dem anderen. Lasse auch immer den WAI drüberlaufen, fehlen im Backend auch noch Metatags. Trotzdem danke für deine Hinweise. Ist gut wenn man weiss, da passt jemand auf.
Dietmar
-
Na, dann ist's ja gut, wenn jemand das Backend prüft.
Ich muß NUR das Frontend berücksichtigen, und hier nur die Kernmodule WYSIWYG + NEWS + Kommunikation berücksichtigen.
Man darf aber nicht vergessen, daß allein die Inhaltserstellung (Medien) trotz guter Werkzeuge erheblich viel Zeit in Anspruch nimmt. Ein CMS sollte die WAI-Kriterien einhalten damit es mit der Ausgabe dieser Inhalte keine Probleme gibt. Das gilt für die Kommunikation ebenso.
Gruß, Hans>NUL
-
Hallo Hans>NUL,
ich stimme völlig mit dir überein. Bin ja sowieso ein Verfechter davon. Schön, dass ich nicht mehr alleine da stehe mit meiner Meinung. Du bist mein Mann. Wir sollten in Zukunft enger zusammen arbeiten.
Dietmar
-
<offtopic>
Du bist mein Mann.
Aber ich hab' doch schon 'ne Frau :-D
</offtopic>
WB 2.7 soll angeblich barrierefrei sein.
Gruß, Hans>NUL
-
WB 2.7 soll angeblich barrierefrei sein.
Dann hätte nwir jetzt keine Probleme
Dietmar
-
Zu Post #100
Da es anscheinend Captcha betrifft, und somit alle Eingaben, also nicht nur Form, wäre eine Rückmeldung zum Problem nicht schlecht. Richtigstellungen zur Klärung nehme ich auch gerne... oder auch gern den Hinweis auf RC2. Dann lege ich mich bis dahin erst mal hin :-D
Gruß, Hans>NUL
-
<offtopic>
Jetzt mal ne ganz blöde Frage: Wie kann ich mir die Nummern der Posts anzeigen lassen?
</offtopic>
-
hier spricht der zuständige für blöde fragen&antworten..... :-D
siehe genau über dem text deines posts....da gibts die überschrift in schwarz und fett
darunter steht dann: « Antworten #107 am: Heute um 02:55:11 »
dein post hat #107....oder war die frage anders?
mfg martin
-
Hab ich echt davor nicht gesehen. Ich sag ja, es war ne blöde Frage...
-
Zu Post #100 / #106
Im Textreader gab's kein Problem.
Screenreader und Braille habe ich noch nicht gecheckt.
Besser wär's mit WAI: Alles OK
Wird der Thread noch gelesen, oder soll ich für jeden verbliebenen Punkt ein Ticket aufmachen? :?
Oder soll ich mit meinem Friseur darüber sprechen? :-D
Gruß, Hans>NUL
-
Zwischenfrage:
Die WAI-Richtlinen galten bisher als recht schwierig und nur mit viel mitdenken umsetzbar. Scheinbar gibt es mittlerweile einen hirnlosen Test, so mit rot oder grün.
Wo ist der? Welche WAI Richtlinie wird überprüft? Kann man den genauso leicht aushebeln wie den W3C Validator?
-
Guckst Du hier:
Vischeck (http://www.vischeck.com/)
Testen kann man mit dem "Fujitsu ColorDoctor" (WB 2.8 Accessibility Check (Tools) (https://forum.WebsiteBaker.org/index.php/topic,14172.0.html))
----------------------------------------
Ja, sowas löst auch bei mir nicht immer nur Einsicht aus :evil: :evil: :evil:
Das mit rot/grün bezieht sich auf die entsprechende Farbenblindheit.
Dieser Part des Tests ist inhaltsbezogen, spielt also für die gerätebezogenen Tests keine Rolle.
Ich teste bei WB nur letztere (gerätebezogenes, also xhtml/css).
Alles andere ist Sache der Medienersteller, also TV, PDF, Bilder, Audio. Hat also nix mit WB zu tun.
Gruß, Hans>NUL
<edit>
Bei manchen Angeboten (Gutmensch-Terroristen) kann man sich wirklich nur noch an den Kopf fassen.
Beispiel:
Redakteurinnen und Redakteure haben alle veröffentlichten Textbeiträge sprachlich so bearbeitet, dass sie leicht verstehbar sind und...
Wäre daran interessiert wie ein Betrag von H. Marcuse für geistig Behinderte dann aussieht.
Soweit ich weiß, klappt sowas nur mit der Bibel
So finden sich halt immer wieder ein paar Korinthenkacker, an deren Wesen wir genesen sollen.
</edit>
-
Ääääh, mal doof gefragt... es ist auch keine Fehlermeldung, aber... Wieso macht man sowas hier? (admin/pages/index.php)
<td class="list_page_title">
<a href="<?php echo ADMIN_URL; ?>/pages/modify.php?page_id=<?php echo $page['page_id']; ?>" title="<?php echo $TEXT['MODIFY']; ?>">
<?php if($page['visibility'] == 'public') { ?>
<img src="<?php echo THEME_URL; ?>/images/visible_16.png" alt="<?php echo $TEXT['VISIBILITY']; ?>: <?php echo $TEXT['PUBLIC']; ?>" class="page_list_rights" />
<?php } elseif($page['visibility'] == 'private') { ?>
<img src="<?php echo THEME_URL; ?>/images/private_16.png" alt="<?php echo $TEXT['VISIBILITY']; ?>: <?php echo $TEXT['PRIVATE']; ?>" class="page_list_rights" />
<?php } elseif($page['visibility'] == 'registered') { ?>
<img src="<?php echo THEME_URL; ?>/images/keys_16.png" alt="<?php echo $TEXT['VISIBILITY']; ?>: <?php echo $TEXT['REGISTERED']; ?>" class="page_list_rights" />
<?php } elseif($page['visibility'] == 'hidden') { ?>
<img src="<?php echo THEME_URL; ?>/images/hidden_16.png" alt="<?php echo $TEXT['VISIBILITY']; ?>: <?php echo $TEXT['HIDDEN']; ?>" class="page_list_rights" />
<?php } elseif($page['visibility'] == 'none') { ?>
<img src="<?php echo THEME_URL; ?>/images/none_16.png" alt="<?php echo $TEXT['VISIBILITY']; ?>: <?php echo $TEXT['NONE']; ?>" class="page_list_rights" />
<?php } elseif($page['visibility'] == 'deleted') { ?>
<img src="<?php echo THEME_URL; ?>/images/deleted_16.png" alt="<?php echo $TEXT['VISIBILITY']; ?>: <?php echo $TEXT['DELETED']; ?>" class="page_list_rights" />
<?php }
echo '<span class="modify_link">'.($page['page_title']).'</span>'; ?>
</a>
</td>
Wenn die Grafiken anders heißen als der Eintrag in der DB (was so ist), würde ich mit einem assoziativen Array arbeiten.
$vis_to_img = array( 'registered' => 'keys', ... );
<img src="<?php echo THEME_URL; ?>/images/".$vis_to_img[ $page['visibility'] ]."_16.png" alt="<?php echo $TEXT['VISIBILITY']; ?>: <?php echo $TEXT[ strtoupper($page['visibility']) ]; ?>" class="page_list_rights" />
So in der Art. Oder findet Ihr das zu verwirrend?
-
Hallo,
die pages/index.php ist unser aller Sorgenkind. Ist eine uralt Entwicklung aus den Anfängen und muss neu erfunden werden, bzw geschrieben werden. Eine Umsetzung mit jquery, sowie Bereinigung des Code wäre da wohl ratsam.
Alles zu seiner Zeit. Ich hoffe, dass es bis zur 2.9 einen vernünftigne Ersatz gibt und damit auch schneller wird.
Dietmar
-
Hallo,
Ääääh, mal doof gefragt... es ist auch keine Fehlermeldung, aber... Wieso macht man sowas hier? (admin/pages/index.php)
Die admin/pages/index.php ist ehrlich gesagt momentan unser großes Sorgenkind. Eigentlich sollten auch in dieser php Datei alle styles raus und in die backend themes ausgelagert werden(.htt + .css). Aber jeder der sich dran versucht hat, hat sich bisher die Zähne ausgebissen. Deswegen ist sie auch im Vergleich zu allen anderen files im admin Verzeichnis nur ganz wenig verändert worden. Hier besteht extrem viel Handlungsbedarf.
Wäre froh es würde sich jemand finden, der hier mal aufräumt und die admin/pages/index.php in die backend themes (in alle 3) integriert. Halt nur nix davon, jetzt dadran rumzudoktern, wenn eigentlich eh klar ist, dass sie mehr oder weniger neu geschrieben werden muss.
Wegen der Grafiknamen mach ich mir da die wenigsten Probleme. Die liegen im themes_verzeichnis und können dort unter beibehaltung des namens beliebig durch eigene ersetzt werden.
Matthias
Edit:
Luisehahne war anscheinend schneller :-D
-
Hm, vielleicht kann ich mich mal dran versuchen, wenn ich mal Zeit und Lust habe. ;) Wir können uns ja mal "intern" darüber unterhalten, was da noch so alles geplant ist. (Bezüglich dieser Datei, meine ich.) Mehr als Scheitern kann ich ja auch nicht. :-D
-
Obwohl ich mit jquery einer Lösung schon sehr nahe bin. Leider fällt zwischendurch immer wieder die Internetverbindung und Telefon aus, Soll noch bis Dienstag andauern. Das unwetter war schuld.
Dietmar
-
Also brauch ich nicht gucken? Oder wie?
-
Warum nicht, manchmal ergibt 1+1 =1
Dietmar
-
Macht aber keinen Sinn, wenn zwei Leute an der gleichen Basis rumfummeln, und hinterher paßt's dann nicht zusammen.
-
SEhe ich zwar ein bisschen anders. WEil jeder hat so seine eigene Gedanlen, wie er es umsetzt. Und es funktioniert wirklich, wenn man source untereinander austauscht, das optimalste rauszuholen. Teamarbeit, ausdiskutieren, was gut sein könnte oder auchschlecht. Nur zu blöde, dass bei mir zwischendurch das Internet ausfällt. Wir sollten uns Mitte nächster Woche kurzschliessen. Vielleicht hast du ja auch Skype, dann könne nwir Gedanken austauschen.
Lese dich mal in den bestehenden Source ein. Solltest du Probleme haben, so kann ich dir bestimmt helfen.
Dietmar
-
trunk1094
auf WB-Portable
Test auf xHTML-Fehler
frontend,js befindet sich nicht im Header (ergab sonst bekannten WAi noscript-Fehler (nicht erneut getestet)
Fehler, durch fehlende Einträge im Header (Meta-Tags) wurden auch ignoriert (nicht erneut getestet)
News + Kommentar = OK
News ausgeklappt (weiterlesen) + Kommentar = Fehler src="" alt=""
Output:
<td height="30"><h1>Nachrichten</h1></td>
<td rowspan="3" style="display: none"><img src="" alt="" /></td>
</tr>
Dieser Fehler war schon in WB 2.8 RC1 trunk-r1068 drin.
News ausgeklappt (weiterlesen) + ohne Kommentar = Fehler
1.) Wie oben angegeben
2.) Beanstandet wird <table cellpadding="2" cellspacing="0" border="0" width="98%"></table>
The "table" element must directly contain at least one of the following elements: "tr", "thead", "tbody", "tfoot", "col", "colgroup", "caption".
Output:
<a href="http://127.0.0.1:4001/wb28rc2/pages/news.php">Zurück</a><br /><br />
<h2>Kommentare</h2>
<table cellpadding="2" cellspacing="0" border="0" width="98%"></table>
<br /><a href="http://127.0.0.1:4001/wb28rc2/modules/news/comment.php?id=3&sid=2">Kommentar hinzufügen</a> </div>
Form-Module = Diverse Fehler
1.) The attribute "multiple" does not have a value. (Steht da in der Gegend rum)
2.) The "id" or "name" attribute value "wb_Option_1"<(1/2/3) has already been used in this document.
3.) The "maxlength" attribute has an invalid attribute value ""
WAI hat bei diesen Tests nicht gemeckert :-D :-D :-D
(ASP abgeschaltet, Felder noch nicht erneut geprüft)
Es müßte auf Reproduzierbarkeit gescheckt werden.
Gruß, Hans>NUL
-
Eine Anmerkung noch. Das Textfeld "Kurztext" ist aus meiner Sicht etwas mehr als kurz ausgefallen.
Kann man das etwas größer gestalten, oder die Länge selbst bestimmen (inkl dynamisch (100%) ?
Gruß, Hans>NUL
-
Im News Modul fehlen Abfragen ob $numrow > 0, ansonsten gibt er die von dir geschilderte Fehlermeldung
2.) Beanstandet wird <table cellpadding="2" cellspacing="0" border="0" width="98%"></table>
aus. Bin noch nicht am Ende. Schaue weiter.
Dietmar
-
Installation WB-Portable
Wb 2.8 trunk1115
(x)html-Fehlermeldungen
WYSIWYG & NEWS
<a class="section_anchor" id="wb_1" name="wb_1"></a> </div>
Das "name"-Attribute ist in xhtml 1.0 nicht erwünscht und wurde in Version 1.1 entfernt.
Diese Feststellung ist keine Fehlermeldung, sondern nur ein Hinweis für Template-Ersteller.
Entfernt man im Backend unter Abschnitts-Anker Text den Anker "wb_" tritt diese Inkompatibilität nicht mehr auf.
NEWS
Tritt in der Übersicht von NEWS auf.
<td class="post_title"><a href="#" onclick="javascript:void(0);return false;" style="cursor:no-drop;">Nachrichten</a></td>
und
<span style="visibility:none;"><a href="#" onclick="javascript:void(0);return false;" style="cursor:no-drop;"></a></span>
Beanstandet wird href="#" ,da als LINK formatiert, der aber nicht existiert (Seite.php#).
Der WAI-Test ergab keine Fehlermeldung (wenn META-TAGS auch "gefüllt" sind)
FORM und Captcha wurden noch nicht getestet.
Gruß, Hans>NUL
-
Danke für deine Tests.
News und Form liegen noch im Argen. Einiges ist schon beseitigt, aber eben noch nicht alles. Bin aber dran. Da es aber Module sind und nicht zum Core gehören, werde nspäter bereinigte Versionen nachgezogen. Hoffe das ist ok?
Aber teste trotzdem, damit ich weiss, wo ich anpacken muss.
Dietmar
-
News und Form liegen noch im Argen.
Form ist mir letztendlich nicht wichtig, da Alternativen existieren.
NEWS sollte aber stimmen, da es mit WYSIWYG die einzigen Module sind, die für die Inhaltserstellung nötig sind.
Das war ja die grundsätzliche Verärgerung bei den Kunden, daß noch nicht mal diese fehlerfrei funktionierten. Da werden saubere und aufwendige Templates erstellt und anschließend dann sowas. Für Medien-Inhalte gibt's klassische Lösungen und eine saubere Möglichkeit der Einbindung. Aber auch das geht schief, wenn die o.a. Module nicht sauber funktionieren.
Wenn man dann noch nahelegt, daß diese Module nicht zum CORE gehören, können die Kunden ja direkt zu funktionierenden Frameworks wechseln. Ein einfach zu bedienendes CMS muß doch nicht zwangsläufig auch schlecht sein. Was andere Module betrifft, ist klar, daß die XHTML-Schrott produzieren, hauptsache Effekte. Ich möchte nur, daß das wenige sauber funktioniert; wohlgemerkt nach mittlerweile einem Jahr.
Gruß, Hans>NUL
-
Naja jetzt bleib mal auf dem Teppich. Es ist viel passiert letzte Zeit. Werde mich wegen dir bestimmt nicht überschlagen müssen. Alles der Reihe nach und hau nicht so auf den Putz. Kommt nicht so gut. Wir wollen doch nett miteinander umgehen. Tue ich doch mit dir auch.
Es geht im Moment eim News Modul hauptsächlich um den Kommentar Bereich. Teste mal und schreibe was dir auffällt.
Dietmar
-
Ich habe nicht "auf den Putz" gehauen, sondern nur eine Feststellung getroffen.
Du bist da nicht persönlich gemeint. Die Identifizierung mit einem Projekt muß trotzdem auch sowas ertragen.
Die Leistungen, die Ihr speziell in den letzten Monaten hervorgebracht habt, werden dadurch überhaupt nicht geschmälert, sondern von allen mehr als gelobt. Daß dabei einzelne wirklich mit Biß dabei sind wird auch erkannt und gewürdigt. Also bitte keine Mißverständnisse produzieren
Gruß, Hans>NUL
-
Teste mal und schreibe was dir auffällt.
Das mit dem Pfadsprung nach MODULE ? ? ?
Teste nur xhtml, nicht die WB-Funktionalität
Gruß, Hans>NUL
-
Es sollte auc heinwandfrei funktionieren und nicht nur valide sein. Also auch wenn er Fehler beim anlegen, usw. produziert. Mal auf Herz und Nieren prüfen, wenns dir möglich ist.
Dietmar
-
Achja vergessen. Hol dir bitte aber den letzten Trunk (1115), da dort schon einiges bereinigt ist. Sonst suche ich mich tot.
Dietmar
-
Das Teil ist ja richtig gemein.
Beim Anlegen des dritten Kommentars flippts nach "HOME", und der Eintrag fehlt.
Wärri häftisch
Isch abe Wb 2.8 trunk1115 :-D
Edit: jetzt klappte es gerade wieder mit den Anlegen. Könnte also auch ein lokales Problem gewesen sein.
Edit: Läßt sich nicht reproduzieren. Werde nochmal alles löschen und von vorne..........
Nicht reproduzierbar
Aber wie ich an Deinem Kommentar sehe, war ich nicht blind :-D
-
Beim Anlegen des dritten Kommentars flippts nach "HOME", und der Eintrag fehlt.
Wärri häftisch
Jau das isses was er auch bei mir macht. Das Komische ist, wenn du einen Captcha Fehler hast springt er zur Startseite. Gehst du wieder in News rein und Kommentar hinzufügen, siehst du deinen Kommentar und die Fehlermeldung. Gut ich habe es auch lokal getestet. Werde es mal im Web versuchen.
Dietmar
-
Anscheinend wird das Ticket zu/m Fehler/n nicht mehr für 2.8 bearbeitet.
Gibt's dafür 'ne nachvollziehbare Erklärung?
Gruß, Hans>NUL
-
Hallo,
Anscheinend wird das Ticket zu/m Fehler/n nicht mehr für 2.8 bearbeitet.
Fixes kommen frühestens in einer 2.8.1. Wenn wir das in 2.8 noch reinpacken wollen wird es vermutlich Weihnachten bis es eine 2.8 Final geben wird und das ist eindeutig zu lang.
Matthias
-
Bisher war WB (m)eine Empfehlung für kleine sozial engagierte Leute die eine Website wollten. Nach einem Jahr gemachter Erfahrungen gilt dies nicht mehr. Der Mehraufwand, der wiederum durch andere kostenlos arbeitende Leute erbracht werden mußte, ist es nicht wert. Die Frickeleien hinterlassen zudem keinen guten Eindruck. Möchte nicht noch einmal erleben, daß eine Installation entfernt wird weil "das Teil nur nervt und den Betrieb aufhält". Hier werden also zukünftig die bisher eingesetzten CMS/Frameworks wieder an erster Stelle stehen.
Aaaaaaaaaber
Nach Abschluß der Upgrades der verbliebenen 8 Domains, ist es nur einer, der einen Wechsel des CMS verlangt hat und ihn auch verlangen kann. Den anderen sind die Fehler bekannt, ist ihnen aber auch egal, solange "nichts grobes" passiert. Außerdem haben die wegen Haftungssauschluß keinen Anspruch auf kostenlosen Wechsel. Auf dem Papier habe ich jetzt also noch 7 WB-Installationen, wo nicht nur keiner meckert, sondern man auch zufrieden ist.
Ich hatte ja -wie erwähnt- in diesen Fällen Angst "die Arschkarte" zu ziehen. Also nochmal Glück gehabt.
Gruß, Hans>NUL