Download-Produkt / Auswahl leer

Hallo zusammen und ein gutes neues Jahr.

Wenn doch nur ein einziges Update mal problemlos verlaufen würde... :-(

Also, ich habe auf folgende Versionen aktualisiert:
Contao 4.8.7
Isotope 2.6.4

Wenn ich nun im Shop zu einem Produkt einen Download anlegen möchte, also einen Anhang definieren, und entsprechend auf "Auswahl ändern" klicke, dann erscheint ein leeres Fenster (siehe Anlage).

Außerdem ist das BE total langsam, was aber schon vorher regelmäßig der Fall war, nur nicht so extrem. Ich glaube, das System ist mit ein paar Tausend Dateien (jpg, mp4) schlichtweg überfordert.

Hat jemand eine Idee, warum die auszuwählenden Download-Dateien nicht mehr angezeigt werden?

Danke!

Ahoi,

entferne in der Benutzerverwaltung mal das Häckchen bei "Vorschaubilder anzeigen" und lösche gleichzeitig auf der selben Seite die Caches bei "Daten bereinigen".
Geht es dann?

Zitat:

---

Zitat von Stefko

Ahoi,

entferne in der Benutzerverwaltung mal das Häckchen bei "Vorschaubilder anzeigen" und lösche gleichzeitig auf der selben Seite die Caches bei "Daten bereinigen".
Geht es dann?

---

Danke für Deinen Tipp, aber das Häkchen habe ich schon vor geraumer Zeit entfernt, und Cache auch vorhin nochmals gelöscht. Die Seite hängt gerade bis zum Timeout.

Aber auch bevor sie hing, war das Datei-Auswahlfenster leer. Die Dateien befinden sich in Ordnern mit jeweils ca. 1500 Dateien. Ein Ordner mp4, ein Ordner jpg. Und wenn ich in der Dateiverwaltung die Verzeichnisse aufrufe, dann ist Ende, nichts geht mehr. Und zwar nicht nur kurz sondern dann für mind. 15 Minuten.

Doch abgesehen von der katastrophalen Performance ist das leere Auswahlfenster bei den Produkt-Downloads neu.

Die Benutzung des BE legt die gesamte Website lahm. Auch der Aufruf der Produkte führt zum Timeout und völliger Überlastung. Ich vermute fast, dass nach dem Update die bestehenden Performance-Probleme verstärkt wurden und daher vielleicht auch das Auswahlfenster leer bleibt.

Im Error Log stehen Dinge wir:

An exception occurred in driver: SQLSTATE[HY000] [1203] User dbxxxxxx already has more than 'max_user_connections' active connections at /Pfad/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/AbstractMySQLDriver.php:106, Doctrine\\DBAL\\Driver\\PDOException(code: 1203): SQLSTATE[HY000] [1203] User dbxxxxxx already has more than 'max_user_connections' active connections at /Pfad/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:31, PDOException(code: 1203): SQLSTATE[HY000] [1203] User dbxxxxxx already has more than 'max_user_connections' active connections at /Pfad/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:27)"} []

Hast Du einen SSH-Zugang?
Dann führe auf der Kommandozeile doch mal ein

Code:

---

vendor/bin/contao-console contao:filesync

---

aus und lösche zuvor sämtliche Chaches nochmals.

Zitat:

---

Zitat von Stefko

Hast Du einen SSH-Zugang?
Dann führe auf der Kommandozeile doch mal ein

Code:

---

vendor/bin/contao-console contao:filesync

---

aus und lösche zuvor sämtliche Chaches nochmals.

---

SSH Zugang habe ich jetzt nicht, bin ich auch leider nicht vertraut mit, aber ich hatte auch schon eine Dateisynchronisation durchgeführt.

Zitat:

---

Zitat von Ricks

(...) aber ich hatte auch schon eine Dateisynchronisation durchgeführt.

---

und die funktionierte, brach also nicht ab oder blieb hängen?

Zitat:

---

Zitat von Stefko

und die funktionierte, brach also nicht ab oder blieb hängen?

---

Doch, blieb sie ;-)

