nicht angemeldet
hi,
erstmal vielen Dank für die Ausführliche Kritik!
Leider ja aber nicht konsequent, wie man an deinem Code sieht. Du benutzt einmal für die Abfrage eines einzigen Datensatzes ein Prepared Statement, und dann für die Abfrage eines weiteren Datensatzes einen normalen Query.
Das hatte ich so gelöst, weil dass zweite SELECT keine „Usereingaben“ benötigt, dass meinte ich mit „Script arbeitet Intern weiter“, also nur mit Existierenden Daten, die ich aus der DB hole.
So ist sichergestellt, dass die benötigten Daten auch existieren und richtig sind.
Der Geschwindigkeitsvorteil kommt zum Tragen, wenn du z.B. ein SELECT vorbereitest, mit Platzhalter im WHERE, und dann eine Folge von vielleicht hundert Aufrufen (d.h. hundert SELECTs) startest, jeweils mit unterschiedlichen Werten für den WHERE-Teil.
Danke, jetzt habe ich die Logik dahinter endlich verstanden, ich hatte viel darüber gelesen aber nie richtig verstanden.
Obendrein ist deine Anwendung von mysqli extrem unterschiedlich. Du mixt - wie erwähnt - Prepared Statements und normale Querys. Dann auch noch die (viel elegantere) objektorientierte Methode mit der prozeduralen (mysqli_real_escape_string-Aufruf mittendrin).
Ja, bin doch noch Anfänger, ich bin froh, dass mein CMS überhaupt funktioniert, so wie ich es wollte (Update-Funktion und neue Seiten anlegen).
Die ganze umkopiererei der Variablen musste ich machen, damit meine URI lesbar bleibt, also ohne $_GET verwenden zu müssen.
Der Preis dafür ist halt so ein schrecklicher Code.
Aber ich glaube ich schreibe es Komplett um auf $_GET, das ist viel einfacher.
Variablenkopiererei! DAS ist wirklich ÜBEL! Im Skriptverlauf entstehen bei dir unzählige Variablen, werden ineinander kopiert, weisen eventuell - aber nicht unbedingt immer, das hängt von den Verzweigungen in diversen IFs ab - den identischen Inhalt auf, werden irgendwann einfach nicht mehr benutzt
Nein, die werden Script-intern verwendet, es fehlen ja noch dutzende Funktionen und Programme, die ausgelagert sind und kleine Aufgaben erledigen.
Beispielsweise für den Aufbau der Menus und Footermenu.
Insgesamt ist mein Code ein Paar tausend Zeilen lang, dass möchte ich hier niemandem zumuten, zumal, wie du schon sagtest, mein Code ist voll mit Anfängerfehlern.
Meine grösste Hürde ist zurzeit die Navigation der Seite, dass kriege ich einfach nicht gebacken, diese zwingt mich auch, den Umweg mit den umkopierten Variablen zu gehen.
http://dj-tut.de/z_test/meinMenu.php
Nested Sets habe ich viermal versucht und nicht verstanden geschweige denn umgesetzt bekommen.
Beispiele für solche unsicheren, weil sinnlos verwendeten Variablen sind:
$mein_server_request, $query_request_check, $site_exists, $aktuelle_gruppe, $aktuelle_link.
Bis auf $query_request_check werden alle Variablen im weiteren Scriptverlauf verwendet, insbesondere benötige ich $site_exists, um z. B. auf Error 404 reagieren zu können. Das liegt aber an meiner .htaccess, da habe ich mit drei Zeilen veranlasst, das jede aufgerufene URI existiert.
Wenn ich nicht auf die Existenz der Seite Prüfe, kann man jede X-beliebige URI aufrufen und bekommt immer ein header Status 200 Ok.
Weiterhin fragst du Dinge aus der DB ab, die du nirgends benutzt:
$haupt_gruppe_1, $url_link
Das stimmt, ich kriege die Abfrage nicht anders hin.
Die Krönung der sinnlosen Kopiererei aber ist der Transfer des wunderschönen assoziativen Arrays, welches aus der zweiten DB-Abfrage kommt, in tausend Einzelvariablen, nur um dann vor dem finalen Transfer der Inhalte in das Smarty-Template diese Einzelvariablen wieder in ein komplettes assoziatives Array zu stecken.
FULL ACK! Ich habe mich mit diesem CMS definitiv komplett übernommen :)
Das schlimme ist, das es funktioniert, daher kann ich nicht aufhören, weiter drauf aufzubauen.
Ungeklärt bleibt, warum diese Badwordliste existiert. Der Code zeigt eindeutig, dass die REQUEST_URI direkt als Abfragekriterium in der Datenbank dient - allerdings muss ich gestehen, dass dieser Wert auch mehrfach wieder aus der Datenbank zurückgelesen, wieder als Parameter in Querys reingesteckt und wieder ausgelesen wird, so dass man die Spur der Herkunft leicht aus den Augen verlieren kann.
Die Badwordliste kommt nur einmal zum tragen, nämlich wenn die Aktuell aufgerufene Seite abgefragt wird, der Gesamte weitere Scriptverlauf basiert auf $site_exists, also bestehenden Daten aus der Datenbank.
Ich ging davon aus, dass Prepared Statements die benötigte Sicherheit garantieren, welche vorgefertigten Funktionen gibt es denn noch für MySQL?
Ich bezog mich auf das URL-Parsen und würde im Zweifel den Inhalt von $_GET & Co. vorziehen.
Ich werde versuchen, mein CMS umzuschreiben und mit $_GET zu arbeiten, das dumme an $_GET ist nur die URI, die dann so verunstaltet aussieht.
holla holla