shwups-CMS tester gesucht

[töbi]

Hallo

ich habe hier den source-code des shwups-cms freigegeben

https://github.com/nuxodin/shwups-cms

Wenn jemand Lust hat zum testen, helfe ich gerne bei der Installation.

Gruss
tobi

[Tom]

Hello,

ich habe hier den source-code des shwups-cms freigegeben

https://github.com/nuxodin/shwups-cms

Gibt es das auch irgendwo vernünftig gezipped oder habe ich das übesehen?

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[der Frager]

Hallo,

ich habe hier den source-code des shwups-cms freigegeben

https://github.com/nuxodin/shwups-cms

Gibt es das auch irgendwo vernünftig gezipped oder habe ich das übesehen?

wie funktioniert das eigentlich, dieses Github? Bekommt man da Zugang zu ner Shell oder Web-Frontend oder sowas und kann dann wie gewöhnlich Versionierung betreiben (indem man Dateien verändert und dann die Reps online bei Github pushed bzw. pulled oder wie auch immer)? Irgendwie ist mir das nicht klar.

Fragen über Fragen

[Töbi]

wie funktioniert das eigentlich, dieses Github? Bekommt man da Zugang zu ner Shell oder Web-Frontend oder sowas und kann dann wie gewöhnlich Versionierung betreiben (indem man Dateien verändert und dann die Reps online bei Github pushed bzw. pulled oder wie auch immer)? Irgendwie ist mir das nicht klar.

Ja, mit push und pull.
Ähnlich wie svn.

Gruss
Töbi

[dedlfix]

Hi!

https://github.com/nuxodin/shwups-cms

In den Requirements hast du short_open_tag = on stehen. Das ist völlig in Ordnung, wenn du es nur bei das bei deinen eigenen Sachen so verwendest. Aber es gibt genügend PHP-Anwender, die das aufgrund einer kleinen Inkompatibilität zur XML-Deklaration abgeschaltet haben. Auch die Magic Quotes - obwohl ihr bevorstehendes Ableben schon seit Jahren angekündigt wurde - sind noch vielerorts eingeschaltet. Es ist gut, die Deaktivierung zu empfehlen, doch das ist für Hoster-Kunden nicht unbedingt einfach erledigt, weil das außerhalb der Scripte gemacht werden muss. Besser ist es, den Code von Example #2 ins Script zu nehmen.

Da ich mir kein git-Dingens installieren möchte, hab ich nur mal so in einige wenige Code-Dateien geschaut.

In m/core/sysinit.php versuchst du ini_set('magic_quotes_gpc' ,'off'); auszuführen. Wenn du mal den Rückgabewert von ini_set() anschauen würdest, sähest du, dass dieser false ist. Du kannst die Magic Quotes nicht zur Laufzeit deaktivieren, denn sie haben ihre Arbeit bereits vor dem Scriptstart getan. Du kannst lediglich mit o.g. Code ihre Auswirkungen rückgängig machen.

Ich sehe (stichprobenartig) keine Code-Kommentierung. Wenn du mal eine Weile nichts mehr an dem Projekt gemacht hast, wirst du dich ganz sicher nicht mehr genau erinnern, wofür jetzt nochmal die eine Methode den Parameter $vs und die andere das $m haben wollte.

Und bist du sicher, dass das Zusammenbauen eines Statements wie in der project/index.php

D()->query("UPDATE log SET page_id = '".Page()."' WHERE id = '".liveLog::$id."'");

den Kontextwechsel angemessen berücksichtigt? Und warum setzt du auch garantierte Integer-Werte in Stringbegrenzer wie bei: " expires = '".(int)$expires."', "? Das macht MySQL zwar nichts aus, aber überflüssig ist es immer noch. Außerdem nimmst du doch PDO, warum nimmst du dann nicht auch Prepared Statements und bist alle Quotier- und Maskiersorgen los?

Es gibt extra für Beispiele reservierte Domainnamen, da muss man keine potentiell existierenden Phantasie-Domains wie asdfasdf.ch verwenden.

Lo!

[Töbi]

Hi

In den Requirements hast du short_open_tag = on stehen. Das ist völlig in Ordnung, wenn du es nur bei das bei deinen eigenen Sachen so verwendest. Aber es gibt genügend PHP-Anwender, die das aufgrund einer kleinen Inkompatibilität zur XML-Deklaration abgeschaltet haben. Auch die Magic Quotes - obwohl ihr bevorstehendes Ableben schon seit Jahren angekündigt wurde - sind noch vielerorts eingeschaltet. Es ist gut, die Deaktivierung zu empfehlen, doch das ist für Hoster-Kunden nicht unbedingt einfach erledigt, weil das außerhalb der Scripte gemacht werden muss. Besser ist es, den Code von Example #2 ins Script zu nehmen.

