error_reporting habe ich false gesetzt.
Keine Änderung.
Tatsächlich fehlte in $dbtype das i hinter mysql. Dieses habe ich hinzugefügt. Ebenfalls keine Änderung.
Siehe auch mein Edit oben. Soll ich mal ein DB Update z. B. auf Anfang Oktober machen, oder mache ich damit noch mehr kaputt?
Das sieht schwer nach einem Datenbank-Fehler aus.
Sind die DB-Zugangsdaten in der configuration.php alle korrekt eingetragen?
Hab ich gerade nochmal kontrolliert. Zugangsdaten DB sind in der configuration.php korrekt.
Edit: Ich könnte mal über meinen Hoster ein Datenbank-Backup von Anfang Oktober ziehen. Ich weiß, dass es zu dem Zeitpunkt noch gelaufen ist. Zumindest kam ich da auch noch in das Backend um Aktualisierungen vorzunehmen.
Bitte beachtet, dass die Site eigentlich noch im Offline-Modus wäre.
Ansonsten, ich weiß ehrlich gesagt nicht, ob ein Backup existiert. Normalerweise arbeite ich mit Akeeba, aber ich bin mit nicht sicher, ob ich Akeeba auch für diese Site genutzt habe, da ich längere Zeit an der Site nicht gearbeitet hatte.
Hallo zusammen,
ich habe aktuell ein Problem. Eine meiner Sites ist offensichtlich komplett im Eimer. Weder das Front- noch das Backend ist aufrufbar.
Im Backend:
ZitatFailed to start the session because headers have already been sent by "/.../.../.../.../.../libraries/vendor/joomla/database/src/Mysql/MysqlDriver.php" at line 121.
Im Frontend:
ZitatAttempted to load class "Framework" from namespace "Astroid".
Did you forget a "use" statement for another namespace?
Was kann ich ggfs. noch tun. Habe mal versucht, die aktuelle Joomla 4.4.0. per ftp drüber zu installieren. Da ich auf das Backend nicht drauf komme, kann ich auch Astroid nicht per Backend neu installieren.
Ich nutze PHP 8.2
Bin gerade etwas ratlos und wäre über Hilfe dankbar.
Beste Grüße
Sven
Mit Aktivierung der htaccess ist das Problem nun behoben...
Zwischenmeldung:
Das Problem "Sourcerer" war tatsächlich kein Problem "Sourcerer", sondern ein Tippfehler bei der Datenbankverbindung. Das ist also behoben.
Es bleibt allerdings das Backend-Problem, welches "crashed", sobald ich den Debug-Modus ausschalte.
F12 gibt im Backend unter Konsole das aus:
Zitat[Intervention]Images loaded lazily and replaced with placeholders. Load events are deferred. See https://go.microsoft.com/fwlink/?linkid=2048113
index.php:1 [DOM] Multiple forms should be contained in their own form elements; break up complex forms into ones that represent a single action: (More info: https://www.chromium.org/devel…te-amazing-password-forms) <form action="/administrator/index.php?option=com_config" id="application-form" method="post" name="adminForm" class="main-card form-validate">…</form>
Unter Probleme bekomme ich das:
Zitat
- Audit usage of navigator.userAgent, navigator.appVersion, and navigator.platform Warnung
- A page or script is accessing at least one of
navigator.userAgent,navigator.appVersion, andnavigator.platform. Starting in Chrome 101, the amount of information available in the User Agent string will be reduced.To fix this issue, replace the usage of
navigator.userAgent,navigator.appVersion, andnavigator.platformwith feature detection, progressive enhancement, or migrate tonavigator.userAgentData.Note that for performance reasons, only the first access to one of the properties is shown.
- BETROFFENE RESSOURCEN
- 1 source
hotkeys.min.js:1
Wenn das so ist, wird es natürlich schwierig zu helfen, da niemand deinen Code kennt.
Bzgl. zerschossenem Backend musst du weiter analysieren mit F12!
Inzwischen habe ich festgestellt, dass bei Alfahosting MySQL Version 5.7.25 zur Verfügung steht, bei IONOS hingegen MySQL 8. Ich habe nun nicht wirklich eine Ahnung, in wie weit sich das auf meine Probleme auswirkt.
F12 hat übrigens nichts sonderbares ausgespuckt.
Alles anzeigenHast du die letzte Version vom Sourcerer? 10.0.0
Da wurde wohl einiges geändert, insbesondere in Hinblick auf PHP 8.1.
Eventuell den Sourcerer testweise mal deaktivieren.
Je nachdem, ob du das Error-Reporting aktiviert oder deaktiviert hast, werden verschiedene Dateien zur Darstellung verwendet.
Zwischen den beiden Hostern bestehen auch einige Unterschiede. Beispielsweise muss bei Ionos das RewrtiteBase / ohne # drinstehen in der .htaccess drinstehen (falls verwendet).
Ja, Sourcerer Version 10.0.0.
Hab den schon deaktiviert. Wenn deaktiviert, läuft das Frontend auch, natürlich ohne meinen Code auszuführen. Die Probleme kommen offensichtlich aus meinem Code (Vermutlich Abfragen), wobei ich noch nicht weiß, was sich genau von 8.0 auf 8.1 geändert hat und wo ich im Code ansetzen muss.
.htaccess habe ich im Monent gar nicht in Verwendung. Das mit dem RewriteBase wusste ich schon, aber wie gesagt, die htaccess ist als text datei auf dem Server und derzeit noch nicht in Verwendung. Daran kann es also eigentlich nicht liegen.
Hallo zusammen,
nach einem Umzug von Alfahosting zu IONOS habe ich 2 Probleme, die aktuell auftreten:
1. Das Backend zerschießt, sobald ich den Debug-Modus ausschalte und Error Reporting auf None setze. Schalte ich beides wieder ein (Error Reporting auf Maximum), ist das Backend wieder vollständig in Ordnung. Das Backend läuft zwar soweit funktionell ohne Debug-Modus, es sieht nur komplett zerschossen aus. Eine Fehlermeldung wird mir aber im Backend nicht ausgegeben. Ich wüsste aktuell auch kein Plugin, welches ich noch deaktivieren könnte. htaccess ist deaktiviert. Die Pfade zu den Templates sind in der configuration.php auch korrekt. $live_site ist leer, $cookie_domain und $cookie_path sind ebenfalls leer. Bin gerade ratlos, woran das liegen könnte. Jemand eine Idee?
2. Ich nutze in Joomla "Sourcerer" von Regular Labs. Dieses macht offensichtlich Probleme unter PHP 8.1, zumindest bekomme ich Fehlermeldungen im Frontend: "ERROR 2002 - SQLSTATE[HY000] [2002] No such file or directory in... "
Ich vermute, dass etwas an meinen Abfragen nicht mehr konform mit PHP 8.1 ist, was unter 8.0 noch funktionierte. Zumindest wird mir im Call Stack unter function "PDO->construct()" angezeigt, was vermutlich den Hinweis auf ein Problem mit der Datenbank gibt. Hat jemand einen Hinweis für mich, wo ich zur Fehlerbehebung ansetzen muss bzw. könnte?
Besten Dank für den Support.
Ohne kann es dir passieren, dass die Beiträge noch nicht mal im Backend zu sehen sind, weil Assets die Rechte zum Beitrag sind. Deshalb empfiehlt es sich eigentlich auch, zum Erstellen von Beiträgen auf Joomla-Bibliotheken bzw -Models zurückzugreifen (seve()-Methoden), die das Anlegen der Assets-Einträge gleich miterledigen, ohne, dass man irgendwas vorgeben muss.
Vielen Dank für die Info. Eine solche Antwort habe ich befürchtet.
Hast du da irgendwas, wo ich mich diesbezüglich einlesen kann, um zu sehen, wie genau das mit den Joomla-Bibliotheken bzw. Models funktioniert?
Ich möchte mit Daten, die in ein Frontend-Formular eingegeben werden, Beiträge erstellen und diese Beiträge letztlich im Frontend ausgeben.
Hallöchen,
kurze Frage an die Entwickler-Profis unter euch.
In der Tabelle #_content gibt es eine Spalte "asset_id".
Welchen Zweck hat diese Spalte.
Wenn ich manuell per PHP Skript Beitrage in der Tabelle speichere, muss ich zwingend Werte in dieser Spalte setzen bzw. was passiert, wenn ich beim speichern neuer Beiträge eine 0 setze?
Ich habe schon gesehen, dass der Wert aus der Tabelle #_assets kommt und die ID aus #_assets darstellt. Muss ich zwingend auch einen Eintrag in #_assets vornehmen, wenn ich Beiträge speichern will?
Vielen Dank für eine kurze antwort.
Übrigens in deinem post#17 ist in der Zeile 9 von dir wohl versehentlich $hostlocal anstatt $host wie in der Zeile 4 verwendet worden.
korrekt. Das passiert, wenn man nicht ordnungsgemäß mit Copy Paste arbeitet. 
Danke für den Hinweis. Ich kann es leider nicht mehr updaten/korrigieren.
Sieger66 vielen Dank für den vielen Support.
Habe es nun gelöst bekommen.
Für die Nachwelt, die Lösung sieht wie folgt aus:
use Joomla\CMS\Factory;
$conf = Factory::getApplication()->getConfig();
$host = $conf->get('host');
$db = $conf->get('db');
$user_db = $conf->get('user');
$password_db = $conf->get('password');
$pdo = new PDO('mysql:host='.$hostlocal.';dbname='.$db.';charset=UTF8', $user_db, $password_db);Ich wusste leider nicht, mit welchem identifier man das charset mittels $conf->get ausliest, sonst hätte ich das auch noch gemacht. So funktioniert es aber nun zumindest.
Eleganter wäre nach wie vor, eine etwaig vorhandene Datenbankverbindung zu nutzen. Dazu hätte ich aber nun sämtliche Abfragen umschreiben müssen. Dazu hatte ich keine Lust. Das werde ich aber noch nachholen.
Herzlichen Dank!
Sieger66 , vielen Dank! Das hat bereits sehr geholfen, wobei ich auch selbst bereits einen dummen Fehler begannen hatte, auf den ich auch hätte selbst kommen können... Aktuell läuft die Verbindung aber noch nicht. Meine Zeilen sehen nun so aus:
use Joomla\CMS\Factory;
$conf = Factory::getApplication()->getConfig();
$host = $conf->get('host');
$db = $conf->get('db');
$user_db = $conf->get('user');
$password_db = $conf->get('password');
$pdo = new PDO('mysql:host=$host;dbname=$db;charset=UTF8', '$user_db', '$password_db');Fehlermeldung:
Die Variablen $host, $db, $user_db und $password_db habe ich testweise einmal ausgegeben, um zu schauen, ob die korrekten Daten gezogen und ausgegeben werden. Das war der Fall. Die Variablen sind also korrekt "befüllt".
Nicht mein Fachgebiet. Deshalb nur so eine Idee. Ist das überhaupt nötig? Eine DB-Verbindung besteht doch bereits- Der Beitrag wird doch selber auch schon aus der DB abgerufen.
Oder sollte es um eine externe DB gehen?
Oder möchtest du die Zugangsdaten für eine externe DB in einer Tabelle in der Joomla-DB hinterlegen?
Das ist ja eigentlich genau das, was ich am liebsten wollte. Ich dachte mir auch, dass eine DB-Verbindung bereits bestehen muss. Aber wie greife ich auf die DB-Verbindung innerhalb meiner SELECT-Abfragen zu? Ich muss Tabellen innerhalb der Joomla-DB abfragen, also nix externes... Erleuchtung gerne erwünscht.
Beispiel einer Abfrage:
$query = "SELECT Spalte FROM Joomla-Tabelle-X GROUP BY Spalte";
foreach ($pdo->query($query) as $row)
{
...
}$pdo war die Datenbankverbindung...
Danke für deine Hilfe, Sieger66,
ich komme aber noch nicht ganz klar.
Wie muss ich die Options abrufen und einbauen?
Habe mehrere Dinge versucht, funkt aber nicht. Aktuell stehe ich bei diesem Versuch:
use Joomla\CMS\Factory;
Factory::getApplication->getConfig();
$pdo = new PDO('mysql:host=$conf->get($host);dbname=$conf->get($db);charset=UTF8', $conf->get($user), $conf->get($password));Nicht lachen, wird grundfalsch sein, nicht umsonst erhalte ich eine Fehlermeldung. Aber das ist mir aktuell vom Verständnis her noch zu hoch.
Okay, ich frage mal anders.
Wie kann ich $db, $user und $password für die Datenbank-Connection aus der configuration.php in Joomla 4 innerhalb eines Beitrages abrufen und nutzen?
Keine Ahnung. Ob dieser Thread ev. passt?
Wenn nicht, kommt ev. Korrektur von den Experten.
Liebe Grüße
Christine
Vielen Dank, Christine,
Das hat mir aber mit meiner Frage nicht so richtig geholfen.
Mir geht es tatsächlich nur um die Herstellung der Datenbankverbindung. Ich möchte die Verbindung nicht händisch herstellen, sondern auf die Daten der Joomla Installation zurückgreifen. Das ist auch möglich. Ich fürchte nur, dass ich dann alle meine Abfragen, Inserts und Updates ändern muss und ich wollte zunächst einmal fragen, ob es noch eine andere Lösung gibt.
Hallo zusammen,
ich habe mal eine Frage. Ich arbeite oftmals mit eigenen PHP Skripten, die ich in Beiträgen einsetze. Als Extension nutze ich dazu "Sourcerer".
Bisher habe ich nun immer eine Datenhbankverbindung händisch hergestellt. Das sah dann so aus:
$pdo = new PDO('mysql:host=localhost;dbname=***;charset=UTF8', '***benutzername***', '***passwort***');
Anschließend ziehe ich mir dann z. B. Daten über klassische SELECT Abfragen.
Jetzt frage ich mich, ob es eine Möglichkeit gibt
$db = JFactory::getDbo();für die Datenbankverbindung zu verwenden, ohne dass ich nun alle Abfragen nach Joomla-Handbuch umbauen müsste? Mir geht es also nur darum, für meine Abfragen die Datenbankverbindung herzustellen mit Hilfe der in Joomla hinterlegten Daten. Geht sowas?
Kann hier zu. Problem gelöst
Versuche mal eine andere Datei hochzuladen, z.B. ein Bild! Vielleicht ist doch einfach nur der Webspace voll.
Ist dein FTP-Programm aktuell und funktionsfähig?
Ich brech zusammen. Das scheint es gewesen zu sein.
Leider kann ich derzeit nicht sehen, vieviel Speicher ich tatsächlich beim Hoster liegen habe.
Laut Tarif müssten 300GB zur Verfügung stehen. Daher bin ich auch überhaupt nicht auf die Idee gekommen, dass es der Webspace sein könnte.
Heute abend werde ich mich mal mit Filezille draufschalten und mir das mal anschauen. Mit dem ftp von Alfahosting sieht man leider nicht, wieviel Speicher aktuell drauf liegt. Aber ich habe gerade mal eine größere nicht mehr benötigte Datei gelöscht. Seitdem funktioniert nun wieder alles...