Zwischenzeitlich war die Performance mal wieder okay, und das Problem des leeren Auswahlfensters blieb. Die entsprechende Seite hängt dann auch nicht, sondern das Fenster öffnet zügig, aber ist leer. Es sieht nicht so aus, als ob er da lädt, es ist einfach leer. Das ist definitiv neu, nach dem Update. Wüsste auch nicht, was für Rechte da vielleicht eine Rolle spielen, zumal wir nichts geändert haben.

Hmmm, das an irgendwelchen Rechten liegt, glaube ich weniger. Ich tippe/vermute das Problem eher an der Performance des Servers. Erzähle doch da mal was dazu, welcher Hoster, was für ein Paket? Und was für eine PHP-Version?

Bin per SSH drin und hänge nun hier:

(12:24:58) [bin] contao-console contao:filesync
-bash: contao-console: command not found
(12:25:44) [bin]

Wie muss ich es eingeben? Danke sehr für Deine Hilfe!

Zitat:

---

Zitat von Stefko

Erzähle doch da mal was dazu, welcher Hoster, was für ein Paket? Und was für eine PHP-Version?

---

Managed Server bei Domainfactory.

Intel Core i5
3,2 GHz oder größer
4 CPU-Kerne
16 GB Arbeitsspeicher

Die Website hat nicht viele Zugriffe zeitgleich, und für das Handling eines BE sollte das eigentlich reichen.

Du musst in das Contao Root-Verzeichnis (also NICHT /web sondern eines darüber und dann

Code:

---

vendor/bin/contao-console contao:filesync

---

eingeben.
Je nach Konfiguration des Servers musst du noch ein

Code:

---

php

---

voranstellen.
Also auf einem Ionos-Server müsste ich

Code:

---

php7.3-cli vendor/bin/contao-console contao:filesync

---

eingeben

Befehl bei DF ist: php7-73LATEST-CLI vendor/bin/contao-console contao:filesync

Nachdem er 30 Minuten synchronisiert hat, ist das Problem leider noch nicht behoben. Noch immer ist die Auswahl leer. Danke trotzdem für Deine Zeit und guten Tipps.

Oh, ssh hat hat folgendes ausgeworfen:

Warning: require(/PFAD/var/cache/prod/ContainerVI8HDuD/removed-ids.php): failed to open stream: No such file or directory in /PFAD/var/cache/prod/ContainerVI8HDuD/appContao_ManagerBundle_HttpKernel_ContaoKernelPro dContainer.php on line 435

Fatal error: require(): Failed opening required '/PFAD/var/cache/prod/ContainerVI8HDuD/removed-ids.php' (include_path='.:/usr/local/lib/php') in /PFAD/var/cache/prod/ContainerVI8HDuD/appContao_ManagerBundle_HttpKernel_ContaoKernelPro dContainer.php on line 435

In appContao_ManagerBundle_HttpKernel_ContaoKernelPro dContainer.php line 435:

Compile Error: require(): Failed opening required '/PFAD/var/cache/prod/ContainerVI8HDuD/remo
ved-ids.php' (include_path='.:/usr/local/lib/php')


contao:filesync [-h|--help] [-q|--quiet] [-v|vv|vvv|--verbose] [-V|--version] [--ansi] [--no-ansi] [-n|--no-interaction] [-e|--env ENV] [--] <command>

ggf. mal

PHP-Code:

---

php7-73LATEST-CLI vendor/bin/contao-console contao:filesync -vvv 


---

aufrufen "-v" gibt mehr Infos aus - "je mehr Vaus, um so mehr Infos"

PS: ich hatte mal den Fall, dass ich eine "handvoll" Dateien als Videos mit über 2GB (je Datei) hatte - das hat die ganze Sync-Geschichte zum Absturz gebracht

Zitat:

---

Zitat von zonky

PS: ich hatte mal den Fall, dass ich eine "handvoll" Dateien als Videos mit über 2GB (je Datei) hatte - das hat die ganze Sync-Geschichte zum Absturz gebracht

---

Und was hast Du getan? Die Datein gelöscht oder gibts eine Lösung? Ich meine, das sollte ein CMS/Shop schon abkönnen, ein paar tausend files verwalten, oder eben einige große Dateien.

Ich setze gerade eine neue, saubere Installation auf, importiere alles und schaue, ob das Problem zu lösen ist oder System-immanent ist, was dann ein echtes Problem wäre.

Ich starte jetzt erst einmal keinen Sync-Prozess mehr, denn der legt jedes Mal den kompletten Server mit sämtlichen Websites lahm.

Danke nochmals für Deine Hilfe. Und sollte ich eine Lösung finden, werde ich es hier posten.

ist noch eine 3.5er Version...

spätestens ab 4.9 kann man Dateien (und/oder Ordner?) vom Sync ausschließen

Zitat:

---

Zitat von zonky

(...) eine "handvoll" Dateien als Videos mit über 2GB (je Datei) hatte - das hat die ganze Sync-Geschichte zum Absturz gebracht

---

Stimmt, da war was ... es gab in den letzten ein/zwei Wochen auch einen Thread hier im Forum, wo Dateien >2GB Probleme machten ... wenn ich mich nicht komplett irre, wurden die dann als Ordner in der Dateiverwaltung dargestellt.

Zitat:

---

Zitat von zonky

ist noch eine 3.5er Version...

spätestens ab 4.9 kann man Dateien (und/oder Ordner?) vom Sync ausschließen

---

Ah, okay. Aber das Problem ist leider nicht der sync sondern das Contao sich per se enorm verlangsamt, wenn in der Dateiverwaltung viele Files sind oder große. Das Problem mit den großen Dateien hatte ich übrigens auch schon.

So etwas kann ein ganzes Projekt zunichte machen, wenn das dann nicht lösbar ist. Im aktuellen Fall ein Shop. Man könnte die Dateien auf diverse Unterordner aufteilen, aber das würde bedeutet bei hunderten von Produkten die Download-Anhänge manuell neu zuzuordnen. Das kann man einem Kunden nicht wirklich plausibel machen ;-)