Dass die xml-process-instructions nicht mehr xml konform sind, nehme ich in kauf weil es damit viel einfacher und übersichtlicher aussieht. Ich habe mir das lange überlegt und da die PHP-Dateien nicht mit einem xml-parser geparsed werden, wählte ich "Schönheit" vor (in diesem Fall)"unrelevanter Konformität".
Aber dein Argument ist berechtigt.

Beim den Magic Quotes stimme ich der ausdrücklichen Warnung auf php.net zu.
Vor allem auch mit der Philosophie auf künftige Entwicklungen zu setzen und keine Altlasten mitzunehmen.

In m/core/sysinit.php versuchst du ini_set('magic_quotes_gpc' ,'off'); auszuführen. Wenn du mal den Rückgabewert von ini_set() anschauen würdest, sähest du, dass dieser false ist. Du kannst die Magic Quotes nicht zur Laufzeit deaktivieren, denn sie haben ihre Arbeit bereits vor dem Scriptstart getan.

Danke für den Hinweis, ich habe die Anweisung raus genommen.

Ich sehe (stichprobenartig) keine Code-Kommentierung. Wenn du mal eine Weile nichts mehr an dem Projekt gemacht hast, wirst du dich ganz sicher nicht mehr genau erinnern, wofür jetzt nochmal die eine Methode den Parameter $vs und die andere das $m haben wollte.

Da muss ich dir recht geben, an Kommentaren mangelt es noch. :/
Zu viel Kommentare erachte ich als unübersichtlich.
Es gibt ein paar Konventionen die ich noch irgendwo festhalten sollte, z.B. $vs heisst immer "values" (ein array mit Werten)

Und bist du sicher, dass das Zusammenbauen eines Statements wie in der project/index.php

D()->query("UPDATE log SET page_id = '".Page()."' WHERE id = '".liveLog::$id."'");

Ja, das sind garantiert ganzzahlige Zahlen.

den Kontextwechsel angemessen berücksichtigt? Und warum setzt du auch garantierte Integer-Werte in Stringbegrenzer wie bei: " expires = '".(int)$expires."', "? Das macht MySQL zwar nichts aus, aber überflüssig ist es immer noch.

Ich weiss gerade nicht wo du das gefunden hast, aber wenn es garantiert ein Integer-Wert ist ändere ich das.

Außerdem nimmst du doch PDO, warum nimmst du dann nicht auch Prepared Statements und bist alle Quotier- und Maskiersorgen los?

Die verwende ich zum Teil, finde sie bei solch einfachen Querys einfach unübersichtlicher.

Es gibt extra für Beispiele reservierte Domainnamen, da muss man keine potentiell existierenden Phantasie-Domains wie asdfasdf.ch verwenden.

Ok, kannte ich bis jetzt nicht.
Wo bist du auf asdfasdf.ch gestossen?

To!

[dedlfix]

Hi!

Beim den Magic Quotes stimme ich der ausdrücklichen Warnung auf php.net zu.
Vor allem auch mit der Philosophie auf künftige Entwicklungen zu setzen und keine Altlasten mitzunehmen.

Eine Altlast wäre, sich auf eingeschaltete MQs zu verlassen. Das tust du nicht, aber du stellst auch nicht sicher, dass sie keinen Unfug anstellen, wenn sie auf einem Zielsystem angeschaltet sind. Wenn du die MQs nicht stillschweigend entfernen willst, könntest du eine Warnung einbauen, die auf eingeschaltete MQs hinweist.

Da muss ich dir recht geben, an Kommentaren mangelt es noch. :/
Zu viel Kommentare erachte ich als unübersichtlich.

Das gesunde Mittelmaß machts, und natürlich vor allem die Art der Kommentare. Gute Kommentare erklären nicht den Code, sondern die Intention dahinter.

Es gibt ein paar Konventionen die ich noch irgendwo festhalten sollte, z.B. $vs heisst immer "values" (ein array mit Werten)

Sprechende Namen wären mir lieber. "Values" kann ja für alles mögliche stehen. Besser fände ich es, wenn man ihre Bedeutung dem Variablennamen entnehmen könnte.

Und bist du sicher, dass das Zusammenbauen eines Statements wie in der project/index.php
  D()->query("UPDATE log SET page_id = '".Page()."' WHERE id = '".liveLog::$id."'");
den Kontextwechsel angemessen berücksichtigt?
Ja, das sind garantiert ganzzahlige Zahlen.

