JoomlaWunder CookieAutodelete löscht erst dann Cookies der gerade besuchten Website, wenn der Browsertab geschlossen wird, vorher macht das AddOn nix, kann also keinen bösen Einfluss haben.
Selbst wenn ich mich im BE ausloggen würde und später wieder hinein, ohne den Browser-Tab zu schließen, bleibt ein eventuelles Cookie erhalten.
https://lebenslust-jetzt.de/heisse-themen/
und dann unter Corona schauen 
j!-n OK, ich nutze dann wieder htaccess Variante 2.
Dies dürfte aber kein Problem für das Ausloggen darstellen.
Paranoia? Die Sache mit der index.php stellt keine Sicherheitsmaßnahme dar, sondern verhindert, dass die unter Entwicklung befindliche Site öffentlich wahrgenommen wird. Die htaccess im Backend sorgt für die nötige Sicherheit beim Backend und vorne natürlich die übliche htaccess.
Meine AddOns im Firefox waren nioch nie ein Problem in Verbindung mit Joomla oder Joomla-Backend. Konkret habe ich im Einsatz:
uBlock-Origin, uMatrix, Smart Referer, Cookie Autodelete, https everywhere, Decentral Eyes, User Agent SAwitcher, Measure-it, KeepassXC-Browser
In meinem Joomla ist kein Schlangenöl verbaut, sondern lediglich BruteForceStop und die Absicherung des Backend durch die htaccess (wie erwähnt).
Betreffend Ausloggen bin ich bereits eins weiter gekommen:
Harmageddon Bin deiner Anregung gefolgt und hab alles deaktiviert, was geht. Resultat: Kein Ausloggen mehr! Auch nicht über mehrere Stunden hinweg und bei viel Herumklicken.
Danach habe ich nach und nach die Extensions wieder aktiviert und zwei überflüssige, die auch vor dem Test nicht aktiviert waren, deinstalliert.
Resultat: Nichts loggt mehr aus. Alles stabil.
Aaaber:
Nach dem sicherheitshalber neu installierten JCE Editor mitsamt JCE-Mediabox zeigt die Modalbox, in der ein Beitrag gezeigt werden soll, zusätzlich links oben einen iFrame, der natürlich unerwünscht ist. Erst jetzt stelle ich fest, dass der gleiche Darstellungsfehler auch auf meiner derzeitigen Produktivseite auftritt.
Ursache unbekannt.
Und die von mir gewünschte Extension SEO-Glossary lässt sich zwar installieren und einrichten, funktioniert aber nicht, da die angelegten Begriffe nicht mit dem Text des Beitrags abgeglichen werden.
Ursache unbekannt.
j!-n Ich habe ein Angebot eines Dienstleisters, bei dem es nur um die Anpassung des Mobile-Menü und (herausfordernder) die Anpassung der RokBox geht, damit Videos und Audio auf möglichst allen Geräteklassen und üblichen Browsern abgespielt werden können. Schon das liegt bei ca. 1.800 Euro.
Die Einrichtung einer Joomla-Installation nebst htaccess usw. ist darin nicht enthalten, weil ich dies selbst machen will.
Mit ca. 1.000 Euro Kosten hatte ich gerechnet.
Dank der idiotischen Corona-Zwangsmaßnahmen habe ich keine Ahnung, wie es in Zukunft weiter geht. Zuerst kommt immer das Essen, dann erst die Psyche / Therapie – und ich kann es meinen Klienten nicht verdenken. Daher ist es riskant, jetzt so viel Geld zu investieren.
JoomlaWunder Meine Antwort von soeben in dem anderen Thread:
Bei mir hatte bisher immer funktioniert, beide URLs auf das Joomla-Verzeichnis zu legen. Die Umleitung auf https mache ich in der htaccess mit:
Oder in zwei Schritten:
Ich gebe allerdings zu, dass mir jemand dies gestrickt hat und ich selbst gar nicht so genau weiß, wie die Codes zustande kommen. Jedenfalls hat es bisher funktioniert.
Ansonsten habe ich noch Keep alive aktiviert:
Betreffend apache2handler und cgi-fcgi kann ich nur folgendes sagen:
Ich war bis ca. 2018 bei DomainFactory / GoDaddy und bin wegen der untragbaren Zustände umgezogen nach WebGo. – Das unerwünschte Ausloggen begann noch während der GoDaddy-Zeit und der Server lief auf CGI.
Bei WebGo bin ich bisher gar nicht auf die Idee gekommen, dass es hier anders laufen könnte mit apache2handler. Zudem funktionieren ja alle neu angelegten Websites einwandfrei, sofern ich die Maria-DB nutze und nicht MySQL. Nur die beiden von DF umgezogenen Joomla-Sites (meine beiden Produktiv-Seiten) haben auch bei WebGo das Problem mit dem unerwünschten Ausloggen.
j!-n Hallo Chris, da müsste ich jetzt erst mal den ISP abfragen, denn in den mir zugänglichen Einstellungen finde ich keine Möglichkeit "das PHP-Interface" auf CGI oder FCGI umzustellen. – Ferner macht diese Umstellung aus meiner laienhaften Sicht kaum Sinn, wenn man meine obige Darstellung aus der Antwort zum anderen Thread berücksichtigt.
Bei mir hatte bisher immer funktioniert, beide URLs auf das Joomla-Verzeichnis zu legen. Die Umleitung auf https mache ich in der htaccess mit:
Oder in zwei Schritten:
Ich gebe allerdings zu, dass mir jemand dies gestrickt hat und ich selbst gar nicht so genau weiß, wie die Codes zustande kommen. Jedenfalls hat es bisher funktioniert.
Ansonsten habe ich noch Keep alive aktiviert:
Betreffend apache2handler und cgi-fcgi kann ich nur folgendes sagen:
Ich war bis ca. 2018 bei DomainFactory / GoDaddy und bin wegen der untragbaren Zustände umgezogen nach WebGo. – Das unerwünschte Ausloggen begann noch während der GoDaddy-Zeit und der Server lief auf CGI.
Bei WebGo bin ich bisher gar nicht auf die Idee gekommen, dass es hier anders laufen könnte mit apache2handler. Zudem funktionieren ja alle neu angelegten Websites einwandfrei, sofern ich die Maria-DB nutze und nicht MySQL. Nur die beiden von DF umgezogenen Joomla-Sites (meine beiden Produktiv-Seiten) haben auch bei WebGo das Problem mit dem unerwünschten Ausloggen.
Um CrossPosting zu vermeiden, poste ich diesen Beitrag jetzt in den anderen, neuen Thread, den ich extra wegen des Ausloggen gestartet habe. Denn in diesem Thread ging es nur um die Schwierigkeit, den Dump einer MySQL-DB in die Maria-DB hinein zu bekommen. Und das ist ja mittels Akeeba-Backup endlich auch erfolgreich gelungen, das Thjema also gelöst.
Das iost alles kein Widerspruch:
1.) Ich arbeite ja gerade an der Site, also ist die htaccess für das Backend zurzeit deaktiviert (umbenennen).
2.) Wenn du aus der LogIn-Seite des Backend auf den Link zur Frontseite klickst, wird logischer Weise die URL ohne /index.php dahinter aufgerufen. Tja und dann soll ja die Seite weiß bleiben, weil ich niemanden neugierig machen will.
Was bedeutet denn das, dass ich auf "apache2handler" fahre? Die anderen neu installierten Joomla-Sites funktionieren ohne diesen Auslogg-Effekt einwandfrei, sofern ich Maria-DB als Datenbank auswähle und nicht MySQL. Also kann es ja eigentlich "am Handler" nicht liegen.
Ich kann ja mal morgen per Korrespondenzfunktion dir Zugang zum Backend geben, wenn du mal reinschauen möchtest. Jetzt muss ich zu einer Verabredung.
Nein, wie ich oben schon schrieb, kann das Ausloggen jedes mal dann geschehen, wenn ich auf "etwas" klicke. Ohne einen Klick erfolgt kein Ausloggen. Ich kann also innerhalb der Session-Zeit (hier 30 Minuten) alles Mögliche in einem Beitrag editieren, außer ich würde irgendwo drauf klicken, wie z.B. beim Einfügen eines Link oder JCE-PopUp oder bei der Auswahl einer Absatzformatierung oder einer Inline-Formatierung (fett, kursiv usw.)
Liebe Christine, nein, es geht dieses Mal nicht um die von dir genannte Site. Die war „nur zum Spielen“, um z.B. Video und Audio in Lightboxen darstellen zu können usw. und es ist auch richtig, dass sie regulär kaum auffindbar ist (index.html im Root) und nur über index.php. Das Backend der Site ist, wenn ich nicht dran arbeite, wie bei allen meiner Sites, durch htaccess komplett gesperrt. Seither hatte ich auch keine LogIn-Versuche und URL-injections von ScriptKiddies mehr.
Es geht um folgende Site:
Diese ist entstanden aus der Wiederherstellung des Backup meiner aktuellen Produktiv-Site:
Der einzige wichtige Unterschied ist, dass die .net Domain mit einer Maria-DB betrieben wird und bei Einsatz von z.B. SEO-Glossary keine Probleme macht und die Produktivsite noch auf einer MySQL-DB sitzt, wo das SEO-Glossary einen massiven Konflkikt verursacht.
Das System-Info von Joomla meldet:
Ein oder mehrere triggernde Events, die zum Ausloggen führen, kann ich nicht feststellen. Das Problem tritt immer überraschend auf. Über der nach dem Ausloggen erscheinenden LogIn-Maske steht fast nie, dass ich wegen SessionTimeOut rausgeflogen wäre. Sessionlänge (DB) habe ich schon auf 30 Minuten gesetzt.
Das Ausloggen passiert manchmal kurz nach dem Einloggen, manchmal auch erst 10 bis 15 Minuten danach, je nachdem, wie oft ich etwas anklicke. Anklicken von etwas ist hier ein dauerndes Risiko!
Beispiele für das Ausloggen:
OK, wenn man so will, liegt all den o.g. Aktionen natürlich ein Mausklick zu Grunde, also eine "action". Aber mehr Gemeinsames sehe ich da nicht.
Gemäß dem früheren Thread hier zum gleichen Thema:
RE: Joomla Backend: Ich werde dauernd ausgeloggt - Session-Problem?
hatte ich schon damals die dort vorgeschlagenen Ideen erprobt, aber keine Lösung gefunden. Da ging es um Session-Cookies und meinen Browser aber auch um das Caching der Joomla-Site sowie das Browser-Caching.
Da mein Firefox mit AddOn sehr gut abgesichert ist, hatte ich damals auch mit anderen Browsern experimentiert. Das Ausloggen ist immer gleich geblieben.
Alle meine Sites laufen auf dem gleichen Webspace und der gleichen Server-Konfiguration. Eine php.ini z.B. im Joomla-Root nutze ich nicht.
Da ist es wieder, mein altes Problem aus einem älteren Thread:
Auf meiner alten Joomla-Site (3.9.19) mit MySQL-Datenbank wurde ich immer wieder spontan aus dem Backend geworfen durch Zwangs-Ausloggen. Nachdem nun auch eine mir wichtige Extension wegen der MySQL-DAtenbank nicht funktionieren wollte, habe ich den ganzen Kram mit AkeebaBackup gesichert, eine neue Datenbank (Maria-DB) angelegt und das Backup in einem neuen Verzeichnis auf dem Webspace installiert.
Nach ein wenig Hakelei betr. der URL, die natürlich auf das neue Verzeichnis verweisen sollte, lief alles prima... DACHTE ich!
Denn als ich einen Beitrag editieren wollte, flog ich unvermittelt schon wieder aus dem Backend und landete vor dem LogIn-Screen des Backend.
Leider ist diese Joomla-Site meine Produktiv-Site und ich wollte sie noch einmal inhaltlich pflegen, ehe sie bis zum Jahresende durch eine neuer Site ersetzt wird. Die neue Site läuft auf dem selben Webspace und ebenfalls mit der Maria-DB. Auch drei andere experimentell aufgesetzte Joomla-Sites auf diesem Webspace und mit Maria-DB laufen einwandfrei: Keine einzige wirft mich aus dem Backend!
Es muss etwas in dieser alten Website vorliegen, was diesen Fehler verursacht. Aber wie finde ich das heraus?
Hab den Fehler gefunden!
In der Verwaltung der Websites auf meinem Webspace muss ich eine URL einem (Joomla-)Verzeichnis zuweisen, damit bei Aufruf der URL der Inhalt des Verzeichnisses verfügbar wird. Nun ist die URL zu meiner jetzigen Installation zwei mal aufgeführt, nämlich einmal ohne und einmal mit www. davor.
Normaler Weise hätte ich darauf geachtet. Am Bildschirm wurde in Tabellenform aber nur die www. URL dargestellt und erst bei Weiterblättern auf die nächste Tabellenseite wurde die non-www. URL aufgeführt.
Ich hatte den Fehler gemacht, nur eine der URLs auf das jetzige Joomla-Verzeichnis zeigen zu lassen und nicht auch die andere URL. Folglich zeigte die eine URL korrekt auf das gewünschte Joomla-Verzeichnis, wurde aber wegen Einstellungen in meiner htaccess nicht benutzt und die andere URL zeigte in ein leeres Verzeichnis meines Webspace.
Nachdem ich auch die andere URL auf das richtige Verzeichnis gelegt hatte, funktionierte nun alles, wie gewünscht.
AddOn zu deinen Anregungen:
Bei der oben beschrieben Fehlkonfiguration kann auch der Aufruf der robots.txt nicht funktionieren. Ist aber eine gute Idee, um unkompliziert und schnell zu testen, ob überhaupt was geht.
Gestern hatte ich auch die htaccess im Joomla-Wurzelverzeichnis kurzzeitig deaktiviert, brachte aber (logischer Weise) keine Änderung. Die dort vorliegenden Rewrite-Bedingungen sowie URL-Umleitungen hatte ich aber schon sehr sorgfältig geprüft.
Die neue Site habe ich in ein ganz frisches Verzeichnis installiert und auch die Maria-DB war blank. Ich verwende keine Subdomain, sondern immer https://meine-domain.de
Ich danke dir herzlich für deine Anregungen zur Fehlersuche und hoffe, dass diese Anregungen anderen weiter helfen werden!
Hab übrigens gemäß Akeeba-Ratgeber in der configuration.php geprüft, dass
eingetragen sind. caching stand vorher auf '2' und session_handler stand auf 'none'
Mehr Hinweise fand ich auch bei Akeeba nicht.
Nun habe ich mittels Akeeba Backup die alte Site in einem neuen Serververzeichnis installiert und als Datenbank eine Maria-DB angegeben. Akeeba lief einwandfrei durch und ich fand auch weder im Joomla-Verzeichnis noch in der DB Auffälligkeiten. Immerhin ist damit ja wohl die DB korrekt erstellt worden.
Die htaccess im Joomla-Verzeichnis hab ich natürlich angepasst, da ich nun eine andere URL nutzten muss, statt der Produktiv-URL. Die neue URL ist genau so per LetsEncrypt gesichert erreichbar wie die alte Produktiv-Site.
Ferner habe ich die configuration.php im Joomla-Verzeichnis geprüft, aber alle Pfadangaben darin waren OK.
Eine andere URL zu verwenden als die URL der Produktiv-Site war eine gute Idee, denn prompt funktioniert die über Akeeba erstellte Site nicht. Sowohl auf der Homepage als auch auf der Admin-Site erhalte ich "404 The requested URL was not found on this server."
Die URL muss aber gültig sein, denn immerhin funktionierte sie ja während der Akeeba-Wiederherstellung.
Im Web fand ich bisher keine Lösungs-Anregungen.
Was tun?
Ich habe in PHPmyAdmin alles durchsucht, aber keine Möglichkeit gefunden, die Datenbankversion heraus zu finden!
Dann habe ich mir eine info.php erstellt. Dort erhalte ich dann die gleiche unglaublich umfangreiche Anzeige, zu der auch Joomla in der Lage ist, wenn ich das System-Info abfrage. Allerdings steht da wenigstens klar verständlich gelistet:
Datenbankversion: 5.5.5-10.3.11-MariaDB-log
und
PHP-Version: 7.3.18-1+0~20200515.59+debian9~1.gbp12fa4f
Der Dump, den ich erstellt hatte, hat knapp 10 MB Größe. Nirgendwo fand ich darin "CREATE DATABASE" sondern immer nur CREATE TABLE.
Inzwischen habe ich eine komplett neue Joomla-Installation erstellt. Mit der läuft SEO-Glossary ebenfalls auf Anhieb einwandfrei.
Ich hatte gedacht, dass der Weg über den Dump einfacher sein könnte. Dann blieben die Verzeichnisse der alten Joomla-Instalation auf dem Server gleich.
Mit Akeeba müsste ich einen neuen Installationsordner anlegen und auch zum Ausprobieren im Server die URL auf den neuen Ordner legen.
Ich versuch morgen noch mal den Dump in die Maria-DB zu bekommen. Wenn's dann nicht geht, kann ich immer noch die Akeeba-Lösung nutzen.
flotte Also ungewöhnliche Zeichen gibt es auf meinen Websites nicht. Daher wäre ein erweiterter Zeichensatz in der DB nicht nötig.
Wie ich oben angab, nutze ich sowohl unter MySQL als auch unter MariaDB bereits Versionen größer 5.5, sodass utf8mb4 von beiden genutzt werden kann.
Darauf deutet auch hin, dass insgesamt drei meiner Test-Websites auf der MariaDB einwandfrei laufen, einschließlich der kritischen Joomla-Extension. Diese Sites wurden allerdings auch von Anfang an auf MariaDB installiert und nicht zunächst auf einer MySQL DB.
Die Version von MariaDB ist, wie ich oben schrieb:
Datenbankversion 5.5.5-10.3.11-MariaDB-log
Mag sein, dass es inzwischen Neueres gibt. Mich verwirren hier die Versions-Zahlenangaben. Wenn du von Version größer 10.1 sprichst, nehme ich mal an, dass meine o.g. Version die 10.3.11 ist und nicht irgend eine 5.5.5
Ich mache jetzt noch einen neuen Versuch, einen Dump zu importieren, wobei ich dann das gleiche DB-Passwort nutzen werde. Den gleichen DB-User und DB-Name wie die aus der der Dump stammt, kann ich nicht verwenden, weil User / Name einfach vom Server hochgezählt werden.
Meine vorige Frage, ob vor dem Import Username und Datenbankname identisch sein muss mit den Angaben im zu importierenden Datensatz ist noch offen und so frage ich jetzt noch mal nach.
Ich möchte beim Import den Weg gehen, eine neue Maria-DB durch Import des Dump der alten DB erstellen und dann mit der bestehenden Joomla-Installation einbinden (neue DB in die configuration.php eintragen).
Hab leider jetzt ein Problem beim Import:
Zuerst habe ich aus der bestehenden MySQL-DB mittels der GUI MySQL-Admin einen Dump herunter geladen. Dann habe ich in eine bereits angelegte Maria-DB den Dump hochgeladen. Dabei gab es nach einer relativ langen Zeit eine Fehlermeldung:
Nachdem ich den Zurück-Button im Browser betätigt hatte, sah ich in einem rot hinterlegten Bereich einen anscheinend detaillierten Fehlerbericht, den ich aber mangels Kenntnisse nicht interpretieren kann:
string 'SELECT `db_name`, COUNT(*) AS `count` FROM `phpmyadmin`.`pma__navigationhiding` WHERE `username`=\'web215\' GROUP BY `db_name`',
string 'SELECT `db_name`, COUNT(*) AS `count` FROM `phpmyadmin`.`pma__navigationhiding` WHERE `username`=\'web278\' GROUP BY `db_name`',
string 'SELECT `db_name`, COUNT(*) AS `count` FROM `phpmyadmin`.`pma__navigationhiding` WHERE `username`=\'web278\' GROUP BY `db_name`',
string 'SELECT `db_name`, COUNT(*) AS `count` FROM `phpmyadmin`.`pma__navigationhiding` WHERE `username`=\'web278\' GROUP BY `db_name`',
./libraries/classes/Navigation/NavigationTree.php#292: PhpMyAdmin\Navigation\Nodes\Node->getNavigationHidingData()
./libraries/classes/Navigation/NavigationTree.php#849: PhpMyAdmin\Navigation\NavigationTree->_buildPath()
Ich habe dann hier nachgelesen (aber auch fast nichts verstanden):
https://mariadb.com/kb/en/importing-data-into-mariadb/
Aber im Abschnitt „mysqlimport“ inspirierte mich der Inhalt des Kastens, dass es möglicher Weise einen Konflikt mit dem Datenbank-Prefix, dem DB-User und DB_Passwort geben könnte.
Hätte ich also vor dem Import eine neue leere Maria-DB anlegen müssen, die den gleichen Usernamen, Passwort und Prefix hat, wie die DB, deren Dump ich importieren möchte?
Und könnte es sein, dass der Dateiname des Dump, der ja auf die ursprüngliche DB verweist oder den Namen der ursprünglichen DB enthält, irgendwie in Konflikt mit dem Namen der neuen Maria-DB steht?
Wie muss ich also den Import meines Dump korrekt durchführen?
Nein, den Versuch eines Import habe ich noch gar nicht unternommen. Ich möchte mich ja vorher informieren, um unnötige und zeitfressende Fehler zu vermeiden.
Der Fehler betr. Reg-ex, den SEO Glossary zeigt, könnte durchaus mit den unterschiedlichen Zeichensätzen zu tun haben. Deshalb wäre es ja sinnvoll, schon vo dem Import nach Maria-DB die Zeichensatzgeschichte zu klären bzw. zu korrigieren. I
ch weiß bloß nicht wie ich das machen könnte! Daher meine Frage hier.
Danke für deine Antwort! Bleibt aber noch die Frage nach den unterschiedlichen Zeichensätzen.
Wie soll ich damit umgehen?
Sorry, hab deine Frage zuletzt übersehen. Die fragliche Erweiterung heisst SEO Glossary. Sobald die Komponente aktiv geschaltet wird und die Texte der Beiträge nach Glossary-Worten durchsucht wird, erscheint im Frontend nur noch die Fehlermeldung, dass Regular Expressions einen Fehler verursachen. Die gesamte Site ist damit platt / blockiert.
Allerdings haben meine Produktivseiten gemeinsam noch einen Fehler, der bereits in diesem Forum (ohne Ergebnis) diskutiert wurde: Ich werde häufig im Backend einfach ausgeloggt. Zuverlässige Arbeit im Backend ist damit kaum möglich.
Es ist denkbar, dass dieser Fehler mit dem Zeichensatz in Verbindung steht.
Die von dir angesprochenen Mängel sind dem reinen Experimental-Status dieser Site geschuldet. Durch diese Experimente fand ich auch heraus, dass weder die CK-Modals noch die von RegularLabs und auch nicht die JCE-Mediabox zuverlässig funktionieren.
Am besten funktioniert für meine Anforderungen bisher die RokBox. Inzwischen habe ich die Experimental-Site überarbeitet, sodass Interessierte Forumsteilnehmer die Möglichkeiten und Unterschiede von JCE und RokBox ausprobieren können auf den verschiedenen Geräteklassen und Viewportbreiten.
RokBox arbeitet (leider) mit den Mootools, verwendet aber nur ca. 138 kB der Mootool-Bibliothek. Nach Durchsicht des Script konnte cih erkennen, dass hier sehr sorgfältig nach Geräteklasse, VIewportbreite usw. abgefragt wird und zudem automatisch erkannt wird, welche Art der Content ist, der in die Modalbox geladen werden soll.
Sicher gibt es solche Scripts aber auch auf Basis von jQuery oder anderen Frameworks. Hab solche Erweiterungen aber noch nicht gefunden. Hinsichtlich Joomla-4-Kompatibilität wäre das vermutlich besser, als die Mootools.
RokBox ist die einzige Erweiterung, bei der Audio und Video auf allen bisher geprüften Android-Geräten und insgesamt 8 verschiedenen Browsern läuft. Beim Video gibt es eine ca. 3 Sekunden lang erscheinende Fehlermeldung, wonach das Video bzw. dessen URL nicht gefunden wird, um es dann aber erstaunlicher Weise doch anzuzeigen.
RokBox hat aber in meiner aktuellen Konfiguration noch erhebliche Probleme damit, den Joomla-Textbeitrag ebenso gut anzuzeigen. Das könnte evtl. ganz einfach mittels CSS-Anpassung gelöst werden, weil es nur um die Größe der Contentbox in der Lightbox geht. Immerhin öffnet diese Box auf allen Geräten / Browsern zuverlässig.
RokBox hat aber erstaunlicher Weise bei Desktop-PCs ein Problem mit der Audio-Wiedergabe im Firefox-Browser, während dies im Chrome-Browser und im Midori einwandfrei läuft. Hier könnte ein Fehler im Script vorliegen.
Und betreffend des Schließen-Button: Natürlich ist der essentiell wichtig. Er lässt sich aber bequem per CSS anpassen und (hoffentlich) auch dann noch über ein gezeigtes Video drüber legen, wenn der Besucher das Video im Vollbild-Modus ablaufen lässt. Auch hier zeigt sich, wie vorteilhaft es wäre, nur eine Joomla-Erweiterung für alle Modalbox-Inhalte zu haben, weil dann der Schließen-Button und andere Details immer zentral in einer einzigen CSS definierbar sind.
Zurzeit läuft eine Anfrage bei einem Joomla-Dienstleister, die erforderlichen Veränderungen und Anpassungen vorzunehmen.
firstlady Das Audio "spricht", wie oben beschrieben, nur bei der RokBox, aber mit Ausnahme, wenn Firefox im Desktop-PC genutzt wird.
Hallo!
Ich erlebe gerade mit zwei Produktiv-Sites ein Problem, sobald ich eine bestimmte Joomla-Erweiterung verwenden will. Nach Diskussion mit den Entwicklern der Erweiterung deutet alles darauf hin, dass die Ursache in der MySQL-Datenbank liegt. Denn zwei Sites mit der Maria-DB funktionieren auf Anhieb einwandfrei und drei andere mit einer Standard-MySQL-Datenbank haben Probleme.
Meine Frage:
Auf welche Weise kann ich den Inhalt der bisherigen Datenbank in eine Maria-DB hinein bekommen und dann die Joomla-Site mit der neu angelegten Maria-DB verbinden?
Meine eigenen Ideen dazu:
a) mit Akeeba-Backup die ganze Site sichern und in einen neu angelegten Webspace mit Maria-DB hinein kopieren
b) aus der bestehenden Datenbank einen Dump erstellen und diesen in die Maria-DB importieren und dann die aktuelle Site mit der neuen DB verbinden.
Schwierigkeiten können auch durch die Unterschiede entstehen, die ich in der System-Info finde, wenn ich eine funktionierende Site mit Maria-DB vergleiche mit den System-Infos der Produktiv-Sites:
Funktioniert:
Funktioniert mit der gewünschten Joomla-Erweiterung nicht:
Da es sich um Produktiv-Sites handelt, auf die ich angewiesen bin, muss ich sehr sorgfältig vorgehen, damit Besucher immer etwas Funktionierendes ausgeliefert bekommen.
Liebe Christiane!
Das mit den Modals hatte ich mir schon genau überlegt: Es soll dazu beitragen, dass der Besucher nach Aufnahme eines Video oder Audio oder des Texts nach Schließen des Modal exakt an die Stelle zurück kehrt, von der er gekommen ist.
Wenn auf einer Seite z.B. 10 oder mehr Beiträge in Blogform und großem Bild angefeatured werden und ein Beitrag wird geöffnet und später wieder geschlossen, dann kehrt der Besucher an den ersten Beitrag auf der Blog-Seite zurück.
Bei Nutzung eines Modal bleibt aber die dahinter liegende Blog-Seite ungescrollt genau an der Stelle stehen, wo der Besucher das Modal gestartet hatte.
Einen weiteren Vorteil der Modals sehe ich darin, dass das ganze Fenster, in dem die Website läuft, vom Modal bedeckt wird und so der Besucher nicht mehr durch andere Elemente auf meiner Website von der Aufnahme des Inhalts abgelenkt wird (wie sonst z.B. durch Menüleiste / Seitenleiste usw..) Dies ist natürlich bei Video und Audio besonders wichtig.
Zudem ist so sicher gestellt, dass das Video immer mit seiner maximalen Breite dargestellt wird. Direkt auf der Seite wäre das ja nicht möglich. Oder es nimmt riesig Platz ein, schon beim Vorschau-Bild – auch wenn der User am Video gar nicht interessiert wäre.
Und wenn ich Modals schon bei Video und Audio einsetze, dann setzt sich die GUI lediglich logisch fort, wenn auch die Texte in Modals gezeigt werden.
Auf der von mir eingangs genannten Testseite ist das ja gut nachvollziehbar, auch wenn aktuell das Audio im Modal leider nicht spielt (RokBox) – keine Ahnung warum. Eigentlich müsste das aber gehen. -> Support über das Forum? Ja, gegen 19 Euro für 6 Monate Foren-Zugang.
Hier nochmals verdeckt der Zugang zur Testseite, sodass du meinen Ansatz noch mal sehen kannst (nur Homepage ist relevant):
Mir ist klar, dass Modals betreffend Usability kontrovers diskutiert oder kritisch gesehen werden. Bei den bisherigen Diskussionen dazu, die ich gelesen habe, fand ich aber die von mir hier genannten Argumente nicht berücksichtigt.
Ich wüsste aber auch nicht, weshalb jemand mit eingeschränkten Fähigkeiten mit einem Modal Schwierigkeiten haben sollte: Bei Video und Audio gewiss nicht. Und beim Text würde z.B. ein Screenreader ja wohl das vorlesen, was „vorne“ steht (z-Index).
Und wer JS deaktiviert… naja, dem kann ich auch nicht mehr helfen; kann mich ja immerhin noch anrufen!
Welche Gründe sprechen denn noch gegen Modals, wenn man meine Argumente pro-Modals berücksichtigt?
Danke für die guten Hinweise. Darauf kann ich ja zurück kommen, wenn meine 3.9 Site fertig ist. Falls die in der von mir erstellten Konfiguration nicht für 3.10 geeignet ist, muss ich später halt daran arbeiten und hätte dazu bis zu 3 Jahre Zeit, bis der Support ausläuft. Das ist ja erst mal was!
Das in der von mir benannten Musterseite gestaltete Blog-Design, bei dem jeder Beitrag bis zum Readmore mit einem Rahmen plus Hintergrund und den drei Buttons für Video, Audio und Text erscheint, ist ja mit CSS gestaltet und wird genau so auch bei Joomla 4 verwendbar sein.
Der Trick hierbei war, im Editor den Readmore-Link zu setzen, aber dann in den Veröffentlichungseinstellungen auszublenden. Nun kann der Beitrag in der Textansicht nur noch über den Button in einem Modal-Fenster angezeigt werden.
Auch für Audio und Video möchte ich mittels der Buttons Modal-Fenster öffnen. Modal-Fenster sind daher für mich sehr wichtig und sie sollten auf möglichst allen Geräten incl. Mobil laufen. Und das ist derzeit noch meine größte Schwierigkeit!
Gibt es eigentlich in Joomla oder im Template eingebaute Modal-Fenster, die so zuverlässig arbeiten, dass Video, Audio und Text (mit interner Joomla-URL aufgerufen) auf allen geräten zuverlässig angezeigt / abgespielt werden?
Ich hatte ja mal einen CSS-3-basierten Ansatz im Web gefunden. Es war kein JS enthalten! Beeindruckend! Aber auf Android-Mobilgeräten funktionierte diese CSS-Lösung überhaupt nicht. Und ich fand keinen Grund, warum das so war.
Mit RokBox hakelt das Video beim Start auf Mobilgeräten zwar, aber es läuft meistens. Das Audio läuft weder in der JCE-Mediabox, noch in der RokBox. Und der Text wird nur über JCE-Mediabox zuverlässig angezeigt.
Daran änderte sich auch nichts, wenn ich versuchte, den AllVideo-Player mit zu verwenden.
Aktuell experimentiere ich mit dieser reinen CSS-Lösung hier:
https://www.w3schools.com/w3cs…name=tryw3css_modal_image
Im Beispiel wird aber lediglich ein Bild geladen, kein Video, Audio oder eine Joomla-interne URL.
Frage also:
Gibt es ein einfaches Standard-Template, mit dem ich zuverlässige Modal-Fenster bekomme und incl. einem vernünftigen Mobil-Menü (Sandwich)?
Wenn nein, wie kann ich ein möglichst rein auf CSS-Basis beruhendes zuverlässiges Modal-Fenster hinbekommen?