ich würde aber dennoch mal andere Server austesten - DF ist nicht gerade für einen "Geschwindigkeitsrausch" bekannt...

z.B. lokal, sofern Du Linux hast (unter Win/Mac brauchst Du nicht testen) - oder mal bei All-inkl...

Zitat:

---

Zitat von zonky

ich würde aber dennoch mal andere Server austesten - DF ist nicht gerade für einen "Geschwindigkeitsrausch" bekannt...

---

Ja, auch das werde ich mal prüfen, danke!

So, Fazit: Saubere neue Installation bringt nichts. Sobald man im BE eine Seite/Funktion aufruft, die das Dateisystem nutzt ist Ende. Ob Download-Auswahl oder Dateiverwaltung, das System ist überfordert und danach für Minuten down. Ist von Version zu Version langsamer geworden, jetzt geht nichts mehr.

Eigentlich müsste dieser Thread in die Rubrik Bilder/Dateien.

Zitat:

---

Zitat von Ricks

So, Fazit: Saubere neue Installation bringt nichts. Sobald man im BE eine Seite/Funktion aufruft, die das Dateisystem nutzt ist Ende. Ob Download-Auswahl oder Dateiverwaltung, das System ist überfordert und danach für Minuten down. Ist von Version zu Version langsamer geworden, jetzt geht nichts mehr.

Eigentlich müsste dieser Thread in die Rubrik Bilder/Dateien.

---

selber Server oder wo getestet?

Zitat:

---

Zitat von zonky

selber Server oder wo getestet?

---

Ja, selber Server.

Ich teste noch einen anderen Server, was bleibt auch sonst ;) Aber das kann doch nicht der richtige Weg sein. Das sollte ein CMS schon bewältigen können, das quasi alleine auf einem eigenen Server läuft. Da passiert wirklich nicht viel, wenig Zugriffe, nur eben die Dateien liegen dort. Und es hat sich definitiv nach dem Update vor ein paar Tagen erneut verschlechtert. Vorher ging es zumindest noch, wenn auch langsam. Aber jetzt ist Stillstand. Wie will man so etwas einem Kunden erklären? Aktuell ist der Shop nicht mehr administrierbar.

