Beiträge von tk1234

    Ich hab von Redis keine Ahnung, aber dieses "return $ObjectMap;" scheint mir falsch zu sein, lass das mal weg (und vergiss nicht die Variable vorzubelegen sonst bekommst du eine Warning bzw. Notice).

    Fallback ist ja schön und gut, aber wie weit zurück sollte man dann die Browser unterstützen (alte IE Versionen, Netscape Browser, )? Wo zieht man sinnvoll einen Strich und sagt dem User dann "so leider nicht mehr"?

    Dem User sagst du überhaupt nicht "so leider nicht mehr". Der bekommt immer eine Seite auf der die benötigten Informationen zu finden sind, ob die gut aussehen oder jede Funktionalität vorhanden ist, ist dabei egal. Mit welchen alten Browsern du dir die Seiten anschaust hängt etwas von deiner Zielgruppe ab, caniuse ist evtl. auch ganz hilfreich um einschätzen zu können wie weit ein bestimmtes Feature unterstützt wird. Aber jeglicher IE sollte soweit ich weiß eigentlich auf aktuell noch unterstützten und mit aktuellen Update versehenden Windows-Versionen nicht mehr zu finden sein - die müssten (außer evtl. in Firmenumgebungen?) schon durch Edge ersetzt worden sein. Netscape kann man natürlich ignorieren, der war schon vor 10 Jahren tot.

    Wenn ich auf meinen Seiten diverse Techniken verwende, die von älteren Browsern nicht mehr unterstützt werden, wie kann ich diese Browser abfragen und auf eine Fehlerseite umleiten?

    Falsche Herangehensweise, was soll der Besucher dann auf der Fehlerseite machen? Nicht jeder hat Einfluss auf den installierten Browser. Liefere allen Browsern die gleiche Seite aus und sorge dafür dass die Inhalte grundsätzlich in allen Browsern zur Verfügung stehen - schön muss es ja nicht sein. In Browsern die die verwendeten neueren Techniken verstehen, sieht die Seite dann entsprechende besser aus bzw. bietet mehr Funktionalität, Stichwort progressive enhancement.

    Ich dachte, er "sieht" sich die URL an, die in der Browserzeile steht und "entscheidet" dann, ob er die css - Anweisung ausführt oder nicht.

    Nein. Der Selektor sucht alle Elemente mit der ID site-header die ein href-Attribut haben in dessen Wert "produkt" vorkommt - da dein div natürlich kein href-Attribut hat/haben kann, passiert natürlich nichts.

    Mit reinem CSS geht das was du vor hast nicht, da brauchst du eine Priese JS dafür (wenn in der URL der Wert "produkt" vorkommt per JS an <body> eine Klasse dranhängen und über einen entsprechenden CSS-Selektor position setzen).

    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