Dateien nach Umbenennung von /contao in /httpdocs nicht mehr änderbar

[Infidel]

Hallo ihr Lieben,

ich habe eine neue Contao Seite in einem Unterverzeichnis als Subdomain aufgebaut und das Ganze dann nach Fertigstellung vom Hoster umstellen lassen. Seit dem habe ich massive Probleme mit der Rechtevergabe (vermute ich). Der Contao Check behauptet, der php Prozess dürfe Dateien erstellen und ändern, tatsächlich geht das jedoch nicht.

Wenn ich z.B. eine bestehende CSS Datei per Contao editiere, wird diese danach nicht mehr geladen. Wenn ich Dateien per FTP hochlade, findet Contao diese nicht (trotz Cache Leerung und Synchro). Ich kann auch keine CSS Dateien importieren.

Das könnte an Benutzerrechten liegen... aber die CSS Files stehen auf 777 und derzeit sogar alle darüber liegenden Ordner.

Hat jemand eine Idee?


LG Fidel

[BugBuster]

Hast du nach der Umstellung die install.php aufgerufen? nach Passworteingabe und Anmeldung wird die pathconfig.php neu geschrieben in der der Pfad angepasst wird.
Ich vermute mal da steht noch der falsche (/contao) drin.

[Infidel]

Hallo BugBuster,

ich habe das gerade eben gemacht. Jetzt bekomme ich bei der Synchro einen Haufen Warnungen:

[function.fopen]: failed to open stream: No such file or directory in system/modules/core/drivers/DC_Folder.php on line 2096

fgets() expects parameter 1 to be resource, boolean given in system/modules/core/drivers/DC_Folder.php on line 2098

fclose() expects parameter 1 to be resource, boolean given in system/modules/core/drivers/DC_Folder.php on line 2132

Warning: Cannot modify header information - headers already sent by...


und so weiter. Glücklicherweise läuft das Frontend noch...

LG Fidel

[do_while]

Auch in der .htaccess könnte noch der alte Pfad drin stehen:

RewriteBase /alterPfad

[BugBuster]

Mir ist noch nicht ganz klar wie die Umstellung erfolgte.
Einerseits schreibst du was von Subdomain, andererseits im Betreff dass das Verzeichnis umbenannt wurde.
Das sind zwei paar Schuhe.

[Infidel]

Hi,

danke für eure Antworten!

Die RewriteBase ist / . Die .htaccess liegt direkt im httpdocs Verzeichnis. Sollte passen, oder?


Was den Umzug angeht: Die Seite war als Subdomain in einem neuen Ordner angelegt. Also: Neuer Ordner auf Ebene des .httpdocs erstellt, Subdomain dafür eingerichtet. Hinterher den Namen der Ordner getauscht/geändert und die Subdomain wieder gelöscht. Ist das nicht üblich?

LG Fidel

[Infidel]

Hat niemand mehr eine Idee?

Ich würde mich freuen...

[BugBuster]

dazu bräuchte man mal eine vollständige Fehlermeldung dmait man sieht, welche Datei nicht gefunden wird/geschrieben werden kann und wer das angefordert hat.

[ciaobello]

Die RewriteBase ist / . Die .htaccess liegt direkt im httpdocs Verzeichnis. Sollte passen, oder?

Nicht wirklich, mach es in ein entsprechendes Unterverzeichnis und lass die Domain da rein Zeigen. Htdocs ist dein Webhosting root, aber nicht zwangsläufig das Webroot der Hauptdomain. So kannst dann auch Domains/Subdomains erstellen welche unabhängig sind von der Hauptdomain sind falls dein Hostingpaket das zulassen sollte.

Was den Umzug angeht: Die Seite war als Subdomain in einem neuen Ordner angelegt. Also: Neuer Ordner auf Ebene des .httpdocs erstellt, Subdomain dafür eingerichtet. Hinterher den Namen der Ordner getauscht/geändert und die Subdomain wieder gelöscht. Ist das nicht üblich?

Das ganze muss ohne löschen und Umbenennen funktionieren. Immer zusätzlicher Unterordner in httpdocs erstellen und Daten dort rein kopieren. Erst wenn alles läuft und auch bei den Domain/Subdomain Einstellungen alles richtig eingetragen ist die alten Daten löschen.

[Spooky]

Nicht wirklich, mach es in ein entsprechendes Unterverzeichnis und lass die Domain da rein Zeigen. Htdocs ist dein Webhosting root, aber nicht zwangsläufig das Webroot der Hauptdomain. So kannst dann auch Domains/Subdomains erstellen welche unabhängig sind von der Hauptdomain sind falls dein Hostingpaket das zulassen sollte.