Ich hatte ein ähnliches Problem schon vor längerer Zeit mit einer 4.4 (mit vielen, aber nicht riesig großen Dateien, beobachtet bei uberspace und bei WebGo)
Das scheint an der Berechnung der Hashes für das DB-basierte Filesystem zu liegen. Diese Operation für alle Dateien braucht einfach ihre Zeit, die evtl. sogar die Skriptlaufzeit überschreitet.

Ich bin mir nicht sicher, aber ist es vielleicht möglich, dass du die Dateien auf mehrere Ordner verteilst und die Synchronisation einzeln je Ordner aufrufst?

du könntest im app_dev-Modus bei "Performance" nachsehen wer oder was so rumeiert - ggf. bringt das schon eine Idee... ansonsten müsste man mal mit blackfire.io oder sowas rein gucken

Zitat:

---

Zitat von Ricks

Im Error Log stehen Dinge wir:

An exception occurred in driver: SQLSTATE[HY000] [1203] User dbxxxxxx already has more than 'max_user_connections' active connections at /Pfad/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/AbstractMySQLDriver.php:106, Doctrine\\DBAL\\Driver\\PDOException(code: 1203): SQLSTATE[HY000] [1203] User dbxxxxxx already has more than 'max_user_connections' active connections at /Pfad/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:31, PDOException(code: 1203): SQLSTATE[HY000] [1203] User dbxxxxxx already has more than 'max_user_connections' active connections at /Pfad/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:27)"} []

---

Hallo Ricks,
das Problem kenne ich von Mittwald (da warens nur 80 gleichzeitige Zugriffe, was bei einer gut besuchten Seite oft vorgekommen ist...). Dort musste ich auf ein anderes Paket umstellen (90,- Euro pro Monat), da dort das limit nicht gesetzt war von max_user_connections.
Bei df hatte ich das Problem noch nicht. Dort habe ich aber auch keine Kunden mehr, die größere Installationen haben.
Das Problem: Zu viele gleichzeitige Zugriffe auf die DB von Contao (sei es durch die Dateiverwaltung oder/und Besucher oder sonstige Operationen).
Du könntest dazu mal den Suppport von DF bemühen.. eventuell hat sich da auch nur etwas festgefahren, weswegen du jetzt immer wieder in dieses Problem rennst.
Ansonsten müstest du gucken, ob du das Limit eventuell hoch setzen kannst oder von denen hoch setzen lassen kannst.

Viele Grüße

Zitat:

---

Zitat von MacKP

Du könntest dazu mal den Suppport von DF bemühen.. eventuell hat sich da auch nur etwas festgefahren, weswegen du jetzt immer wieder in dieses Problem rennst.
Ansonsten müstest du gucken, ob du das Limit eventuell hoch setzen kannst oder von denen hoch setzen lassen kannst.

---

Merci, das mache ich.

Domainfactory hat die max_user_connections und die max_connections verdoppelt. Dadurch hängt der Server zwar nicht mehr so lange, aber das Grundproblem bleibt. Contao ist nicht in der Lage einen Ordner mit 1000+ Dateien zu öffnen. Die Dateiverwaltung hängt sich dann auf, und wenn man im Shop einem Produkt einen Download zuweisen möchte, so passiert das Gleiche, weil das System dazu ja auch die Ordnerstruktur laden muss.

Es ist eine neue, saubere Installation, und der filesync via SSH hat auch fehlerfrei funktioniert (allerdings in 1 Std. 20 Minuten)

Okay, nun bleibt nur noch ein leistungsstärkerer Server. Was okay ist, wenn es dann funktioniert. Aber das weiß man erst, wenn man ihn gebucht hat.

Danke nochmals an Euch alle für den diversen Input!

Zitat:

---

Zitat von Ricks

A) Contao ist nicht in der Lage einen Ordner mit 1000+ Dateien zu öffnen. Die Dateiverwaltung hängt sich dann auf, und wenn man im Shop einem Produkt einen Download zuweisen möchte, so passiert das Gleiche, weil das System dazu ja auch die Ordnerstruktur laden muss.

B) Okay, nun bleibt nur noch ein leistungsstärkerer Server. Was okay ist, wenn es dann funktioniert. Aber das weiß man erst, wenn man ihn gebucht hat.

---

zu A) bleibt die Frage, wer hier die "Schnecke" ist... ein PHP-Script oder der File-Zugriff direkt..?

