Jetzt das HTML-Seminar als
Video-Tutorial
mit über 210 Videos,
Gesamtspielzeit über 24 Stunden
Video-Kurs HTML5+CSS+Webdesign
Also nur mit HTML und CSS ist ein Slide wie ich ihn möchte nicht möglich außer mit diese checkbox Hack?
Nein. Der Checkbox-Hack *ist* nur HTML und CSS und nur damit alleine geht das nicht barrierefrei.
ZitatHab eine Abneigung gegen diese Fonds und mit Java bin ich noch lange nicht so weit
Was meinst du mit "Fonds"? Und Java brauchst du auch nicht, ohne Javascript geht es allerdings nicht.
glaub der Text fehlt oben , Checkbox Hack? Sorry soweit bin ich nicht […]
nun, du verwendest ihn, deswegen ja auch die Checkbox in deinem Code …
Wenn ich diesen in der index.php über App\Controller\Authentification(); aufrufen möchte wird es immer noch nicht gefunden.
Klar, der ist ja unter App\Controller\Authentification\Authentification zu finden. Und irgendwie sieht das auch jetzt alles ganz anders aus als oben, da war noch davon die Rede dass in $class nur Authentification stehen würde. Was du mit dem $prefix und dem strncmp genau vorhast erschließt sich mir auch nicht so ganz …
ZitatHatte groses vorgehabt wie eine Div Box zu erstellen . Bitte Bitte Meine Hompage 👉👉👉 https://dblagojevic.000webhostapp.com/#
Der Ansatz ist für die Tonne: der Checkbox-Hack ist nicht barrierefrei und damit unbrauchbar. Ein solches Menü lässt sich barrierefrei nur mit JS umsetzen, alleine mit HTML/CSS geht das nicht.
btw: HTML ist keine Programmiersprache, du kannst in HTML also nicht programmieren.
Damit machst du dir deinen Dateinamen kaputt - lass dir $file an der Stelle mal ausgeben.
Außerdem: beschäftige dich dringend mit dem Thema Behandlung von Kontextwechseln, entweder ignorierst du sie (beim Ausgeben der Dateinamen in den Link hast du sogar zwei Kontextwechsel die beide nicht behandelt werden!) oder du machst es falsch (das htmlspecialchars() in der auf das preg_replace folgende Zeile ist Käse, du hast hier keinen Kontextwechsel nach HTML).
Leider greift das PHP script nicht weiss jemand grad vielleicht warum
Wie franky77 schon richtig bemerkt hat: das Problem ist deine Bedingung: es gibt kein Formularelement mit name="submitted", weswegen die Bedingung niemals wahr und der Code damit niemals ausgeführt wird. Verpasse dem Button ein name-Attribut oder frage ab ob Name oder Passwort in $_POST enthalten sind.
Du wirst dann allerdings gleich auf das nächste Problem stoßen: die Abfrage auf korrekte Zugangsdaten wird immer true ergeben - du weist den Variablen nämlich nur einen Wert zu, zum Vergleichen musst du == verwenden. btw: das Umkopieren der Werte aus $_POST (oder auch $_GET) war schon immer sinnlos, du kannst auch direkt mit den Werten in $_POST vergleichen, $name und $PW sind überflüssig.
Und wie willst du eigentlich verhindern dass der Besucher die Zielseite (sites/logged_in.html) einfach direkt aufruft? Beschäftige dich mit dem Thema Sessions (wobei die Zielseiten dann keine reinen HTML-Seiten sein können).
Ach, noch was: deine header-Aufrufe werden nicht funktionieren: vorher darf nämlich *nichts* ausgegeben worden sein. Du gibst vorher das Formular aus womit die header von PHP bereits verschickt wurden und jeder Aufruf von header() nur eine Fehlermeldung ergibt. Beschäftige dich mit dem EVA-Prinzip.
Dein HTML-Code enthält leider auch noch Fehler:
- deine Eingabefelder haben keine Beschriftung (ein label-Element fehlt); und nein, das placeholder-Attribut ersetzt diese nicht
- </input> gibt es nicht
- das button-Element hat kein placeholder-Attribut
(- HTML-Grundgerüst fehlt (vor, nach und in <html> fehlt noch was, aber evtl./hoffentlich ist <html> hier nur als Platzhalter zu sehen))
Besser so?
Sicherheitstechnisch, ja. Wirklich gut/richtig ist es aber nicht: zum einen hast du meinen Pseudocode nicht genau gelesen, das prepare gehört *vor* die Schleife, das muss nicht bei jedem Durchlauf erneut aufgerufen werden. Zum Anderen greifst du auf $_POST["Belag"] und überprüfst dann erst ob das Element überhaupt existiert … Lass das unsinnige Umkopieren der Werte in die Variablen einfach ganz weg und weis in $para direkt die Werte aus $_POST zu.
Bekomme ich fiat mit Komma neben volvo?
Sicher (implode hilft), aber wie du schon bemerkt hast: das macht man nicht. Bau das Datenbankdesign so um dass jeder Eintrag eine Zeile (in einer extra Tabelle) bekommt. Dir wird ein kaputtes Datenbankdesign sonst früher oder später auf die Füße fallen und du musst es unter großem Aufwand dann doch korrigieren, mach es also besser gleich richtig.
Genau was ich befürchtet hatte: Die Schleife läuft leer durch, anschließend haben $key und $val jeweils den letzten Wert. Du musst das Eintragen in die DB innerhalb der Schleife erledigen:
Und prepared Statements dabei natürlich richtig verwenden - so wie du das machst ist es falsch: im Query dürfen nur Platzhalter stehen, die Werte werden mit execute (bzw. eine bind-Methode) übergeben (Pseudocode):
Zudem fehlt beim Aufbau der Datenbankverbindung noch ein »;charset=utf8mb4« am Ende des DSN (bei dir die Variable $server) damit definiert ist in welcher Form du Daten bekommst bzw. in welcher Form sie die Datenbank erwartet - wenn du das weglässt bist du auf die Standardeinstellung angewiesen und die kann sich ändern.
Aber bei Codepen zeigt er mir das nur richtig an wenn nth-child 4,5,6,7 sind.
In das HTML-Feld gehört nur das was in <body> steht, kein vollständiges HTML-Dokument (das CSS entsprechend ins CSS-Feld).
Ich hatte es einfacherhalber mit Komma in die Datenbank schreiben lassen um im Nachgang die Werte nicht wieder in Komma umwandeln lassen muss.
Die Datenbank brauch einen Punkt, sonst kann sie nicht damit rechnen. Andersrum wird eher ein Schuh daraus: verwende intern immer den Punkt als Dezimaltrenner - nur dann wenn du die Werte als Text (in einem Eingabefeld bleibt der Punkt) ausgibst, bekommt der Benutzer den Wert ordentlich mit Komma formatiert angezeigt.
Wie meinst Du das mit dem output-Element? Stehe da gerade etwas auf dem Schlauch?
Die Felder die ein readonly-Attribut haben sind doch dazu da um die Ergebnisse von Javascript-Berechnungen auszugeben, oder? Das sind also keine Eingabe- sondern Ausgabefelder - und dafür gibt es output (die natürlich nur sichtbar sein sollten wenn Javascript auch aktiviert ist, ohne JS sind die ja relativ sinnlos)
Zu SELECT *...was spricht in dem konkreten Fall gegen ein *?
Siehe z.B. https://www.pg-forum.de/t/waru…rom-verwenden-sollte/5062 (ja, der Eintrag ist schon älter, er ist aber immer noch aktuell)
Der Wert nach dem gesucht wird, ist quasi unveränderbar vorgegeben und kann durch den Benutzer nicht geändert werden.
Das ist ein Irrtum: der Wert wird per POST-Request übertragen und kann damit vom Benutzer manipuliert werden (schon klar, vielleicht nicht von jedem Laien grundsätzlich ist es aber möglich). Kontextwechsel müssen *immer* behandelt werden ohne Ausnahme! (das gilt übrigens nicht nur für die zu SQL sondern z.B. auch für die nach HTML, d.h. wenn du irgendwas im HTML-Code an den Browser ausgibst)
Es gibt 20 Posten-Möglichkeiten bei einem Angebot die einzeln hinterlegt werden.
Da lag ich ja richtig, das Datenbankdesign ist tatsächlich kaputt: was ist wenn z.B. nur ein Posten hinterlegt wird, oder was ist wenn es mal 21 Posten sein sollen? Die Posten gehören in eine zweite Tabelle in der jeder Datensatz einen Posten zu einem Angebot enthält - beschäftige dich mit dem Thema Normalisierung.
Bist du bei deinem eigentlichen Problem weitergekommen? Liegt es an dem Komma als Feldtrenner an dem Javascript wieder aufgetrennt wird?
Ich lasse mittel Ajax ein Formular (Kostenangebot) aus einer Datenbank füllen, darunter auch reichlich Input-Felder mit Preisen. Diese haben bekannter Weise das Format 12,34, sprich 2 Nachkommastellen. In der Datenbank selbst ist das richtige Format hinterlegt (mit Komma, nicht mit Punkt).
Wie kommst du darauf dass es mit Komma richtig wäre? Richtig ist mit Punkt, alle Programmiersprachen (und auch HTML, siehe unten) und Datenbanken erwarten einen Punkt als Dezimaltrenner.
ZitatAuszug aus dem Formular was mittels Ajax gefüllt wird:
Das Formular ist kaputt:
ZitatDie stmmactionangebot.php:
Alles anzeigenPHP
- <?php
- session_start();
- $connect = mysqli_connect("localhost", "*****", "******", "office");
- $angebotsnummer = $_POST["angebotsnummer"];
- $code = $_POST["angebotsnummer"];
- $query = "SELECT * FROM angebote WHERE angebotsnummer = $angebotsnummer ";
- $result = mysqli_query($connect, $query);
- while($erg = mysqli_fetch_assoc($result))
- echo $erg["kundennummer"] . "," . $erg["anrede"] . "," […];
- ?>
Der Code hat gleich mehrere Problem (eines davon ist gefährlich!):
Dein eigentliches Problem dürfte aber das unpassende Datenformat sein in dem du die Werte an Javascript schickst: du klebst einfach alles mit Komma zusammen und trennst es im Javascript wieder auf - allerdings ohne Rücksicht darauf ob der Wert selbst auch ein Komma enthält … Verwende besser ein Format wie JSON, damit solltest du das Problem nicht haben (PHP und Javascript können beide standardmäßig mit JSON umgehen).
Gibt es da eine Möglichkeit?
Nein. Wie der Funktionsname schon sagt verschlüsselt die Funktion nicht, sie erstellt ein Hash des Passworts - und dieser Vorgang ist nicht umkehrbar. Wenn ein Benutzer sein Passwort vergessen hat bleibt nur ein neues zu setzen - wobei dass ein Benutzer normalerweise ohne Hilfe des Admins machen können sollte.
Geht es noch kürzer ?
Klar: Zeilenumbrüche entfernen, </form> weglassen, name-Attribut weg, Anführungszeichen um Attributwerte weglassen, das Bild im gleichen Verzeichnis speichern und nur "b" nennen; zudem noch den PHP-Teil nach hinten (spart das »?>«), dort das if weglassen und die Kurzform des php-Tag verwenden (»<?=var_dump($_GET);«). var_dump() ist zum einen gefordert und zum anderen gibt print_r immer was zurück was - auf Kosten zusätzlicher Zeichen - unterdrückt werden müsste wenn man <?= verwenden will.
Natürlich ist das valide, warum sollte es das nicht sein? Input mit type="image" ist valides HTML.
das input selbst ist grundsätzlich schon valide, meine gesamte Konstruktion aber nicht: es fehlt das HTML-Grundgerüst und z.B. das alt-Attribut des input. Wobei mir auffällt dass auch 49 Zeichen reichen: da waren noch 4 Anführungszeichen drin die man weglassen kann.
Wie viele Zeichen braucht ihr?
Welchen Weg geht ihr da?
53. Allerdings entspricht das nicht ganz der Aufgabenstellung, um das Bild darzustellen habe ich ein input mit type=image verwendet, ein Klick darauf überträgt die Koordinaten des Klicks womit keinerlei Javascript notwendig ist. Valide usw. ist das natürlich überhaupt nicht, da mir die Aufgabe aber wohl in Richtung wie CSSBattle geht ist das in dem Fall schon ok.
Das sollte schon gehen.
Nein, da der Pfad ($verzeichnis) fehlt.
genauer habe ich mir den Code jetzt nicht angesehen, aber verwende statt "keyup" mal "input" als Eventhandler.
Einer div-Box, die absolut positioniert ist (das Framework berechnet das Layout server-seitig),
… und hat sich damit selbst disqualifiziert. Ein Layout kann nicht serverseitig berechnet werden und postion als Layoutmittel ist auch nur sehr mäßig sinnvoll - verwende grid bzw. flex und lass den Browser das Rechnen machen.