Du darfst es nur nicht vergessen, solche Stellen mit zu berücksichtigen, wenn du nicht mehr gerantieren kannst, dass nur Zahlen enthalten sind. Im Allgemeinen möchte man als Programmierer solchen Code nicht sehen, weil da augenscheinlich eine Behandlung durch Abwesenheit glänzt. Und aufgrund der Tatsache, dass das einer der häufigsten Programmierfehler ist, schrillen einem dabei immer die Alarmglocken in unangenehmen Tönen.

Und warum setzt du auch garantierte Integer-Werte in Stringbegrenzer wie bei: " expires = '".(int)$expires."', "? Das macht MySQL zwar nichts aus, aber überflüssig ist es immer noch.
Ich weiss gerade nicht wo du das gefunden hast, aber wenn es garantiert ein Integer-Wert ist ändere ich das.

Weiß ich nicht mehr. Dein Editor hat doch bestimmt "Suchen in Dateien"?

Außerdem nimmst du doch PDO, warum nimmst du dann nicht auch Prepared Statements und bist alle Quotier- und Maskiersorgen los?
Die verwende ich zum Teil, finde sie bei solch einfachen Querys einfach unübersichtlicher.

Naja, ich empfinde es nicht als übersichtlich, den SQL-Statement-String immerzu zu unterbrechen, um die Werte einzufügen. Und im Gegensatz zur mysqli-Extension sind doch Prepared Statements bei PDO sogar recht angenehm zu bedienen.

Wo bist du auf asdfasdf.ch gestossen?

Weiß ich auch nicht mehr, war an einer Stelle, an der du eine Email zusammenbaust.

Lo!

[Töbi]

Eine Altlast wäre, sich auf eingeschaltete MQs zu verlassen. Das tust du nicht, aber du stellst auch nicht sicher, dass sie keinen Unfug anstellen, wenn sie auf einem Zielsystem angeschaltet sind. Wenn du die MQs nicht stillschweigend entfernen willst, könntest du eine Warnung einbauen, die auf eingeschaltete MQs hinweist.

Ja, eine Warnung einzubauen wäre Sinnvoll.

Das gesunde Mittelmaß machts, und natürlich vor allem die Art der Kommentare. Gute Kommentare erklären nicht den Code, sondern die Intention dahinter.

Dem stimme ich zu.

Du darfst es nur nicht vergessen, solche Stellen mit zu berücksichtigen, wenn du nicht mehr gerantieren kannst, dass nur Zahlen enthalten sind. Im Allgemeinen möchte man als Programmierer solchen Code nicht sehen, weil da augenscheinlich eine Behandlung durch Abwesenheit glänzt. Und aufgrund der Tatsache, dass das einer der häufigsten Programmierfehler ist, schrillen einem dabei immer die Alarmglocken in unangenehmen Tönen.

Dein Argument hat schon was...

Sprechende Namen wären mir lieber. "Values" kann ja für alles mögliche stehen. Besser fände ich es, wenn man ihre Bedeutung dem Variablennamen entnehmen könnte.
Naja, ich empfinde es nicht als übersichtlich, den SQL-Statement-String immerzu zu unterbrechen, um die Werte einzufügen. Und im Gegensatz zur mysqli-Extension sind doch Prepared Statements bei PDO sogar recht angenehm zu bedienen.

Siehe meine Argumente in diesem Post:
http://forum.de.selfhtml.org/?t=202167&m=1365285

Gruss
Töbi

[Vinzenz Mai]

Hallo,

Ich sehe (stichprobenartig) keine Code-Kommentierung. Wenn du mal eine Weile nichts mehr an dem Projekt gemacht hast, wirst du dich ganz sicher nicht mehr genau erinnern, wofür jetzt nochmal die eine Methode den Parameter $vs und die andere das $m haben wollte.

Da muss ich dir recht geben, an Kommentaren mangelt es noch. :/
Zu viel Kommentare erachte ich als unübersichtlich.
Es gibt ein paar Konventionen die ich noch irgendwo festhalten sollte, z.B. $vs heisst immer "values" (ein array mit Werten)

$values ist ein wesentlich besserer Variablenname als $vs und ist dennoch ein schlechter Variablenname, weil "Werte", ein Array mit "Werten" *nichts* aussagt. Eine Variable enthält typischerweise einen Wert (das kann auch ein Array, ein Objekt oder sonstwas sein). Der Variablenname sollte so gewählt sein, dass man weiß oder zumindest ahnen kann um *was* es sich bei den "Werten" handelt.

Zusätzlich willst Du Dich um ausführliches, sinnvolles Kommentieren drücken?
Find' ich nicht gut.

