Beiträge von tk1234

    hover alleine taugt nichts, egal auf welchem Gerät: es gibt auch Personen die kein Touch-Gerät aber auch keine Maus verwenden (können), für die sind Links die nur per hover erreichbar sind evtl. unerreichbar. Für eine zugängliche Navigation braucht es etwas mehr

    Ich möchte nun daraus etwas animiertes Basteln.

    Nein, möchtest du nicht. Irgendwelches Gezappel lenkt nur vom eigentlichen Inhalt der Seite ab und wenn man mal eine der beiden Legenden braucht ist garantiert die falsche gerade da. Von der Lesbarkeit der Farben mal garnicht anzufangen …

    Achja: mit HTML/CSS alleine geht das nicht, da brauchst du JS dafür.

    Vom Prinzip her richtig, aber wenn man das in einem Admin-Bereich macht, der abgesichert ist und man nur selber drauf Zugriff hat, sehe ich das nicht als Problem an

    … zumindest solange bis der Browser anfängt im Hintergrund die verlinkten Seiten vorzuladen und dabei fröhlich Daten löscht. Imho ist es sinnvoll sich anzugewöhnen solche Aktionen *immer* per POST zu machen, auch in einem Adminbereich den man nur selbst benutzt - auch das kann sich ja ändern.

    also immer noch sehr viel trial an error.

    Ich spendiere mal noch ein "d" - Fehler verfolgen ist noch weniger sinnvoll als wild rumprobieren. Beschäftige dich erstmal mit den Grundlagen, alles andere führt zu nichts.

    separate datei, meinst du etwas in der art:

    Nein. Das was du da gepostet hast gibt nur einen Syntaxfehler. Mir ist auch nicht wirklich klar was du eigentlich vor hast, aber Löschaktionen sollten niemals per get-Request erfolgen sondern immer per post-Request - du brauchst also keine Link sondern ein Formular mit Button.

    Was das erreichen des Untermenüs angeht klappt das bei mir aber im Screen-Media, wie auf der Mobile-Ansicht einwandfrei - womit hast dir das denn angeguckt?

    Am Desktop mit Firefox und Vivaldi, am Handy (Samsung A51) mit Vivaldi. Am Handy aber nur die Variante mit dem <li>.</li>, eine extra Seite ohne die Konstruktion habe ich nicht gebaut und damit nicht testen können.

    Irgendwas stimmt mit der Seite übrigens nicht, die Browser (besonders am Handy) reagieren beim Scrollen o.ä. sehr zäh, die Seite ist kaum bedienbar.

    Jetzt funktioniert das ganze mit dem Slide-In der UnterLinks ( <ul><ul> ) allerdings nur, wenn über besagtem 'Überlink' ein […]

    Das kann ich nicht nachvollziehen, selbst wenn ich das <li>.</li> per Inspektor entferne "funktioniert" die Unterebene trotzdem. Die Anführungszeichen deswegen da deine Seite wegen der Checkbox-Konstruktion nicht barrierefrei ist und damit eben nicht funktioniert (auch mit der Maus lassen sich Untermenüpunkte nicht erreichen da das Untermenü in der falschen Höhe erscheint).

    (wie gesagt, Mobile-Ansicht... also Handy, Tablet oder kleiner Browser (max-Breite 768px) )

    Falsche Einheit für Breakpoints, verwende em.

    Übrigens arbeite ich bei der WebSite mit der SmartyEngine, aber glaube das sollte eig kein Problem sein, oder?

    Wie die Seite zusammengebaut wurde ist dem Browser völlig egal - nur hat dein Problem mit Smarty nichts zu tun, im Code sollte also auch nur das stehen was tatsächlich beim Browser ankommt.

    Bei deinem "Ordnerbaum" blicke ich nicht durch was da wo liegt - da fehlt (fast) jegliche Einrückung um das vernünftig erkennen zu können. Ich vermute aber mal dass du wirklich ../ brauchst um eine Eben höher zu kommen (in dem Link geht es um Links in HTML, ./ und ../ gilt auf Dateisystembasis aber genauso).

    PHP ist es völlig egal was da in welcher Datei steht, dass da einzelne HTML-Tags in einer Datei stehen interessiert PHP nicht - am Ende muss aber trotzdem valides HTML rauskommen sonst ist es ein Glücksspiel ob die Darstellung in den Browsern passt oder nicht. Einfach ein div offen lassen ist also nicht wobei dein wrapper-Div sowieso überflüssig ist, du hast bereits ein Element das die komplette Seite enthält: body. Aber dein raten woran es liegen könnte ist Blödsinn: schalte display_errors ein (oder schau ins Errorlog) und setze error_reporting hoch dann sagt dir PHP schon wo das Problem liegt.

    Außerdem halte ich das Stückeln für unübersichtlich und fehleranfällig, aber wenn du meinst … Was machst du wenn du für body mal ein Attribut (z.B. id oder class) brauchst?

    Auch ist dein HTML kaputt:

    • img ist ein leeres Element, </img> gibt es nicht (dito bei hr)
    • vergiss Attribute wie align (beim img)
    • img *muss* ein alt-Attribut haben
    • a darf kein button enthalten
    • im head fehlt ein meta-Element mit der Viewportangabe
    • <div class="sidebox"> klingt nach <aside>
    • <a id="pagetop"></a> ist Unsinn, ID für body oder zumindest ein Element ohne Bedeutung (span/div) reicht
    • <div class="wrapper"> ist Unsinn und </div> fehlt, siehe oben

    dachte der php code wird nicht angezeigt bzw. nur serverseitig abgehandelt ^^

    Das stimmt schon - aber kannst du garantieren dass in deinen Scripten keinerlei Sicherheitslücken sind und der Server so sicher ist dass da garantiert nie jemand Zugriff darauf bekommen kann? Oder dass die Scripte mit dem Passwort darin garantiert nie in falsche Hände gelangen? Nein, kannst du nicht, deswegen immer nur den Hash des Passworts speichern, damit kann niemand was anfangen und zum Einloggen braucht es das Passwort nicht im Klartext.

    Ich möchte das die sternen nur innerhalb des Bildschirm angezeigt werden und keinen Scrollbalken des wegen generiert.

    Den ohne die Sternen hats keine Scrollbalken.

    Ein Anfang wäre es wenn du die Hinweise die du bekommst auch umsetzen würdest: ich habe dir schon irgendwo oben geschrieben dass du das Bild mit dem Stern verkleinern sollst (also die leere Fläche um den Stern entfernen). Achja, wurde glaube ich hier im Thread noch nicht erwähnt: du weißt schon dass so Animationen so vor 20 Jahren aktuell waren (wenn auch glaube ich eher mit Schneeflocken)?

    if (

    $passwort == ( $_POST['passwort'] ))

    {

    Nein. Ok, der Code zerstört jetzt keine Daten mehr aber die Klammern um $_POST sind überflüssig und v.a. hast du meinen letzten Satz in #2 nicht beachtet: Passwörter niemals im Klartext speichern (Ausnahme sind natürlich die Passwörter für Datenbankverbindungen o.ä.).

    Aber wozu überhaupt das Passwort? Der Benutzer kann doch die about.html auch gleich direkt aufrufen …