Zitat von Re:Later

Ist das eine Frage oder nur ein Hinweis für Leute, die bei one.com hosten??

Es sollte mit dem Beitrag ONE.COM Kunden, die nach einer Lösung des Problems suchen, ein Lösungsvorschlag aufgezeigt werden. Auch wollte ich mit dem Beitrag einen Hinweis geben, dass One.Com ihre Joomla-Kunden „im Regen“ stehen lässt, und nicht gewillt ist das Problem zu lösen.

Wie von Re:Later hingewiesen, ist man zur Zeit gezwungen die MysqliDriver.php per Sftp herunterzuladen mit einem Editor die blöde Zeile einzufügen und wieder die Datei hochzuladen, um ein Joomla update durchzuführen. Darüber könnte man noch nachdenken. Aber hinzukommt die Preispolitik von ONE.COM von 2019 bis 2023 hat sich der Hostingpreis um fast 100 % erhöht. Zur Entschuldigung könnte man sagen die Energiepreise sind gestiegen. Als Neuestes kommt beim Einloggen ins Kontrollpanel der Hinweis: „Wir aktualisieren die Berechnung des Speicherplatzes für Ihr Konto, um ein Backup Ihrer Webspace-Daten einzubeziehen. Infolgedessen wird sich Ihr Gesamtverbrauch nach dieser Änderung erhöhen.“ Unter den FAQ bei One.Com steht „Wenn Sie 100 MB Speicherplatz für Ihr Webhosting-Paket verwenden, beträgt der Speicherplatzverbrauch für Backups ebenfalls 100 MB, sodass es insgesamt 200 MB sind.“ Wenn das so ist, halbiert sich der Webspace. One.Com Beginner 50 GB: Hat man eine 25 GB Webseite fallen 25 GB fürs Backup an. Das ist wieder eine Preiserhöhung über die Hintertur von 50 % zusätzlich.

Es ist zu überlegen ob hierzu eine Bewertung bei Trust-Pilot zu One.com durchzuführen ist.

Seit Joomla 4.3 bis heute bei jedem update, also auch beim Update von Joomla 5.0.0 auf 5.0.1 kommt folgende Fehlermeldung:

The SELECT would examine more than MAX_JOIN_SIZE rows; check your WHERE and use SET SQL_BIG_SELECTS=1 or SET MAX_JOIN_SIZE=# if the SELECT is okay

Der Support/die Administratoren/Techniker von One.com teilen dazu mit, dass in der Datei /libraries/vendor/joomla/database/src/Mysqli/MysqliDriver.php folgendes einzutragen ist:

mysqli_query($this->connection,"SET SQL_BIG_SELECTS = 1;" );

Macht man dies, so sieht es wie folgt aus beim Update von Joomla 5.0.0 auf 5.0.1 in Zeile 305

Das Update von Joomla 5.0.0 auf Joomla 5.0.1 konnte dann durchgeführt werden. Nach dem Update erscheint dann aber folgende Fehlermeldung:

Es ist ein Fehler aufgetreten.

Zitat

1104 The SELECT would examine more than MAX_JOIN_SIZE rows; check your WHERE and use SET SQL_BIG_SELECTS=1 or SET MAX_JOIN_SIZE=# if the SELECT is okay

Dies hängt damit zusammen, dass bei dem Joomla update die Datei MysqliDriver.php überschrieben wird mit der Original Joomla MysqliDriver.php Datei ohne den Dateieintrag mit der zusätzlichen Zeile.

Unter Systeminformation im Joomla backend wird die Version Joomla 5.0.1 angezeigt nach dem Uupdate. Die Joomla-Internetseite funktioniert auch offensichtlich nach dem update.

Trotzdem: Der von one.com.team vorgeschlagene Workaround ist hinter diesem Hintergrund nicht zufriedenstellend, wenn nach dem Joomla update obige Fehlermeldung angezeigt wird. Außerdem ist vor jedem Update von Joomla der obige Workaround zu machen. Die Techniker von One.Com haben auch nicht in absehbarer Zeit vor etwas gegen diesen Fehler zu tun wie mir der Support mitgeteilt hat. Warten die Techniker von ONE.COM jetzt darauf, dass die Joomla Entwickler die Zeile in MysqliDriver.php aufnehmen, dass One.com keine Probleme mehr hat?

