Öhm... Reloadsperre schön und gut, aber man sollte schon Datenbank seitig abfangen, dass doppelte Werte nicht zulässig sind.
Ein Mitarbeiter sollte z.B. keine zwei Einträge für dasselbe Datum und dieselbe Uhrzeit eintragen können.
Bei den Reloadsperre-Varianten aus dem Link sind tlw. einige Dinge nicht bedacht.
Ich würde eine Session verwenden und eine angepasste Token-Variante. Alternativ wäre die Weiterleitung-Variante noch im Spiel, hier aber auch mit Session erweitert.
Prima, danke! 
Schöne Lösung, MrMurphy
Kurze Frage: Warum wäre UL nach HTML Regeln falsch?
We schon angesprochen, ist das ganze List-Style verbogen, nimm einfach den Standard-Style und setze Deine Dreiecke als List-Symbole, dann sollte das funktionieren.
Ich habe das schon versucht in dem ich das alles auf issets umbaue und mit Values (?) arbeite aber da bekomme ich nur fehler.
Dann gilt es, die Fehler zu beheben. Du gibst eine richtigen Weg auf, weil Du Fehler bekommst... Klingt nicht clever.
Ich habe mir als Vorlage einfach unsere Stundenlisten von der Frima das Formular genommen und versuche mir das im Eigenstudium selbst nachzubauen.
Und mir das alles selbst beizubringen.
Das ist doch gut, sagt ja keiner was gegen. Deshalb bekommst Du hier ja auch Tipps, wie Du selbstständig weiter kommst 
Glaub mir, Leute mit Deiner Einstellung sind mir 1000mal lieber, wie die, die Seiten lang immer nur antworten: "klappt bei mir immer noch nicht", bis jemand das für sie gelöst hat, aber sie selber weder etwas verstanden noch sich selbst ausreichend weitergebildet haben!
Das Problem ist sobald man die Seite aufruft wird ein leerer Datensatz in die Datenbank geschrieben das bei jedem Aufruf der Site.
Dir fehlt ein Formularprüfung. Wenn du die Werte, die in die Datenbank geschrieben werden sollen validierst, kann das nicht passieren, denn leere Werte sollten zumindest für bestimmte Werte als fehlerhaft validiert werden.
In dem Fall einfach keine Daten an die Datenbank senden.
Vermutlich prüfst Du GET und POST auch nicht beim Aufruf der Seite, weshalb es überhaupt zu den leeren Werten beim initialen Aufruf der Seite kommt.
EDIT:
Ja, wie vermutet, keine Validierung von GET oder POST, geschweige denn der Werte => SQL Injection Gefahr!
Na sicher wird es um die Einrichtung des Client gehen, aus dem Inhaltsverzeichnis:
html-seminar.de/woltlab/attachment/2288/
...jetzt die Frage an die Experten: wie soll man den FTP-Client ohne FTP-Server einrichten? 
Spoiler: Gar nicht, wenn man den Client nutzen will, braucht man einen Server. Hat man keinen, kann man mit FileZilla einen zur Verfügung stellen.
Ob das Sinn macht, steht in einem ganz anderen Raum.
Grundsätzlich sehe ich den Punkt allerdings als komplett überflüssig, denn wie schon gesagt, reicht der localhost von XAMPP, der ab Seite 591 beschrieben zu sein scheint, romae
Einfach Deine Dateien und Verzeichnisse m Webroot ablegen und gut is.
Sollte alles auch dort beschrieben sein.
Naja, um die Dateien in den Webspace zu bekommen.
Für zu Hause und zum Üben würde XAMPP Sinn machen, da ist alles dabei. Der Unterschied ist halt, dass man dann kein FTP benötigt, weil man direkt ins Webroot von localhost speichern kann.
Wenn das Buch aber von einem dedizierten Webspace ausgeht, ist FTP nicht unbedingt falsch.
Leute, Leute, Leute... und wenn dann eine Option dazu kommt, geht man wieder in den Code und setzt noch eine IF ein.
Respekt fürs Ignorieren sinnvoller Lösungswege...
Warum nicht nutzen, was da ist?
Eben... Ein DELETE FROM `Zuege` WHERE `Zugnummer` = :train_id kann keine 1000000 Datensätze löschen, es sei denn, Du hast überall die gleiche Train_id, was nicht passieren kann, wenn das UNIQUE ist.
Wenn der Entwickler selber die falsche Query schreibt und die WHERE-Klausel bspw. vergisst, ist das Lehrgeld, sowas sollte nicht mit Live-Daten getestet werden.
Wenn die Datenbank sauber aufgebaut ist und die Queries entsprechend getestet wurden, kann so etwas, wie hier beschrieben nicht passieren.
Geht man dennoch davon aus, dass sowas passieren kann, liegt aus meiner Sicht ein Verständnisproblem der Materie vor.
Sicher kann man bei vielen Dingen auf Nummer sicher gehen, aber manches ist halt unnötig, wenn die Basis vernünftig aufgebaut wurde, jedes LIMIT kostet.
Eine Datenbank - soweit vorhanden - ist das fundamentalste und Zeit intensivste Element in einer Anwendung.
Wenn diese erstmal steht, darf so etwas nicht passieren.
Natürlich fragen die Leute hier - und vermutlich der TE auch -, weil Sie da nicht die Profis sind ( ich auch nicht! ).
Aber ich finde es viel wichtiger, die Grundprobleme aufzuzeigen, als einen Workaround anzubieten, der im Grunde nicht nötig wäre, wenn man sich damit befasst. Ich setze da einfach voraus, dass die Leute etwas lernen wollen. Wenn nicht, können sie die Hinweise ignorieren.
Ich will aber keinen davon anhalten, LIMIT zu verwenden! Ich möchte nur sensibilisieren, dass es sinnvollere Ansätze gibt.
Das ist der falsche Ansatz, eine URL mit mehrfach dem gleichen Parameter-Schlüssel zu haben.
Es gibt die Möglichkeit, diese als Array zu übermitteln. Dein Formular würde ich bspw. in etwa so erstellen:
<form action="#" method="post" name="FORM">
<p>Marke:</p>
<input type="checkbox" name="t_manuf[]" id="vw" value="vw">VW
<input type="checkbox" name="t_manuf[]" id="audi" value="audi">Audi
<input type="checkbox" name="t_manuf[]" id="skoda" value="skoda">Skoda
<input type="button" name="buttonSuche" value="Suchen">
</form>Im Javascript kannst du dann nämlich auf alle t_manuf als NodeList zugreifen:
var _checks = document.querySelectorAll('[name^="t_manuf"]');Diese NodeList brauchst Du dann nur noch in einer Schleife durchlaufen und die Parameter zusammenbauen.
Da gibt es natürlich viele Wege, ich würde auch hier wieder ein Array nehmen und bspw. so vorgehen:
var _values = [];
_checks.forEach(i => {
if (i.checked)
_values.push(encodeURIComponent(i.value));
});Im Prinzip brauchst Du dann nur noch das Array _values Komma separiert zusammenfügen, was über _values.join(',') relativ einfach geht.
Deine URL sollte dann entweder den Parameter t_manuf abhängig von dem Inhalt des Array _values entweder leer oder gar nicht übergeben.
Btw. onclick würde ich nicht verwenden, stattdessen addEventListener.
Auch switch wäre bei der Vorlage zu viel des Guten, würde ich behaupten.
Da die Page scheinbar immer so heißt, wie die Datei, reicht ein kurze Überprüfung und dann das include:
$page = ( isset($_GET['page']) && $_GET['page'] != '' )
? filter_input(INPUT_GET, 'page', FILTER_SANITIZE_STRING)
: 'home';
if ( !file_exists($page) )
$page = 'fehler.php';
include_once $page;Ich vermute mal Pyr0maniak1 befindet sich mit seiner Frage in der Windoof Welt und möchte den Windows Benutzer auslesen.
In $_SERVER oder $_ENV sollte sich da schon was finden lassen, ansonsten hat PHP auch die Möglichkeit das AD anzusprechen über die ldap-Funktionen.
Aber das ist eine DELETE query. Du willst doch nicht erst, wenn alles gelöscht ist, feststellen, dass da ein Fehler ist
DELETE habe ich übersehen, dann wäre es natürlich besser, wenn man den Fehler vorher schon erkennt.
Aber bei einem DELETE macht LIMIT erst recht keinen Sinn. Wenn das die Lösung ist, stimmt das Datenbankdesign nicht.
Wenn Du nur einen user laden willst, der per query definition nur einmal vorkommen kann,
dann macht ORDER BY id ASC LIMIT 1 Sinn
Dann macht LIMIT überhaupt gar keinen Sinn. Warum will man den ersten Datensatz einer Datenmenge aus genau einem Datensatz noch extra limitieren?!
Du gehst doch auch nicht auf den Wochenmarkt und sagst zu dem Obsthändler, der nur noch einen Apfel in der Auswahl hat: "Von diesem einen Apfel möchte ich bitte nur den ersten". Welcher Sinn sollte dahinter stecken.
LIMIT macht dann Sinn, wenn man bspw. Pagination einsetzen möchte, vielleicht gibt es noch ein zwei Anwendungsfälle mehr, die mir grad nicht einfallen würden, aber in allen anderen Situationen, wie auch hier ist das nur kaschieren von Fehlern.
Was nicht funktioniert ist, dass sich beim Einfügen von Text der vorhandene Text automatisch auf die weiteren Seiten (Container) verteilt, wie es in Textverarbeitungen üblich ist.
Mit PHP wäre das schon möglich.
Wenn jedes Blatt ein eigener Container wäre, könnte man bspw. mit der GDLibrary den Text in der Höhe messen und bei Überschreitung eines Wertes einen neuen Container anfangen.
Ist zwar jetzt schnell dahin gesagt, ohne Berücksichtigung der Silbentrennung usw., aber machbar wäre das.
Die Messung bspw. muss ja auch nicht permanent stattfinden. Mann kann ja auch Berechnungen durchführen und aus den Ergebnissen entsprechen sinnvolle String-Längen nutzen. Und ja, da könnte man auch berücksichtigen, dass manche Zeichen weniger Platz einnehmen, wie andere und auch die Schriftart bei den Eingangsmessungen berücksichtigen.
Die Frage ist halt, ob es den Aufwand wert ist.
Sie haben es nicht nötig, das ist der Grund
Outlook ist ausreichend weit verbreitet, dass die Versender Ihre Mails an Outlook anpassen, als dass M$ sich darum kümmert die Engine auszutauschen.
Wenn Du Desktop-Anwendungen für Windows entwickelst und die Webbrowser-Komponente darin nutzt, rendert selbst Windows 10 per Default noch auf der IE7 Engine 
. Kann man zwar anpassen, aber das bedeutet eine Registry-Anpassung auf jedem Client.
Hi,
Für Mails musst Du leider auf die modernen Möglichkeiten verzichten, ein Grund dafür ist wie Du schon erwähnst Outlook.
Das Layout funktioniert leider über diese Channel am besten mit Tables.
Schau Dir mal Newsletter an, auch von großen Unternehmen, die haben da auch viel Krams drin, den man online nicht machen würde.
Klingt sch...e, is aber so
Warum LIMIT 1:
Die Query funktioniert, alles i.O.
Aber mit der Zeit wird sie erweitert, wird immer komplizierter, und evtl passiert ein Fehler - die Bedingungen betreffen auf einmal mehrere oder alle Zeilen in der db.
...wodurch die Ergebnisliste fehlerhaft sortiert sein kann und man ein falsches Ergebnis verarbeitet. Hier würde ich eher nicht Limit nehmen, da solche Fehler sonst kaum auffallen werden und man wundert sich, warum mit falschen Daten gearbeitet wird.
Es ist nie gut, mögliche Fehler zu kaschieren!
Wenn sie auftreten => fixen!
Hast Du den Link auch gelesen und verarbeitet?
Damit haben das vor Dir schon haufenweise andere geschafft, wird also nicht am Script liegen
#7 und Du hast keine Sorgen. 