D()->query("UPDATE log SET page_id = '".Page()."' WHERE id = '".liveLog::$id."'");

Ja, das sind garantiert ganzzahlige Zahlen.

Und ganz genau deswegen ist bei dieser Codezeile in dieser Form ein Kommentar *zwingend* erforderlich:

# Der Rückgabewert von Page() und liveLog::$id sind garantiert ganze Zahlen,  
# deswegen ist keine Maskierung erforderlich  
D()->query("UPDATE log SET page_id = '".Page()."' WHERE id = '".liveLog::$id."'");  

[...]

Ich weiss gerade nicht wo du das gefunden hast, aber wenn es garantiert ein Integer-Wert ist ändere ich das.

Da zum Beispiel :-)

Außerdem nimmst du doch PDO, warum nimmst du dann nicht auch Prepared Statements und bist alle Quotier- und Maskiersorgen los?

Die verwende ich zum Teil, finde sie bei solch einfachen Querys einfach unübersichtlicher.

den zwingend erforderlichen Kommentar kannst Du Dir durch Verwenden der Prepared Statements sparen.

Wie dedlfix halte ich solche Zeichenkettenverkettungen für sehr unübersichtlich, verstärkt noch durch die fehlenden Leerzeichen vor und nach den Verkettungsoperatoren.

Freundliche Grüße

Vinzenz

[Töbi]

$values ist ein wesentlich besserer Variablenname als $vs und ist dennoch ein schlechter Variablenname, weil "Werte", ein Array mit "Werten" *nichts* aussagt. Eine Variable enthält typischerweise einen Wert (das kann auch ein Array, ein Objekt oder sonstwas sein). Der Variablenname sollte so gewählt sein, dass man weiß oder zumindest ahnen kann um *was* es sich bei den "Werten" handelt.

Die Deklaration von $vs ist nie weit entfernt, sodass ich sofort den Bezug dazu habe. schneller als wenn ich schreibe $ResultatDerDBAbfrageWoIchInDerTabelleUsersNachDemMitDerEntsprechendenIdGesuchtHabe

Zusätzlich willst Du Dich um ausführliches, sinnvolles Kommentieren drücken?
Find' ich nicht gut.

Um zu ausführliches möchte ich mich drücken, um sinnvolles nicht. Ich stosse oft auf fremden Code, bei dem ich erst drei viertel der Kommentare löschen muss damit ich mir einen Überblick verschaffen kann.

Und zwar genau solche Kommentare:

Der Rückgabewert von Page() und liveLog::$id sind garantiert ganze Zahlen,

deswegen ist keine Maskierung erforderlich

D()->query("UPDATE log SET page_id = '".Page()."' WHERE id = '".liveLog::$id."'");

  
Jetzt mal ehrlich, in diesem Fall musst du doch hier annehmen dass Page() eine "page\_id" also eine Zahl zurück gibt. Und wenn du Zweifel hast schaust du dir die Funktion Page() genauer an, dann weisst du es auch gleich für die Zukunft.  
Aber um dem Entwickler-Kollegen die Qualität von meinem Code zu versichern, blase ich ihn nicht sinnlos mit Kommentaren auf.  
  

> den zwingend erforderlichen Kommentar kannst Du Dir durch Verwenden der Prepared Statements sparen.  
  
Vergleiche:  
\-------------------------------------------------------  
~~~php
  
$stmt = D()->prepare("UPDATE log SET page_id=:page_id WHERE id = :id ");  
$stmt->bindParam(':page_id', Page() );  
$stmt->bindParam(':id', $liveLog::$id );  
$stmt->execute();  

vs

  
D()->query("UPDATE log SET page_id = '".Page()."' WHERE id = '".liveLog::$id."'");  

-------------------------------------------------------

Also ich habe bei der zweiten Variante viel schneller kapiert was passiert.
Gut man könnte die prepared statments in einer Funktion kapseln damit es irgendwie so aussieht:

  
D()->myPreparedQuery("UPDATE log SET page_id=? WHERE id = ? ", Page(), $livelog::$id);  

Das wäre eventuell noch sinnvoll, auch um andere Entwickler zu beruhigen :)
Hat die Nachteile, dass es nicht mehr ganz so gut lesbar ist und dass man einen Zwischenschritt einbaut, was die Komplexität des Codes erhöht.

Gruss
Töbi

[dedlfix]

Hi!

Die Deklaration von $vs ist nie weit entfernt, sodass ich sofort den Bezug dazu habe. schneller als wenn ich schreibe $ResultatDerDBAbfrageWoIchInDerTabelleUsersNachDemMitDerEntsprechendenIdGesuchtHabe

