Beiträge von tk1234

    Ausgehend von meinem Posting in #8 hier mal wie ich mir das vorstelle.

    Ich hatte die gewünschte Darstellung nicht genau gelesen bzw. falsch verstanden. Ich war davon ausgegangen dass es quasi drei Spalten geben soll, links Block 1, rechts Block 2 (jeweils auf die ganze Höhe) und in der Mitte Bild, Überschrift und Block 3 - und das hätte sich mit grid-template-areas gut lösen lassen.

    Warum du jetzt allerdings immer noch flex bevorzugst obwohl das ja ein Element mehr braucht, ist mir nicht so ganz klar.

    Hier wäre eine Begründung wünschenswert, warum Du an dieser Stelle Grid bevorzugst.

    Weil Grid sich für zweidimensionale Layouts (also die hier gefragte Anordnung von Elementen neben- und untereinander) besser eignet als Flex.

    Zitat

    Dadurch wird alles nur unnötig kompliziert und mit jedem Spanning entfernt man sich von der Semantik eines Grid.

    Wieso komplizierter? Das gewünschte Layout lässt sich ohne die in #8 genannten zusätzlichen Elemente umsetzen - es reicht ein Element außenrum (section oder article evtl.) und die gewünschten Elemente (Bild, Überschrift, 3 Textblöcke) darin.

    Nachtrag (edit geht wohl nicht mehr): grid-template-rows brauchst du ggf. auch noch um die Höhe der einzelnen Felder in der mittleren Spalte zu definieren damit die Felder für Bild und Überschrift nicht zu hoch sind. Über Media Querys kannst du das ganze dann auch so steuern dass je nach verfügbarer Breite ein unterschiedlicher Wert für grid-template-areas verwendet wird und die Elemente somit schmäler oder breiter dargestellt werden.

    Ein item soll links eines Rechts und das dritte mittig unter beiden. Kann mir gerade nicht vorstellen wie das gehen soll wenn ich nicht den Bierdeckel zerschiessen will

    Nicht mit flex, versuch es mal mit grid: grid-template-areas ist dein Freund. Damit kannst du benannte Bereiche erzeugen (in der Mitte drei mit unterschiedlichen Namen, links und rechts jeweils in jeder Zeile den gleichen Namen vergeben), dann mit grid-area den Elementen sagen wo sie hin sollen (hier ist dann das bereits genannte :nth-child() oder auch :nth-of-type() hilfreich), die Elemente ausrichten und fertig.

    so der Footer ist fertig. Gefällt mich auch selbst ganz gut.

    Vielleicht schaust du, wenn du Zeit hast noch mal über den Code. Ich befürchte da ist mehr drin als man braucht.

    Semantisch ist der Footer eine Katastrophe:

    1. die Links bei Telefonnummer und E-Mailadresse kannst du dir schenken: sie haben keinerlei Inhalt (sowohl für sehende gerade aber auch für nicht sehende - da ist nur ein leeres i in dem Link); ggf. wäre für die Kontaktdaten auch ein address-Element angebracht
    2. h1 scheint mir für die Überschriften die falsche Ebene …
    3. Die Öffnungszeiten (warum "hours" als Überschrift?) sind eine ungenießbare Div-Suppe, wären aber gerne eine Liste - damit kann der Browser dann auch eine Beziehung zwischen Wochentag und Uhrzeit herstellen (am Grid-Layout ändert sich da - bis auf die Selektoren - nichts); generell: bau das HTML erst semantisch passend zusammen und formatiere das Ergebnis anschließend.
    4. die URL ganz am Ende möchte keine Überschrift sein

    Dein Facebook-Link ist übrigens etwas verunglückt, da musst du nochmal ran. Zudem steht im Content-Type-Header ein "charset=none" und der Header hat Vorrang vor dem was im HTML steht womit die charset-Angabe quasi fehlt - da musst du dem Server noch Manieren beibringen

    Zitat

    Aber mehr sorgen macht mir der link Inhalt. Mir will sich nicht erschließen wieso der nich direkt zum Ziel Inhalt springt.

    Ich bin mir nicht sicher was du meinst, vermute aber mal dass dich stört dass die angesprungene Überschrift hinter der Navigation verschwindet - dagegen hilft ein scroll-padding-top für das html-Element.

    Ich habe dir ja trotzdem eine Lösung gepostet. ;)

    Genau das ist ja das Problem. Wer immer wieder fertige Lösungen vorgesetzt bekommt, kommt halt immer wieder um bequem fertigen Code abzugreifen, egal ob für private oder kommerzielle Zwecke - selber machen geht auch garnicht da man als Fragender durch das Kopieren von fertigen Lösungen nicht (genug) lernt um Probleme irgendwann auch selbst lösen zu können (früher oder später wohl schon, aber das abgreifen von fertigen Lösungen ist ohnehin entspannter …).

    Frage: kann ich problemlos auf den PHP-Mailer 6.1.8 wechseln, ohne dass die Funktionalität eines Formulars, das ich mit dem PHP-Mailer verschicke, beeinträchtigt wird?

    Ich nehme mal an du meinst "auf den PHP-Mailer 6.9.1" (wie im Betreff genannt) - warum probierst du es in der Testumgebung nicht einfach aus?

    Beim Überfliegen des Changelog habe ich jetzt aber nichts gesehen was dagegen sprechen sollte dass der Code auch mit der 6.9 noch läuft. Bei der 6.0.0 steht auch dabei dass die Version nicht abwärtskompatibel ist - bei späteren Versionen steht sowas nicht, ich würde also mal davon ausgehen dass sich innerhalb der 6er Versionen nichts gravierendes geändert hat.

    PHPMailer-master Verzeichnis liegt unter root

    Falsch. Wie ich schon schrieb gehören die Dateien in das Verzeichnis in dem die PHP-Datei liegt bzw. du musst den Pfad zu den Dateien eben so anpassen dass PHP die Dateien auch findet. Aber:

    Und darin befindet sich "PHPMailer-master/PHPMailerAutoload.php'"

    Die Datei gibt es in der aktuellen Version von PHPMailer nicht - wo hast du die Version her bzw. wo ist die Anleitung zu finden nach der du vorgegangen bist? Vermutlich hast du da eine uralte Version erwischt, verwende eine aktuelle Anleitung bzw. die Readme von PHPMailer.

    Code
    [Wed Oct 25 19:44:34.926488 2023] [fcgid:warn] [pid 3859936:tid 139954424747776] [client […]] mod_fcgid: stderr: PHP Warning:  Unexpected character in input:  '\\' (ASCII=92) state=1 in […]/php/contact-3.php on line 51, referer: […]

    Gemäß der allwissenden Müllhalde (aka Google) bzw. Stackoverflow liegt das Problem an der verwendeten PHP-Version: PHP 5.2 kennt noch keine Namespaces, stell auf auf eine aktuelle PHP-Version (>= 8.1) um.

    Vielleicht hat jemand ein passendes PHP, das ich einfach über mein HTML und CSS legen kann.

    Damit ist es leider nicht getan: das Formular ist unbedienbar da die einzelnen Felder keine Beschriftung haben - und nein, placeholder-Attribute sind keine Beschriftung!

    PHP
    $headers = 'From: ' . $_POST["name"] . '<' . $_POST["email"] . '>' . "\r\n" .
        'Reply-To: ' . $_POST["email"] . "\r\n" .
        'X-Mailer: PHP/' . phpversion();

    Keine gute Idee: der Besucher ist idR niemand der über deinen Server Mails verschicken darf - du erhöhst damit das Risiko dass solche Mails als Spam eingestuft werden und u.U. garnicht erst ankommen.

    Zitat
    Code
     mail( "kontakt@ristorante-sicilia-reinheim.de", $_POST['subject'], $_POST['message'], $headers );

    Vergiss mail(), verwende eine Mailerklasse (z.B. PHPMailer) um Mails zu verschicken.

    Zitat

    Das Layout gefällt mir sehr gut nur die Technik macht Probleme.

    Definiere "macht Probleme".

    Der Inhalt des Warenkorbs wird nicht im Cookie gespeichert, sondern in der Session. Die Session wird zerstört, wenn du den Browser schließt.

    Das ist nicht ganz richtig. Der Warenkorb wird in der Session gespeichert, das stimmt - aber diese wird nicht zerstört wenn der Browser geschlossen wird. Die Sessiondaten liegen (idR in Form einer Textdatei) auf dem Server und werden vom GC (Garbage Collection) regelmäßig aufgeräumt (bei ungünstiger Konfiguration u.U. auch dann wenn der zugehörige Cookie eigentlich noch existiert und die Session noch benötigt würde!). Beim Schließen des Browsers wird lediglich das Cookie gelöscht womit die Session am Server nicht mehr zugeordnet werden kann und bei einem erneuten Besuch der Seite eine neue Session gestartet wird.

    Ok, danke! Und warum wird die Session zerstört, wenn ich den Browser schließe? Wäre es nicht möglich, das Cookie im Browser sowie die Session auf dem Server länger zu speichern oder ist dies technisch nicht machbar?

    Doch, sowohl Session als auch Cookie lassen sich auch länger speichern (durch Anpassen der Einstellungen session.gc_maxlifetime bzw. session.cookie_lifetime) - als Besucher einer Seite hast du da aber keinen Einfluss. Sessions sind eben so definiert dass sie nur bis zum Schließen des Browsers gültig sind und der Standardwert für cookie_lifetime ist eben 0 (also bis zum Schließen des Browsers).


    Vorsicht, eine längere Laufzeit des Session-Cookies heißt u.U. dass es im Bezug auf die DSGVO in eine andere Kategorie fällt und du die Einwilligung des Besuchers brauchst - für Session-Cookies brauchst du die wohl nicht (keine Rechtsberatung, frag ggf. den Anwalt deines geringsten Misstrauens!).

    Beim Einsatz von SQL-Datenbanken sollte das Abrufen aller Spalten eines Datensatzes per SELECT * vermieden werden. […]

    Völlig richtig, das größere Problem an der Codezeile ist allerdings die fehlende Behandlung des Kontextwechsels, so ist der Code gefährlich! Direkt davor ist ja anscheinend noch klar wie das richtig geht, da werden prepared Statements verwendet (wenn auch das Ergebnis der Abfrage nicht abgeholt wird) …

    Wozu Eingaben & Buttons mit dem input-Tag realisieren, wenn es doch den button-Tag als "richtigen" Button gibt?

    Zumal ein richtiger <button> noch die Vorteile hat dass man die Werte der name-/value-Attribute unabhängig von der Beschriftung des Buttons definieren kann und diese auch nicht nur aus Text bestehen muss. Das Problem hier ist allerdings dass Links und Buttons (egal ob input oder button) nicht verschachtelt werden dürfen, <a><input></a> ist also kein gültiges HTML - aber m.scatello schrieb ja schon dass der Code nach /dev/null verschoben gehört …