Beiträge von Clemens-XS

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?

Tja, dann werde ich wohl mit Matomo weiter machen. Hilft ja nix.

Schade!

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:

#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!

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

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.)

Herzlichen Dank für deine schnelle Antwort. Meine realtiv aufwendige @media-Kondition hatte ich irgendwo im Web in einem Scriptforum gefunden.

Die Bootstrap Klasse hidden-phone kannte ich noch gar nicht. Tja hab's gerade probiert und es funzt auf Anhieb und erspart wieder paar Zeilen zusätzliche CSS.

Allerdings hab ich an ein sich daraus neu ergebendes Problemchen nicht gedacht:

Zu oberst steht mein Signet, in ca. 10px Abstand darunter die Breadcrumbs und in ca. 10px weiterem Abstand darunter beginnt der erste Inhalt / Beitrag usw.

Sobald Breadcrumbs weg fällt, fallen auch die Abstände weg, sodass der Inhalt direkt unter dem Signet beginnt.

Wie bekomme ich den Abstand eingefügt, wenn Breadcrumbs mittels "hidden-phone" nicht angezeigt wird?

In Benutzung ist das Standard-Protostar-Template. Ich glaube nicht, dass meine @media-Regel falsch oder unwirksam ist. Aber vielleicht ist ist die Art und Weise, wie ich diese Regel zur Anwendung bringen möchte falsch?

Hier mein CSS:

/* Breadcrumbs platzsparend auf Mobil (= hohe dpi-Werte) ausblenden */
 @media only screen and (-webkit-min-device-pixel-ratio: 1.3),
    only screen and (-o-min-device-pixel-ratio: 13/10),
    only screen and (min-resolution: 120dpi){
    .breadcrumb-cl {
            display: none !important!;
    }
}

Die Klasse "breadcrumb-cl" habe ich (mit Leerzeichen davor) im Modul für die Breadcrumbs unter "erweitert" eingetragen. Dennoch wird breadcrumbs immer noch angezeigt, egal auf welchem Gerät – und auch wenn ich experimentell die "min-resolution" auf absurde Werte setze, um überhaupt eine Wirkung feststellen zu können. In der Firefox-Konsole im HTML-Quelltext ist die Klasse korrekt angezeigt aber nicht unter "Stile".

Wie muss ich es anstellen, damit die @media-Regel für das Modul breadcrumb wirksam wird?

Ich danke dir herzlich für deine Meinung. Für das Mitscrollen lassen der Seitenspalte spricht auch, dass es ein evtl. ungewohnter und irritierender Anblick ist, dass zunächst der gesamte Content beim Scroillen nach oben geht und abrupt und ohne dass für den normalen Besucher eine Ursache erkennbar ist, der Spaltencontent wieder stoppt und sich nur der MainContent weiter bewegt.

Eine ähnliche Schwierigkeit habe ich auch bei dem Button "zurück zur Übersicht" beobachten können, den ich zunächst ebenfalls als "sticky" so positioniert haben wollte, dass er immer im unteren Bereich des gerade in vollem Umfang angezeigten Beitrag zu sehen ist und per z-index über dem Text liegt.

Auch hier geht die Überlegung nicht auf, weil bei sehr schmalen Screens der Footer so viel Höhe einnimmt, dass der Button über dem Footer liegen wird. Der aber muss sichtbar bleiben, da er ja den gesetzlichen Hinweis auf Cookies usw. enthält. Wenn die Position von "sticky" sich auf den Container von Main-Content beziehen könnte, wäre es ja gut, aber das lässt die CSS-Definition von sticky nicht zu. Das bezieht sich immer auf den Screen.

Aktuell hab ich es mit "fixed" definiert, zumal aus unbekanntem Grund an dieser Stelle "sticky" einfach nicht funktionieren will. Der Button ist am Ende des Beitrags definiert. Gut zu sehen hier: https://idcreativ.de/einblicke…ratung-und-psychotherapie

Aber vielleicht mach ich dafür besser einen neuen Thread auf?

Ja genau, so wie du es beschreibst, habe ich es auch beabsichtigt. Wenn jemand einen Bildschirm mit geringerer Höhe hat, kommt der von dir beschriebene Effekt zustande. Ich gehe aber davon aus, dass jemand, der den Inhalt des zweiten Moduls in der rechten Spalte zu Ende lesen will, ganz intuitiv versucht, weiter zu scrollen und hat dann auch endlich Erfolg damit.

Schwierig würde es, wenn auf der Webseite im BlogLayout z.B. 20 Beiträge stehen und dann der Scroll wirklich unzumutbar lang würde.

