Beiträge von tk1234

    Wenn du zb auf der Startseite bist gibst du dein <li> eine Klasse

    <li class="active_seite">

    Nein. Das richtige Attribut für den Fall ist aria-current="page" - so ist für jeden Client klar dass sich der Link auf die aktuelle Seite bezieht. Die Formatierung kann dann ja ebenfalls über CSS erfolgen, der Attributselektor existiert.

    Es gibt auch noch die möglichkeit mit :target

    … die aber hier nichts bringt.

    BTW: Für die Navigation kannst Du mit Vorteil auch das nav-Tag verwenden.

    s/kannst/musst (ja, ich weiß das ist Perl, kein PHP)

    woran liegt es wohl?

    Daran dass du nicht alle Dateien hochgeladen hast.

    Aber du kannst dir die Mühe des Hochladens ohnehin sparen: der Code der Seite taugt nichts und gehört fachgerecht entsorgt - die einzig sinnvolle Option ist es die Seite neu zu machen. Wie ich in #10 schon schrieb müssen Seiten auf allen Geräten funktionieren und deine passt sich eben Mobilgeräten nicht an (die machen inzwischen einen großen Anteil aus!) - von der Barrierefreiheit mal garnicht erst anzufangen.

    ja, aber wenn ich dich richtig verstehe, hätte ich die zeile doch in dem visual studio code und darin in der json die zeile löschen sollen,

    Nein, ich schrieb doch dass du die Zeile mit einem anderen Editor löschen sollst. Datei umbenennen, Zeile mit VS Code löschen und wieder zurück benenne wäre natürlich auch gegangen.

    warum hat es nach einer deinstallation und wieder installieren die einstellungen gehalten?

    Weil bei der Deinstallation die die Einstellungen wohl nicht gelöscht werden.

    Ich verstehe nicht genau, was Traffic ist. Ich dachte, dass wären einfach nur die Besucherzahlen. Hat man auf strato automatisch mehr Besucher als auf bplaced. Ich fände irgendwie schade, meine Homepage auf bplaced aufzugeben, nachdem ich mir so viel mühe gegeben habe, aber ich habe praktisch keine Besucher.

    Wie basti1012 schon schrieb ist der Traffic die Menge an Daten die dein Server verschickt (hängt aber idR nicht direkt mit der Größe der Dateien zusammen, wenn die komprimiert übertragen werden, werden weniger Daten übertragen als die Dateien groß sind - zumindest bei HTML/CSS/JS). Der Traffic ist aber idR so großzügig bemessen (oder unbeschränkt) dass du da an keine Grenzen stoßen wirst.

    Mit den Besucherzahlen hat der Traffic aber (erstmal) nichts zu tun zwar hast du bei großeren Besucherzahlen idR mehr Traffic aber die Besucherzahl ist den Anbietern von Webspace egal und deswegen auch bei den Eigenschaften nicht eingeschränkt. Die Anzahl der Besucher hat auch absolut nichts mit dem Hoster zu tun, ob die Seite bei Strato, bei bplaced oder sonst wo liegt ist völlig egal - die Besucherzahl hängt nicht davon ab.

    Ich glaube allerdings dass du dem Irrtum aufsitzt, dass man mal eben schnell eine Seite ins Internet stellen kann und diese dann sofort Massen von Besuchern hat und über Werbung Geld abwirft. Vergiss es.

    Ich weiß nicht welchen Inhalt deine Seite haben soll/hat, aber mal eben so eine Seite hinklatschen funktioniert nicht. Du musst die Seite pflegen und mit Inhalt füttern, mit etwas Glück wird sie dann gefunden, verlinkt und am besten auch regelmäßig wieder besucht. Achja, technisch sollte die Seite natürlich auch in Ordnung sein, also ordentliches HTML und das CSS so geschrieben dass sie sowohl auf Mobilgeräten als auch am Desktop gut aussieht und gut bedienbar ist (Zugänglichkeit für körperlich eingeschränkte Benutzer usw. nicht vergessen!).

    Verabschiede dich auch von dem Gedanken mit der Seite über Werbung Geld zu verdienen, da brauchst du schon richtig viele Besucher (auch solche die die Werbung nicht blockieren, je nach Zielgruppe kann der Anteil derer auch recht hoch sein), rechne erstmal nicht damit mehr als einstellige Cent-Beträge zu bekommen (wenn überhaupt).

    Du solltest Werbung machen und Googel beauftragen deine Page in regelmäßigen Abständen zu crawlen, damit du auch in der Suche gefunden wirst.

    Google findet die Seite schon von alleine, irgendwelche revisit-after-Meta-Tags bringen da exakt garnichts.

    ich habe nun etwas gefunden, man muss eine datei namens settings .json einfach löschen, danach ist das programm irgendwie wieder resetet.

    In der Datei stehen alle deine Einstellungen drin, wenn du die Datei löschst, sind die natürlich weg - deswegen schrieb ich ja dass du nur die Zeile mit »window.zoomLevel« löschen sollst …

    Welche Tastenkombination hast du verwendet? Dein Problem ist vmtl. nicht die Schriftgröße (die hat auf den Einstellungs-Dialog keinen Einfluss) sondern das zoomLevel und das lässt sich standardmäßig mit Strg+- verringern (vergrößern mit Strg+Shift+0). Aber lösch einfach mit einem anderen Editor die Zeile mit »window.zoomLevel« aus der settings.json (unter Linux in: ~/.conf/Code/User, sonst siehe Doku).

    Mal abgesehen davon dass die Meldung ohnehin Unsinn ist: warum verwendest du einen click-Handler wenn du eigentlich auf submit reagieren möchtest?

    Außerdem: dein HTML ist kaputt: es fehlt was, außerdem dürfen IDs nicht mehrfach verwendet werden und "rot" ist ein völlig falscher Name für eine ID (für eine Klasse auch) - IDs/Klassen sollten niemals nach dem Aussehen eines Elementes benannt werden.

    Danke die Abfrage hat mit einem SELECT * FROM Statement super funktioniert.

    Vergiss dass es den Stern hinter "SELECT" gibt, gib *immer* die Spalten an die du brauchst.

    Die Double-Opt-in Funktion ist eine gute Idee und schaue ich mir die kommenden Tage an..

    Ich würde es weniger als "gute Idee" ansehen sondern eher als Pflicht …

    Der Newsletter ist in der Fußzeile integriert. Wird eine E-Mail Adresse eingegeben, läd die Seite neu - Dadurch wird der User wieder hoch zum Start geleitet.

    Was muss ich tun damit zB. bei einer falschen Eingabe der User unten beim Newsletter bleibt?

    Wie schon in #16 geschrieben: entweder dem form-Element die Attribute action="#newsletter" und id="newsletter" (statt »newsletter« kann da natürlich auch was anderes stehen) verpassen oder eigene Seite für die Newsletteranmeldung machen.

    Gibt es eine Möglichkeit, zu überprüfen ob in der DB eine E-Mail Adresse bereits vorhanden ist, um doppelte Einträge zu verhindern?

    Vor dem Speichern abfragen ob es Datensätze es mit der Adresse gibt, wenn ja -> Fehlermeldung. Alternativ kannst du auch prüfen ob das execute fehlschlägt oder nicht (mit deinem Unique-Index wird jeder weitere Eintrag eine Adresse einzutragen ja fehlschlagen, das lässt sich abfangen).

    Übrigens: du denkst an sowas wie Double-Opt-in damit nicht jeder beliebige Adresse da eintragen kann die vielleicht gar keinen Newsletter haben wollen?

    man könnte ja, weil es ein Affenformular ist ja auch den Code nutzen PHP
    <form action="<?php echo $_SERVER['PHP_SELF']; ?>" method="post">

    Das hat man auch schon 1000 mal gesehen.

    … und war schon 10000mal falsch: das ist eine gefährliche Sicherheitslücke, auch hier muss der (doppelte!) Kontextwechsel beachtet werden!

    Die von dir genannten Varianten PHP_SELF, SCRIPT_NAME und REQUEST_URI enthalten alle unterschiedliche Werte. Mit »/index.php/"onmouseover="alert('hi')« als URI und ohne Behandlung der Kontextwechsel bekommst du als Ergebnis jeweils (ich habe mal ein a-Element genommen, das gleiche gilt natürlich für form):

    HTML
    <a href="/index.php/"onmouseover="alert('hi')">PHP_SELF</a><br>
    <a href="/index.php/%22onmouseover=%22alert('hi')">REQUEST_URI</a><br>
    <a href="/index.php">SCRIPT_NAME</a><br>

    Wie du siehst, ist PHP_SELF gefährlich: das ist eine Sicherheitslücke da sich beliebiger HTML-Code (und damit auch JS-Code) einschleusen lässt. Bei REQUEST_URI wird der Wert URL-Codiert (macht PHP anscheinend von alleine, nachgeforscht warum und weshalb habe ich da jetzt nicht, meine lokale PHP-Installation (aktuell PHP 8.0) spuckt das aber so aus) und bei SCRIPT_NAME wird alles nach dem Dateinamen abgeschnitten (auch ein evtl. vorhandene path-info).

    Wenn man allerdings alle URIs auf die index.php umschreibt (was bei aktuellen Scripten oft/meist der Fall ist) und die entscheidet was geladen wird, fallen zwei Varianten weg: beim Aufruf von z.B. »/training/«, spucken PHP_SELF und SCRIPT_NAME nur »/index.php« aus - was natürlich unbrauchbar ist. Nur REQUEST_URI enthält den hier benötigten Wert »/training/«.

    Was hältst du von der Methode?

    Viel. Viel Abstand. Soweit ich mich erinnere hat das historische Gründe: früher war das action-Attribut notwendig und konnte/durfte nicht weggelassen werden - in HTML5 darf das Attribut weggelassen werden, in dem Fall ist automatisch die aktuelle URI das Ziel des Formulars - warum soll man sich die Mühe machen die URI von Hand da reinzubasteln?

    - Sonderzeichen wie ', oder < und > im Eintrag werden immer noch an die db übertragen, ist das normal?

    Davon ausgehen dass du mit type=text getestet hast: ja. Die Zeichen sollen ja nur so behandelt werden, dass sie keinen Schaden anrichten können, entfernt werden sie aber natürlich nicht.

    In der newsletter.php befindet sich das prepared statement.

    Wie m.scatello schon schrieb: du hast das mit dem Affenformular noch nicht begriffen. Außerdem hast du schon wieder Code kopiert ohne ihn zu lesen/zu verstehen - sonst hättest du nämlich den Kommentar "Registrierung ausführen..." gesehen: der muss natürlich durch den Code für die Speicherung der Daten ersetzt werden. Auch die Zeile »$statement->execute(array($mail));« in der newsletter.php zeigt dass du es noch nicht wirklich verstanden hast: ich habe bereits mehrfach geschrieben, dass ein umkopieren von $_POST['mail'] nicht nötig ist, du verwendest aber trotzdem immer noch $mail statt $_POST['mail'].

    Ich bin dann erstmal raus hier, eine Antwort gibt es erst wieder wenn deutlich wird, dass das Verständnis da ist.

    bis jetzt programmiert in HTML & CSS.

    Garantiert nicht: HTML und CSS sind keine Programmiersprachen, damit kann man da auch nichts programmieren :)

    Zur Verständnis: Mein Code hat mit htmlspezialchars() den kompletten echo String eingebunden.

    Du hingegen nimmst nur die Variable - so würde ich es mir erklären - weil diese an die DB weitergeleitet wird und durch htmlspezialchars() nicht manipuliert werden kann!?

    Ich nehme nur die Variable weil nur die von außen kommt und damit als potentiell gefährlich anzusehen ist - was sonst mit dem Inhalt passiert ist egal. Der Rest von dem Text steht ja fest im PHP-Code und enthält damit garantiert keine gefährlichen Daten. Den kompletten String zu behandeln ist nicht nötig, schadet aber auch nicht.

    Ich habe hier ein Affenformular gefunden.

    Kann ich es verwenden wenn ich es auf mein Formular anpasse?

    Ich würde davon abraten: die Seite beachtet das EVA-Prinzip nicht. Schau dir mal das Beispiel bei SELFHTML an, ganz optimal ist das (wegen dem die()) auch nicht aber definitiv besser als das bei php-kurs.

    Aber Frage, wie verknüpfe ich dann das Affenformular mit der newsletter.php? Oder reicht es wenn am Server eine affenformular.php -Datei liegt?

    Ich kenne deine aktuellen Dateien nicht, irgendwas "verknüpfen" musst du aber nicht: es gibt halt eine Datei in der die komplette Verarbeitung der Daten sowie das Formular steht. Vielleicht hilft die entsprechende Seite im Wiki von SELFHTML bzw. die dort verlinkte Seite bei php.de beim Verständnis.

    Was noch dazukommen wird ist eine DSGVO-Zustimmung...

    So eine Checkbox sollte ja kein Problem sein … Hinweis: das Name/Value-Paar von Checkboxen wird nur übertragen wenn diese ausgewählt wurde, andernfalls steht zu der Checkbox nichts in $_POST drin. Hilfreich könnte übrigens noch das required-Attribut sein (auch für das E-Mail-Feld).

    Abfragen will ich gar nichts. Es soll nur ein Eintrag in die DB gemacht werden, deswegen habe ich die Select * From Abfrage durch ein INSERT INTO ersetzt.

    Dann lass die drei Zeilen mit der while-Schleife einfach ersatzlos weg, du brauchst sie hier nicht. Aber genau das meinte ich: nicht einfach nur blind kopieren/abändern sondern auch genau anschauen und verstehen was das Script eigentlich macht.

    so, jetzt habe ich das Formular mit dem anfälligen script als eigene homepage am lokalen Server angelegt. Die Eingabe kommt auch in der db an, aber sobald ich ein ' oder es zB. mit order+by versuche kommt folgendes....

    Um das zu testen brauchst du ein input mit type=text (oder ohne type-Attribut) - bei type=email sorgt der Browser schon dafür dass da eine E-Mail-Adresse drin steht, allerdings kannst du dich nicht darauf verlassen das der Browser die Prüfung übernimmt: Formulare lassen sich manipulieren bzw. nachbauen, die Daten können also auch von wo anders her kommen.

    Ok, dann weiß ich leider nicht wieder der Code korrekt aussehen soll

    So wie ich es in der Code-Zeile geschrieben habe: htmlspezialchars() wird nur auf die Variable mit den Daten angewandt.

    Die Idee mit der Ziel Weiterleitung habe ich schon begonnen. Aktuell ist es auch so, dass ab dem Absenden des Formulars eine weiße Seite (so wie Du sagst) mit der Fehlermeldungen bzw. Erfolgsmeldung ausgegeben wird. Da eine Extraseite erstellt und auf die dann umgeleitet, damit es dann für den Benutzer freundlicher aussieht

    Falscher Ansatz. Vergiss die Weiterleiterei. Das ist ja gerade der Vorteil bei Affenformularen: die Fehlerbehandlung findet in einem Script statt, irgendwelche Weiterleitungen sind nicht nötig. Wenn das Script nach dem Abschicken des Formulars wieder aufgerufen wird, wird geprüft ob die Daten ok sind. Wenn ja werden sie gespeichert, wenn nein, wird eine Fehlermeldung ausgegeben und anschließend wieder das Formular (einschließlich bereits eingegebener Daten). Beschäftige dich mit dem Thema EVA-Prinzip.

    Ich verstehe Deine Frage nicht, das INSERT soll den Eintrag in die Datenbank übernehmen!?

    Die beiden Zeilen mit prepare und execute sind völlig ok und können so bleiben (laut #13 funktioniert das Speichern ja auch). Das "Problem" ist der while-Block danach: da versuchst du mit fetch() irgendwelche Daten zu holen ohne vorher mit SELECT welche abgefragt zu haben. Was an der Stelle richtig ist weiß ich nicht: du hast noch nicht verraten was nach dem Speichern überhaupt passieren soll. Und wenn du irgendwo Code kopierst: du musst den dann schon auch verstehen, sonst kommst du nie auf einen grünen Zweig, immer nur irgendwo Fetzen zusammen zu kopieren funktioniert nicht.