Nein, das passt schon so. Auf Servern mit Plesk wird das bspw. so gehandhabt. Die Hauptdomain ist by default im httpdocs Ordner, neu angelegte Subdomains (die nicht ein "Alias" der Hauptdomain sind, also Subdomains mit eigenem DocumentRoot) werden auf der selben Ebene der Hauptdomain angelegt, also auf der selben Ebene des httpdocs Ordners. Ist eigentlich auch logisch so . Sonst hätte man ja eine Subdomain mit eigenem DocumentRoot unter Umständen innerhalb des DocumentRoot einer anderen Domain (der Hauptdomain).

[ciaobello]

Das war vielleicht mal so. Ich habe hier ein Plesk 12 installiert. Da wird standardmäßig ein Verzeichnis im Stammverzeichnis erstellt wo die Domain oder Subdomain rein zeigt. Da es die httpdocs von früher noch gibt kann ich das Handhaben wie ich will.

So wie es verschiedene Leute gibt gibt es wohl auch verschiedene Hostings

[Spooky]

Das war vielleicht mal so. Ich habe hier ein Plesk 12 installiert. Da wird standardmäßig ein Verzeichnis im Stammverzeichnis erstellt wo die Domain oder Subdomain rein zeigt.

Ja, eben. Dann war das nicht vielleicht mal so, sondern ist immer noch so . Es gibt ein Verzeichnis für die Subscription (ich denke das meinst du mit Stammverzeichnis), dort hinein kommen dann die Ordner für die jeweiligen Domains (und unter Plesk <= 11.x heißt der Ordner für die Hauptdomain halt by default httpdocs).

[Infidel]

Liebe Profis,

ich schließe daraus, dass die htaccess vermutlich nicht das Problem verursacht?

Hier ist die Error.log:

[17-Feb-2015 16:12:47]
PHP Warning: fopen(/var/www/vhosts/test-haus.de/httpdocs/system/tmp/2827aa8936dc8a49faca5ca5b273d607) [<a href='function.fopen'>function.fopen</a>]: failed to open stream: No such file or directory in /var/www/vhosts/test-haus.de/httpdocs/system/modules/core/drivers/DC_Folder.php on line 2096
#0 [internal function]: __error(2, 'fopen(/var/www/...', '/var/www/vhosts...', 2096, Array)
#1 /var/www/vhosts/test-haus.de/httpdocs/system/modules/core/drivers/DC_Folder.php(2096): fopen('/var/www/vhosts...', 'rb')
#2 /var/www/vhosts/test-haus.de/httpdocs/system/modules/core/classes/Backend.php(568): Contao\DC_Folder->sync()
#3 /var/www/vhosts/test-haus.de/httpdocs/contao/main.php(142): Contao\Backend->getBackendModule('files')
#4 /var/www/vhosts/test-haus.de/httpdocs/contao/main.php(293): Main->run()
#5 {main}

[17-Feb-2015 16:12:47]
PHP Warning: fgets() expects parameter 1 to be resource, boolean given in /var/www/vhosts/test-haus.de/httpdocs/system/modules/core/drivers/DC_Folder.php on line 2098
#0 [internal function]: __error(2, 'fgets() expects...', '/var/www/vhosts...', 2098, Array)
#1 /var/www/vhosts/test-haus.de/httpdocs/system/modules/core/drivers/DC_Folder.php(2098): fgets(false)
#2 /var/www/vhosts/test-haus.de/httpdocs/system/modules/core/classes/Backend.php(568): Contao\DC_Folder->sync()
#3 /var/www/vhosts/test-haus.de/httpdocs/contao/main.php(142): Contao\Backend->getBackendModule('files')
#4 /var/www/vhosts/test-haus.de/httpdocs/contao/main.php(293): Main->run()
#5 {main}

[17-Feb-2015 16:12:47]
PHP Warning: fclose() expects parameter 1 to be resource, boolean given in /var/www/vhosts/test-haus.de/httpdocs/system/modules/core/drivers/DC_Folder.php on line 2132
#0 [internal function]: __error(2, 'fclose() expect...', '/var/www/vhosts...', 2132, Array)
#1 /var/www/vhosts/test-haus.de/httpdocs/system/modules/core/drivers/DC_Folder.php(2132): fclose(false)
#2 /var/www/vhosts/test-haus.de/httpdocs/system/modules/core/classes/Backend.php(568): Contao\DC_Folder->sync()
#3 /var/www/vhosts/test-haus.de/httpdocs/contao/main.php(142): Contao\Backend->getBackendModule('files')
#4 /var/www/vhosts/test-haus.de/httpdocs/contao/main.php(293): Main->run()
#5 {main}

