Jo. habe ich geändert, bekomme aber beim upload_max_filesize nicht mehr wie 100M eingestellt, also 256M wäre ein Traum
100M für upload_max_filesize und post_max_size sind doch mehr als ausreichend. Die 256M bezogen sich auf das memory_limit. Siehe #2!
Seitdem kann ich keine Updates mehr machen dieser Seite, der Reiter der Komponente ist nicht mehr vorhanden.
Logge dich im Backend ein und rufe anschließend die folgende URL im Browser auf:
http://www.example.com/administrator/index.php?option=com_joomlaupdate
Die Domain musst du natürlich gegen deine Domain austauschen! Vielleicht läuft ja doch noch was übers Backend.
Ansonsten wie erwähnt, korrekt drüberbügeln und DB über's Backend reparieren.
Wenn das alles nicht helfen sollte, spiele deine Sicherung ein, die du hoffentlich vor dem Update-Versuch gemacht hast, und aktualisiere erneut (also ohne diese zu unterbrechen 
).
Haben vorherige Updates bei dieser Seite reibungslos funktioniert?
Mögliche Fehlerquellen:
1. In der configuration.php wurde bei $live_site eine Domain eingetragen. (Leer lassen!)
2. Die Pfade zum /tmp bzw. /administrator/logs-Verzeichnis stehen nicht korrekt in der configuration.php drin oder sind nicht beschreibbar
3. Serverwerte sind unterdimensioniert. Typischerweise: upload_max_filesize (64M), post_max_size (64M), memory_limit (256M)
Die in den Klammern angegebenen Werte sollten auf jeden Fall ausreichend sein.
Geht es um die Hamburger Klassenfahrt? Da ist unten im Beitrag wohl was falsch im Code.
Schau dir mal diesen Link zu Kubrik-Rubik (Simple Image Gallery) genauer an! Da scheint was mit den <p> nicht zu stimmen oder Ähnliches.
Das beeinflusst dann die weitere Darstellung auf der Seite.
Nebenbei: Da wird auf der Webseite auch was über http aufgerufen, was aufgrund von Mixed Content dann nicht geladen wird.
Für MySQL5.7: localhost
Für MySQL8: 127.0.0.1:3307
Damit hatte ich bei noch keiner einzigen J5-Installation Probleme bei diesem Hoster.
Hallo,
ich habe das Problem das ich mich nicht mehr im Administrator einloggen kann.
.....
Gestern Abend ging alles noch Problemlos
Hast du da irgendwas an den Plugins aktiviert oder deaktiviert, die für die Authentifizierung zuständig sind?
Dann über die DB-Tabelle "_extensions" wird zurückstellen!
...es wird nur eine MySQLvorgeschlagen ?
Help !!!
LG Günther
Nimm die, sofern du lediglich den DB-Typ meinst! Bei den Zugangsdaten trägst du dann ja die der Maria-DB ein.
Seit der Umstellung auf Joomla 5.0.2 komme ich nicht mehr in einen Beitrag hinein.
Fehlermeldung: 500 behavior::modal not found.
Was passiert, wenn du nach Erscheinen der Fehlermeldung einfach mal F5 (Seite neu laden) drückst?
Was ich gemacht habe:
1. Die Datenbanktabellen via Export migriert: #_content, #_categories, #_menu, #_assets, #_modules, #_modules_menu und #_user
Bedeutet das, dass du DB-Tabellen aus Joomla 3 in die Datenbank von Joomla 5 importiert hast?
Suche mal nach Ex- und Importtools, die die Inhalte korrekt übernehmen!
Ich kann jetzt nichts mehr machen. Ich kann das Plugin auch nicht deaktivieren, da diese Fehlermeldung sofort wieder angezeigt wird, wenn ich irgendetwas auswähle.
Ich bin totaler Laie, daher würde ich mich freuen, wenn es eine einfache Möglichkeit gibt, den Fehler zu beseitigen.
Nebenbei:
Wenn man ein Plugin im Backend nichts mehr deaktivieren kann, weil man keinen Zugriff mehr hat, dann kann man in die Datenbank gehen (Stichwort: phpmyadmin) und dort in der Tabelle _extensions das gewünschte Plugin suchen und es deaktivieren, indem man "enable" von "1" auf "0" stellt. Dann hat man zumindest wieder Zugriff.
Welche Drittanbieter-Erweiterung nutzt du denn für die Buchung? Wurde die Erweiterung aktualisiert? Ist diese Option mit dem ReCaptcha ev. deaktiviert?
Warum die einst von dir eingetragenen Schlüssel im Plugin nun fehlen, kannst du wahrscheinlich nur selber wissen.
ok aber ich brauche ja nur 2 solange ich die Seite parallel aufbaue? Oder warum hat man bei einem Paket 10 Datenbanken?
....
was heißt denn nur 1 email Postfach? Habe ich dann aber schon mehrere Adressen?
Bei der Verwendung verschiedener Datenbanken lassen sich die Projekte besser voneinander trennen. 1 Datenbank mit verschiedenen Präfixen birgt z.B. die Gefahr, dass man mal eine Datenbank löscht, weil es ein Projekt vielleicht nicht mehr gibt. Anschließend stellt man dann fest, dass man halt nur die Tabellen mit dem einem Präfix innerhalb der DB hätte löschen dürfen.
Und wie viele Email-Adressen möglich sind, muss doch auch irgendwo beim Hoster angegeben sein? Das sind typischerweise deutlich mehr als man benötigt. Die Anzahl der Postfächer ist ein anderes Thema.
Es scheint mit der Kategorie zusammenzuhängen. Sobald ich diese ändere, ist der entsprechende Beitrag aufrufbar.
Die Frage ist jetzt, was ist mit der Kategorie "Wichtige Mitteilungen"? Wir haben da nichts geändert
Das scheint irgendwie auch mit den Menüpunkten zusammenzuhängen. Vorher wurde eine sprechende URL erzeugt, in Verbindung mit der neuen Kategorie nun nicht mehr.
Vorher gab es Fehler bzgl. der Blockade von css-Inhalten (Mime-Type Conflict), nun nicht mehr. Könnte da eventuell das den Menüpunkten zugeordnete Template bzw. der Template-Stil (Helix) eine Rolle spielen? Konnte das nicht weiter untersuchen, da du zeitgleich an der Seite gearbeitet hast.
Vielleicht habt ihr an der Kategorie "Wichtige Mitteilungen" nichts geändert, aber irgendeine Änderung muss es ja gegeben haben, ev. im Template, bei den Menüpunkten, in der .htaccess .....
Es heißt doch überall, dass das migrieren so einfach wäre
Da muss man unterscheiden. Zwischen 3 und 4 ist die Migration beispielsweise aufwendiger als zwischen 4 und 5.
Wenn es um das "nackte" Joomla geht ist das alles recht einfach. Jede eingesetzte Drittanbieter-Erweiterung erhöht den Aufwand.
Wie bereits erwähnt wurde, sind es die Drittanbieter-Erweiterungen, die da für Probleme sorgen können. Manche wurden gar nicht weiterentwickelt und liefern nicht einmal Infos im PreUpdate-Checker. Das könnte zu der Annahme führen, dass alles gut ist.
Andere Drittanbieter-Erweiterungen pflegen ihre Produkte 1a. Da gibt es dann manchmal nur verschiedene Vorgehensweisen bei der Aktualisierung. Man sollte sich also zwingend mit den einzelnen Erweiterungen beschäftigen. Auch spielt hier die PHP-Version eine wichtige Rolle und natürlich ab Joomla5 auch die Datenbank-Version.
Du gibst oben PHP 8.2 für Joomla 3.10 an. Das könnte bereits das erste Problem sein. Die ist einfach zu hoch. Idealerweise nutzt man PHP 7.4 / 8.0 für die Migration. Deshalb sollte man die Migration in einer Testebene durchführen, wo diese techn. Voraussetzungen gegeben sind.
Vielleicht kommen hier noch Hinweise (Crossposting): https://www.joomshaper.com/forum/question/30977
Passen DB und Files zusammen, d.h. wurden sie zum gleichen Zeitpunkt gesichert? NIcht dass das Joomla 4.0 ist und die DB von Joomla 4.2 oder ähnlich.
Problem war das DB-Passwort. Es wurde ein neues PW angelegt und die Seite ist wieder erreichbar.
vielen dank für die ausführliche Antwort. Ich habe aber keine .htaccess Datei im Root Verzeichnis. Kann das sein?
Die .htaccess wird dann benötigt, wenn man dem Server spezielle Anweisungen (z.B. Einstellungen, Weiterleitungen...usw.) geben möchte, oder wenn man in der SEO-Konfiguration im Joomla-Backend den zweiten Haken setzt, sonst funktionieren die Menüpunkte nicht mehr. Es kann also sein, dass du überhaupt keine benötigst.
Da du in den URL noch dieses /index.php/ drinstehen hast, hast du den zweiten Haken nicht gesetzt. Ansonsten würde das verschwinden.
Du musst die .htaccess bearbeiten, sofern du überhaupt eine verwendest! Diese liegt im Joomla-Root-Verzeichnis, also dort , wo auch die htaccess.txt liegt.
Die htaccess.txt ist lediglich eine Textdatei, die keine Beachtung findet. Die .htaccess hingegen wird vom Server abgearbeitet.
Die htaccess.txt wird durch Joomla-Updates automatisch korrigiert. Die .htaccess halt nicht, da man diese je nach Bedarf immer händisch anlegt. Deshalb muss man die selber nachkorrigieren. Und deshalb auch der Hinweis bei den Nachinstallationshinweisen.
Nebenbei: Eine .htaccess wirkt sich im Gegensatz zu php.ini-Dateien auch auf Unterverzeichnisse aus und kann dadurch Einfluss auf darunterliegende Projekte nehmen. Deshalb empfiehlt sich immer, Projekte parallel zu installieren.
Bin dran. DB ist momentan nicht erreichbar.
Das eintragen der DB-Werte in die configuration.php macht dabei Ärger.
In der configuration.php stehen dann die richtigen Werte aber im Backend stehen dann immer noch die alten Werte und schon knallt's.
Die Werte im Backend werden aber doch aus der configuration.php geholt. Wenn die Werte in der configuration.php geändert werden und man sich anschließend im Backend anmeldet, sollten diese auch korrekt angezeigt werden.