$userData oder etwas ähnlich ist sicher weder übertrieben noch nichtssagend.

Um zu ausführliches möchte ich mich drücken, um sinnvolles nicht. Ich stosse oft auf fremden Code, bei dem ich erst drei viertel der Kommentare löschen muss damit ich mir einen Überblick verschaffen kann.

Und zwar genau solche Kommentare:

Der Rückgabewert von Page() und liveLog::$id sind garantiert ganze Zahlen,

deswegen ist keine Maskierung erforderlich

D()->query("UPDATE log SET page_id = '".Page()."' WHERE id = '".liveLog::$id."'");

>   
> Jetzt mal ehrlich, in diesem Fall musst du doch hier annehmen dass Page() eine "page\_id" also eine Zahl zurück gibt.  
  
Ich persönlich treffe keine Annahmen, nur weil etwas so sein müsste, dass es funktioniert. An dieser Stelle kann ich höchstens hoffen. PHP ist keine typsichere Sprache, als Rückgabewert kann kein bestimmter Typ erzwungen werden. Für C# hingegen könnte man annehmen, dass das passt, besonders wenn man mit einer IDE à la Visual Studio unterwegs ist, die beim Positionieren des Mauszeigers auf Page() dessen Rückgabetyp (beziehungsweise die gesamte Signatur) anzeigt. Aber auch das wäre noch nicht 100% sicher, denn C# nimmt beim Verknüpfen von String und Integer stillschweigend eine Konvertierung vor. Wenn also eines Tages Page() einen String liefern würde, geht das genauso geräuschlos durch den Compiler wie der Integer.  
  
Wenn du zumindest eine gewisse Beruhigung des leidgeprüften Programmiererauges erreichen willst, empfehle ich dir PHPDoc-Kommentare zu verwenden, denn die werden von den PHP-IDEs üblicherweise als kontextsensitive Hilfe beim Überfahren mit dem Mauszeiger angezeigt.  
  

> Und wenn du Zweifel hast schaust du dir die Funktion Page() genauer an, dann weisst du es auch gleich für die Zukunft.  
  
Nachschauen ist eine Möglichkeit, aber eine zeitaufwendige. Und in die Zukunft kann ich leider nicht sehen, weswegen ich mich sehr schwer tue, einmal gelernte Gegebenheiten als in der Zukunft unveränderlich zu betrachten.  
  

> Vergleiche:  
> -------------------------------------------------------  
> ~~~php

$stmt = D()->prepare("UPDATE log SET page_id=:page_id WHERE id = :id ");  

> $stmt->bindParam(':page_id', Page() );  
> $stmt->bindParam(':id', $liveLog::$id );  
> $stmt->execute();

vs
D()->query("UPDATE log SET page_id = '".Page()."' WHERE id = '".liveLog::$id."'");

Betrachte von PDOStatement->execute die Beispiele #2 und #3. Das sollte doch sowohl flexibel für beliebige Parameteranzahlen als auch komfortabel sein - und garantiert sicher obendrein. (Das ist ja der Vorteil von PDO gegenüber mysqli, dass du nicht zwingend extra binden musst, sondern es eine kombinierte Lösung mit PDOStatement->execute() gibt.)

Gut man könnte die prepared statments in einer Funktion kapseln damit es irgendwie so aussieht:
D()->myPreparedQuery("UPDATE log SET page_id=? WHERE id = ? ", Page(), $livelog::$id);

Dann würde ich aber keine separate Methode erstellen, sondern in query() ein Array als optionalen Parameter aufnehmen (Defaultwert: null). Dieses Array (oder das null) kannst du dann dem execute() übergeben und hast damit Querys mit und ohne Parameter erschlagen. Zudem ist es dir freigestellt, ob du positionierte oder benannte Platzhalter verwenden willst. Beides kannst du über das eine Array erledigen.

Das wäre eventuell noch sinnvoll, auch um andere Entwickler zu beruhigen :)
Hat die Nachteile, dass es nicht mehr ganz so gut lesbar ist und dass man einen Zwischenschritt einbaut, was die Komplexität des Codes erhöht.

Nun, das optionale Array erhöht den bestehenden Code nur ganz geringfügig, bringt dich aber einen enormen Schritt bei der Funktionalität und Sicherheit nach vorn. (Ich weiß nicht, ob du jetzt schon P.S. verwendest oder erst noch query() gegen prepare() und execute() tauschen musst, aber dieser Aufwand ist auch recht gering.)

Lo!

[Töbi]

Ok gut, ich werde bei Gelegenheit alles anpassen. Phuuu :)
Danke!

Weitere Anregungen natürlich erwünscht.

Gruss
Töbi