Pfadprobleme der startup.php

[Seperion]

Aufgrund der vorhandenen Serverkonfigurationen bei Quell und Zielserver musste ich bei dem Umzug einer Webseite auch gleichzeitig ein Update durchführen.
Die Webseite besitzt 2 Mandanten, jeweils im root Verzeichnis.
Der Erste Mandant ist irrelevant und funktioniert bedauerlicherweise.
Ganz im Gegansatz zum zweiten Mandanten.
Ich erhalte die Fehlermeldung das die Datei "startup.php" aus dem pfad "./web/includes/" nicht includiert werden konnte. Die Datei jedoch liegt unter "./web/contenido/includes/". Dementsprechend habe ich irgendwo ein Pfadproblem.
Ich habe jedoch sämtliche Dateien mit der Suche misshandelt, ohne Erfolg.

Bin am Verzweifeln, finde nicht wo ich noch was ändern könnte.
Hoffe irgendjemand kann sich einen Reim darauf machen.

Ach ja... der fehler tritt in der Datei "/cms/front_content.php" Zeile 19 auf.

Danke im Vorraus.

Edit: Noch etwas was vielleicht bei der Lösungsfindung hilft. Sobald ich den Pfad in der Datei "/web/cms/config.php" von "/home/.sites/..../web/" auf "/home/.sites/..../web/contenido/" ändere, bekomme ich eine Fehlermeldung "Illegal Call" statt der bisherigen include-Fehlermeldung. mfg

[Seperion]

Endlich!!!
Ich habe das Problem selber lösen können.
Hier die Lösung:

nach der Pfadänderung habe ich ja nurnoch die meldung "Illegal Call" erhalten.
nach ein Paar Tests konnte ich auch den Ursprung dieser Meldung ermitteln.
Wie nicht anderst zu erwarten befand sich dieser in der "/web/contenido/includes/startup.php"
Dort habe ich den folgenden Block

Code: Alles auswählen

if (!defined('CON_FRAMEWORK')) {
    die('Illegal call');
}

auskommentiert und gegen den Block

Code: Alles auswählen

if (!defined("CON_FRAMEWORK")) {
    define("CON_FRAMEWORK", true);
}

ausgetauscht.

Nicht schön, aber selten.
Leichte bedenken habe ich schon bei einem solchen Eingriff in ein bestehendes System, ist jedoch scheinbar notwendig.

Hoffe ich konnte anderen damit helfen,
dieser beitrag wäre damit geschlossen!


Edit: würd den Beitrag ja selbst schließen, finds aber net. Daher: Moderatoren.... wenn ich bitten dürfte?

[Dodger77]

Mal eine kurze Frage vor dem Schließen, da die vorgenommene Änderung so nicht sinnvoll sein dürfte: wurden bei dem Update auch die Dateien aus dem Mandantenordner ("cms") auf den neuen Stand gebracht?

[Seperion]

Ich habe sowohl den Installationspunkt "Update" und "Migration" (im Laufe der Problemsuche) mehrmals ausgeführt.
Ansonsten sind nur die oben beschriebenen Änderungen geschehen. (Ausgenommen vielleicht dem ändern des Adminpassworts über die Datenbank)

Warum das Problem auftrat, oder wieso die Lösung geholfen hat, kann ich leider nicht nachvollziehen.
Solange es läuft, ist's aber in Ordnung.
Sobald der Kunde ein Redesign seiner Webseite wünscht wird sowieso auf ein anderes System Umgeschwenkt.
Ein System für das wir einen geschulten Mitarbeiter besitzten und Probleme dementsprechend nicht mehr an mir hängen bleiben.

[Oldperl]

Ein System für das wir einen geschulten Mitarbeiter besitzten und Probleme dementsprechend nicht mehr an mir hängen bleiben.

Na dann wollen wir mal hoffen, daß das System bis dahin ohne Hackerangriff läuft.

Tauscht man nämlich die alten Coredateien im Mandantenverzeichnis nicht ebenfalls aus bei einem Update/Upgrade, so wie hier offensichtlich geschehen, können selbstverständlich sicherheitsrelevante Änderungen nicht greifen. Ändert man dann noch dazu andere neue Coredateien, weil die alten, eben wegen solcher sicherheitsrelevanten neuen Funktionen, nicht mehr funktionieren, öffnet man eventuell noch größere Einfalltore dabei.

Und zum mehrmaligen Aufruf des Setup noch kurz...
Das Setup prüft nicht auf den Austausch von Coredateien im Mandanten. Dieses muss man von Hand machen. Eine Prüfung durch das Setup ist auch schwierig, da bei einem Webauftritt, anders wie bei einer Software auf dem PC, nicht alle möglichen (und unmöglichen) Konstellationen sicher voraussehbar/planbar sind, geschweige denn alle möglichen Situationen per PHP prüfbar sind.

Gruß aus Franken

Ortwin