Da ich auch eine Webseite bei 1 blu regelmäßig mit Joomla update ist anzumerken bei 1blu Webhosting funktionieren die updates von Joomla auch ohne den von One.com vorgeschlagenen Workaround. Es muss die Zeile nicht in die php Datei bei 1blu eingetragen werden.

Vielleicht sollten Hoster wie 1blu und andere Hoster die dieses Problem nicht haben One.com mal einen Tipp geben.

Der Pfad

public $log_path = '/var/www/html/joomla/logs';

ergab sich durch die Datensicherung von der Live-Website. Bei meinem hoster ist der logs Ordner auch auf der Ebene mit den anderen joomla-Ordnern. Unter dem Ordner administrator befindet sich auf der Live-Website kein logs Ordner. Dadurch dass ich die Live-Website mit filezilla gesichert habe ist dementsprechend auf der eingespielten Sicherung unter virtualbox auch kein logs Ordner unter /var/www/html/joomla/administrator vorhanden.

Zur zweiten Frage kann ich nichts sagen. Ich habe mich lediglich an die Anleitung von tecmint angelehnt. Ich möchte lediglich wenn joomla 5 erscheint ein update von der website unter virtualbox fahren und schauen ob alles noch funktioniert oder was angepasst werden muss. Die Installation weiterer Instanzen habe ich bisher nicht gemacht. Erfahrungen dazu habe ich bisher auch nicht. Welche Befehle von der Beschreibung bei tecmint angepasst werden müssten und ob es dann funktioniert dazu kann ich bisher nicht sagen.

Informationen sind hoffentlich hilfreich.

Da beim letzten großen Upgrade von Joomla 3 auf Joomla 4 bei meiner Live Website 3 von 5 Plugins/Extensions nicht mehr funktionierten und das zu größeren Umbauarbeiten bei der Website führte, will ich diesmal, wenn Joomla 4 auf Joomla 5 upgegraded wird, genau wissen was auf mich zukommt. Dies soll zuerst auf einer Website getestet werden die nicht live ist.

Deswegen habe ich unter Virtualbox mit Debian testing zuerst die Voraussetzungen geschaffen, indem ich

PHP 8.2

Apache2

MariaDB

installiert und konfiguriert habe nach der Beschreibung von

How to Install Joomla on Debian 10

In this article, we are going to demonstrate how you can install Joomla CMS on Debian 10.

www.tecmint.com

Dann habe ich eine Datensicherung meiner Live-Website, die ich mit filezilla und myphpadmin erstellt habe, auf virtualbox mit Debian testing in das Verzeichnis /var/www/html/joomla

eingespielt. Die Datenbank habe ich mit myphpadmin auf MariaDB übertragen und den Zugriff für den neuen Datenbanknamen angelegt.

Anschließend habe ich wie aus dem Verzeichnis /var/www/html/joomla ausgelesen in der Datei

configuration.php die Pfade für

$tmp_path = '/var/www/html/joomla/tmp';

public $log_path = '/var/www/html/joomla/logs';

wie oben angezeigt angepasst.

Die IPAdresse für Joomla wurde ermittelt und im Browser

http://10.0.2.15/index.php (mit und ohne index.php)

http://10.0.2.15/administrator/index.php (mit und ohne index.php)

eingegeben.

Der Seitenaufruf der Website brachte die Fehlermeldung Access denied. Beim Versuch das Backend aufzurufen kam die Fehlermeldung von Joomla mit der rot-orangen Seite „Sorry, there was a problem we could not recover from. The server returned a "500 - Whoops, looks like something went wrong“

Die Lösung für beide Fehlermeldungen war eine Änderung in der configuration.php. Es wurde folgendes eingetragen:

public $user = 'root';

public $password = 'GeheimesRootPasswort’;

