CMS Made Simple Forums

Wer sich etwas Zeit nimmt und über einen Debugger verfügt, der kann erstaunlich viele Warnungen erhalten, die aus dem PHP - Code der CMS kommen.

z.B.

Warning: strstr() [function.strstr]: Empty delimiter. in I:\xampp\htdocs\011\plugins\function.bulletmenu.php on line 191

Das deutet auf unsauber programmierte Einheiten hin und kann durchaus in Fehlfunktionen enden.

Ja es kann sogar je nach Einstellung des Webservers zu einem Abriss komm, wenn der auf Warnungen wie auf Fehler reagiert.

Im Bereich preview tauchen verstärkt solche Warnungen auf, aber auch in diversen Funktionseinheiten.

Empfehlung - die Developer sollten ebenfalls mal Debuggerläufe machen.

Dein Vorschlag ist eindeutig ein Fall für die "Principals, Policies and Standards for Module Development" - guckst Du hier ..

Ja das kenne ich

Punkt 1

Da geht das Problem schon los. Wer tested etwas und wie kommen die Rückmeldungen in einer Art, bei mit der ein Developer etwas anfangen kann
Das gleiche Thema ist dann, wenn etwas veröffentlicht wird - die Gefahr ist gross, dass in vielen Fällen Unzulänglichkeiten der Anwender oder dessen Webservers nachgejagt wird.
Meine Devise - eigener Beta Tester, wobei das natürlich den Nachteil hat, dass man nicht alle denkbaren Kombinationen die es an Webservervariationrn, PHP - Variationen, Mysql - Versionen und was noch schlimmer ist, individuellen Einstellungsmöglichkeiten dieser Produkte betrifft, abdecken kann und auch nicht will.
Ich teste daher immer mit den aktuellsten Versionen unter Verwendung von XAMPP bzw. LAMPP (wobei es zwischen diesen beiden auch schon Unterschiede gibt).

Punkt 2

Ist ja alles gut und schön, aber welcher Anwender liest sich das schon durch und handelt entsprechend der Information.
Der hätte im Zweifelsfall schon ein erhebliches Problem detailierte Hinweise verstehen zu können.


Punkt 3

Auch das betrifft meiner Meinung nicht die Masse der Anwender und wegen einigen wenigen Leuten mache ich bestimmt nicht den Aufwand.

Punkt 4

Da spricht einiges dafür und viel mehr dagegen. Ich glaube erstens nicht dass es viele Leute gibt, die nach Punkt 3 downloaden.
Haben die ein richtiges Problem mit einer Release, dann haben es auch andere.
Die Leute machen eher ein Download der neuesten Release in der berechtigten Annahme, dass Fehler beseitigt wurden.
Damit reduziert sich aber auch die Anzahl der Neumeldungen alter Probleme
---------------------------------
Wer sich tatsächlich an diese vorgeschlagenen Punkte hält, sorgt dafür, dass zu lange mit veralteten oder fehlerhaften Einheiten bei den Anwendern gearbeitet wird und das bedeutet viele unnütze Rückmeldungen, Threads und immer wieder Beschäftigung mit bereits erledigten Themen.
Auf der anderen Seite blockiert man sich wie ein Beamter seine mickrigen Kapazitäten und handelt erst einmal nach Checkliste und programmiert dann.
Das ist der sichere Weg in den Abgang einer Software.

Ich für meinen Teil bringe stets neue Releases raus, wenn sich da etwas geändert hat wie z.B. Fehlerbeseitigung.
Das hat zur Folge, dass unterm Strich erstaunlich wenig negative Rückmeldungen kommen - der Grund - die Leute , die meinen ein Problem zu haben, holen sich die jeweils letzte Version.
Und - sie erkennen, dass man auf ihre Meldungen im Forum reagiert. Bei Bug - Meldungen zur CMS hat es schon mal Monate gedauert, bevor überhaupt eine Reaktion kam, das wollen die Leute nicht.

Bei Virenscanner oder Spybotscannern wäre das ständige Zögern mit einer neuen Release tödlich und ähnlich denke ich bei den CMS - Scripten.

Piratos wrote: Punkt 1

Ich teste daher immer mit den aktuellsten Versionen unter Verwendung von XAMPP bzw. LAMPP (wobei es zwischen diesen beiden auch schon Unterschiede gibt).

Genau, irgend wo muss man ja mal auf Standards setzen. Aber vielleicht sollte in jede Doku ein Punkt aufgenommen werden - erfolgreich getestet unter Xampp 1.5.1 (oder so ähnlich).

Mir geht es da speziell um Punkt 1, da offensichtlich manche Devs selbst nicht ausreichend testen (Anwesende ausgeschlossen  ). Dein Debugger-Durchlauf beweist es ja eindeutig.

Was mir auch aufgefallen ist: CMSms ist bzw. soll ein XHTML-CMS sein. Das bedeutet nach meinem Verständnis, dass auch der Output (egal, ob Output des Modules, des Admins oder der Doku) xhtml-valid sein muss. XHTML-Fehler sind für mich keine Programmierfehler; so schwer ist doch xhtml nun wirklich nicht.

Anders gesagt, so lange ein Modul/Tag nicht xhtml-valid ist, ist es kein Modul bzw. Tag für CMSms.

erfolgreich getestet unter Xampp 1.5.1

Da stellt sich nur die Frage, wer kann mit dem Begriff Xampp etwas anfangen ? Der normale User ?

