Beiträge von Re:Later

    Bei mir, bzw. Bootstrap 4, sieht das z.B. so aus:

    Heißt, die Überschriften werden responsiv anhand der Bildschirmbreite dynamisch kalkuliert.


    Pro-Tipp ;-) :

    In Bootstrap-4-SASS

    Code
    1. $enable-responsive-font-sizes: true;

    Für Selberbäcker: https://github.com/twbs/bootst…4.1/scss/vendor/_rfs.scss


    Oder für ganz harte Selberbäcker: https://github.com/twbs/rfs

    Jetzt mach ich noch eine Test-Installation auf dem "defekten" Account und probiere aus, ob reproduzierbar mit blankem Joomla.

    Ja, ist reproduzierbar. Joomla 3.9.15 auf Subdomain installiert. Nur Demodaten.


    Joomla-Aktualisierung:



    PHP auf 7.3.11: Update ohne Fehler möglich.


    Da ist also doch was "schräg" im Joomla. Und irgendwie Hoster- und Hoster-Paket-abhängig.

    Nachtrag:

    Ich wollte das nur (teils) bestätigen. Selbes Szenario bei Update 3.9.15 auf 3.9.16.


    Seite unter PHP7.4.2, die regelmäßig geupdatet wird. Und schon mehrfach unter PHP7.4 erfolgreich. Zuletzt PHP 7.4.1.


    Die Seite hat kaum was installiert, außer Akeeba, EJB, JCE. Vieles vom Core deaktiviert.


    Fehler:

    Zitat

    Ajax Error: service unavalaible.

    Nach Ausschluss aller mir bekannten, denkbaren Vielleicht-Ursachen:

    Keine Änderung.


    Auf PHP7.2 gesetzt und Update funktioniert. Bin auf Joomla 3.9.16.


    Danach wieder auf PHP7.4:

    Joomla-Aktualisierung > Live-Installation > "Neuinstallation der Joomla-Core-Dateien" gibt wieder den Ajax-Fehler aus.


    Aber, blöd das, eine andere Seite mit mindestens den selben Erweiterungen und Kram und PHP7.4.2 lief und läuft problemlos bei Updates. Zwar selber Provider, aber kleineres Paket, also nicht 100% vergleichbar, aber nahezu.


    Jetzt mach ich noch eine Test-Installation auf dem "defekten" Account und probiere aus, ob reproduzierbar mit blankem Joomla.

    Versuchs wie empfohlen mit dem Umleitungsplugin.

    Das kann nicht funktionieren, wenn der Server die 404 schmeißt und eigene Fahlerseite, bevor Joomla überhaupt in's Spiel kommt. Und das ist der Fall.

    Da "Rewrite" auch diverse Unterseiten matchen kann und deshalb mit Vorsicht zu genießen ist, tät ich das so machen:

    Code
    1. RewriteRule ^kassieren(\/|)$ https://haar-kommunal.net/index.php/service/kassieren$1 [R=301,NC,L]

    Das gehört dann natürlich in die .htaccess von haar-technik.de.


    EDIT: Aber scheinen eh beide Domains im selben Verzeichnis zu landen.

    Was mache ich falsch ?

    Schwer zu sagen, wenn wir nicht wissen, was du gemacht hast ;-)


    Eine einfache Variante ist, deine Versuche erst mal wieder zu löschen.

    Dann im Plugin "Umleitung" "URLs sammeln" eintragen.

    Die falsche Seite aufrufen.

    In die Komponente gehen. Die hat jetzt die falsche URL schon eingetragen. Draufklicken und neuen Link eintragen.


    AAAAAAAAAAAAAAABER ich sehe gerade, dass Ihr gar nicht die Joomla-Fehlerseite verwendet. Der Fehler kommt quasi gar nicht bei Joomla an.


    Also bleibt nur noch die .htaccess-Datei.

    Ich schrei jetzt mal, weil von dir nie nötige Links oder Infos kommen:


    Wenn du einen Link zur betroffenen Seite, die du getestet hast, postest, kann man das vermutlich mit 1, 2 Overrides lösen

    Wer der Publisher ist, ist von Fall zu Fall verschieden. Per Seite eine individuelle Entscheidung. Die seitenbetreibende GmbH, ein Verlag, was-weiß-ich.. Woher soll Joomla diese Infos korrekt ziehen?

    Wenn man sich für einen Publisher vom Typ "Organization" entscheidet, will G auch das zugehörige Logo im selben Auszeichnungsblock.


    Und wieder Normallautstärke: Was soll man dir jetzt wie erklären? Im Netz findet man genügend HTML-Beispiele und christine2 , hat dir sogar ein Beispiel verlinkt. Und das ist nebenbei ein offenes Joomla-Issue.


    Und: Um das im Joomla-Core zu haben, benötigt man irgendwo die Möglichkeit diese von WebSite zu WebSite abweichenden Daten individuell zu hinterlegen. Dafür verwende ich z.B. ein eigenes Plugin und niemals nicht diese antiquierten Joomla-Auszeichnungen, die Google noch nicht mal mehr auf seinen SD-"Manuals"-Seiten beschreibt. Heute macht man das mit ld+json-Auszeichnungen. Und soweit ich mich erinnere, gibt es da irgendwo Plugins auf dem Markt.


    EDIT:

    Beispielsweise (ich kenne es nicht!! Sieht aber nicht falsch aus): https://www.tassos.gr/joomla-e…red-data-markup/freevspro

    wobei ich dir final dringend die Pro-Version empfehlen würde, wenn das deinen Ansprüchen genügt, was das Plugin generell macht, weil nur die Pro-Version die Option hat "Remove Faulty Structured Data". Oben beschriebene, veraltete Joomla-Tags kollidieren nämlich mit der empfohlenen ld+json

    PS: Ich hoffe mal diese ganzen URL und Routing Geschichten werden in der V4 besser.

    Teste halt Joomla 4, dann kannst rechtzeitig meckern gehen. Downloads des täglichen Standes:

    https://developer.joomla.org/nightly-builds.html


    Mit dem "custom update server"-Url, den man unter Joomla-Update > Optionen einträgt, kann man dann via Joomla-Update > Check for Updates-Klick > Tabulator "Live Update" täglich das neue Nightly nachziehen. Ohne Gewähr allerdings.


    Gemecker über das unhandliche und teils schon ewig verbuggte Backend-Template kann man sich aber mehr oder weniger sparen.

    Leider liefert mir Joomla mit und ohne Slash zwei verschiedene Base Pfade

    Deswegen mein Hinweis auf JUri.

    Nicht groß getestet und exakt so abgeschrieben nur für die Template-index.php, wenn man die ODER-Variante verwendet:

    Und, wenn du auch die Startseite haben willst (eigentlich nicht nötig, laut Google), lässt halt

    Code
    1. $juri->getPath() !== '/' &&

    weg.


    Das ODER-Ergebnis:


    Da musst du den Hackwar bezirzen ;-)


    Zusätzlich ist ja anscheinend auch noch eine Anfrage ans Sicherheits-Team unbeantwortet. Versteh aber nicht, worum es da genau geht.


    Workaround:

    In solchen Spezial-Fällen installiere ich mir den Joomla-Patchtester, ziehe darin vor jedem Joomla-Update den Patch zurück, mache das Joomla-Update, hole mir die aktuellen Patchdaten per Klick auf "Zurücksetzen", dann "Daten abrufen" neu ab und installiere den Patch wieder.


    Unter'm Strich bequemer, als Verzeichnisse kopieren.

    Kennt jemand das Problem und hat es schon lösen können?

    Es ist ja auch wichtig in welchem Zusammenhang das bemängelt wird. SD sind mal so oder mal so, je nach Kontext (Artikel, Kontaktseite, Startseite etc. pp. zu setzen). Wo und wie sind die andern Daten, wie Author und was weiß ich auf der Seite korrekt ausgezeichnet.


    Macht es bei der betr. Seite überhaupt Sinn sie auzuzeichnen, also lang nach Lösungen zu suchen? Google stellt(e) klar, dass es G zwar nicht stört, wenn unnötige Seiten ausgezeichnet werden, aber pupst dann drauf. Das Validierungstool validiert halt, aber es validiert auch Zeugs, was G komplett wurst ist.


    Weiters hat sich in den letzten 1,5 Jahren klarer herausgestellt, dass SD für viele Seiten nahe reiner Beschäftigungstherapie war. G stellte u.a. klar, dass SD seitens G keinen unmittelbaren Einfluss auf das Ranking hat. Während SEO-""Spezialisten"" weiters behaupten "toootaaaal wichtig".


    In Joomla-Core irgendwas für die AUTOMATISCHE Publisherauszeichnung einzusetzen, nur um den G-VALIDATOR zufriedenzustellen, scheint mir ziemlicher Nonsens. Wer der Publisher ist, ist von Fall zu Fall verschieden. Per Seite eine individuelle Entscheidung. Die seitenbetreibende GmbH, ein Verlag, was-weiß-ich.. Woher soll Joomla diese Infos korrekt ziehen?


    Wenn man sich für einen Publisher vom Typ "Organization" entscheidet, will G auch das zugehörige Logo im selben Auszeichnungsblock. Eine "Person" als Publisher, die nur einen Namen braucht, ist bei G ENTGEGEN JEDER SPEZIFIKATION durch schema.org verboten.


    Wenn es morgen nicht schon wieder alles anders ist. Was immer und immer wieder der Fall ist. Ich habe z.B. auf meiner Seite eine vollkommene Überauszeichnung, weil die auf der ersten SD-Spezifikation von Depperl-Google beruht.


    KURZ:

    und hat es schon lösen können?

    Wenn du einen Link zur betroffenen Seite, die du getestet hast, postest, kann man das vermutlich mit 1, 2 Overrides lösen, wenn es sich überhaupt lohnt es zu lösen.

    Google empfiehlt u.a., neben "lass es wie es ist, ist kein großes Drama", ein Canonical zu verwenden.


    Wenn sonst nichts im Joomla Canonicals schreibt (= wäre konfliktträchtig) vielleicht in der "echten" Template-Datei entsprechender Code, aber nicht in der error.php.


    Oder System-Plugin, dass dann ähnlich dem Rewrite-Plugin ermittelt, ob der Header eine 404 ist (= nix tun).


    Pure Theorie.


    Generell ungut, egal, wo in Joomla, jede URL muss geprüft werden, bspw. mit JUri.

    Ich habe mich jetzt noch etwas schlauer gemacht.


    Wenn ein Benutzername länger als 150 Zeichen ist, was (auch) z.B. Spammer gerne mal ausprobieren, um Links und Kram in den Benutzernamen einzusetzen, dann wird der Benutzername von Joomla auf 150 Zeichen gekürzt. Genauer: Die Datenbank kürzte ihn bisher "unbeobachtet".


    Auch dadurch kann es zu doppelten Benutzernamen kommen, die widerum ein Sicherheitsrisiko darstellen können, noch mehr, wenn dann auch noch das Kennwort doppelt ist, was ja generell erlaubt ist.


    Deshalb jetzt also dieser kleine, aber richtige Stolperstein beim letzten Update. Und Joomla selbst kümmert sich zuvor darum, dass der Benutzername nicht zu lang ist.


    Die Nutzertabelle hat einen neuen Index bekommen, der festlegt, dass username UNIQUE (eindeutig/einzigartig) ist.


    Damit sollten auch plumpe Importe via Datenbank nicht mehr möglich sein.

    Ich frage mich aber aus welchem Grund man selber in der Datenbank Doppelte Usernamen anlegen sollte, was steck dahinter ?

    Wenn man sie unachtsam z.B. aus einem anderen CMS oder Listen oder ... mit eigenen Skripten einspielt/importiert und solche Sachen. Oder irgendwelche "schlechten" Registrierungs-Erweiterungen. So Kram...

    Zum Debuggen kannst das

    Code
    1. type="hidden"

    in

    Code
    1. type="text"

    ändern. Dann siehst, was im Feld passiert, wenn du das number-Feld änderst.


    Du musst natürlich aufpassen, dass die ids "start" und "startinput" auf der Seite sonst nirgends vorkommen.

    Ich denke nicht, dass die Hauptfehlermeldung an dem liegt, was in der Log steht. Letztere sagt ja nur, dass auf deiner Fehlerseite, die ja angezeigt wird, eine CSS-Datei nicht gefunden wurde und zwar eine, die norm. immer in Joomla vorhanden ist.


    Aaaaber, beides zusammen lässt mutmaßen:


    Ich geh mal davon aus, dass die

    Code
    1. .htaccess

    deines Joomlas nicht stimmt oder gar nicht "scharf geschaltet" wurde.


    Wenn sie existiert, könnte viell. helfen (ohne Gatterzeichen vor der Zeile)

    Code
    1. RewriteBase /dionysiusneu/

    damit die Pfade korrekt ermittelt werden.