[17-Feb-2015 16:13:23] PHP Fatal error: Uncaught exception 'Exception' with message 'File assets/css/daily.css does not exist' thrown in /var/www/vhosts/test-haus.de/httpdocs/system/modules/core/library/Contao/Combiner.php on line 136
#0 /var/www/vhosts/test-haus.de/httpdocs/system/modules/core/library/Contao/Controller.php(1887): Contao\Combiner->add('assets/css/dail...', '1423838057', 'all')
#1 /var/www/vhosts/test-haus.de/httpdocs/system/modules/core/classes/FrontendTemplate.php(99): Contao\Controller::replaceDynamicScriptTags('<!DOC TYPE html>...')
#2 /var/www/vhosts/test-haus.de/httpdocs/system/modules/core/pages/PageRegular.php(189): Contao\FrontendTemplate->output(true)
#3 /var/www/vhosts/test-haus.de/httpdocs/index.php(263): Contao\PageRegular->generate(Object(Contao\PageModel), true)
#4 /var/www/vhosts/test-haus.de/httpdocs/index.php(447): Index->run()
#5 {main}

[BugBuster]

Prüfe mal die Rechte für das Verzeichnis assets/ bzw. assets/css/ und schaue mal ob es da die gesucht Datei gibt daily.css.

Falls nicht und die Rechte stimmen, mal im Backend eine Systemwartung machen, Punkt "Skriptcache leeren" auswählen dafür.
Dann müsste Contao die internen CSS Dateien neu anlegen und prüfe das dann.
Das sollte auch in System - System-Log protokolliert werden. (Generated style sheet "daily.css")
Ich gehe mal davon aus, dass daily.css eine interne ist.

[Infidel]

Heya,

die Rechte stehen auf 775. Die daily.css war die Datei, die Probleme verursacht hat (ließ sich, wie alle anderen, nicht mehr beschreiben bzw. ließ sich nach versuchter Veränderung auch nicht mehr im Fronend laden). Deswegen habe ich den Inhalt in eine neue CSS kopiert und versucht, diese von Contao erkennen zu lassen. Tut Contao aber nicht, und ich habe X Mal Synchronisiert und Caches geleert.

Temp Dateien löscht Contao offenbar auch nicht mehr!

LG Fidel... und danke für deine Hilfe!

[BugBuster]

Deswegen habe ich den Inhalt in eine neue CSS kopiert und versucht, diese von Contao erkennen zu lassen.

Das bedeutet also die lag vor?
Das kopieren dieser Datei bringt gar nichts!
Dortige CSS Dateien werden im internen CSS Editor definiert und beim Aufruf einer Seite generiert und dort abgelegt. Das können auch mehrere sein.
Damit nun nicht alle einzeln geladen werden müssen werden diese durch den "Combiner" zusammengefasst zu einer. Genau da kam dann die Fehlermeldung, die aber aussagt, die Datei wäre nicht da.

Wenn die deiner Aussage nach vorlag aber nicht gefunden wird, dann stimmt immer noch was nicht mit den Pfad Definitionen.
Daher nochmal gefragt:
* was steht in der system/config/pathconfig.php?
* gibt es in der system/config/localconfig.php eine Eintrag "$GLOBALS['TL_CONFIG']['websitePath']" ? (Darf es nicht mehr geben)
* kannst du im Browser, sofern die daily.css wirklich existiert, folgendes aufrufen: http://deinedomain/assets/css/daily.css

[tab]

Wenn ich mir die Fehlermeldung anschaue, dann stelle ich fest, dass hier eine Datei im temporären Verzeichnis gelesen werden sollte, die nicht existiert. Also konnte sie wahrscheinlich zuvor nicht geschrieben werden. Ist das Verzeichnis "voll"? Oder darf PHP da nicht schreiben und lesen?

Heisst "Namen der Ordner getauscht/geändert", dass das Verzeichnis, auf das die Domain zeigt, nur umbenannt wurde und nicht etwa in Plesk der Ordner für die Domains getauscht wurde? Das habe ich bei 1&1 auch mal gemacht. War dann auch Fiasko, leider weiss ich nicht mehr genau, wie ich das dann gelöst habe, aber vermutlich durch wieder umbenennen auf die ursprünglichen Namen und dann Zuweisung des gewünschten Verzeichnisses an die Domain im DomainCenter.

[Infidel]

Danke für euer Interesse!

Ich habe eben nochmal eine Mail an den Hoster geschickt bzgl. der Umstellung und warte die Infos ab.

Was die CSS Dateien angeht: Die daily.css lag vor, als ich versucht habe, sie per Contao zu editieren. Erst, als dadurch die Seite, auf der diese Datei geladen wird, nicht mehr korrekt angezeigt wurde, habe ich sie irgendwann gelöscht und versucht, die Inhalte als externes STylesheet einzubinden. Contao erkennt aber diese externen Styles nicht und behauptet strikt, die daily.css würde noch existieren - was nicht der Fall ist.

[Infidel]

In der pathconfig steht

<?php

// Relative path to the installation
return '';

