Hallo wie werde ich die Wartungsseite wieder los?
Denke alle Pfade und DB angepasst zu haben auch ein ‘composer dump-autoload’ via ssh brachte keine Verbesserung.
mit der wartungsseite hast du auch ein errorlog das wird dir weiterhelfen.
du findest es im verzeichnis log
thx du meinst unter …/source/log oder ?
Falls ja, hier habe ich keine error.log nur eine oxideshop.log mit null Byte und no_dhl…'s.logs
Oft sind fehlende Schreibrechte auf Verzeichnisse die Ursache (z.B. source/tmp).
Frohe Weihnachtszeit. …/source/tmp hat 755.
Gibt es irgendwo eine Schreibrechteübersicht, damit ich da nachschauen kann?
In der Installationsdokumentation:
https://docs.oxid-esales.com/developer/en/6.1/getting_started/installation/eshop_installation.html
thx, habe die Rechte entsprechend den docs angepasst, leider weiterhin Wartungsseite, Habe nun auch eine error.log, aber Inhalt ist eine Warnung: PHP Warning: file_put_contents.
Noch weitere Ideen?
Hallo,
Das Problem ist vielleicht ganz simpel zu lösen.
Schau mal unter Stammdaten → Grundeinstellungen → Stamm ob der Haken bei Aktiv gesetzt ist.
Oder auf der Konsole nach einander ausführen:
rm -rf source/tmp/*
vendor/bin/oe-eshop-db_views_regenerate
thx, via Konsole geht’s nur, das erste tmp löschen hat funktiniert, der zweite Befehl allerdings mit
$ vendor/bin/oe-eshop-db_views_regenerate
There was an error while regenerating the views. Please look at `oxideshop.log` for more details.
und in der oxideshop.log
[27 Dec 20:10:40.584965 2024] [uncaught error] [type E_ERROR] [file ../vendor/oxid-esales/oxideshop-ce/source/Core/Database/Adapter/Doctrine/Database.php] [line 955] [code ] [message Uncaught PDOException: SQLSTATE[42000]: Syntax error or access violation: 1305 FUNCTION DECODE does not exist in ../vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOStatement.php:117
Versuch mal:
vendor/bin/oe-eshop-db_views_generate
oder
php vendor/bin/oe-eshop-db_views_generate
von was für einer OXID 6 Version reden wird überhaupt?
Php Version und Datenbank Version wäre auch interressant zu wissen.
Ansonsten gäbe es noch die Möglichkeit in der confic.inc.php
die Stelle zu suchen
// Enable temporarily in case you can’t access the backend due to broken views
$this->blSkipViewUsage = false;
und auf true ändern (Schreibschutz der Datei per FTP auf 777 ändern).
Dann solltest du wieder ins Backend kommen und dort unter system → Tools → Views updaten den Cache erneuern können.
thx, habe oxid verion 6.5.x und php 8.1.
Leider komme ich mit beiden Vorschlägen nicht weiter. Beim ersten:
$ vendor/bin/oe-eshop-db_views_generate
There was an error while regenerating the views. Please look at `oxideshop.log` for more details.
Beim zweiten trotz true und 777 weiterhin Wartungsseite
Empfehlung was ich zuerst bei einem Serverumzug tun würde:
Prüfen ob Systemvoraussetzungen erfüllt Server, Composer, PHP und Datenbank ggfs. vorab Neuinstallation über Browser GUI testen ob alles grün
Hallo corel,
ich würde das auch vorschlagen, teste erst einmal ob sich OXID 6.5 mit Demodaten installieren lässt.
Also zurück auf Anfang.
1 Like
thx ok heute versuchte ich mal mein Glück aber mit Version 7.x, bzw erzeugt ein Projekt und startete das Setup mit dem Ergebnis:
hänge an den url &istep=200 dann sollte es weitergehen
das hat funktioniert habe …/setup?istep=200 angehängt, thx
Frontend wird Wartungsseite angezeigt
Backend Login erhalte ich
danach wieder beim Login, also Schleife.
theme im backend aktvieren, ansonsten fehlerlog lesen
ok, habe jetzt in der config.inc.php unter $this->sShopURL = 'http:… https… gemacht und schon ging das Backend auf nur hier habe ich dann gleich eine bereits bekannte Meldung unter Systemgesundheitsprüfung
OXID 7 und der bekloppte Bug ist immer noch da.
Irgendwo hatte ich sogar diese Konfiguration gefunden
return (ini_get(‘session.name’) === ‘sid’ || @ini_set(‘session.name’, ‘sid’) !== false) ? 2 : 0;
Da wird ini_set sogar grün.