zu B) bei vielen Providern gibt es einen "Testmonat"

DF schreibt:

"Ursprung der gestrigen Festplattenauslastung war der Aufruf des Skriptes "PFAD/web/app.php". Dieses scheint Teil einer Contao-Installation zu sein und ruft laut Inhalt lediglich die "index.php" im gleichen Verzeichnis auf.

Leider ist hierbei nicht ersichtlich, ob dabei weitere Skripte/Prozesse angestoßen wurden. Aufgrund der Überlastung wurde jedoch in Abstimmung mit Ihnen der Prozess des Skriptaufrufes beendet, sodass die Festplattenauslastung und somit wieder die Serverlast gesunken ist."

**

Nach telefonischer Rückfrage hat DF nochmals erläutert, dass Auslöser des Stillstands eine Festplattenauslastung und keine CPU-Auslastung ist. Also Schreib- und Leseprozesse, was immer Contao da macht.

... k.A. - ggf. hat @toflar noch eine Idee

Zitat:

---

Zitat von zonky

zu B) bei vielen Providern gibt es einen "Testmonat"

---

Da es eine Festplattenauslastung ist, hilft mehr CPU leider nicht. Da müsste man dann ein System mit Loadbalancing buchen. Aber das sehe ich jetzt noch nicht. Im FE läuft alles rund, es passiert nur beim Administrieren im BE.

Zitat:

---

Zitat von Ricks

Da es eine Festplattenauslastung ist, hilft mehr CPU leider nicht. Da müsste man dann ein System mit Loadbalancing buchen. Aber das sehe ich jetzt noch nicht. Im FE läuft alles rund, es passiert nur beim Administrieren im BE.

---

hilft SSD? - wäre dennoch die Frage, wer da "ständig" im BE auf die Dateien zugreift

Zitat:

---

Zitat von zonky

hilft SSD? - wäre dennoch die Frage, wer da "ständig" im BE auf die Dateien zugreift

---

DF meint, sie haben keine Festplatten, die da helfen würden. "Ständig" ist der Zugriff ja nicht, nur bei Aufruf der Dateistruktur. Ansonsten läuft das BE rund.

Zitat:

---

Zitat von Ricks

"Ständig" ist der Zugriff ja nicht, nur bei Aufruf der Dateistruktur. Ansonsten läuft das BE rund.

---

vielleicht kann man das ja irgendwie cachen - ich würde dazu mal ein Issue auf Github schreiben...

Das von DF ins Spiel gebrachte Loadbalancing bringt natürlich auch nichts, hatte nicht nachgedacht. Dabei würde nur die CPU-Last verteilt, oder beim Ausliefern von Daten auch von verschiedenen, gespiegelten Festplatten bereitgestellt. Aber dieses Schreiben und Lesen, das Contao beim Abruf der Dateistruktur veranstaltet, muss natürlich auf einer Platte erfolgen.

ja, das LB soll ja nur viele Anfragen (FE) auf verschiedene Server verteilen - hat m.E. mit dem Problem nix zu tun

ich denke, ein Caching könnte das Problem umschiffen

Ich hake nochmal wegen der Synchronisation der Dateiverwaltung ein, die ja in dem betroffenen System noch nicht abgeschlossen ist.
Kann es sein, dass darum schon beim Öffnen der Dateiverwaltung im BE irgendwas passiert, das z.B. die Hashes nachrechnet oder überprüft? Oder bin ich da völlig auf dem Holzweg?

Weitere Frage: wie sind denn die 1000+ Dateien auf den Server gekommen, alle gleichzeitig oder nacheinander? Könnte es helfen, zunächst mit nur, sagen wir, 100 Dateien zu synchronisieren und dann jeweils weitere Files zu ergänzen und neu zu synchronisieren?

Zitat:

---

Zitat von folkfreund

Ich hake nochmal wegen der Synchronisation der Dateiverwaltung ein, die ja in dem betroffenen System noch nicht abgeschlossen ist.
Kann es sein, dass darum schon beim Öffnen der Dateiverwaltung im BE irgendwas passiert, das z.B. die Hashes nachrechnet oder überprüft? Oder bin ich da völlig auf dem Holzweg?

