Gibt es ein Limit für die Datenmenge einzelner Artikel?

hast du regelmäßig mal ein backup der db gemacht? wenn ja, kann man :arrow: notfalls auch das backup wieder einspielen, wenn dadurch nicht zuviel verloren geht.

normalerweise sollten bilder (auch screenshots) eh nicht in der db gespeichert werden, sondern auf dem webspace abgelegt werden.

bist du mal per phpmyadmin in die db gegangen und hast die tabellen reparieren/optimieren lassen?

vG

arno

Zitat von filfil

Nein, leider nicht. Aber ich habe alles auf der Festplatte, um den Artikel wiederherzustellen. Ich will nur beim zweiten Versuch eben nicht den gleichen Fehler machen, der möglicherweise beim ersten Mal zum GAU geführt hat.

Nun machst Du ja eine interessante Andeutung hinsichtlich des Ortes, an dem die Bilder gelagert werden. Ich habe die Bilder bisher über den WP-WYSIWYG-Editor hochgeladen und eingefügt. Mir ist schon aufgefallen, dass ab einer bestimmten Menge Bilder - ich sage mal ab 50 Stück - die Ladezeit in störendem Maß zunimmt. Auch wenn ich etwas im Editor ändere, dauert es ziemlich lange, bis der Text im Editor wieder zu bearbeiten ist.

die bilder werden auch bei dieser technik sicherlich auf dem webspace abgelegt. das feld in dem die artikel gespeichert werden, ist ein longtextfeld - also zur aufnahme von binärdaten (wie bildern) generell nicht geeignet.

Zitat

Wenn ich Deine Andeutung richtig verstehe, vermutest Du, dass es zum Kollaps führen kann, wenn ich die Bilder massenhaft direkt im Artikel also letztlich der Datenbank lagere?

Wie genau funktioniert es denn anderweitig? Schreibe ich den Artikel und füge dann Links zu einem anderen Ort meines Webspaces ein, wo die Bilder dann extern geladen und hineinverlinkt werden?

Was genau ist daran besser, die Bilder an einem anderen Ort des Webspaces zu lagern als im Artikel selbst? Müssen die Bilder dann nicht geladen werden, weil sie sich an einem bestimmten Ort immer in geladenem Zustand befinden? Ich bin noch etwas irritiert, weil ich bei Wordpress noch nie auf die Idee gekommen bin, die Bilder außerhalb des eigentlichen Artikels aufzubewahren. Bei Ebay mache ich das natürlich - aber aus Kostengründen, nicht weil ich dachte, dass es dann besser lädt. Oder hälst Du den externen Ort aus Sicherheitsgründen für besser? Hinsichtlich Datenverlust?

Es wäre natürlich phantastisch, wenn das meines Rätsels Lösung wäre. Welche Vorgehensweise empfiehlt sich da? Der Vorteil wäre wahrscheinlich auch, dass ich die Bilder per Bulk-Upload hochladen könnte und nicht einzeln wie im Editor - bei mehreren Hundert wäre dies natürlich eine enorme Erleichterung ...

nun die langen ladezeiten beruhen sicherlich eher auf der tatsache des eingesetzten wysiwyg-editors, denn auf dem speicherort der bilder - die werden, wie gesagt, mit hoher wahrscheinlichkeit ohnehin auf dem webspace liegen. da ich allerdings keine artikel mit bildern (bzw. wenn überhaupt nur selten) verfasse, habe ich mir das auch nicht genauer angeschaut.

ein wysiwig-editor hat jedoch - wie der name schon sagt - die eigenart, den artikel den du bearbeitest, so anzuzeigen, wie er später dargestellt werden soll! dazu gehört natürlich auch, das eingebundene bilder aus dem webspace geladen und das benötigt eben auch seine zeit. daher auch die langen ladezeiten.

Zitat

bislang nicht. Jetzt habe ich mal nachgesehen. Dort finde ich aber keine Option "reparieren/optimieren". Unter Operationen steht dort:

- Neue Tabelle in Datenbank espritd1_blog erstellen
- Datenbank umbenennen in:
- Datenbank kopieren nach:
- Kollation:

Unter Kollation irritiert mich übrigens, dass dort "latin1_swedish_ci" angezeigt wird. Sollte ich da nicht "latin1_german1_ci" bzw. "latin1_german2_ci" aktivieren? Wenn ja, welches von beiden?

normalerweise sollte dort eine unicode-codierung stehen - bei mir in der db steht allerdings auch häufiger latin_swedish_ci. solange im frontend alles ordentlich ausgegeben wird, störts mich jedoch nicht weiter und im nachhinein die db entsprechend umzustellen, könnte sich durchaus als schuss nach hinten herausstellen.

die optionen zum optimieren/reparieren der tabellen befinden sich nicht im reiter operationen, sondern im überblick der db-tabellen. dort wo die tabellen über checkboxen auswählbar sind, ist am ende der liste ein dropdownfeld, über welches die optionen auswählbar sind (siehe screenshot)

vG

Arno