Hallo, vorab: mein Shop läuft in einem Unterverzeichnis. Seit dem Update auf die 4.2.x muss ich täglich die logs-Datei von chmod 700 auf chmod 777 setzen (unterordner/logs). Ich erhalte regelmäßig die Fehlermeldung, dass diese Datei nicht beschreibbar ist. Weiter arbeiten kann ich dann im Adminbereich nicht. Da ich im Hauptverzeichnis ebenfalls eine logs-Datei habe, nehme ich mal an, dass sich da was in die Quere kommt. Ich würde ja gern die Besitzrechte dieser Datei entsprechend korrigieren, nur diese Datei wird mir seitens all-inkl. nicht angezeigt. Was kann ich also tun, damit dieser Wert bestehen bleibt. Hat jemand einen Rat. Perfekt wäre es natürlich, wenn shopware diese Datei anders benenne würde…
Hallo, in der Vergangenheit gab es hier bereits einen Fall, dass der Server das eigene “log” auch in diesem Ordner abgespeichert hat und dementsprechend die Besitzrechte regelmäßig geändert hat. Hier hat es ausgereicht das Log-Level des Servers zu verändern, sodass dieser nur im Root-Verzeichnis des Servers die Log-Dateien ablegt und nicht in jedem Unterordner. Damals hat der Kunde von allinkl. folgende Antwort bekommen: [quote]Wenn Sie im KAS “https://kas.all-inkl.com/” unter Domain - bearbeiten, die Statistik auf kompakt stellen, werden die Logdateien im ordner logs im Rootverzeichnis geschrieben. Steht die Statistik auf detailiert oder erweitert, wird in den Unterordner/logs die Logdateien erstellt. [/quote] Eventuell hilft dir das ja schon weiter! Grüße Moritz
2 „Gefällt mir“
Der Tipp hat mir auch sehr gut geholfen
Danke, der Tipp half :thumbup:
Hallo, ich stehe vor dem Problem, dass ich die Shopware NICHT in einem Untervereichnis, sonderm im Root installiert habe und dort nun eben besagtes Problem mit dem logs Verzeichnis auftritt, dass sich einmal am Tag auf CHMOD 700 zurücksetzt. Ändern kann und will all-inkl.com das nicht, habe schon den Support kontaktiert. Als Alternative zum verschieben in ein Unterverzeichnis (was ich echt nicht will) haben sie mir folgenden Vorschlag gemacht, was haltet ihr davon: -------- Es gibt zwei Lösungswege. Zum einen die, wie schon geschrieben. Der Shop liegt in einem Unterordner und ein eigener Ordner logs liegt im Unterordner. Die zweite Möglichkeit ist, Sie lassen auf dem FTP alles so wie es jetzt ist und erstellen einen neuen eigenen Ordner in der root in welchen Shopware die Files ablegen kann. Diesen können Sie an sich benennen wie Sie wollen. Nun müssen Sie Shopware noch den neuen Ordner bekannt geben. Dazu gehen Sie bitte in die /engine/Shopware/Kernel.php. Am besten im Web-FTP. Dort tragen Sie den Ordner in der Zeile 388 statt dem Eintrag logs den neuen Ordnernamen ein. Nun sollte Shopware keine Fehler mehr ausgeben. -------- Die Kernel.php umbiegen ist natürlich ne Holzhammer-Methode. Aber wenn man nicht den ganzen Shop in ein Unterverzeichnis umziehen will (hab ihn erst vor 3 Tagen aus dem Test-Verzeichnis in die Produktivumgebung gezogen), bleibt einem wohl nichts anderes übrig? Lässt sich so eine Änderung Update-sicher gestalten? Oder noch besser: besteht die Möglichkeit, dass es von Shopware ein Update gibt, das bei der Installation schon fragt in welchem Verzeichnis die Shopware ihre Logs ablegen soll. Dass ein “logs” Verzeichnis bereits auf einem Server existiert ist ja nun auch nicht so ungewöhnlich. Konflikte sind da ja quasi vorprogrammiert, wenn man keine Chance hat, die Shopware-Logs in ein anderes Verzeichnis schreiben zu lassen.
Hallo, das kann viele Probleme und Seiteneffekte geben. Daher haben wir den Ordner absichtlich fest definiert und nicht änderbar gemacht. Das sind elementare Dinge, genau wie z.B. /cache Grundsätzlich gilt, dass bei einer Shopware Installation keinerlei andere Dateien oder Ordner drin liegen sollten. Das kann immer Probleme geben und sollte strikt getrennt werden. Mit der Lösung die Installation in einen Ordner zu schieben war auch gemeint, dass die Domain dann darauf geroutet wird. So haben es einige andere auch gemacht. Du hast dann ja kein Ordner sichtbar. Alles andere ist so nicht oder nicht sauber möglich. Wie geschrieben sollte da nichts fremdes mit drin liegen und Shopware eine saubere Umgebung haben ohne andere Skripte, Ordner oder Dateien - alleine schon aufgrund der Übersichtlichkeit Sebastian
Wenn schon fix hardgecodet, wieso hat man nicht einen Verzeichnisnamen gewählt, der etwas weniger allgemein ist als “logs”? Wie gesagt, dass auf (Web-)Servern bereits Log-Verzeichnisse vorhanden sind, ist ja nun nicht die große Überraschung. Wie wäre es mit “sw_logs”? Da dürften Konflikte ausgeschlossen sein.
[quote=„dewib“]Wenn schon fix hardgecodet, wieso hat man nicht einen Verzeichnisnamen gewählt, der etwas weniger allgemein ist als „logs“? Wie gesagt, dass auf (Web-)Servern bereits Log-Verzeichnisse vorhanden sind, ist ja nun nicht die große Überraschung. Wie wäre es mit „sw_logs“? Da dürften Konflikte ausgeschlossen sein.[/quote] Ich verstehe dein Problem nicht. Wenn Du im Root das Verzeichnis shopware erstellst und das Ziel deiner Domain bei all-inkl.com auf /shopware stellst läuft doch alles?
Musst du nicht verstehen. Genauso wenig wie ich verstehen muss, wie man einer Software hardgecodete Verzeichnisse mitgibt, die durchaus üblicherweise bereits systemseitig vergeben sind.
Um noch etwas zu ergänzen: wenn ich die Shopware in ein Verzeichnis lege und die Domain darauf konnektiere, muss ich die Statistik-Einstellung “kompakt” bei all-inkl.com wählen, damit nicht in diesem Verzeichnis wieder das logs-Verzeichnis vom Server für die separate Domain-Statistik genutzt wird. Die Einstellung “kompakt” bedeutet aber, ich habe keine nach Domains aufgeschlüsselten Zugriffsstatistiken mehr auf dem Server, sondern für alle Domains eine gemeinsame Statistik (eben nur die eine im root logs Verzeichnis). Möchte ich eine Statistik pro Domain, legt der Server die wiederum im logs-Ordner des entsprechenden Domain-Verzeichnisses an. Und damit bleibt das Problem bestehen. Dass die Shopware das /logs/-Verzeichnis braucht ist und bleibt daher ein Problem. Oder zumindest mit deutlichen Einschränkungen verbunden, was die Server-Statistiken angeht. Man muss Einbußen bei den Zugriffsstatisiken in Kauf nehmen.
[quote=“dewib”]Musst du nicht verstehen. Genauso wenig wie ich verstehen muss, wie man einer Software hardgecodete Verzeichnisse mitgibt, die durchaus üblicherweise bereits systemseitig vergeben sind.[/quote] Dann müsste das Verzeichnis “bin” auch umbenannt werden. Das Verzeichnis “cache” wird es in manchen Konstellation auch geben und zu “Problemen” führen. Eine andere Frage, wieso prangerst Du die Konfiguration von all-inkl nicht auch an? Die haben das Verzeichnis “logs” ja genauso “hardgecodet” wie Shopware… 
Pass auf, ich will mich nicht mit dir streiten. Mir gehts hier um Verbesserungsvorschläge und das Erkennen/Beheben von Problemen. Polemik bringt uns hier nicht weiter.
[quote=„dewib“]Pass auf, ich will mich nicht mit dir streiten. Mir gehts hier um Verbesserungsvorschläge und das Erkennen/Beheben von Problemen. Polemik bringt uns hier nicht weiter.[/quote] Dann mach ein Ticket unter jira.shopware.de auf. Ich denke aber das Shopware dies auch als Hostingproblem einstufen wird. Alternativ kannst Du auch die Funktion buildContainer in der Kernel.php (Shopware 4.3.0_RC1)erweitern. Du musst nur nach der foreach Schleife und vor der ersten If Abfrage folgendes einfügen: exec("chmod 0777 $dir"); Wie du exec ggf. aktivierst ist hier beschrieben: http://all-inkl.com/wichtig/ Somit hast Du zwar die Standarddatei verändert, bekommst aber keine mysteriösen Probleme die durch ein umbenennen des logs Verzeichnisses auftreten können. Gruß
Auch ich habe diese Problem mit SW bei All-inkl. Da ich meinen Shop in einem Unteraccount installiert habe, kann ich leider die Statistikeinstellungen nicht vornehmen, da diese Optionen nicht zur Verfügung stehen. Jedoch habe ich das Problem mit einem Cronjob umgangen, welcher aller 15min. die Rechte des logs-Ordner wieder auf volle Rechte (777) setzt. <?php //zurücksetzen der Berechtigung des logs-Ordners über exec
exec('chmod a+rwx /www/htdocs/wxxxxxx/shop.domain.de/logs/');
?>
Hallo, ich habe ebenfalls das Problem und ich habe bei all-inkl nachgefragt, bevor ich hier in das Forum geschaut habe. Man kann die Statistik auch auf “keine” setzen. Hat bei mir aber auch nicht funktioniert. “Kompakt” gab dann das gewünschte Ergebnis (Logs nur im Root). Vorsichtshalber habe ich aber die Logs umgebogen, ist mir sicherer, als mich auf all-inkl zu verlassen… wer will kann sich bedienen. Aber vor aktivierung sw_logs (0777) anlegen. https://www.dropbox.com/s/41r3w54em7bp9cn/blogsdir.zip?dl=0 @iceman_fx Der Cron läuft aber nicht direkt nach der Änderung durch die all-inkl Routine. Also im Zweifel ist der Shop über 14 Min. nicht zu erreichen. Oder habe ich da gerade einen Denkfehler?