Beiträge von Re:Later

    Das hat was mit Barrierefreiheit zu tun und es fehlt einfach passendes CSS. Das ist schon richtig so. Füge das am Ende deiner CSS-Datei ein:

    Code
    1. a .force-read-before {
    2. position: absolute;
    3. width: 1px;
    4. height: 1px;
    5. padding: 0;
    6. overflow: hidden;
    7. clip: rect(0, 0, 0, 0);
    8. white-space: nowrap;
    9. border: 0;
    10. }

    Dann wird z.B. sehgeschwächten Screenreader-Nutzern das vorgelesen, die Titelattribut des Links nicht sehen können bzw. nicht vorbereitet sind, dass Link ein neues Fenster öffnet.

    Ich kann das auch auf IE 11 (der einzige IE, der, wenn überhaupt noch zu berücksichtigen ist) nicht nachvollziehen. Ich seh aber auch keine Seite, die irgenwie so aussieht, wie deine Bilder (grauer Hintergrund und so). Müsstest also den korrekten Link posten.


    Ich würde den IE ignorieren.

    Ich Depp habe gerade wieder gelernt, dass man das als Dienstleister unbedingt im Angebot erwähnen muss, dass IE11-Anpassungen mehr kosten ;-)

    Viele Firmen bleiben hartnäckig und ich habe gerade 2 Tage Mehrarbeit hinter mir, ein "schickes" Bootstrap-4-Template für IE11 nachzubessern, weil Microsoft den IE-Müll zwar noch supportet, aber sich seit Jahren weigert, zahlreiche flex-Bugs zu korrigieren, Features, die u.a. das Arbeiten mit Bootstrap-4 eben so "schick" machen.


    Unterhalb IE11 ist aber tatsächlich "tot" und man sollte als Dienstleister eher verweigern, Seiten dafür zu erstellen, als für unsichere Versionen zu arbeiten.

    Statt deinen kopierten Override default.php zu nennen, gibst du ihm einen anderen Namen, bspw.

    sonstwas.php,

    sonstwas_component.php

    usw..


    Im Menümodul kannst dann "sonstwas" im Feld "Layout" auswählen.


    So kannst diverse Alternative Layouts anlegen. Klappt für (fast) alle Module.


    Bei mod_menu muss man noch beachten, dass in der Basisdatei "sonstwas.php" diese 2 Stellen angepasst werden müssen

    Code
    1. getLayoutPath('mod_menu', 'default_ ...usw...

    "default" durch "sonstwas" ersetzen.

    In einem Override kann man auch so machen machen. Ich geh von einem Template-Override der Original-Joomla von

    /components/com_content/views/featured/tmpl/default_item aus:


    Da findet sich

    PHP
    1. <?php echo $this->item->introtext; ?>

    Da macht man draus

    PHP
    1. <?php
    2. $Limit = 250;
    3. echo JHtml::_(
    4. 'string.truncateComplex',
    5. $this->item->introtext,
    6. $Limit
    7. );
    8. ?>

    $Limit ist dabei die gewünschte, maximale Länge.


    ODER:

    PHP
    1. <?php
    2. $Limit = 250;
    3. echo JHtml::_(
    4. 'string.truncate',
    5. $this->item->introtext,
    6. $Limit
    7. );
    8. ?>

    Erste Variante (truncateComplex) erhält die HTML-Tags, bspw. Links, Überschriften und Absätze im Text, hat aber die unschöne Eigenart, dass die abschließenden 3 Pünktchen (...) in einer neuen Zeile erscheinen. Braucht man dann wieder zusätzlichen Code (zu faul).


    Zweite (truncate) entfernt alle Tags ist also gut geeignet, wenn der Introtext puristisch gehalten wird. Einfach stinknormale Absätze.

    Erst das RokCommon Plugin aktualisieren auf Mindest-Version 3.2.6. Aktuelle ist 3.2.8, geht also.


    Dann erst das RokSprocket.


    Deshalb ist es immer gut Fehlermeldungen in voller Länge zu posten. Hätte mir etwas Code-Wühlerei erspart ;-)


    So irgendwie wird die Melsung aussehen:

    Zitat

    RokSprocket needs at least RokCommon version 3.2.6. You currently have RokCommon version %s

    Nun habe ich im Verzeichnis mod_login eine dritte default.php (versehen mit dem Datum von heute), mit der ich nichts anfangen kann.

    Wenn du einen neuen Override anlegst via Backend-Geklicke und schon einer da ist, erhält der neue eine Datumsmarkierung.


    Ich muss aber zugeben, dass mir die Sinnhaftigkeit dahinter nicht wirklich klar ist ;-) Irgendwo werden einem die Unterschiede der Overrides zu Original angezeigt. Aber wie gesagt blick ich nicht wirklich zu welchem Original eigentlich und wozu.


    Aber du kannst die Dateien löschen und fängst dann mit einem neuen Override an. Der heißt dann wieder default.php und ist frisch.

    Könntet ihr bitte prüfen, welche Cookies auf meinen Seiten aktiviert werden.

    Für den Firefox gibt es das kostenlose AddOn "Cookie Quick Manager". Damit kann man sehr gut die Cookies identfizieren, die dein Browser so sammelt.


    Klickerst also die Seiten einfach mal durch, nachdem du die Cookies alle gelöscht hast. Dann siehst, welche neu erscheinen.

    Ich verstehe nicht, woher der o. g. Code „#dokument...“ kommt.

    Der kommt vom eingebundenen IFrame. Findest du auch, wenn Inhalte des IFrames angezeigt werden. Hier ein willkürliches Beispiel:



    Kurz: "Ausgeführt/Abgeholt" wird er, aber irgendwas blockiert die Darstellung des Inhalts (in <html> und <body>). Das können u.a. Browsereinstellungen sein und/oder Sicherheitseinstellungen (Seite läuft unter https, aber IFrame wird via http abgefragt), Fremdseite mag es nicht, dass deine Seite nicht erreichbar ist usw. usf. Gibt es Diverses...

    Wenns so einfach wäre im DPCalendar-Wust die richtige Zeile zu finden ;-) Deshalb mein Hnweis zu CSS.


    Overrides gehen da genauso wie in anderen Erweiterungen, anderen Modulen. Welches Modul es ist, weißt nur du. Ob PageBuilder mitspielt kann man nur hoffen. Machen ja oft ihr eigenes Ding.

    Ich habe auf einen Override im Template gehofft

    Man verliert irgendwann die Lust, puristische Codes abzuliefern, um dann hinterher zu erfahren, dass irgendwelche schrägen PageBuilder und/oder Frameworks, die komplett weg sind von Joomla-Standards, verwendet werden ;-) Im Grunde einfach so eine Joomla-Override-Weiche, ob es sich um eine Kategorie- oder Einzelartikelansicht handelt.

    Sagen wir, dein neues Template liegt im Ordner "sonstwas".


    Lege in diesem neuen Template im Ordner /languages/ einen Unterordner /de-DE/ an.


    Gehe in den Joomla-Ordner /languages/de-DE/ und kopiere die beiden Dateien


    de-DE.tpl_beez3.ini

    de-DE.tpl_beez3.sys.ini


    in den neuen Ordner im Templateordner.


    Benenne diese Kopien dann um nach


    de-DE.tpl_sonstwas.ini

    de-DE.tpl_sonstwas.sys.ini


    Alternativ kannst die umbenannten Kopien auch im Joomla-Ordner /languages/de-DE/ ablegen.

    Hm, ich trage seit Ewigkeiten Umleitungen so ein, mal mit, mal ohne einleitenden Schrägstrich.

    Und funktioniert problemlos dann auf allen Plattformen (XAMPP, online, mit http, ohne https)


    Und noch mal, Die Umleitungskomponente leitet nur dann um, wenn die "Alte Adresse" nicht erreichbar ist.



    Zum Testen gebe ich dann im Browser ein

    Code
    1. http://example.org/de/anfrageliste
    2. example.org/de/anfrageliste
    3. https://example.org/de/anfrageliste
    4. http://www.example.org/de/anfrageliste
    5. usw.

    Und alle funktionieren.

    Wenn du die http -> https weiterleitung beim Provider aktivierst, wird die zuerst ausgeführt.


    Wenn du sie in der htaccess durch 3,4-Zeiler erzwingst, gehört sie halt an den Anfang (vor den anderen Weiterleitungen). htaccess-Umleitungen finden statt bevor Joomla ins Spiel kommt.


    So lange du in der Joomla-Umleitung die Umleitungen ohne Domain, also ohne den Part http://example.org anlegst (für das Sammeln kann man das im Plugin wegkonfigurieren), gibt es da keine Probleme, wenn man mittendrin auf https umstellt. Und ja, die Joomla-Umleitung ist die letzte.


    Auch in der htaccess brauchst du den Domainteil nicht. Machen viele falsch/unhandlich.


    Wenn du eine Weiterleitung

    von http: // domain / Beitrag
    auf http: // domain / neuerbeitrag

    in der Umleitungskomponente anlegst, muss gewährleistet sein, dass die alte URL eine Fehlerseite (404) ausgibt. Sonst tut die nämlich nichts.


    Da ist dann die htaccess der richtige Platz.