Weitere Frage: wie sind denn die 1000+ Dateien auf den Server gekommen, alle gleichzeitig oder nacheinander? Könnte es helfen, zunächst mit nur, sagen wir, 100 Dateien zu synchronisieren und dann jeweils weitere Files zu ergänzen und neu zu synchronisieren?

---

Doch, die Synchronisation wurde mittels SSH ohne Fehlermeldung in 1 Std. 20 Min. abgeschlossen. Die Dateien sind nach und nach auf den Server gekommen. Es handelt sich um zwei Ordner: Filme, Trailer. In jedem ca. 1300 Dateien. Größe der Filmdateien ca. 120 MB.

Ordner mit weniger Dateien kann man öffnen. Aber ich kann die o.g. Ordner nicht einfach aufteilen, weil dann Pfade nicht mehr stimmen und Funktionen, die den Pfad im FE verschlüsseln. Abgesehen davon könnte ich die Downloads auch nicht neu zuordnen, da er genau dabei ja in die Knie geht. Denn zur File-Auswahl lädt er ja die gesamte Struktur im Ordner "files", also ca. 3000 Dateien, alles in allem. Wirklich nervig, aber ich experimentiere weiter ;)

Also mein Ansatz wäre erst einmal, Verzeichnisse mit so vielen Dateien zu vermeiden. Das ist in der Regel eigentlich immer inperformant. Und das nicht nur beim Contao-Dateisystem. Also meinetwegen die Dateien weiter zu unterteilen nach welchen sinnvollen (oder sinnlosen :D) Kriterien auch immer.

Zitat:

---

Zitat von tab

Also mein Ansatz wäre erst einmal, Verzeichnisse mit so vielen Dateien zu vermeiden. Das ist in der Regel eigentlich immer inperformant. Und das nicht nur beim Contao-Dateisystem. Also meinetwegen die Dateien weiter zu unterteilen nach welchen sinnvollen (oder sinnlosen :D) Kriterien auch immer.

---

Darauf wird es hinauslaufen. Dann muss zwar einiges angepasst werden, aber eine Alternative sehe ich auch nicht.

Der Vorteil der DB-basierten Dateiverwaltung ist ja, dass Dateien automatisch wieder zugeordnet werden, auch wenn du sie in einen anderen Ordner verschoben hast. Du musst sie also nicht neu zuweisen! Sie werden anhand ihres Hashwertes wiedererkannt. Also ist vielleicht der Aufwand für die Umstrukturierung deiner Dateien doch überschaubar.

Viel Erfolg!

Generell wäre es hilfreich, wenn man tatsächlich die Synchronisation auch nur für Teile der Dateiverwaltung (z.B. ordnerweise) auslösen könnte. Aber vermutlich spricht genau der erwähnte Fall der verschobenen Dateien dagegen.
Blöd ist jedenfalls, dass eine einzige neu hinzugefügte Datei es notwendig macht, alle Hashes neu zu berechnen - und sei es nur wegen der Überprüfung.

Zitat:

---

Zitat von folkfreund

Der Vorteil der DB-basierten Dateiverwaltung ist ja, dass Dateien automatisch wieder zugeordnet werden, auch wenn du sie in einen anderen Ordner verschoben hast. Du musst sie also nicht neu zuweisen! Sie werden anhand ihres Hashwertes wiedererkannt. Also ist vielleicht der Aufwand für die Umstrukturierung deiner Dateien doch überschaubar.

---

Sicher? Also wenn ich in Isotope Produkten einen Download zugeordnet habe, dann wird die Zuordnung aktualisiert, wenn ich die Datei verschiebe? Das wäre in der Tat hilfreich.

Zitat:

---

Zitat von folkfreund

Der Vorteil der DB-basierten Dateiverwaltung ist ja, dass Dateien automatisch wieder zugeordnet werden, auch wenn du sie in einen anderen Ordner verschoben hast. Du musst sie also nicht neu zuweisen!

---

Zitat:

---

Zitat von Ricks

Sicher? Also wenn ich in Isotope Produkten einen Download zugeordnet habe, dann wird die Zuordnung aktualisiert, wenn ich die Datei verschiebe? Das wäre in der Tat hilfreich.