Ich bin halt dabei, viel auszuprobieren und an manche Folgen – wie z.B. diese hier – hatte ich nicht gedacht. Die Aufforderung, "Termin vereinbaren?" ist ja das PayOff und sollte möglichst immer präsent sein, solange der Besucher sich noch nicht dazu entschieden hat, einen der Beiträge auszuwählen und zu lesen. Hat er aber diese Entscheidung getroffen, schwuppst der Beitrag auf 100% Breite, weil ich die Entscheidung des Besuchers unterstütze, ungestört und ohne Ablenkung den Beitrag lesen zu können.

Vielleicht sollte ich mich darauf beschränken, nur ein Modul in die rechte Spalte zu packen und dieses darf dann mit "sticky" positioniert sein? Oder gibt es noch eine andere Lösung?

Wow! Das mit dem falschen Ausrufungszeichen ist schon ein Klopper. Da wär ich so nicht drauf gekommen. Herzlichen Dank dir! Hab's heute Mittag korrigiert und jetzt wird Breadcrumbs zuverlässig unterhalb ca. 760px ausgeblendet.

Ziel meiner ganzen Aktionen mit sticky oder fixed usw. ist, die Aufmerksamkeit des Besuchers zu fokussieren. Deshalb fliegt ja auch bei Anzeige eines vollständigen Beitrags die rechte Spalte raus, sofern sie zuvor angezeigt wurde. Der Beitrag hat damit immer 100% Breite. Und je kleiner die Screenabmessungen sind, desto kostbarer wird der Platz, sodass ich deshalb die Breadcrumbs verschwinden lasse.

Der MobileMenü-Button bleibt immer sichtbar und ist die einzige Navigation auf der Site.

LukasHH Danke dir für deinen Hinweis. Ich habe hier nur Testmöglichkeit auf Desktop mit Firefox + Chrome sowie Galaxy-S5 mit Android 7 und ab und zu hab ich Zugriff auf ein Samsung 10"-Tablet, auf iPhone kann ich gar nicht testen. Wenn ich dich recht verstehe, so siehst du Darstellungsfehler der rechten Spalte. Diese Spalte wird im CSS durch die Klasse "aside" definiert und beide Module in der rechten Spalte liegen in dem Container "aside". Folglich müsste sich ein Darstellungsfehler immer auf beide Module zugleich auswirken.

"Aside" habe ich auf sticky positioniert, sodass die beiden Module bei längerem Scrollen nicht nach oben aus dem Blickfeld verschwinden, sondern nach anfänglichem Scrollen in ca. 10px Abstand vor dem oberen Displayrand stehen bleiben, während sich der Main-Content weiter scrollen lässt.

Was konkret wird denn da nur zu 50% dargestellt?

Ach ja, die 60px hatte ich lediglich zum Ausprobieren eingesetzt. Manchmal setze ich drastische Werte ein, um eine Wirkung zu provozieren.

Habe gerade auf 600px geändert und... es tut sich nichts! Unterhalb von 600px müsste ja jetzt eigentlich Breadcrumb verschwinden. Tut's aber nicht.

Übrigens habe ich die Klasse .breadcrumb-cl im Modul Breadcrumbs unter "erweitert" eingetragen, ja und mit Leerzeichen davor und ohne Punkt. Firefox bestätigt ja auch bei "Element untersuchen", dass diese Klasse korrekt eingebunden ist. Aber sie ist halt nicht wirksam.

Hast du ne Idee, warum?

Nee ich geb's auf... falls nicht hier noch eine Lösung kommt.

Hab gerade bemerkt, dass der Abstand der Breadcrumbs vom oberen Rand ständig variiert und nicht stabil zu bekommen ist.

Wer also jetzt noch auf die Muster-Site geht, wird meine Versuche nicht im CSS oder in den gewünschten Funktionen finden können.

Aber jetzt möchte ich die Breadcrumbs bei schmalen Bildschirmen ausblenden, da sie dort zu viel Platz wegnehmen. Auch dies gelingt mir bisher nicht, weder durch eine CSS-Klasse, die ich im Breadcrumb-Modul unter "Erweitert" einfüge, noch durch direkten Eingriff in die template.css des Protostar-Templates.

Wie kann ich das hinbekommen?

Ich ändere mal meine Frage hier, denn ich habe inzwischen bei Screenwidth über 756px die von mir gewünschte "position: sticky" eingebaut.

Das Signet hat 5px Abstand vom oberen Rand und Breadcrumbs 12%. Beide Module sind mit sticky positioniert.

Die Schwierigkeit jetzt liegt darin, dass beim Scrollen sich der Main-Content und auch die rechte Spalte unter das Signet und unter die Breadcrumbs schieben.

Ich benötige also eine CSS-Definition, die den div-Containern "main-content" und "well" die obere Positionierungsgrenze zeigen. Diese Grenze ist die Unterkante des Moduls Breadcrumbs.

Diese Grenze kann nicht durch einen festen oder prozentualen Pixelwert angegeben werden, da sich die Höhe des Signets teils proportional, teils linear ändert.

Bin gespannt, ob es noch eine Lösung gibt!

