[quote=“Gerlinde”]Hallo, die Logfiles haben tatsächlich fehlende Schreibrechte. Setze ich sie auf 777 wird der Wert allerdings nicht übernommen. [/quote] Nur zur Klarstellung: Lock-File und Log-File sind unterschiedliche Dinge. Wenn man Schreibrechte nicht ändern kann, fehlen dem Nutzer unter dem man eingeloggt ist die Rechte für diese Operation. Z. B. kann nicht jeder FTP-Nutzer dies ändern, selbst wenn er die Datei lesen/sehen kann. Bei den restlichen Fragen kann ich so auch nur im Nebel stochern. Evtl. ist das Dateisystem nicht mehr in Ordnung und/oder Dateien oder unvollständige Dateien werden nicht mehr gelöscht. Natürlich kann auch eine Datenbank “zugemüllt” werden, wie groß ist die denn? Is es denn sicher, dass die Speicherplatzbelegung von Shopware oder der Shopwaredatenbank kommt und nicht durch eine andere installierte Software? Viele Grüße
Ui, grad wollte ich noch mal genau nachgucken, wieviel Speicherplatz wir haben und siehe da, der Wert des belegten Speicherplatzes ist plötzlich von 30.000 MB auf realistische 200 MB geschrumpft. Verfügbaren Speicher haben wir 8000MB. Wir hatten den Hoster kontaktiert und anscheinend hat er auch schon was dran gewerkelt, denn nun kommt eine andere Errormeldung. Fatal error: Uncaught exception 'Zend\_Db\_Adapter\_Exception' with message 'SQLSTATE[28000] [1045] Access denied for user '\*\*\*\*\*\*'@'localhost' (using password: YES)' in /singoaqn/www.sinartty.com/engine/Library/Enlight/Components/Db/Adapter/Pdo/Mysql.php:101 Stack trace: #0 /singoaqn/www.sinartty.com/engine/Library/Zend/Db/Adapter/Abstract.php(316): Enlight\_Components\_Db\_Adapter\_Pdo\_Mysql-\>\_connect() #1 /singoaqn/www.sinartty.com/engine/Library/Zend/Db/Adapter/Pdo/Abstract.php(263): Zend\_Db\_Adapter\_Abstract-\>getConnection() #2 /singoaqn/www.sinartty.com/engine/Shopware/Components/DependencyInjection/Bridge/Db.php(45): Zend\_Db\_Adapter\_Pdo\_Abstract-\>exec('SET @@session.s...') #3 /singoaqn/www.sinartty.com/var/cache/production\_201510121351/proxies/ShopwareProductionProjectContainer.php(372): Shopware\Components\DependencyInjection\Bridge\Db-\>factory('pdo\_mysql', Array) #4 /singoaqn/www.sinartty.com/vendor/symfony/dependency-injection/Container.php(327): ShopwareProductionProjectContainer-\>getDbService() #5 /singoaqn/www.sinart in /singoaqn/www.sinartty.com/engine/Library/Enlight/Components/Db/Adapter/Pdo/Mysql.php on line 101 Bin gespannt, wo der Grund der enorm hohen Speicherplatzbelegung liegt. Eine andere Software haben wir nicht auf dem Server. Um ein Backup werden wir wohl trotzdem nicht drum herum kommen. Ich würde nur gerne vorher wissen, wo der Fehler nun lag. Ich hatte hier einen anderen Thread gesehen, wo es auch um einen ähnlichen Fehler ging. allgemein-f25/logs-datei-wird-taglich-autom-auf-chmod-700-zuruckgesetzt-t18819.html
[quote=„Gerlinde“]Ui, grad wollte ich noch mal genau nachgucken, wieviel Speicherplatz wir haben und siehe da, der Wert des belegten Speicherplatzes ist plötzlich von 30.000 MB auf realistische 200 MB geschrumpft. Verfügbaren Speicher haben wir 8000MB. Wir hatten den Hoster kontaktiert und anscheinend hat er auch schon was dran gewerkelt, denn nun kommt eine andere Errormeldung. Fatal error: Uncaught exception 'Zend\_Db\_Adapter\_Exception' with message 'SQLSTATE[28000] [1045] Access denied for user '\*\*\*\*\*\*'@'localhost' (using password: YES)' in /singoaqn/www.sinartty.com/engine/Library/Enlight/Components/Db/Adapter/Pdo/Mysql.php:101 Stack trace: #0 /singoaqn/www.sinartty.com/engine/Library/Zend/Db/Adapter/Abstract.php(316): Enlight\_Components\_Db\_Adapter\_Pdo\_Mysql-\>\_connect() #1 /singoaqn/www.sinartty.com/engine/Library/Zend/Db/Adapter/Pdo/Abstract.php(263): Zend\_Db\_Adapter\_Abstract-\>getConnection() #2 /singoaqn/www.sinartty.com/engine/Shopware/Components/DependencyInjection/Bridge/Db.php(45): Zend\_Db\_Adapter\_Pdo\_Abstract-\>exec('SET @@session.s...') #3 /singoaqn/www.sinartty.com/var/cache/production\_201510121351/proxies/ShopwareProductionProjectContainer.php(372): Shopware\Components\DependencyInjection\Bridge\Db-\>factory('pdo\_mysql', Array) #4 /singoaqn/www.sinartty.com/vendor/symfony/dependency-injection/Container.php(327): ShopwareProductionProjectContainer-\>getDbService() #5 /singoaqn/www.sinart in /singoaqn/www.sinartty.com/engine/Library/Enlight/Components/Db/Adapter/Pdo/Mysql.php on line 101 [/quote] Hier musst du in die config.php und die korrekten Daten (DB-User, DB-Host, DB-Passwort) eintragen, dann sollte der Fehler weg sein.
Wenn sich plötzlich der Inhalt der config.php - das Passwort, der Nutzer oder der Datenbankname - ändert, muss jemand diese Dateie angefasst haben. Von alleine geht das nicht. Es gibt SharedHoster, die einen Ordner Log im Webroot speichern. Generell gilt, dass man Shopware nicht bei einem Hoster installieren kann, der im Webroot einen Ordner anlegt oder verwendet, der mit gleichem Namen bei Shopware existiert. Nimm ein vernünftiges Hostingangebot - es gibt für Shopware gute ab ca. 20 Euro Brutto pro Monat und ohne Mindestvertragslaufzeit. Ansonsten müsste im Post eine vollständige und vernünftige Beschreibung der auftretenden Fehler und der Hosting-Konfiguration vorliegen. Bei so allgemein gehaltenen Informationen kann man keine vernünftigen Ratschläge geben. Viele Grüße
In der config.php sind die Daten alle eingetragen. Und ich glaube schon, dass wir einen vernünftigen Hoster haben. Die beiden Ordner für die log-Dateien vom Hoster und von Shopware haben unterschiedliche Namen. Daran kann es dann nicht liegen. Es wird jetzt ein Backup gemacht. Und ich fand eure Ratschläge vernünftig. :; Danke Euch. 
jaja, die lieben updates. eine guter ratschlag von mir. erstmal auf einer entwicklungsumgebung testen bevor man das auf der LIVE macht 
hab ne blanko 5.1.1 aufgesetzt und ein bild hochgeladen. 9 ordner und 3 bilder 
die ganzen unterordner find ich gar nicht schön!
Update von 5.1 auf 5.1.1 Allerdings weiß ich nicht mehr ob es mit 5.1 auch schon so war das die 5.1.1 ja unmittelbar danach kam. So sieht es bei mir im Mediamanager aus:
du musst die Thumbnails mal neu erstellen. Und warum hast du über 7700 Bilder nicht in Benutzung, aber in Shopware importiert?
Thumbnails lassen sich nicht neu erstellen da die Bilder nicht mehr da sind! Irgendwie hat ein Update die Bilder in den Papierkorb verfrachtet.
Hallo zusammen, ich bin mit neuer Ordner-Struktur total unzufrieden 
. Es hat so viel Mühe gekostet alle Bilder sinnvoll zu benennen, um einen besseren Überblick zu bekommen. So konnte ich sofort nachvollziehen welche Bilder doppelt sind (z.B 10003-bild.jpg und 10003-bild452384532844823.jpg), zu welchen Artikeln sie gehören, wie groß sie sind und welche Abmessungen sie haben. So hat der Ordner früher ausgesehen: • Thumbnail- Ordner • 10001-bild.jpg • 10001-bild.png • 10002-bild.jpg • 10002-bild.png • 10003-bild.jpg • 10003-bild.png • usw… (zu jedem Artikel zwei Bilder: .jpg + .png) Nach dem Update sieht der /media/image-Ordner so aus: •Thumbnail- Ordner •go- Ordner •ff- Ordner •fe- Ordner •fd- Ordner •fc- Ordner •usw. •10001-bild.jpg •10002-bild.jpg •10004-bild.jpg •10007-bild.png •usw… (Die Bilder sind nur teilweise da und haben die Größe 0 KB. Manchmal fehlt .png, manchmal .jpg. ) Alle Bilder sind jetzt in unterschiedlichen Ordnern (go, ff, fe usw.) verteilt. Um ein bestimmtes Bild auf dem Server zu finden, muss man seinen Speicherort mit Firebug analysieren: … …
Ist diese neue Struktur wirklich sinnvoll?
[quote=“Oxana”]Ist diese neue Struktur wirklich sinnvoll?[/quote] Ja, ist sie - nur vielleicht nicht für jede individuelle Anforderung. Im wiki findest du eine ausführliche Beschreibung, warum Shopware diesen Weg geht. [quote=“Oxana”]So konnte ich sofort nachvollziehen welche Bilder doppelt sind[/quote] Der garbage collector cronjob sollte dafür sorgen, dass zumindest ungenutzte Bilder automatisch in den Papierkorb wandern. Viele Grüße
Bin von der neuen Ordnerstruktur auch alles andere als begeistert. Ob es sinnvoll ist? Naja, bei Shops mit zig Tausend Artikeln vielleicht, also nicht die breite Masse. Lg
Hallo, ich habe bei ca. 430 Artiklen (inkl. aller Varianten) knapp 4700 Dateien im Thumnail-Ordner. Bei meinem Hoster (und wahrscheinlich bei vielen anderen mit Standard-Liniux-Konfig.) können pro Ordner max. 5000 Dateien per FTP angezeigt und bearbeitet werden. Noch ein paar mehr und es fängt zudem an deutlich langsamer zu werden. Ich denke also, daß durchaus schon Standard-Shops von der neuen Struktur profitieren werden.
dass nur 5000 Bilder in ein Ordner auf Serverebene gehen ist Quatsch. Da gibt es keine Beschränkung. Richtig ist, dass das FTP Programm auf dem PC sehr lang braucht um die Liste vom gefüllten Ordner zu erstellen. Ich habe etwa 11000 Artikelfotos im Shop, stetig steigend… Shops mit solch einer Artikelanzahl nutzen auch Hostings mit Shellzugriff. Dort arbeitet selten jemand mit FTP Programmen. Die neue Ordnerstruktur ist für alle sinnvoll. Auch kleine Shops! Im Normalfall hast du nichts zu tun im Media Ordner. Alles kannst du über den Mediamanager Machen im Backend. Daher gibt es keinen Grund für die Beanstandung.
[quote=„Aquatuning GmbH“]Der garbage collector cronjob sollte dafür sorgen, dass zumindest ungenutzte Bilder automatisch in den Papierkorb wandern. [/quote] Das beduetet, dass Bilder, die nicht mit Artikeln verknüpft sind, automatisch gelöscht werden?
[quote=“derkosta”] Die neue Ordnerstruktur ist für alle sinnvoll. Auch kleine Shops! Im Normalfall hast du nichts zu tun im Media Ordner. Alles kannst du über den Mediamanager Machen im Backend. Daher gibt es keinen Grund für die Beanstandung.[/quote] Ob das jemand beanstandet oder nicht, solltest du demjenigen schon selbst überlassen. Das Verzeichnis /media/ habe ich, wie alle anderen Shopverzeichnisse auch, auf der lokalen Festplatte. Wenn ich nun eins der skalierten Bilder brauche, weil ich es in einem Blogartikel veröffentlichen möchte oder in einem Forum, dann suche ich mir mit der neuen Struktur die Augen wund.
Hallo Frank, du könntest auch einfach in den Mediamanager gehen, dass Keyword in die Suche hauen und dann das Bild direkt aus dem Mediamanager runterladen. Oder gar dort direkt den Link kopieren und in dein Blog oder Forumpost einbinden.
[quote=„simplybecause“][quote=„Aquatuning GmbH“]Der garbage collector cronjob sollte dafür sorgen, dass zumindest ungenutzte Bilder automatisch in den Papierkorb wandern. [/quote] Das beduetet, dass Bilder, die nicht mit Artikeln verknüpft sind, automatisch gelöscht werden?[/quote] Die Bilder werden nicht gelöscht sondern nur im Mediamanager markiert, dass sie nicht benutzt werden (Papierkorb) Mit einem Rutsch könntest du diese dann löschen.
[quote=„derkosta“]Hallo Frank, du könntest auch einfach in den Mediamanager gehen, dass Keyword in die Suche hauen und dann das Bild direkt aus dem Mediamanager runterladen. Oder gar dort direkt den Link kopieren und in dein Blog oder Forumpost einbinden.[/quote] Das funktioniert nicht. 1. Sind dort nur die „Originalbilder“ zu sehen, also aus dem Verzeichnis /media/images/ und nicht aus /media/images/thumbs/. 2. Kann man die URL nicht kopieren, weil man in das viel zu kleine Feld gar nicht rein kommt.
[quote=„derkosta“]Die Bilder werden nicht gelöscht sondern nur im Mediamanager markiert, dass sie nicht benutzt werden (Papierkorb) Mit einem Rutsch könntest du diese dann löschen.[/quote] Okay, danke.