Den Aria-Kram braucht kein Mensch (mehr). […]
Was für ein Schwachsinn!
Natürlich ist WAI-ARIA immer noch wichtig, die Zugänglichkeit von Seiten wird tendenziell sogar wichtiger als früher: früher[tm] wurde wenig Wert auf die Zugänglichkeit von Seiten gelegt (wohl auch mangels entsprechender Techniken), heute ist das anders. Klar, viel lässt sich erschlagen indem man die semantisch richtigen Elemente funktioniert, aber das geht eben längst nicht immer!
Ohne es ausprobiert zu haben: evtl. fehlt einfach die Viewportangabe.
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)
Hier gilt für das Script das gleiche wie bei php.de: es taugt nichts/ist gefährlich, entsorge es fachgerecht.
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.
Und noch eine Info: das Script ist nicht das Gelbe vom Ei.
Das ist noch vorsichtig ausgedrückt: das Script ist gefährlich (Kontextwechsel werden überhaupt nicht behandelt) und gehört fachgerecht entsorgt! Das in dem von dem Script erzeugten Formular die Beschriftung der Felder fehlt, fällt da schon gar nicht mehr groß ins Gewicht …
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.
Kannst du dir doch selber programmieren mit Greasemonkey
Wozu, da gibt es doch schon was …
HTMLLerner23: bitte erst auf das Datum eines Threads schauen und nicht wahllos (ur)alte Threads ausgraben.
Oh, guter Einwand... daran habe ich nicht gedacht. Weil beim Handy gibts ja keine Maus mit der man „hovern“ kann...
Vergiss die Tastaturbedienung nicht! :hover feuert nicht wenn das Element per Tastatur angesteuert wird …
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?
<div id="ausgabe"></div>
Nein, <output> existiert.
Ansonsten gilt natürlich das bereits gesagte: das ist kein HausaufgabenErledigungsService und bei solchen Fragestellungen sollten keine Lösungen gepostet werden (ich bin generell gegen fertige Lösungen, in solchen Fällen aber sowieso).
Was mache ich falsch oder habe ich das Untermenü falsch aufgebaut?
Oder. Das Untermenü taugt überhaupt nichts: es ist per Tastatur garnicht und am Touch-Display nur umständlich bedienbar.
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):
<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.