---

folkfreund hat soweit recht... aber Ricks, das gilt m.E. nicht für die Produktbilder von Iso - die wählt man ja nicht aus, sondern macht ein Upload... die werden auch in einem eigenen Ordnersystem gespeichert und nicht unter /files/...

Deine Downloaddateien solltest Du mittels der Dateiverwaltung umherschieben können, ohne dass die Links verloren gehen - Iso sollte da auch die Haswerte der Dateien speichern und nicht die Pfade ... ein Blick in die DB sollte da schnell Aufklärung geben :D

Zitat:

---

Zitat von zonky

folkfreund hat soweit recht... aber Ricks, das gilt m.E. nicht für die Produktbilder von Iso - die wählt man ja nicht aus, sondern macht ein Upload... die werden auch in einem eigenen Ordnersystem gespeichert und nicht unter /files/...

Deine Downloaddateien solltest Du mittels der Dateiverwaltung umherschieben können, ohne dass die Links verloren gehen - Iso sollte da auch die Haswerte der Dateien speichern und nicht die Pfade ... ein Blick in die DB sollte da schnell Aufklärung geben :D

---

Die Produktbilder müssen zum Glück nicht verschoben werden, die liegen in de Isotope-Ordnern, die erscheinen gar nicht in der Dateiverwaltung. Was ich ändern muss ist der Code für den Player im Reader-Template für die Film- und Trailer-Dateien, da das dann nicht immer der gleiche Pfad ist sondern eben unterschiedliche sein können. Hier muss ich schauen, ob ich den Filmordner im Produktdatensatz hinterlege, also ein neues Attribut schaffe, oder ob ich einfach definiere

ProduktID<700 = Ordner 1
ProduktID>=700 = Ordner 2
ProduktID >= 1400 = Ordner 3

Das muss ich noch zuende denken ;-)

Aber danke schon mal für die Anregungen, es konretisiert sich :)

Zitat:

---

Zitat von Ricks

Was ich ändern muss ist der Code für den Player im Reader-Template für die Film- und Trailer-Dateien, da das dann nicht immer der gleiche Pfad ist sondern eben unterschiedliche sein können.

---

wenn das in Deinem Template nicht dynamisch geht, würde ich eher mal gucken warum? kann ich mir kaum vorstellen... ggf. mal posten

Zitat:

---

Zitat von folkfreund

Generell wäre es hilfreich, wenn man tatsächlich die Synchronisation auch nur für Teile der Dateiverwaltung (z.B. ordnerweise) auslösen könnte. Aber vermutlich spricht genau der erwähnte Fall der verschobenen Dateien dagegen.

---

Ja, das denke ich auch, dass das deswegen Probleme machen würde. Jedenfalls bestünde die Gefahr, dass Inkonsistenzen entstehen, wenn man sich nicht an die "Regeln" hält, die einem eine solche teilweise Synchronisierung auferlegt

Zitat:

---

Zitat von folkfreund

Blöd ist jedenfalls, dass eine einzige neu hinzugefügte Datei es notwendig macht, alle Hashes neu zu berechnen - und sei es nur wegen der Überprüfung.

---

Das muss nicht so sein. Beim Upload über die Dateiverwaltung wird zum Beispiel jede hochgeladene Datei einfach hinzugefügt mit relativ überschaubarem Aufwand. Lädt man dagegen per FTP hoch und lässt dann synchronisieren, dann wird eben alles komplett synchronisiert. Man kann sich allerdings auch ein Skript schreiben, dass z.B. alle Dateien in einem definierten Upload-Ordner der Datenbank einzeln hinzufügt und die verarbeiteten Dateien automatisch in den gewünschten Ordner unterhalb von /files verschiebt. Das könnte man dann auch so gestalten, dass pro Aufruf nur eine bestimmte Anzahl Dateien verarbeitet werden um die PHP-Limits nicht zu überschreiten.

Zitat:

---

Zitat von tab

Lädt man dagegen per FTP hoch und lässt dann synchronisieren, dann wird eben alles komplett synchronisiert.

---

So werde ich es machen, da die Dateien zu groß sind, um das mit der BE Dateiverwaltung zu machen, die ja ohnehin schon am Limit ist.