Auf meiner Website nutze ich das Protostar-Template und habe zu oberst auf der Seite an der Position "banner" mein Signet platziert. Ebenfalls auf "banner" und unterhalb des Signet habe ich "Breadcrumb" positioniert, was ja ebenfalls ein Modul ist.

Wird die Seite gescrollt, bleibt eine evtl. sichtbare rechte Spalte mittels position = sticky immer im Blick, weil sie mit ca. 10px Abstand am oberen Rand der Site stehen bleibt. Wenn nun aber im BlogLayout nicht nur die Beiträge, sondern auch das Signet und Breadcrumb nach oben verschwinden, wirkt dies meiner Ansicht nach irritierend. Test-Website ist hier.

Ziel ist also: Das Signet, Breadcrumb und eine evtl. vorhandene Seitenspalte sollten mit "sticky" positioniert sein, während nur main-content scrollen darf.

Da sich die Höhe des Signet mit der Seitenbreite ändert, muss sich die Position von Breadcrumbs und der Seitenspalte auf die Unterkante des Signet beziehen.

Wie kann ich das am einfachsten verwirklichen?

Tja, das mache ich auch so. Ich hab aber schon gehört, dass es je nach Browser und Smartphone die "zurück"-Taste nicht mehr gibt. Ich besitze nur ein altes Galaxy S5. Und was auf dem iPhone dargestellt wird, weiß ich eh nicht.

Da ich noch experimentiere mit der UX, kann es auch sein, dass ich den dritten Button nicht verwirkliche. Ich sehe ja gerade, wie das aktuell bereits Erreichte wirkt:

Da ich die rechte Spalte, die nur im BlogLayout sichtbar ist, auf "sticky" positioniert habe, kann die scheinbare Bewegung der vielen Beiträge beim Scrollen plus der Bewegung der rechten Spalte irritierend wirken.

Zudem überlege ich gerade, ob es sinnvoll ist, auch das Signet und die Breadcrumbs gemeinsam ebenfalls mit "sticky" zu positionieren, obwohl das dann wieder viel Platz wegnimmt. Es gibt aber optisch einen Halt und festen Punkt gegenüber allem, was sich da bewegt beim Scrollen.

Signet und Breadcrumb sind aber als Module platziert und das Signet variiert in der Höhe, abhängig von Screenwidth. Wie ich dann beides "sticky" bekomme, weiß ich nicht, wäre aber auch evtl. in einem extra Thread besser aufgehoben.

Mir geht es zurzeit um optimale Usability. Da hatte ich schon einen (zu langen) Post abgelassen, auf den niemand geantwortet hatte. War wohl zu abschreckend.

Die von dir empfohlenen Änderungen habe ich gerade eingefügt und auch IcoMoon wieder aktiviert. Das hatte wohl ein Programmierer so auskommentiert, der mir das Modal-Gewraffel programmiert hat, sodass endlich Video und Audio und Text auf allen Geräten zuverlässig und in weitgehend gleicher Form dargestellt werden.

Herzlichen Dank für deine wertvollen Tipps! Das hat ja auf Anhieb funktioniert und hat mir viel Zeit gespart!

Die Modifikation zum dritten Button muss ich wohl in Ruhe ausprobieren.

Gerade im Hochformat auf dem Smartphone scrollt der Besucher einen Beitrag lange nach unten. Will er das Lesen vorher abbrechen, wie kann er dann definieren, wohin er als nächstes will? Für den Breadcrumb müsste er erst wieder ganz an den Anfang des Beitrags scrollen damit Breadcrumbs sichtbar werden.

Würde ich Breadcrumbs auf Sticky positionieren, bekomme ich Probleme mit der Positionierung des Signets, das in einem Modul liegt und dort platziert wurde. Zudem verdirbt Breadcrumbs auf "sticky" die optische Gesamtwirkung.

Es blieb dem Betrachter natürlich noch die Option, über das MobileMenü zur Kategorie zurück zu springen. Aber da beginnen dann persönliche Vorlieben der Besucher.

Wenn er denn mitten im Beitrag ist und sieht weiter unten die von mir hier im Thread gewünschten drei Möglichkeiten "voriger beitrag - zurück - nächster Beitrag", wird er das vermutlich intuitiver und bequemer in der Bedienung finden, als die vorgenannten Möglichkeiten.

Es gibt bei dieser Website übrigens nur das MobileMenü und kein übliches mehr. Zudem lege ich Wert auf Aufmerksamkeitsfokussierung: Wenn der Besucher schon einen Beitrag ausgewählt / geöffnet hat zum Lesen, dann respektiere ich dessen Entscheidung, indem ich ihm nicht weitere optische Elemente zur Ablenkung anbiete. So wird z.B. eine evtl. vorhandene rechte Spalte (ab einer Screenwidth von ca. 760px) nach Öffnen des Beitrags voll ausgeblendet sodass der Beitrag die gesamte Fläche einnimmt.