Beiträge von Re:Later

    Beim Durchsuchen des Codes habe ich noch die Variante method = "patch" gefunden.

    Finde ich bei mir nicht als XML-Eintrag. Da wäre nett, wenn du sagst, wo du das gefunden hast.


    Bei allen Erweiterungen, egal welcher Art, ist method="upgrade" empfohlen. Warum? Das weißt ja selber (siehe #1).


    Natürlich kann es in Ausnahmefällen sinnvoll sein, zuerst eine Deinstallation zu fordern, damit aller Müll entfernt wird. Man kann sich so das Löschen unnötiger, verwaister Dateien z.B. durch ein zu pflegendes <scriptfile> sparen. Aber ich pflege lieber das $deleteFiles und $deleteFolders im ScriptFile von Anfang an, anstatt gemachte Einstellungen, Inhalte jedesmal neu anlegen zu müssen.


    Übrigens könnte man auch ein method="tralalasonstwas" verwenden und das dann im eigenen Scriptfile irgendwie nutzen. Und an Joomla gibt man dann ein method=upgrade weiter oder so....


    Wie es beliebt.

    Du verwendest wohl nicht die aktuellste Version?

    Release Release 4.1.0 · joomla-extensions/search
    4.1.0 is designed natively for 4.0 and also fixes all styling issues from the development package
    github.com

    In der gibt es eine Zeile 44 gar nicht so.


    Und generell kann man in der Joomla-Konfiguration Fehler berichten auf KEINE setzen, damit so Meldungen den Besuchern nicht angezeigt werden.


    Verwende nicht das Modul Suche sondern Suchindex.

    Da widerspreche ich ganz entschieden. Wer SUchindex nicht mag, sollte weiterhin die normale Suche verwenden. Nicht umsonst ist die nach wie vor verfügbar.

    Für Performance- und SEO-Nerds versus Ästhetik-Nerds.


    Heise hat die Entdeckung gemacht, dass ein allgemein übliches

    Code
    font-display: swap;

    beim Abfragen von Webfonts u.U. die Seitenladung (Performance) unangenehm beeinflussen kann, so, dass die Google-Search-Konsole diesbzgl. schlechte Werte ermittelt.


    Die Anweisung oben sorgt dafür, dass, wenn ein Webfont nicht sofort abgeholt werden kann, der Browser eine Fallback-Schriftart lädt, dann aber doch den Webfont nachlädt, wenn dieser bei weiteren Versuchen, die im Hintergrund stattfinden, erreichbar ist; was dazu führt, dass die WebSeite technisch ermittelt länger braucht, um fertig zu sein.


    Eine Anweisung

    Code
    font-display: optional;

    kann das Problem vermeiden. Wenn der Font nicht abholbar ist, wird nicht mehr im Hintergrund nach ihm gesucht. Er wird nicht mittendrin nachgeladen und Fallbackschriftarten werden verwendet.


    Selbstverständlich sind Aspekte wie Browser-/Server-Caches/Caches, in dem die Webfonts ggf. schon liegen, also gar nicht neu abgeholt werden müssen zu beachten, die den gefühlten und technischen Gewinn gegen 0 gehen lassen könnten, also schwer messbar und nachvollziehbar.


    Nur nebenbei erwähnt: Der Satz "Da AMP mittlerweile keine Vorteile mehr bietet...". Es hatten also mal wieder die Recht, die sich ohne Hektik auf die stetige Weiterentwicklung der Webtechnologien (Hard- und Software) verlassen, als auf irgendwelche sonderlichen und arbeitsintensiven Erfindungen der Google-Kontrolleties (und dazu dient AMP).


    Wie eine Zeile CSS den Cumulative Layout Shift bei 3700 URLs verbessert
    Mit einer kleinen Anpassung im CSS reduzierten wir die Layout Shifts bei heise tipps+tricks drastisch. Eine Spurensuche enthüllte die Ursache.
    www.heise.de


    font-display - CSS: Cascading Style Sheets | MDN
    The font-display descriptor for the @font-face at-rule determines how a font face is displayed based on whether and when it is downloaded and ready to use.
    developer.mozilla.org

    Du wirst wohl leider einen Override von JLayout layouts\joomla\content\tags.php anlegen müssen. Oder, falls so einer schon im Template existiert, halt umfrickeln.


    Die Einstellungen gehören alle nicht zu Tags in Beiträgen.


    So als schneller Ansatz: Innerhalb der foreach-Schleife (siehe auch Bild unten): Dann hast den Bildpfad.


    Code
    if (!empty($tag->images))
    {
        $tagImages = new Registry($tag->images);
        $image = $tagImages->get('image_intro', '');
        // ODER
        // $image = $tagImages->get('image_fulltext', '');
    }

    Lässt sich denn diese Erweiterung mit dem Iframe formularen von Brevo verbinden?

    Nein, weil das Newletter-Formular konfiguriert man ja wohl bei brevo.com, denke ich. Brevo kenne ich nicht.


    Ich habe jetzt nicht alles gelesen oben. Vielleicht doppelt??


    Das ist jetzt insofern doof, wenn man es genau nimmt, weil du eigentlich auch für dieses Formular erst eine Einwilligung deiner Besucher abfragen müsstest, weil es ja externen Kram in die Seite holt. Und dann noch dazu, ein Google-Zeugs lädt.

    Beides müsste der Besucher also zuvor erfahren.

    Ob du es genau nimmst, bleibt leider dir überlassen.

    Es gibt Tools für Joomla, die so Abfragen "vor"die Iframes setzen können. Die Frage ist halt immer, wie genervt Besucher sind, dass sie da jetzt zusätzlich einwilligen müssen, nachdem sie blöden Datenschutzhinweis gelesen haben usw. usf.


    Ich kenne das Problem von CleverReach. Da hat man dann aber wenigstens die Möglichkeit, den HTML-Code ohne IFRAME in die Seite einzubinden. Die haben leider auch ein Google-Captcha drinnen, das nicht deaktivierbar ist, selbst, wenn man wollte.

    Aber der Besucher muss halt nur einmalig zu Beginn seines Besuches einwilligen, dass Google-Captcha geladen werden darf. Das geht einfach über das kostenlose "CookieHint and Consent"-Plugin. Wenn er da nicht eingewilligt hat, funktioniert auch Newsletteranmeldung nicht.

    Aber siehe 2.Bild unten (da fehlt das Captche), der Besucher bekommt 2 Möglichkeiten genannt, wie er "reinkommt".


    (Ich will dich nicht zu CleverReach locken! Ich schreib das nur, weil vielleicht kann man bei Brevo ja Ähnliches zusammenfrickeln; ohne Iframe. Und ja, bisschen Frickelei wars dann doch.)



    s sind ja nur 6 Textblöcke mit Bildchen im Content der Seite. Kein Hinweis auf das Cubes-Modul...

    Das meinte ich ja auch nicht. Das wirst da nicht finden, weils ja nach deiner Aussage gar keine solche Einstellung hast. Ich denke, dass du halt doch irgendwo anders so eine Einstellung hast, die man jetzt halt mühsam durchgehen muss.


    Oder anders: Ich habe in meinem Joomla genau 2 Funde mit "noindex".


    irgendwas mit com_content.article

    Die kannst wahrscheinlich ignorieren, weil Tabelle _history(?). Trotzdem spricht das dafür, dass du in deinem Joomla Einstellungen mit "noindex" hast, weil sonst gäbe es sie auch nicht in history.


    Nur um sicher zu sein:

    In Post #7 zeigst du ja gar nicht den Reiter "Metadaten", den Stef meinte. Prüfen würde ich, falls noch nicht gemacht, die Menüeinträge mit ID 166 und ID 200. Die haben sicher "noindex".

    Ich seh nach Durchforsten des Content Cubes-Particles-Codes eigentlich nix, was ein noindex setzen würde. Was mir halt auffällt, ist, dass auch die in den Particles verlinkten, cubes-losen Beiträge dann ein noindex haben?!?!?!


    Kannst ja mal den Tipp mit der Datenbank probieren. Vielleicht. Nur vielleicht.

    Siehe auch Bilder unten.

    - Gehst in die Datenbank, wo alle Tabellen aufgelistet werden.

    - Klickst oben "Suchen".

    - Gibst "noindex" ein.

    - "Alle Tabellen auswählen" nicht vergessen. Manchmal ist das schon, manchmal nicht.

    - Suche starten mit "OK".

    - Wenn was gefunden wird, sieht man einen "Anzeigen"-Link, der nach unten scrollt und die pro Tabelle gefundenen Einträge anzeigt.

    - Je nachdem, kannst ja dann im Backend mal kontroliieren.

    - Scrollst wieder hoch. Klickst den nächsten Link "Anzeigen"




    Wenn ich deinen Link öffne und Quelltext ansehe, sticht sofort ins Auge "noindex,follow":



    Und das ist nicht die einzige Seite, wo das so ist.


    Prüfe die Robotseinstellungen

    - in der Joomla-Konfiguration

    - In den Menüeinträgen

    - In den Kategorien

    - In den Beiträgen


    Leider (für dich im Moment zumindest) könnte das an irgendeiner dieser Stellen sein.


    Wennst bisschen fit bist, kannst auch in der Datenbank über alle Tabellen nach "noindex" suchen. Dann werden dir ggf. schon die EInträge angezeigt, die du im Backend dann anpasst.

    Bei mehrsprachigen Seiten kann man allerdings auch das Länderkürzel, bei dir also z.B. das /de/ für seine "Lieblingssprache" (standardsprache) unterdrücken lassen. Weiß allerdings nicht aus Stegreif in welchem Sprach-Plugin das einzustellen war.

    Hat jemand eine Idee, woran das liegen könnte?

    Das ist seit Joomla 4 so. Absichtlich. Auch bei Kategorien z.B., die bei dir früher vermutlich ein /21-formelles/ innerhalb des Links ergeben hätte.


    Man braucht mindestens 1 Menüeintrag, der versteckt sein kann, auf die oberste Kategorie von com_content, der z.B. vom Typ "Alle Kategorien" sein kann.


    Oder man macht sich die Mühe, den ganzen Menüaufbau mal zu überdenken. In deinem Fall vielleicht für Kategorie "formelles" einen verteckten (oder nicht) Menüeintrag anlegen.

    Ich verstehe die "Enttäuschung" bzgl. Template. Das Cassiopeia ist schon irgendwie was komplett anderes als das alte, weil ersteres Grid-CSS verwendet. Man darf dabei aber nicht vergessen, dass das jemand "ehrenamtlich" für Joomla erstellt hat, der eben bevorzugt bei seinen Templates mit Grid-CSS arbeitet. Die einzelnen Seiten-Bereiche sind somit etwas "verquaster" dahingenagelt/hingelayoutet, wo sie sind. Kurz: Lernkurve für Anpassungen, wenn man es trickiger umbauen will.


    Das "gepimpte" Protostar zu verwenden, halte ich für einen Fehler. Es basiert auf Bootstrap-2-CSS (technisch und inhaltlich bzw. bzgl. Mobilfähigkeit komplett veraltet und "überlang unnötig"), verträgt sich nicht mit aktuellem Bootstrap und/oder JQuery). Wenn man es verwendet, sollte man es gründlich auf aktuelles Bootstrap und neue Joomla-Features umstellen. Also auch reichlich Arbeit am Anfang bis man eine wiederverwendbare Vorlage ähnlich J!3-Protostar hat.


    Kurz: Ein Jain auf den Eröffnungspost ;)

    Und bzgl. "Update-Terror" sprechen wir eine Sprache. Allerdings längst nicht nur bzgl. Joomla ;)

    Nebenbei hat sich zwischen Joomla 4 und 5 gar nicht so viel geändert, wenn man Nutzer und/oder Entwickler ist. Ich denke der nächste Schock wird, zumindest für Entwickler, mit Joomla 6 kommen. Aber das fasel ich nur so vor mich hin. Noch gar nicht mit beschäftigt.


    Und zu K2:

    Zitat

    "Joomla loves backwards compatibility the same way vampires love the sun.


    For some unknown reason, the Joomla dev team always strives for the shiny/new, nevermind if this shiny/new is something users never see or experience (=constant Joomla API renamings & changes)."


    (Fotis Evangelou, K2-Entwickler zum Thema K2 für Joomla 4)

    Oder, gelegentlich die intuitivere Art ein universelles Captcha zu haben, das man in der Joomla-Konfiguration als Standard-Captcha aktivieren kann, weil gelegentlich ist das mit ECC+ etwas aufwendiger, das Captcha Fremderweiterungen unterzujubeln, was mehr an den Fremderweiterungen liegt als an ECC+:

    ECCC - EasyCalcCheck Captcha - Kubik-Rubik Joomla! Extensions
    EasyCalcCheck Captcha protects Joomla! core forms that support the plugin group Captcha like the user or contact component from the core or any third-party…
    kubik-rubik.de