In der localconfig steht kein Website path, aber das hier:

$GLOBALS['TL_CONFIG']['ftpPath'] = 'contao/';

Könnte das ein Fehler sein?

Hm... nee, offenbar nicht. Habe den Pfad testweise auf / gesetzt. Anschließende Datenbereinigung hat den Temp nicht geleert (system/tmp: 13156 Datei(en)) und die neuen CSS Dateien wurden bei der Synchro auch nicht gefunden (0 geänderte Dateien).

LG Fidel

[Spooky]

'ftpPath' gehört zum Safe Mode Hack: https://contao.org/en/news/safe-mode-hack.html

[BugBuster]

OK, wenn jetzt der SafeModeHack noch dazu kommt, bin ich raus, das ist mit zur viel Chaos in der Installation.
Bliebe die Frage ob der noch nötig ist. (Sollte der Check beantworten glaube ich, der sollte ja sagen unter welchem Nutzer PHP läuft und unter welchem Nutzer eine PHP Datei als Test angelegt wurde)

[Infidel]

Dazu dieser Eintrag des Checks:

php.ini settings

The PHP safe_mode is not enabled.

Creating a test folder

The test folder could be created (owner: meinuser, chmod: 755).

Creating a test file

The test file could be created (owner: meinuser, chmod: 644).


Trotzdem kann PHP nichts umschreiben... irgendwas stimmt da nicht. In welchem Ordner kreiert der Check denn die Datei/den Ordner?

LG Fidel

[BugBuster]

In welchem Ordner kreiert der Check denn die Datei/den Ordner?

Meines Wissens im Installationsverzeichnis, also eine Ebene höher wie der Check selbst liegt.

Wenn die Contao Dateien den selben Nutzer haben wie der Check anzeigt und der das kann, dann bleib ich dabei, irgendeine Konfiguration der Contao Installation läuft noch daneben.
Wobei mir die Ideen ausgehen, sofern hier alles so ist wie beschrieben.

[Infidel]

Nach wie vor bekomme ich es nicht hin, dass Contao richtig läuft.

Wenn ich nun die Seite als Template exportiere und die Datenbank sichere, kann ich Contao dann neu installieren und hoffen, dass nach einem Re-Import alles wieder läuft?

Oder übersehe ich da was?

LG Fidel

[mlweb]

Das würde ich zur Sicherheit erst mal in einem lokalen Testserver probieren oder wenn eine zweite DB verfügbar ist auf dem Server in einem eigenen Pfad.

[Infidel]

Hey,

die Synchronisation zeigt:

Die Synchronisation wurde abgeschlossen
Ergebnis: 0 neu | 0 geändert | 0 unverändert | 0 verschoben | 0 gelöscht

0 unverändert - da muss doch was mit der Verzeichnisstruktur nicht stimmen? Denn es sind ja Dateien im files Verzeichnis... hat jemand ne Idee wie ich das prüfen kann?

LG Fidel

[Spooky]

Welche Synchronisation meinst du hier?

[Infidel]

Die Contao Datei Synchronisation.

[BugBuster]

Sieht nach der Synchronisation aus im Dateimanager.

Aber was ist denn nun, stimmen die User der Dateien überein mit dem User den der Contao Check ansagt?

[Infidel]

Wie finde ich das heraus? Der Check sagt, es wäre alles ok.

[Infidel]

Ich frage nochmal explizit:

Woran kann es liegen, wenn

a) der Contao Check behauptet, die Dateien und Ordner seien beschreibbar
b) das de facto nicht funktioniert und
c) die Dateisynchronisation gar keine Dateien findet?

Da muss doch ein einfaches Pfadproblem vorliegen. Aber wo kann ich anfangen zu suchen?

LG Fidel

[BugBuster]

Wenn der Contao Check mit "meinuser" die Datei und das Verzeichnis zum Test schreiben konnte, haben die Dateien von Contao den selben Nutzer?

Ist der SafeModeHack von Contao wirklich noch nötig? ( $GLOBALS['TL_CONFIG']['ftpPath'] gesetzt und $GLOBALS['TL_CONFIG']['useFTP'] = true)
Oder anders gefragt, ist "meinuser" identisch mit dem FTP Nutzer und identisch mit der Angabe in $GLOBALS['TL_CONFIG']['ftpUser'] ?

[tab]

Also ich würde erst mal eine Bestandsaufnahme machen. Was steht im Filesystem? Kann ich eine Textdatei per FTP hochladen ins Installationsverzeichnis? Welchem User gehört sie danach und wie sehen die Rechte aus? (Sowas kann man meist übers FTP-Programm feststellen oder per SSH Zugang). Was steht in der Datenbank? Ist tl_files wirklich leer? Was steht in der pathconfig.php, was in der .htaccess als RewriteBase?