Beiträge von Clemens-XS

    Von zwei Bekannten hörte ich, dass sie sich ihre Joomla-Installation durch das Update auf Version 4.1 zerschossen haben und neu beginnen mussten.


    Ich habe eine Installation vom 04.10.2021, die ich zunächst für beabsichtigte Entwicklungen nicht benutzt hatte, dann aber jetzt upgedatet habe auf 4.1.2


    Meine Frage: Ist diese Installation genügend zuverlässig und stabil, sodass ich darauf mit Entwicklungsarbeit beginnen kann oder sollte ich sicherheitshalber Joomla doch noch mal neu installieren?

    Vielen Dank, genau das wars! Ich musste ja wegen Webgo von Maria-DB auf MySQL wechseln und hatte die ganze Site mittels Akeeba in ein neues Verzeichnis geschoben und dabei eine neue MySQL-DB angelegt. Dann hatte ich zwar den Pfad für die https-URL neu gesetzt, aber den anderen für die www-URL vergessen.


    Weil es universeller verwendbar ist, habe ich deine Code-Empfehlung drin gelassen. Und jetzt funktioniert es prima.


    Allerdings sah ich jetzt auch, dass es im Webgo-Adminbereich die Möglichkeit gibt, per Checkbox die Umleitung auf die entsprechende https-Varainte zu aktivieren. Dennoch lasse ich lieber deinen Code in der htaccess.


    Herzlichen Dank für deinen Hinweis!

    Hab den Code von kitepascal eingefügt, sicherheitshalber nochmals mit RewriteEngine On. Leider immer noch das gleiche Ergebnis, eine 404.


    Hab auch die ganze htaccess noch mal kontrolliert, ob irgendwo ein Fehler steckt, der mit der nicht erfolgreichen Rewrite-Umleitung zusammen hängen könnte. Hab aber nix gefunden.


    Gibt es Einstellungen in Joomla, die hier meinen Absichten entgegen wirken können?


    Ergänzung:
    Auch der Code von CurlY BracketS bringt bei mir nicht das gewünschte Ergebnis. Im Gegenteil, dann bekomme ich einen "Umleitungsfehler" gemeldet.

    Mhhhh "Apache Configuration"??? – Ich glaube nicht, dass ich in meinem gemieteten Webspace an der Apache-Konfiguration etwas ändern kann.


    Und wenn doch, weiß ich leider nicht, wo das gehen könnte. Ich finde etliche Konfigurations-Dateien, kann aber wohl wegen fehlender Berechtigungen daran nix ändern.

    Advanced Apache Configuration - The paths.conf File | cPanel & WHM Documentation
    To improve future compatibility within the cPanel & WHM codebase, we eliminated the use of hardcoded paths to refer to Apache files and directories.
    docs.cpanel.net

    Gerade wurde ich durch einen Besucher meiner Website darauf aufmerksam gemacht, dass meine Site nicht über http://www.lebenslust-jetzt.de erreichbar ist. Der Browser wandelt von sich aus um in https://www.lebenslust-jetzt.de und dann kommt ein 404.

    Ich wünsche mir die Funktion, dass grundsätzlich alle Anfragen nach https://lebenslust-jetzt.de umgeleitet werden.


    Um genau dies zu verhindern, hatte ich gemäß dieser Quelle: https://htaccessbook.com/htaccess-redirect-https-www/ diesen Code in meiner htaccess eingefügt:

    Apache Configuration
    RewriteCond %{HTTPS} off [OR]
    RewriteCond %{HTTP_HOST} ^www\.lebenslust-jetzt\.de [NC]
    RewriteRule (.*) https://lebenslust-jetzt.de/$1 [L,R=301]

    Es ist sicher gestellt, dass das Modul Rewrite aktiv ist. Dennoch erhalte ich wie oben beschrieben, eine 404.


    Was mache ich falsch?

    Hi, endlich hab ich den Umzug abgeschlossen und habe eure Tipps gelesen. Vielen Dank dafür. Mit der Webgo-Anleitung kam ich nicht zurecht, da mir das Verständnis dafür fehlt.

    Nun habe ich die Site mittels Akeeba Backup / Kickstart in einem neuen Verzeichnis meines Webspace wieder hergestellt und zuvor die DB als MySQL angelegt und von Akeeba füllen lassen.


    Resultat:

    Das Backend ist einwandfrei erreichbar, Änderungen lassen sich speichern. Minimale Anpassungen waren noch in der configuration.php betr. TMP- und Log-Verzeichnispfaden vorzunehmen.

    Frontend:

    Katastrophe! – Fehlermeldung:

    3685 - Illegal argument to a regular expression.

    ...

    Illegal argument to a regular expression. (https://lebenslust-jetzt.de/)


    Unter der o.g. URL könnt Ihr das Ergebnis nachvollziehen. Leider habe ich keine Vorstellung bzw. keinen Ansatzpunkt, wie ich jetzt weiter bei der Fehlersuche vorgehen sollte. Es gibt zwei Plugins, die schon mal Schwierigkeiten bereitet hatten und die ich versuchsweise deaktiviert habe, leider ohne Erfolg. Es handelt sich um BruteForceStop und um den JCH-Optimizer.

    Die htaccess habe ich sorgfältig geprüft. Da dort keine Fehler z.B. betr. Pfade oder Redirects enthalten sind, scheidet die auch aus.


    Hab die Ursache gefunden: SEOGLOSSARY war der Übeltäter. Nach dessen Deaktivierung läuft die Site wieder! Ja, das Teil arbeitet mit RegularExpressions.


    Nun eine neue Schwierigkeit: Ich versuche, den Dump aus der MariaDB, den ich mit der Exportfunktion von PHP-MyAdmin gewonnen hatte, in die neu angelegte leere MySQL-DB zu importieren. Die zu importierende DB hat 25 MB Größe, ungezippt. Es dauerte ziemlich lange, dann kam die Meldung, dass die Laufzeit des Importscripts überschritten sei und ich die Datei einfach nochmals in die DB hochladen sollte, weil dann der Importvorgang dort fortgesetzt würde, wo er abbrach.

    Aber schon zu diesem Zeitpunkt gab es Fehlermeldungen, die ich im ersten Screenshot sicherte. Beim zweiten Anlauf wurde zwar der Import vollendet, aber mit Fehlermeldungen, deren Bedeutung und vor allem deren Fehlerbehebung für mich aktuell nicht möglich erscheint.


    Ich öffnete dann den Tab "Struktur" in PHP-MyAdmin und entdeckte erstaunliche Unterschiede in der Zeichencodierung, wie utf8_general_ci und utf8mb4_unicode_ci sowie als Typ des Datensatzes InnoDB und MyISAM. Vielleicht hängen die Fehler damit zusammen?


    Oder macht die MariaDB irgend etwas intern anders, als die MySQL, sodass eine Inkompatibilität entsteht?


    Anhängend die drei Screenshots. Vielleicht habt Ihr ja noch eine Idee, wie ich die Fehler beseitigen kann?

    Vielen Dank für eure schnellen und qualifizierten Antworten!

    Am 07.01.2022 informierte mich Webgo zum ersten Mal, dass "ab Februar 2022" MariaDBs abgeschaltet würden. Auf Nachfrage, warum, man dies machen wolle, wurde mir am 11.01.2022 geantwortet:

    Sowohl MariaDB als auch MySQL sind zwei wunderbare Datenbankverwaltungssysteme, es kommt hier auf den Use-Case an welches der beiden Systeme besser ist. MySQL ist grundsätzlich der Vorreiter, das heißt MySQL ist nach jedem Major Realease erst einmal eine lange Zeit performanter als MariaDB. Als wir die Entscheidung trafen uns ausschließlich auf MySQL zu fokussieren, war MariaDB in der Version 10.2/10.3 aktuell, welche zu dem Zeitpunkt mit MySQL in unserem Use-Case nicht mithalten konnte. Auf unsere Anfrage bei MariaDB ob sich dies wieder ändern würde, konnte man uns keine Antwort bzw Zusicherung tätigen, aus diesem Grund viel für uns die Entscheidung endgültig auf MySQL.Webgo meinte dann, dass man mit den Abschaltungen Ende Februar beginnen würde und gemäß meiner Anfrage meinen Server "zeitlich ganz nach hinten" setzen würde. Dabei wurde kein konkreter Termin genannt.


    Webgo hat einen extrem guten und schnell reagierenden Support. Dass man die Umstellung auf MySQL nicht als Service anbietet, zumal Webgo das Problem selbst geschaffen hat, finde ich allerdings fast schon frech.

    Die Erreichbarkeit meiner Sites liegt bei 99,8%, also nicht so toll (Websiteuptime.de). Die Ausfallzeiten können über den ganzen Tag verteilt auftreten und betragen meist zwischen 1 und 6 Minuten. In Preis-Leistungsverhältnis sehe ich Webgo als sehr günstig an.

    OK und jetzt mach ich die Änderungen der DBs.

    Mein Webhoster (WebGO) überraschte mich mit der Mitteilung, dass bis spätestens Ende Februar keine MariaDB mehr verfügbar sei und ich meine Websites auf MySQL umstellen solle.

    Seit Januar bis jetzt läuft aber mein Umzug auf vollen Touren incl. meiner Praxis und deren Neu-Einrichtung. Nachdem die Telekom es fertig brachte, nach 8 Wochen einen halbwegs funktionierenden DSL-Anschluss herzustellen, kann ich ans Werk gehen. Verdammt knapp mit der Zeit!


    Aber wie gehe ich nun am effizientesten vor? Als erstes habe ich natürlich nochmals nach dem aktuellen Joomla-Update auf 3.10.6 ein Akeeba Backup erstellt und herunter geladen. Die beiden aktuellen Websites sind allerdings längst in die Jahre gekommen und sie müssen dringen auch inhaltlich voll überarbeitet werden. Eine gute Gelegenheit, auf Joomla 4 umzusteigen also. Aber aufgrund von Zeitmangel erst in frühestens 3 Monaten machbar.


    Meine erste Idee: Ich erstelle einen Dump der MariaDB (Export aller Tabellen im sql-Format) und lösche dann die Maria-DB. Dann lege ich eine neue MySQL-DB mit dem gleichen DB-Passwort und DB-Namen an und importiere den Dump. Anschließend müsste eigentlich die alte Site dann wieder laufen. – Aber was, wenn nicht?


    Zweite Idee: Ich erstelle ein neues Joomla-Installationsverzeichnis auf meinem Webspace und lege eine neue MSQL-DB an mit dem gleichen Passwort (aber leider zwangsläufig mit einem anderen DB-Namen). Anschließend lasse ich Kickstart die Site wieder herstellen und editiere dann in der configuration.php den Datenbank-Namen. – Aber ob das geht? Oder überschreibt mir Akeeba dann die bisherige MariaDB?

    Zurzeit arbeite ich an einer neuen Website und deren Ladezeit-Optimierung. Auf gtmetrix und anderen Prüfseiten wird die neue Site sehr gut bewertet mit 98% Performance. Ca. 400ms braucht es, bis der Besucher die Site zu sehen bekommt.


    Lade ich die Site im Chromium-Browser, so lädt sie genau so schnell. Lade ich die Site aber im Firefox, so benötigt das erste Laden bis zu 8 Sekunden! Untragbar! Lade ich diese Seite aber erneut, so verkürzt sich die Ladezeit auf ähnliche oder unwesentlich größere Werte, wie beim Chromium-Browser.


    Die beschriebenen Verhältnisse habe ich auch bei unterschiedlichen Desktops und auf meinem Android-Smartphone. Und die Ladezeit beim Firefox ändert sich nicht, wenn ich alle meine Sicherheits-AddOns deaktiviere wie z.B. uBlock Origin, uBlockMatrix usw.


    Der Marktanteil mit Firefox-Benutzern ist natürlich so groß, dass ich diese Verhältnisse nicht hinnehmen will. Was kann ich zur Abhilfe tun?

    firstlady Mir ist schon klar, dass ich mit deiner Äußerung nicht gemeint war. Ich wollte aber im Sinne meines ersten Postings sozusagen eine Ergänzung schreiben, was ich bereits unternommen habe, um mit Matomo analysieren zu können, trotz SameOrigin oder Cross-Domain-Policy.


    Gibt es denn keine JoomlaExtension, die die Analyse innerhalb der Domain durchführt? Hab jeden falls bisher keine gefunden.

    Evtl. kann ich ja auch innerhalb von Joomla gesammelte Analysedaten woanders hin exportieren oder pollen.

    Wegen all diesem Unfug habe ich ja meine Websites alle cookiefrei gestaltet und ich erhebe keinerlei personenbezogene Daten im Sinne der DSGVO. – Und dennoch biete ich im Footer die Möglichkeit, auch die Erfassung nicht personenbezogener Daten zu deaktivieren. Die sind aber sowieso deaktiviert, wenn der Besucher im Browser "do not track" aktiviert hat (=Matomo-Funktion)


    Allerdings führt diese Benutzer-Privacy-Freundliche Einstellung eben dazu, dass die Analyse immer schlechter / weniger aussagekräftig wird. Darauf zielte meine Frage ab.


    CORS für die zu trackenden Sites sowie in der htaccess der Joomla-Sites ist Header set X-Permitted-Cross-Domain-Policies...... zu Matomo gesetzt sowie Header set Content-Security-Policy "default-src ..."

    Seit über 10 Jahren nutze ich auf meinen Joomla-Websites die Matomo Besucheranalyse und war damit bisher zufrieden. Nachdem dank der Corona-Zwangsmaßnahmen auch die Besucherzahl auf meinen Seiten rückläufig war, habe ich mal die Zahlen der zurück liegenden drei Jahre ausgewertet.


    Ich stellte fest, dass ein ständiger kontinuierlicher Rückgang der Besucherzahlen vorliegt, der in den zurückliegenden 1,5 Jahren besonders stark zugenommen hat. Dem gegenüber widersprechen aber die Server-Logs und die Joomla-eigenen Zähler.


    Ich führe diese Situation auf die zunehmende Verwendung von Blockern in den Browsern der User zurück, wie z.B. uBlockOrigin, uMatrix usw. – Besonders, wenn mein Matomo auf einer anderen Domain meines Webspace gehostet ist, wird eine Zählung durch die "SAmeOrigin-Policy" verhindert.

    Natürlich respektiere ich den damit verbundenen Wunsch meiner Besucher nach Schutz der Privatsphäre.


    Und so frage ich jetzt hier danach, wie ich die inzwischen zunehmend unbrauchbare Matomo-Analytic ersetzen kann durch eine in Joomla integrierte Analytic – auch wenn sie lediglich halbwegs zuverlässig nur wie ein Besucherzählerarbeiten würde. Mit "Besucherzähler" meine ich natürlich keinesfalls etwas, das im Frontend sichtbar wird, sondern eine Zählung, die nur über das Backend zugänglich ist. Im Idealfall hätte sie auch eine tabellarische und / oder graphische Auswertung.


    PS: Über die (Un-)zuverlässigkeit des Standard-Besucherzähler in Joomla hatte ich mich bereits hier https://forum.joomla.de/thread/4963-besucherz%C3%A4hler/ informiert.

    Ich hab's jetzt als Kompromiss so gelöst, dass ich die ID content und die ID aside mit 0.8em Abstand nach oben definiert habe:

    Code
    #content, #aside {
        margin-top: 0.8em;
    }

    Dadurch vergrößert sich zwar der Abstand zwischen dem gesamten Content und Breadcrumb. Aber es stört vom Design her nicht und macht von der Logik her sogar Sinn, weil der Content, dessen Beginn der Besucher ja als "Einsprung-Punkt" in die Seite sucht, so leichter auffindbar wird.

    Frage also geklärt / gelöst.


    Vielen Dank für die wertvollen Anregungen!

    Sorry, aber ich hatte mich doch gerade dazu entschieden, die Breadcrumbs über die Bootstrap-Klasse "hidden-phone" unsichtbar zu machen, wenn Smartphones genutzt werden.


    Die Versuche, rein auf das Pixelmaß screenwidth abzustellen, funktionieren nicht zuverlässig. Würden sie funktionieren, hätte ich im Querformat meiner Test-Website eine zweispaltige Darstellung in den entsprechend gestalteten Test-Beiträgen – wie beim Desktop oder beim Tablet. Statt dessen scheint auch hier das Bootstrap-Grid m it den 12 Spalten und dessen CSS-Definitionen wirksam zu sein, sodass in den Beiträgen nur dann zweispaltig angezeigt wird, wenn ein Desktop oder ein Tablet genutzt wird und nicht ein Smartphone, obwohl die screenwidth beim Smartphone höher sein kann, als beim Desktop.

    Genau deshalb hatte ich ja auch mit pixel-densitiy und den oben zu Beginn beschriebenen @media-Regeln arbeiten wollen. Aber "hidden-phone" ist demgegenüber ja viel einfacher und zuverlässiger!


    Wie kann ich denn den Abstand hinein bekommen, wenn doch das Nicht-Anzeigen der Breadcrumb nun per "hidden-phone" bewirkt wird?

    (Unter dem Signet einen Abstand per margin einfügen, stört massiv, wenn Breadcrumbs angezeigt werden soll.)