Nach dieser Änderung in der configuration.php funktioniert die eingespielte Website auf der Testumgebung von VirtualBox.

Ich habe dies beim JoomlaForum eingestellt, da ich längere Zeit im Web gesucht habe und keine Lösung für mein Problem gefunden habe und anderen die das gleiche Problem haben einen Lösungsvorschlag bieten will.

Super gefixt Astrid

Die neue Version v 5.0.1 und Lösung von Astrid funktioniert einwandfrei.

Anmerkung: Es sollten die Overrides (joomla-field-media.js und/oder joomla-field-media.min.js), die man wie oben beschrieben evtl. erstellt hat um das Problem zu fixen, unter media/templates/administrator/atum/js/system/fields/ wieder gelöscht werden, sonst funktioniert die Lösung von Astrid nicht.

Zitat von astrid

Es gibt jetzt eine funktionierende Version von aggpxtracks für die neueste Joomla-Version. Leider kann man die GPX-Datei nicht mehr im Custom Field auswählen, sondern muss den korrekten Pfad selbst eingeben.

Hier ist die Version zum Download: https://github.com/astridx/pkg…track/releases/tag/v5.0.0

Astrid hat eine neue Version von aggpxtracks herausgegeben die Version

pkg-aggpxtrack-5.0.0.zip

In dieser Version wurde die Umstellung wie oben beschrieben gemacht, eben mit dem kleinen Nachteil des Verzeichts auf Browsen. Ich hatte das erste Zitat etwas länger machen sollen, dann wäre alles klar gewesen. LG

Also ich freue mich wenn ich einen langen Pfad und einen Dateinamen nicht manuell eintragen muss, wo Tippfehler leicht möglich sind und ich den genauen Dateinamen wissen muss, sondern wenn ich einen langen Pfad und den Dateinamen über browsen auswählen kann. Astrid hat bei Ihrer Lösung vom browsen auf manuelle Eingabe umstellen müssen.

Von Astrid gelöst

Astrid

Zitat von astrid

... Leider kann man die GPX-Datei nicht mehr im Custom Field auswählen, sondern muss den korrekten Pfad selbst eingeben

Vorher bis Joomla 4.2.2:

Nachher ab Joomla 4.2.3:

Manchmal wird man von anderen gezwungen vom Rolls-Royce auf Mercedes umzusteigen. Schade. Aber beides sind ja Luxusfahrzeuge

Habe in den beiden Dateien joomla-field-media.js und joomla-field-media-min.js die Änderung von application/pdf gemacht.

forum.joomla.de/core/attachment/13419/

und anschließend die zwei Dateien in das Verzeichnis /media/templates/administrator/atum/js/system/fields kopiert

Bei meinem Joomla waren die UnterOrdner System und Fields nicht vorhanden, wurden also angelegt.

Leider habe ich nach wie vor die oben beschriebene Sachlage mit der Fehlermeldung.

Nach dem Update von Joomla 4.2.2 auf 4.2.3 erhalte ich beim Speichern von Beiträgen folgende Fehlermeldung:

Das Formular kann nicht abgeschickt werden, da erforderliche Daten fehlen.

Bitte die markierten Felder korrigieren und erneut versuchen.

Dies liegt daran, dass agpxtrack unter Joomla 4 von Astrid Günther installiert ist. Bei diesem Programm werden Felder angelegt. Unter Beiträge Felder ist z. B. das Feld „001-runde-don-kaisheim-schloessle“ angelegt mit dem Inhalt: „images/gpxtracks/001-runde-don-kaisheim-schloessle.gpx“ in rot. In der linken Spalte unter Felder steht unter dem Feldnamen“Dieser Wert ist nicht gültig.“ (in rot). Geht man rechts auf das Schaltfeld auswählen und sucht die gpx Datei im richtigen Pfad so ändert sich der Inhalt im Feld auf „images/gpxtracks/001-runde-don-kaisheim-schloessle.gpx#joomlaImage://local-images/gpxtracks/001-runde-don-kaisheim-schloessle.gpx?width=0&height=0“ in der Farbe schwarz. Jetzt ist ein Speichern des Beitrages möglich. Möchte man nochmal speichern, auch ohne etwas zu ändern kommt wieder die Fehlermeldung:

