Wenn du da findest wie du es mit einem Bild machst schreibst du dir einfach eine Funktion die nacheinander die Bilder deines Ordners aufruft und dann für jedes einzeln das Wasserzeichen einfügt.
Oder willst du, dass dir jemand ein fertiges, an deine Bedrüfnisse angepasstes, Script liefert? Was zahlst du denn?
Der Geschwindigkeitsunterschied zwischen ".." und {} ist noch unsignifikanter als der zwischen ' und "
Daher mache ich es so wie ich es am übersichtlichsten finde. Ich habe noch keine Seiten entwickelt die so umfangreich waren und so enorme Zugriffszahlen hätten, dass solche minimalsten Differenzen eine Rolle spielen würden.
Prinzipiell bin ich immer dankbar für Anregungen meinen Code aus Performance-technischer Sicht zu optimieren. Eine gewisse Verhältnismäßigkeit zwischen Geschwindigkeitsgewinn und Umgewöhnung bei meinen Präferenzen sollte aber gegeben sein, und die sehe ich hier nicht.
Ich wollte eigentlich auch nur darauf hinweisen, dass die Geschwindigkeitsunterschiede in deinem Artikel den du verlinkt hast so definitiv nichtmal mehr annähernd stimmen, zumindest für php-Versionen ab 5.2.6 (mit älteren habe ich nicht getestet).
Das mag minimal sein aber es ist unnötig. Mit einfachen Anführungszeichen und . ist die Struktur klarer und es ist schneller ohne irgendwelche Nachteile.
Wie die Struktur klarer ist, ist wohl subjektive Ansichtssache. Ich benutze viel lieber " und bette Variablen {} ein. Damit komme ich am besten klar.
Und der Geschwindigkeitsunterschied ist eben nur minimal, und nicht 3-fache Dauer.
@ The_User:
Also die Angaben in deinem Link kamen mir sehr spanisch vor, da ich bisher von jedem erfahrenen PHP-Entwickler (auch sehr performance-lastige Anwendungen) gehört habe, dass der Geschwindigkeitsunterschied bei Verwendung von " statt ' nur minimal ist.
Ich habe deine Script da mal exakt kopiert und sowohl auf lokalem Wamp, als auch auf einem Managed Server von domainfactory durchlaufen lassen.
Ergebnis lokal:
Einfache Anführungszeichen: 0.0065679550170898s
Doppelte Anführungszeichen: 0.0099749565124512s
Da ist zwar ein kleiner Unterschied, aber nichtmal annähernd 3-fache Dauer.
Ergebnis Managed Server:
Einfache Anführungszeichen: 0.0099408626556396s
Doppelte Anführungszeichen: 0.010456085205078s
Das ist die Laufzeit nahezu identisch.
Dann habe ich das Script einfach mal im Ablauf getauscht, zuerst " und dann '.
define('max', 10000);
$x = '';
$str1 = 'halloblabla';
$str2 = 'hallolalala';
$t1 = microtime(true);
for($i = 0; $i != max; ++$i)
$x = "SELECT `bla`,`bla` FROM `bla` WHERE `name`='$str1' AND `anderer`='$str2'";
$t2 = microtime(true);
echo 'Doppelte Anführungszeichen: ' . ($t2 - $t1) . 's<br/>';
$t1 = microtime(true);
for($i = 0; $i != max; ++$i)
$x = 'SELECT `bla`,`bla` FROM `bla` WHERE `name`=\''.$str1.'\' AND `anderer`=\''.$str2.'\'';
$t2 = microtime(true);
echo 'Einfache Anführungszeichen: ' . ($t2 - $t1) . 's<br/>';Ergebnis lokal:
Doppelte Anführungszeichen: 0.0071289539337158s
Einfache Anführungszeichen: 0.0072078704833984s
Da sind auf einmal " minimal schneller.
Ergebnis Managed Server:
Doppelte Anführungszeichen: 0.010548114776611s
Einfache Anführungszeichen: 0.010170936584473s
Zwar einen Tucken schneller, der Unterschied ist aber marginal.
Mit was für ner PHP-Version hast du das denn getestet? Bei mir waren es lokal php5.2.9 und auf dem managed server php5.2.6
http://www.gidf.de/Notice:%20Undefined%20index
So schwer ist das doch nicht, oder?
Bandits Debug-Anleitung ist sehr sinnvoll. Du solltest dir da nicht nur den einen Punkt 2 raussuchen den du gemacht hast. Die restlichen Punkte ignorierst du ja gepflegt wie man an deinem Quellcode sieht. Also hat er es scheinbar noch nicht oft genug gepostet.
Danach wird dir kein "Headers already sent" ausgespuckt?
Ähm, brauchst du nicht eher eine "oder"-Verknüpfung? 'Name' kann doch vermutlich kaum gleichzeitig Peter UND Paul sein, sondern eher Peter ODER Paul.
Edit:
In dem Fall kannst du die beiden Abfragen einfach hintereinander setzen wenn es tatsächlich keine ODER-Verknüpfung geben sollte (kein Bock mir das anzuschauen und zu suchen), mit dem gleichen Text der im Erfolgsfall ausgegeben wird.
Es kann ja eh nur einer der beiden Fälle eintreten, also keine doppelten Ausgaben.
Es ist nicht nur unnötig, sondern kann auch sehr ungewollte Effekte haben. Die MySQL-Entwickler haben sich schon etwas dabei gedacht die IDs frei zu lassen.
Kleines Beispiel:
Du hast eine Seite auf der sich User registrieren und z.B. Nachrichten schreiben, Bildergalerien anlegen, Gästebucheinträge verfassen, etc.
Alle diese Einträge werden mit Referenzierung auf die ID des Users gespeichert.
Jetzt löscht der User seinen Account. Du möchtest aber die Nachrichten, Gästebucheinträge etc. weiterhin speichern, nur halt z.B. mit "Gelöschter Benutzer schrieb:" o.ä.
Wenn jetzt an einen neuen User die ID des alten gelöschten Users vergeben würde, würden ihm alle Einträge dieses Users zugeordnet werden, was sicherlich nicht erwünscht ist.
Stichwort referentielle Integrität.
Hui, also wenn du noch weiter werkeln willst solltest du dir zumindest grundlegende HTML- und PHP-Kenntnisse aneignen. 
echo "<td>". $zeile['story_digs'] . "</td>";
echo "<td><a href='".$zeile['story_url']."'>". $zeile['story_title'] . "</a></td>";Die Abfrage ist mit dem SELECT * denkbar schlecht. In der Tabelle stehen vermutlich auch die kompletten Artikel, die werden dabei mit selected obwohl du nur titel und digs brauchst, das belegt unnötig resourcen.
http://www.php-faq.de/q-sql-select.html
Schreib die Abfrage lieber so:
[COLOR=#000000][COLOR=#0000cc]SELECT [/COLOR][COLOR=#006600]story_digs,story_title [/COLOR][COLOR=#0000cc]FROM dug_stories ORDER BY [/COLOR][COLOR=#006600]`[/COLOR][COLOR=#0000cc]story_digs[/COLOR][COLOR=#006600]` [/COLOR][COLOR=#0000cc]DESC LIMIT 10
[/COLOR][/COLOR]Ich bin kein Fachmann was solche Rechtsfragen angeht, aber ich kann mir nicht vorstellen wieso man keine Werbung schalten dürfte. Wenn du nicht grad Werbung für Kinderpornos oder verfassungswidrige extreme politische Ansichten o.ä. machst.
Wo wir schon dabei sind, von der Ausgabe des SQLs und des SQL-Errors im Klartext ist auch generell abzuraten. Angenommen, der Benutzer schafft es, einen SQL-Error zu erzeugen, in dem auch Javascript vorkommt. Beispiel:Du hast ein Feld, das einen Zahlentyp erwartet. Der Benutzer schmuggelt einen String ein (wie, will ich an dieser Stelle nicht ausführen). Dann wirft deine Anwendung einen SQL-Error aus, in dem der eingeschmuggelte String ungefiltert ausgegeben wird.
Schlußfolgerung: html_entities() auf $sql und mysql_error() anwenden und dann erst ausgeben.
Naja, die Asugabe ist natürlich nur für die Entwicklungszeit zu Debugging-zwecken gedacht. Bei Inbetriebnahme der Seite hast du vollkommen recht, da wird sowas selbstverständlich rausgenommen, genauso wie error-reporting komplett ausgestellt wird und man Funktionen die zu informative Fehlermeldungen schmeißen könnten zusätzlich noch mit nem @ versieht.
Schreib mal
or die(mysql_error());und poste die Ausgabe.
Und vllt nen Dump von deiner Tabelle (in phpmyadmin die Tabelle auswählen und dann auf "Exportieren"). Sind die Felder vllt. nicht alle als Varchar definiert? Du willst alle Felder mit Strings füllen.
Du schreibst jetzt auch statische Werte rein. Wenn du die Werte aus dem Formular reinschreiben willst mußt du mit dem $_POST-Array arbeiten:
$ja = mysql_real_escape_string($_POST['ja']);
$nein = mysql_real_escape_string($_POST['nein']);
$sport = mysql_real_escape_string($_POST['sport']);
$nachrichten = mysql_real_escape_string($_POST['nachrichten']);
$musik = mysql_real_escape_string($_POST['musik']);
$shopping = mysql_real_escape_string($_POST['shopping']);
$sql = "
INSERT INTO
umfrage
(ja, nein, sport, nachrichten, musik, shopping)
VALUES
('$ja', '$nein', '$sport', '$nachrichten', '$musik', '$shopping')";
mysql_query($sql)
or die("MySQL-Fehler mit:<br>$sql<br><br>".mysql_error());Die Verwendung von mysql_real_escape_string() zum Schutz vor SQL-Injection solltest du dir direkt angewöhnen.
Alternativ kannst du, wenn du nur einen Datensatz einfügst, den INSERT-Befehl auch noch etwas übersichtlicher schreiben:
$sql = "
INSERT INTO
umfrage
SET
ja='$ja',
nein='$nein',
sport='$sport',
nachrichten='$nachrichten',
musik='$musik',
shopping='$shopping'";Edit:
Natürlich sollten vor dem INSERT die Formular-Daten sowieso auf vernünftige Eingaben überprüft werden. Wie diese Überprüfungen im speziellen aussehen hängt dann natürlich immer von den erwarteten Werten ab.
Eine etwas ausführlichere Problembeschreibung wäre nicht schlecht.
Was willst du machen, wie weit bist du schon, was hast du schon versucht, was genau klappt nicht?
In diesem Fall ist es wohl am einfachsten, auf das Script selber zu verweisen, mit <form method=post action="<?php echo $_SERVER['PHP_SELF'];?>">
Das verweist auf den Namen des Scripts, das du gerade ausführst.
Am einfachsten vielleicht, trotzdem ist davon abzuraten.
http://wiki.hackerboard.de/index.php/Cross_Site_Scripting
PHP_SELFPHP-Entwickler nutzen aus Bequemlichkeit oft die Variable $_SERVER['PHP_SELF'] um in Formularen die aktuelle Adresse in das Form-Tag schreiben zu lassen. In nahezu jeder dynamischen Webseite werden Formulare verwendet, beispielsweise in einem Gästebuch, Board, Shopsystem oder auch nur in einem Kontaktformular. Die Verwendung von $_SERVER['PHP_SELF'] birgt jedoch eine Gefahr von XSS in sich.
Der folgende Code stellt ein typisches Beispiel dar.
<form action="<? echo $_SERVER['PHP_SELF']; ?>" method="post">
Nehmen wir an hierbei handelt es sich um ein Kontaktformular welches per http://host/contact.php zu erreichen ist. PHP würde nun automatisch "contact.php" in das Form-Tag schreiben. Was aber passiert, wenn man die URL manipuliert?
In diesem Beispiel wird ein simples Javascript, welches eine Alert Box aufruft, in die Seite eingeschleust. Dazu genügt es den Code an das Ende der URL zu hängen. Würde diese Seite nun über einen Link per folgender URL aufgerufen werden: http://host/contact.php/"><script>alert('XSS')</script><form="
erzeugt PHP folgende Ausgabe:
<form action="contact.php/"><script>alert('XSS')</script><form="" method="post">
Somit würde der Scriptcode zur Ausführung kommen. Möglich wird dies, da die aktuelle Adresse des Scripts ungefiltert ausgegeben wird. Es findet nirgendwo eine Überprüfung der Validität der übergebenen Adresse statt. Durch dass neu entstandene zweite Form-Tag werden zusätzlich Code-Teile, die nun nicht mehr richtig Dargestellt werden würden, ausgeblendet. Der ahnungslose Besucher bekommt von all dem nichts mit.
Doch hier verbirgt sich noch eine weitere Gefahr. Das Umleiten eines Logins. Dadurch das hier direkt das Form Tag verändert wird, ist es sehr einfach möglich sich ein eigenes Form Tag zu erstellen. Dieses würde nach dem originalen angezeigt werden, mit der Folge, dass das originale durch den Browser ignoriert wird. Damit kann ein Angreifer, durch einen User angegebene Login-Daten, zu sich weiterleiten. Dies könnte z.B. bei Onlinebanking fatale Folgen haben.
Ich persönlich schreibe übrigens meine verbindung zur datenbank immer in eine extra datei und binde sie dann per include ein.Was du nicht vergessen solltest ist die verbindung zur datenbank wieder zu beenden mit mysql_close($res_id);
Verbindungsaufbau sollte auf jedenfall in eine Extra-Datei. Wenn aus irgendeinem Grund auf deinem Server mal php ausfällt wird der Code uninterpretiert ausgegeben und jeder Besucher liest deine Zugangsdaten.
mysql_close schadet zwar nicht, ist aber unnötig.
http://dontknow.me/at/?http://de.php.net/mysql_close
Die Verwendung von mysql_close() ist für gewöhnlich nicht notwendig, weil offene, nicht persistente Verbindungen automatisch mit Beendigung des PHP-Skripts geschlossen werden.
In PHP ist != gebräuchlicher. Ich persönlich finds weniger verwirrend, das so zu schreiben:
if ($user_ID != "")
weil sich das für mich logisch besser liest ("wenn Userid ungleich nix" statt "wenn nix ungleich Userid"). Man kann übrigens auch mit empty() auf Leere prüfen.
Ob man jetzt != oder <> schreibt ist wohl einfach eine Frage persönlicher Präferenzen.
Es macht aber auf jedenfall Sinn bei Vergleichsoperatoren zwischen Konstanten und Variablen die Konstante nach links zu setzen wie musti es gemacht hat:
'' <> $user_ID
Bei der Schreibweise <> ist es noch relativ egal, aber bei == oder != findet man viel leichter den Flüchtigkeitsfehler wenn man aus Versehen nur = schreibt.
Wenn die Variable links steht wird ihr dann einfach der Wert der Konstanten zugewiesen und das Script läuft weiter, das macht die Fehlersuche schwerer. Wenn die Konstante links steht und php versucht ihr einen Wert zuzuweisen wird eine Fehlermeldung mit der entsprechenden Zeile ausgeworfen und man spart sich die Suche.
Zu md5, man sollte nicht einfach "nur" md5-verschlüsseln, sondern einen geeigneten Salt verwenden.
Ja das ist eine Möglichkeit, wobei das auch schnell "unsicher" wird wenn jemand den Salt rausfindet.
Wenn es wirklich so sensible Daten sind, dass einem md5 nicht mehr sicher genug erscheint, würde ich eher doppelt verschlüsseln.
Naja das musst du wohl am besten wissen. In deinem letzten Beispiel selectest du ein Feld `pass`, vergleichst aber im $info-Array mit $info['password']. Der Key kann dann ja nicht belegt sein.
Wie heißt denn die Spalte mit den Passwörtern in deiner Tabelle? `password` oder `pass`?
Deswegen kann man ja zb nen md5 vergleich des pwd machen
Ja für genau das eine Beispiel wenn die Passwörter auch (md5-)verschlüsselt in der db liegen.
Generell ist es aber sinnvoll mysql_real_escape_string zu kennen, zum Schutz vor SQL-Injection. Das kann man für alle Felder verwenden, nicht nur für verschlüsselt gespeicherte PWs.
SinnlosS: das noscript kann man doch auch schon per html machen?!
Ja natürlich, per html stellt man eine noscript-Weiche die das ganze über PHP löst. Aber eben nur wenn javascript deaktiviert ist.
Sonst ist eben eine entsprechende Lösung mit javascript/ajax sehr viel performance-freundlicher.
