Beiträge von Re:Later

    Das würde ich so aber nicht sagen, weil es eine stärkere Komprimierung aufweist als komprimiertes jpeg oder png. Dies kann man sehr gut an online Konvertern überprüfen.

    Reale, ausgiebigere Tests zeigen, dass das längst nicht immer der Fall ist.


    Je nach Bildgröße (sowohl Speichergröße als auch Pixelgröße des Originals) sowie Original-Bildformat und Komprimierungsrate kannst du diesbzgl. keine verlässlich konsistenten Ergebnisse erwarten ("so wie du schreibst").

    Es kommen z.B. auch immer mal wieder verpixeltere Bilder raus als ein JPG-Pendant, das selbe Lade-Größe hat.


    Kurz:

    Wenn du jedes Bild händisch machst, hast du wenigstens Kontrolle darüber, ob es Sinn macht. Wenn du das Joomla-Erweiterungen überlässt, hast du 0 Gewähr, ob es Sinn macht.


    Desweiteren ist der Safari-Support nach wie vor ein Lotteriespiel. "Ja, aber nur, wenn..."

    Nur nebenbei: Weil ich Cookies abgelehnt habe, wird mir der Zugriff auf die Seite verwehrt. Das ist ebenso nicht zulässig, wie nicht-willige Besucher nicht vor Tracking-Cookies u.ä. zu schützen.


    Wenn du davon eh keine hast, kannst dir den Cookiewarner auch gleich sparen. So ist das jedenfalls No-Go.

    Kann damit jemand was anfangen?

    Das ist eine Tabelle, die 1 einzelnen Info-Wert enthält. Diese braucht keine ID-Spalte und damit auch keinen UNIQUE-Wert. Ist also nur eine Info von PHPmysql in diesem einzelnen Fall.


    Du solltest bei der Suche in den Reiter "Struktur" der Tabellen schauen. Im Normalfall (aber nicht immer verpflichtend) hat die Spalte "id" einen Wert "AUTO_INCREMENT" in der Spalte "Extra". Das ist dann gleichbedeutend mit "unique" (doppelte Werte/IDs verboten).


    Oder, wenn man den Bearbeitungsstift der Spalte klickt, ein Häkchen unter "A_I".


    Damit erübrigt sich dann auch der Standard-Wert (Default), der dann norm. auf "Keine" steht.


    Dafür kann man aber auch die SQL-Installationsskripte von der Erweiterung sichten, wo ein AUTO_INCREMENT eingetragen ist und, wo es in der DB fehlt.


    Ob's zum Ziel führt? Keine Ahnung.

    Gleichzeitig erscheint auch die Fehlermeldung "Kategorie nicht gefunden" mit einem Einbahn-Verkehrszeichen.

    Dafür müsstest du uns einen Link zur betr. Seite geben, da man sehen muss, wo die Meldung erscheint. Es gibt mehrere Varianten in Joomla und ein Einbahn-Zeichen zeigt ein blankes Joomla 3 meines Erachtens nirgends an. Kann mich natürlich täuschen...

    Welches Layout hast du im Modul eingestellt?


    Damit man nicht intuitiv sieht, wie die Dateien der in Frage kommenden Layouts heißen, hat man die ja nichtssagend und verwechselbar benannt und übersetzt.


    In Frage kommende Layouts mit "navbar-expand-md".


    Habe gerade nur Englisch in Betrieb:


    Modul mod_menu:

    "Collapsible Default Menu": Dateiname "collapse-default.php".


    Vom Cassiopaia selbst:

    "Collapsible Dropdown": "collapse-metismenu.php"

    Leider sind bei mir Umlaute Umlaute in Joomla 4.1.3. Ich habe gestern aus Interesse auch mal die Joomla-Dateien in 3 und 4 für Feeds durchforstet und nichts gefunden, was ins Auge sticht.


    Verwendet die fehlerhafte Anzeige vielleicht einen WebFont, der das Problem verursachen könnte? Bspw. Chrome auf MacOS hatte da immer mal wieder gröbere Probleme. Aber generell kann es auch nur der WebFont sein.

    Joomla-Update stellt ein "mögliches Problem" bei diesem Plugin fest.

    Keine Antwort auf deine eigentliche Frage, aber das Plugin (Version 3.2.11) wird mit Sicherheit erhebliche Probleme unter Joomla 4 machen. Spätestens, wenn du einen Beitrag speicherst. Es ist codeseitig auf Stand Joomla 2.5. Du solltest es also mindestens deaktivieren vor Migration.

    Warum verwendest dann nicht das Core-Template Cassiopeia?


    Das ist ja weniger das Template als Inhalte die ausgelesen werden müssen und ggf. irgendwelche Frameworks, Plugins und sonstiger zuinstallierter Kram, die im Hintergrund fuhrwerken, wenn das memory_limit ins Spiel kommt.


    Aber stimmt schon, dass mindestens 128MB mit Joomla 4 eingestellt sein sollten; für sorgloses "Spielen". Außer, man deaktiviert zahlreiche Erweiterungen wie Plugins.


    Ich weiß nur, dass diese hier sehr nahe an Joomla programmiert sind, also wenigstens nicht mit zu viel "Zusatzgewicht" daher kommen. Allerdings nicht kostenlos: https://www.joomla51.com/joomla-templates

    Die Kombination sollte aber auch nicht funktionieren. Denn wenn nonces aktiviert sind wird unsafe-inline ignoriert und greift dann nur bei Browsern welche keine nonces unterstützen?

    Hast du falsch gelesen. Ich schrieb

    Zitat

    Die ... Lösung ... ist Nonces auszuschalten und natürlich 'strict-dynamic'

    Also beide auszuschalten.


    Ich denke es geht hier um das Backend?

    zero24

    Ich nutze das Plugin natürlich nur im Frontend.


    Im Frontend Joomla 4 gibt es das core-seitige Inline-onclick-Javascript für das Sortieren von Tabellenspalten in Beitrags-Kategorielisten. Wie im ersten Post zu sehen. Das wurde wohl vergessen umzubauen(?)


    Das verhindert das Nutzen von Nonces.


    Ich habe das eingereicht, weil ich mir zwischenzeitlich fast sicher bin, dass das ein """Bugilein""" ist:

    [4] Http Headers plugin. Nonces on Category List · Issue #37799 · joomla/joomla-cms
    Steps to reproduce the issue Configure plugin "Http Headers" > "Content-Security-Policy (CSP)" Nonce: Yes Add a "Policy…
    github.com

    Da bin ich als Depp schon Stunden im Kreis gelaufen. Die einzige Lösung, die ich bisher gefunden habe, ist Nonces auszuschalten und natürlich 'strict-dynamic', und eine Regel


    script-src: 'unsafe-inline' etc.


    hinzuzufügen.


    Oder die onclick-Codes eben nicht an dieser Stelle inline zu verwenden, was aber Joomla so in Kategorielisten einsetzt und ich eigentlich als einen """Joomla-Bug""" ansehe, wenn man dann andere Sicherheits-Einstellungen nicht verwenden kann.


    Varainten wären, das in eine Javascript-Datei auszulagern, die dann unter Kategorie 'self' fällt; oder eben in HEAD mit einer joomla-konformen Methode, die dazu die Nonces einsetzt bzw. vom Plugin eingesetzt bekommt.


    Aber, da ich wie gesagt, eher ein Depp bin, traue ich mich noch mal zero24 anzupingen, wie er das sieht. Falls er Zeit und Lust hat. Ob da vielleicht Joomla ein grundlegendes Manko hat.

    ich habe schon wieder

    Und wie bist du letztes mal vorgegangen, um sicher zu gehen? RE: Virenmeldung auf dem Server


    Ich meine das so: Wenn du Meldungen bekommst und nicht näher prüfst, was in deiner Seite ggf. los ist, welchen Sinn macht es dann, wenn du es uns jedesmal hier im Forum erneut meldest?


    Virenscanner entdecken nicht alles oder auch wechselweise oder auch nur False-Positives, aber, wenn sie was entdecken, sollte man halt auf der Seite mühsam prüfen (z.B. durch Dateiabgleiche), ob was da ist, und, wenn verlässlich nicht, den Virenscanner vielleicht mal umkonfigurieren. Die Meldung besagt ja, dass es deine Seite ist, die angeblich was ausliefert...

    1) Prüfe, ob in den hochgeladenen Dateien der Ordner media/vendor vorhanden ist.

    2) ... die Datei libraries/vendor/autoload.php


    Wenn nein, prüfe, ob dein FTP-Client, z.B. FileZilla, Übertragungsfehler gesammelt hat. Normalerweise am unteren Rand ein Tabulator. Das kann bei zu vielen gleichzeitigen Übertragungen passieren (konfigurierbar im Client).


    Ich bin nicht ganz sicher, ob in diesem Fall auch Schreib-Lese-Rechte eine Rolle spielen ("www-run"-Problem). Bist denn bei einem "brauchbaren" Hoster/Provider?


    EDIT: Die 3 in Frage kommenden ZIP-Pakete "Joomla_4.1.3-Stable-Full_Package" (Github, joomla.de, jgerman.de) habe ich geprüft (Inhalt abgeglichen). Da sind Ordner und Datei vorhanden.