Das Formular kann nicht abgeschickt werden, da erforderliche Daten fehlen.

Bitte die markierten Felder korrigieren und erneut versuchen.

Es ist der gleiche Fehler wie vorher, die Inhalte der gpx-Datei in Felder wird in rot dargestellt. Geht man wieder auf auswählen und wählt die Datei, dann steht wieder in schwarz wie oben „images/gpxtracks/001-runde-don-kaisheim-schloessle.gpx#joomlaImage://local-images/gpxtracks/001-runde-don-kaisheim-schloessle.gpx?width=0&height=0“ also der gleiche Text und man kann wieder speichern aber nur einmal, da sofort beim nächsten mal wieder die gleiche Fehlermeldung kommt.

Anzumerken ist, dass der Standardeditor TinyMCE das Browsen zur gpx Datei unter Beiträge Felder unterstützt. Dazu war es aber notwendig unter „System, Konfiguration, Komponente Menü“ in den Feldern „Zulässige Erweiterungen“ und „Gültige Bildateiendungen (Dateitypen) jeweils gpx zu ergänzen. Ansonsten hätte man den Pfad und den Dateinamen in „Beiträge“, „Felder“, „Feldnahme“ manuell ergänzen müssen. (Übrigens JCE unterstützt selbst nach dieser Ergänzung das Browsen zur gpx Datei unter „Beiträge“, „Felder“ nicht.

Erwähnenswert ist, dass unter Joomla 4 unter allen vorherigen 4er Versionen bis zum Update von 4.2.1 auf 4.2.3 die Erweiterung Agpxtrack von Astrid Günther einwandfrei mit Joomla zusammengearbeitet hat und alles funktioniert hat. Mit dem Update von Joomla auf 4.2.3. erscheint jetzt die Fehlermeldung

Das Formular kann nicht abgeschickt werden, da erforderliche Daten fehlen.

Bitte die markierten Felder korrigieren und erneut versuchen..

Ich glaube das ist ein Bug in Joomla 4.2.3, zumal diese Fehlermeldung auch schon bei anderen Nutzern in anderen Fällen aufgetreten ist.

Bei einer zweiten Website habe ich SIGE 3.4.2 statt deaktiviert deinstalliert und Joomla von 3.10 auf 4.0.4 aktualisiert. Dann wollte ich SIGE wieder installieren. Dies war nicht möglich und endete mit einer Fehlermeldung. Von den oben genannten 3 Modulen war das erste Modul nicht installiert nach der Fehlermeldung und ein Bilderaufruf in Joomla 4 mit SIGE 3.4.2 nicht mehr möglich. Wenn SiGE erhalten bleiben soll nach einem Update auf Joomla 4 war es bei einer anderen Website möglich SIGE 3.4.2 zu deaktivieren, Joomla zu aktualisieren und dann SIGE 3.4.2 wieder zu aktivieren mit den oben genannten Einschränkungen. Insgesamt ist SIGE 3.4.2 also nicht voll Joomla 4 kompatibel.

Ich habe daher auf der Website statt SIGE 3.4.2 die sehr gute Erweiterung SIGPLUS 1.5 als Alternative verwendet, die Joomla 4 tauglich ist und von den Funktionen eher noch mehr hat als die Free Version von SIGE. SIGPLUS finde ich von der Art her ähnlich wie SIGE. Sehr gut an SIGPLUS 1.5 ist, dass in dem Editor von Joomla ein Menüpunkt eingebunden wird, der bei der Einbindung/Einbettung der Bilder/Gallerien in Beiträge unterstützt.

Habe die Module von Sige-free in Joomla 4 nochmal genau durchgesehen. Es sind drei Module installiert:

1. Inhalt - Simple Image Gallery Extended - SIGE - Site - Plugin - 3.4.2-FREE

2. Schaltflache - SIGE Parameter - SIGE Parameter Button - Site - Plugin - 3.3.2-FREE

3. Simple Image Gallery Extended - SIGE - Administrator - Komponente - 3.4.2-FREE

Sind alle drei Module aktiviert lässt sich im Backend von Joomla 4 kein Beitrag aufrufen, neu erstellen oder bearbeiten. Deaktiviert man das 2. Modul "SIGE Parameter Button" lassen sich im Backend die Beiträge aufrufen, bearbeiten und neu erstellen. Man muss halt den Befehl für die Anzeige der Bilder/Gallerien händisch in den Beitrag einfügen.

Im Frontend/Browser werden die Bilder/Gallerien auch unter PHP 8.0 anscheinend einwandfrei dargestellt, wenn das 2. Modul SIGE Parameter deaktivert ist.

Der entscheidende Punkt scheint also das Modul SIGE Parameter Button zu sein. Dieses Modul wurde von Viktor Vogel noch nicht fur eine FREE Version aktualisiert.

ausgezeichnet erklärt.

Die Datensicherung von Akeeba Backup von der Live Website wurde auf VirtualBox Bullseye mit Apache und MariaDB mit Kickstart.php aufgespielt. Nach erfolgreicher Rücksicherung auf Localhost (10.0.2.15) war das Backend von Joomla 4 unter localhost (10.0.2.15/administrator) nicht aufrufbar (kein Anmeldebildschirm). PHP8.0 in Virtualbox Bullseye - Die Live Website wurde mit https und PHP 7.4 betrieben. Um das Backend von Joomla 4 wieder aufrufen zu können war es erforderlich in Bullseye unter /var/www/html/configuration.php die Einstellung "$force_ssl = 2" in "$force_ssl = 0" zu ändern. Damit war das Backend unter Localhost 10.0.2.15/administrator wieder erreichbar.

Beim Frontend war die home-Seite also Startseite erreichbar aber keine Unterseite aufrufbar. Dies lag daran dass auf der Live-Website Search-Engine-Friendly (sef) eingestellt war. Nach Änderung in Virtualbox Bullseye /var/www/html/configuration.php von "$sef = '1' "in "sef = '0' " und "$sef_rewrite = '1' " in "$sef_rewrite = '0' " waren unter virtualbox Bullseye 10.0.2.15 auch wieder die Unterseiten der Website aufrufbar. Übrigens dieses Problem hatte ich auch auf der Live-Website. Die hatte auch erst Unterseiten aufgerufen, nachdem ich sef ausgeschaltet habe.

Habe joomla von 3.10 auf 4.0 upgedatet mit deaktiviertem plugin sige free 3.4. 2 und php 7.4. Nach dem update habe ich sige 3.4.2 wieder aktiviert. Das plugin geht mit php 7.4 und website ist aufrufbar. Aber der in joomla 4 enthaltene editor kann keine Beiträge öffnen und bearbeiten solange das plugin sige 3.4.2 aktiviert ist. Mit aktiviertem sige 3.4.2 und php 8.0 lässt sich im frontend also browser die website nicht mehr aufrufen. Es kommt eine Fehlermeldung dass die website nicht aufrufbar ist. Wann kommt eine free Version von sige die joomla 4 tauglich ist wie die kostenpflichtige 4.0 pro version von sige. Das ist die Frage oder soll man auf ein anderes plugin wechseln.

Habe joomla von 3.10 auf 4.0 upgedatet mit deaktiviertem plugin sige free 3.42 und php 7.4. Nach dem update habe ich sige wieder aktiviert. Das plugin geht mit php 7.4 und website ist sufrufbsr. Aber der in joomla 4 enthaltene editor kann keine Beiträge öffnen und bearbeiten. Mit aktiviertem sige und php 8.0 lässt sich im frontend die website nicht mehr aufrufen. Es kpmmt eine Fehlermeldung dass die website nicht aufrufbar ist. Wann kommt eine free Version von sige die joomla 4 tauglich ist wie die kostenpflichtige 4.0 pro version von sige. Das ist die Frage oder soll man auf ein anderes plugin wechseln.