Beim Verschieben via FTP werde die Dateien ja down- und wieder uploaded glaube ich. Hätte das Einfluss auf die Zuordnung?

Zitat:

---

Zitat von Ricks

Beim Verschieben via FTP werde die Dateien ja down- und wieder uploaded glaube ich. Hätte das Einfluss auf die Zuordnung?

---

mach das über das BE - scheint mir die sichere Variante

Zitat:

---

Zitat von zonky

mach das über das BE - scheint mir die sichere Variante

---

Wie soll ich das machen, wenn ich hunderte von Dateien der Größe 120 MB verschieben möchte? Zumal das schon deshalb leider nicht geht, weil das Aufrufen der Dateiverwaltung bereits zum Einfrieren des BE (und Servers) führt :(

So viele Dateien dieser Größe willst du aber auch nicht runter- und wieder hochladen :eek:
Dann nutze wenigstens mv per SSH. Das sieht dann aber für den Server wieder so aus wie gelöscht und neu hochgeladen, es muss also anschließend eine vollständige Synchronisation laufen.

btw: noch ein paar Infos dazu https://contao.slack.com/archives/CN...78064406002500

Danke für all Euren Input. Ich werde berichten ;)

wie @fritzmg meint, könnte man bei der Darstellung des Dateibaumes die physiche Prüfung der Dateien abschalten... @Ricks - man bräuchte jemanden, der das programmiert oder sponsored ;-)

Edit: ahh.. es gibt einen Link: https://community.contao.org/de/show...m-Isotope-Shop

So, kurzes update: Die Aufteilung der Dateien auf mehrere Unterordner hat nichts genutzt. Im Dezember wurden auch keine Dateien hinzugefügt, so dass nicht zu erklären ist, warum das System plötzlich einfriert. Es gab ein Update auf die neusten Versionen, das habe ich im Verdacht. Aber eine Rückführung auf die älteren Versionen hat das Problem nicht mehr beseitigt. Jetzt bin ich gerade mit meinem Latein am Ende. Falls sich jemand zutraut das zu lösen, ich mache gerne einen Auftrag daraus.

Habe noch eine letzte Frage. Ich habe nun im Testsystem die files auf diverse Ordner verteilt (ohne nennenswerten Performance-Gewinn), und so wie es aussieht, sind nach einem filesync via ssh tatsächlich auch die Produkt-Downloads bzw. deren Pfade neu zugeordnet. Nun muss ich das im laufenden System implementieren. Dazu folgende Frage: Ist außer der tl_iso_download noch eine Datei in die Hinterlegung von Produk-Downloads involviert oder genügt es nach der Neuorganisation der files die Tabelle tl_iso_download aus dem Testsystem zu importieren?

Danke!

Habe eine Neuinstallation auf einem stärkeren Server vorgenommen. Die Dateiverwaltung läuft nun, wenn auch langsam bei 500 files in einem Ordner, aber es läuft stabil. Doch die Auswahl einer Download-Datei, gleich ob in Isotope oder als Inhaltselement, führt zum Einfrieren. Wahrscheinlich, weil alle Ordner auf einmal geladen werden. Keine Ahnung, jedenfalls ist da irgendetwas, das den Prozess enorm verlangsamt, und nach dem Update noch einmal erneut verlangsamt wurde.

in DC_Folder Methode generateTree mal angucken was da so alles aufgerufen wird - ggf. kann man bestimmte Prüfungen testweise umgehen oder mal per Zeitausgabe gucken, was so lange dauert...

der scan-Befehl wird eigentlich gecached (..\helper\functions.php) - ggf. läuft da was nicht optimal

Zitat:

---

Zitat von zonky

in DC_Folder Methode generateTree mal angucken was da so alles aufgerufen wird - ggf. kann man bestimmte Prüfungen testweise umgehen oder mal per Zeitausgabe gucken, was so lange dauert...

der scan-Befehl wird eigentlich gecached (..\helper\functions.php) - ggf. läuft da was nicht optimal

---

Danke! Ich sehe mir das mal an, auch wenn meine Kenntnisse da wahrscheinlich an ihre Grenze kommen ;-)