Und erfolgreich ? Das ist solch eine Sache, denn selbst beim testen gehen einem manchmal Dinge durch die Lappen, weil  es u.U. zig Kombinationen gibt in einem Script selbst und bestimmte Dinge nur in einer bestimmten Situation auftreten und dann haut man in der letzten Sekunde vorm Versand noch einen Tippfehler rein.

XHTML-Fehler sind für mich keine Programmierfehler

Für mich eigentlich schon.  Scripte erzeugen logischerweise immer einen Output und damit ist ein falsch formuliertes Output auch ein Fehler, egal ob es nun eine PHP - Anweisung ist oder eine (X)HTML - Sache.
Man stelle sich das mal bei einer Textverarbeitung vor - Input gut Druck Scheibenkleister, da würde jeder User sofort schreien.Nur weil Browser sehr viel Zeit verwenden um HTML Fehler zu erkennen und zu interpretieren, sieht es hier der Anwender nicht direkt

Würde man z.B. bei XML so grosszügig sein, würde keine einzige Seite zur Anzeige gelangen.

Meine damaligen Arbeiten mit XOOPS haben nachgewiesen, dass so etwas bei einer CMS sich zu Geschwindigkeitsverlusten bis zu 10% führen kann. Was macht man auf der anderen Seite für einen Aufwand um diese CMS nur um paar Bruchteile einer Sekunde zu beschleunigen.

Piratos wrote: Da stellt sich nur die Frage, wer kann mit dem Begriff Xampp etwas anfangen ?

Ich habe den Begriff xampp an dieser Stelle nur als Oberbegriff gewählt, um hier nicht alle möglichen Apache/PHP/MySQL/Postgres-Versionen aufzählen zu müssen, die man testen kann  .

Piratos wrote:

XHTML-Fehler sind für mich keine Programmierfehler

Für mich eigentlich schon.  Scripte erzeugen logischerweise immer einen Output und damit ist ein falsch formuliertes Output auch ein Fehler, egal ob es nun eine PHP - Anweisung ist oder eine (X)HTML - Sache.

OK, ist vielleicht etwas drastisch formuliert, aber ich kann mich da an eine Anfrage hier im Forum vor 1 Monat erinnern, da kam es nur zu Fehlern in der Anzeige, weil der content nicht xhtml-valid war.

Und auch wenn ich mir die 0.11er addcontent.php ansehe - 6 XHTML-Fehler, nur weil dem input-Tag der abschließende Slash fehlt - das muss/darf nicht sein.

Was macht man auf der anderen Seite für einen Aufwand um diese CMS nur um paar Bruchteile einer Sekunde zu beschleunigen.

Siehe oben - es geht manchmal nicht nur um Geschwindigkeit, sondern auch um eine saubere Darstellung  . Außerdem - wenn man sich in der Computerwelt schon mal auf einen Standard einigt (was ja selten genug vorkommt - ich sage da nur BluRay & Co), sollte man sich IMHO auch mal daran halten.

Ein Standard könnte so aussehen:

1. Scripterstellung unter aktuellesten Versionen von Apache Mysql Php (z.B. xampp, lampp)
2. Nur Verwendung von Funktionen, die es unter den kleinst möglichen PHP Nenner bereits gab (z.B. 4.3), das wäre dann die minimal erforderliche Version
3. die CMS muss bei den Fremdlibs (adodb,log4php,smarty, fckeditor) stets auf dem laufenden sein und nicht wie bis jetzt z.B. adodb version 4.65, 4.66  - aktuell ist 4.7, ähnliches bei smarty - da entzieht man z.Z. den Schreiberlingen die Basis praktisch und auch moralisch - man verlang mehr von ihnen als die CMS Führung selbst zu leisten bereit ist.
4. Eigentest unter Windows und Linux
5. Stetige Veröffentlichung der aktullen Version (build).

SVN hat für mich nur einen Sinn wenn mehrer Autoren gleichzeitig an einer Sache schreiben, dass dürfte für die Mehrzahl nicht zuterffen, ansonsten ist das ein ziemlicher Aufwand, da man ja auch mit SVN fähigen Umgebungen arbeiten muss = Totgeburt bei externen Schreiberlingen.

Auf der anderen Seite muss man klar sehen, dass die Verbreitung der CMS minimal ist, wenn in ganz Deutschland 200 aktive Webseiten mit der CMS existieren, dann war ich wahrscheinlich schon optimistisch. - Marktanteil ist da kaum noch auszudrücken. Das kann man nur ändern mit mehr Leistung und schnellerer Abgabe der Leistung.

Piratos wrote: Ein Standard könnte so aussehen:

1. Scripterstellung unter aktuellesten Versionen von Apache Mysql Php (z.B. xampp, lampp)
2. Nur Verwendung von Funktionen, die es unter den kleinst möglichen PHP Nenner bereits gab (z.B. 4.3), das wäre dann die minimal erforderliche Version
3. die CMS muss bei den Fremdlibs (adodb,log4php,smarty, fckeditor) stets auf dem laufenden sein und nicht wie bis jetzt z.B. adodb version 4.65, 4.66  - aktuell ist 4.7, ähnliches bei smarty - da entzieht man z.Z. den Schreiberlingen die Basis praktisch und auch moralisch - man verlang mehr von ihnen als die CMS Führung selbst zu leisten bereit ist.
4. Eigentest unter Windows und Linux
5. Stetige Veröffentlichung der aktullen Version (build).

Klingt für mich gut, hast meine volle Unterstützung.

Da ja aber noch nix festgelegt und noch alles offen ist, wäre es vielleicht nicht schlecht, wenn Du Deine Ideen in die Diskussion im englischen Forum einbringst.