Einen Call Stack aus #2 sehe ich nicht.
Was ich auch nicht verstehe, das der Hoster local ist.
ICH würde jetzt das Backup einspielen ( auch wenn es verboten ist).
Dann ggf. die Seite lokal mit Xampp zum laufen bringen und die Fehler lokalisieren.
Einen Call Stack aus #2 sehe ich nicht.
Was ich auch nicht verstehe, das der Hoster local ist.
ICH würde jetzt das Backup einspielen ( auch wenn es verboten ist).
Dann ggf. die Seite lokal mit Xampp zum laufen bringen und die Fehler lokalisieren.
Ende September 2023, war im Quelltext gut erkennbar dass Helix Ultimate benutzt wurde.
In #15 lese ich etwas von "Restore durchgeführt"
Wenn der TE da etwas unüberlegtes getan hat, ist die Seite möglicherweise klinisch tot.
zu #20
Nutzt du AdminTools?
- Nein, keine Admin-Tools
Was wurde an der Seite geändert, kurz bevor der Fehler aus #1 aufgetreten ist? (auch Änderungen auf dem Server)
- Es wurde seit Monaten nichts mehr geändert
Kann es sein, dass die Webseite ein Mix verschiedener Joomla-Versionen ist?
- Nein, kein Mix
Wurde ev. mal ein Backup in ein Verzeichnis eingespielt, welches nicht leer war?
- Nein, wurde nicht gemacht; immer aus dem Backend heraus
zu #21
Ich weiß nicht, wie lang die Seite schon spinnt.
Vermutlich derzeit nicht aktuell.
zu #24
Habe mich unklar ausgedrückt.
Ich führte mittels Akeeba Kickstart einen Restore durch.
Danach kamen die beiden Fehlermeldungen für Backend und Frontend.
Ein Zugang zur Seite ist nicht mehr möglich.
Wer bitte ist "TE"?
zu #22
Die Seite wird von STRATO gehostet.
Derzeitige Version: 8.1
Call-Stack:
die oberste Zeile steht in Beitrag #11
TE = Thread Eröffner. Und wenn einen Backup restoren musst, geht das nur schmerzlos, wenn du erst das ganze Joomlaroot-Verzeichnis löschst und die Datenbank auch. Sonst gibt es Probleme, wie du sie jetzt hast. Meine 2 Cent.
Wichtig ist, dass vor einem Restore die DB und der Webspace gelöscht wird (wurde).
TE ist 'Thread Ersteller', also du!
BTW:
Wenn nur Strato das Backup hat, würde ich es dringend lokal speichern.
M.E. wird bei Strato nach 7 Tagen das Backup überschrieben!
Wer bitte ist "TE"?
Das bist Du, denn es ist die Abkürzung für ThemenErsteller*in.
Ich vermute du hast die Datenbank vor dem Restore mit Kickstart nicht geleert?
Brauche ich jetzt nur mehr kurz bestätigen: #29-32
Call-Stack:
die oberste Zeile steht in Beitrag #11
da stehen ev. oder sicher sogar noch mehr Zeilen?
Liebe Grüße
Christine
ZitatCall-Stack:
die oberste Zeile steht in Beitrag #11
Hinweis dazu gab es in #6.
Da wir aber nicht wissen:
Ich weiß, dasss die Updates nicht up to date sind, Aktualisierung geht aber aus o.g. Gründen nicht.
Kann es auch alles sein!
Ich werde noch einmal einen Restore versuchen.
Dazu
- LEERE ich die Datenbank
- LÖSCHE ich den Webspace oder benenne ihn um
- danach führe ich mit Kickstart den Restore aus
Ist das richtig so?
Ja, korrekt!
Nur das Verzeichnis musst du nicht umbenennen.
Ja, korrekt!
Nur das Verzeichnis musst du nicht umbenennen.
Aber leerfegen ...
Dann benenne ich's doch einfach um und spar' mir die Kehrarbeit, oddr?
Bin jetzt auch verwirrt. Weiß nicht mehr, was aktuell wo ist.
Mein Vorschlag:
- DB löschen
- Webspace löschen
Backup einspielen.
Hostest ja lokal.
Sollte da keine Probleme geben, mit der Backupdatei.
Genau so habe ich es für morgen geplant.
Aber was meinst du mit "Hostest ja lokal."?
Muss bei der ganzen Geschichte die PHP-Version beachtet werden?
Genau so habe ich es für morgen geplant.
Aber was meinst du mit "Hostest ja lokal."?
Muss bei der ganzen Geschichte die PHP-Version beachtet werden?
Die Seite ist doch online !
Und das Hosting ist Strato ! Nicht Local !
Aber was meinst du mit "Hostest ja lokal."
Ein ganz großes Dankeschön an alle Helfer und ganz besonders für die unendliche Geduld, die ihr mit mir hattet.
PS:
Warum die Seite jetzt wieder online ist?
Ich wars nicht!
Warum ist der Zugriff auf die joomla.xml nicht möglich (403)?
Die MIME-TYP-Konflikte sind aber jetzt behoben.
Achte darauf, dass beispielsweise ein Optimierungstools die .htaccess ändern könnte. NIcht, dass das Problem bald wieder vorhanden ist.
Nebenbei: In der robots.txt steht noch ein falscher Sitemap-Link zu OSMap (404).
Warum ist der Zugriff auf die joomla.xml nicht möglich (403)?
Achte darauf, dass beispielsweise ein Optimierungstools die .htaccess ändern könnte. NIcht, dass das Problem bald wieder vorhanden ist.
Danke für deine Hinweise, JoomlaWunder.
(403)-Fehler: Ich finde auf der Seite 9 "joomla.xml"-Dateien - alle ausnahmslos mit Lese- und Schreibrechten (rw)
.htacess: Soll ich der Datei die Schreibrechte entziehen oder gibt es eine andere Möglichkeit zu deren Schutz?
Herzliche Grüße
Reinhard