Support » Allgemeine Fragen » Gibt es ein content limit fuer worpress pages?

  • Hallo,
    auf einer WordPress-Seite habe ich viel Content (Texte, Addons/Elemente, Fotos) eingebunden. Allerdings lässt sich die Seite nicht länger bearbeiten: bei jedem Bearbeitungsschritt stürzt die Seite ab. Die Seite braucht auch sehr lange um überhaupt im Backend zu laden.
    Dies ist die Seite: http://financial-stability.org/events/
    Bei den anderen Seiten (mit weniger Content) passiert das nicht.
    Gibt es ein Limit für Content pro WP-Seite? Oder kann das Problem an etwas anderem liegen? Muss ich ggfls. den Content dieser Seite auf mehrere Seiten verteilen?
    Auf eine Antwort freut sich
    Martin Aehling

Ansicht von 4 Antworten - 16 bis 19 (von insgesamt 19)
  • Danke für die Rückmeldung.

    (habe nur adv. tinymce, visual composer, ultimate vc addons, slider revolution, duplicate post, newsletter und wp editor – keine weiteren Plugins)

    Das „nur“ in diesem Satz kann ich jetzt nicht so richtig nachvollziehen. 😉 Aber gut, daran lags ja offenbar nicht.

    Wenn – auch nach Deaktivieren *sämtlicher* Plugins, wie du sagst – diese Seite, und *nur diese*, im Back-End teilweise abstürzte, dann wird der Kreis potenzieller Verursacher allerdings immer kleiner, wenn man sich mal anguckt, was bei dieser Seite anders ist als bei den übrigen: die Thumbnails/Bilder und die Tabs/Akkordeons. Bei den Thumbnails hatte ich mal kurz an einen möglichen Konflikt mit der FancyBox-Funktion des WP-Editor-Plugins gedacht, aber das hattest du ja offenbar testweise deaktiviert.

    wirklich arbeitsfähig war die Seite jedoch erst nach Löschen von ca. 3/4 der Elemente samt Content und aller Bilder. Das kann eigentlich nicht sein, weil dann kaum mehr Content auf der Seite war, auch keine Akkordeons.

    Die letzten zwei Sätze von dir lassen für mich noch die Frage offen, ob du da auch systematisch vorgegangen bist, um durch Ausschlussverfahren eindeutig festzustellen, ob es nun die Thumbnails/Bilder waren oder die Tabs/Akkordeons, deren Löschung schlussendlich wieder zum einwandfreien Funktionieren führte?

    Mit Quantität hat es meiner Meinung nach nichts zu tun, denn die 3×28 Thumbnails und die dazugehörigen, nicht übergroßen Bilder dürften das Back-End keineswegs zum Abstürzen bringen, zumal in dieser doch ziemlich performanten Umgebung.

    Und ich gehe mal davon aus, dass in der Media Library nicht noch hunderte anderer, nicht referenzierter Bilder liegen, denn das könnte natürlich auch Auswirkungen haben. 😉 Halte ich aber bei deiner Gründlichkeit für ausgeschlossen. Die Einstellungen der Media-Library bist du auch noch mal alle einzeln durchgegangen?

    Was ich schließlich auch noch versucht hätte: Hast du mal die Theme-Entwickler kontaktiert?

    Allerdings lässt sich die Seite nicht länger bearbeiten: bei jedem Bearbeitungsschritt stürzt die Seite ab. Die Seite braucht auch sehr lange um überhaupt im Backend zu laden.

    Ich möchte nochmal auf das Thema zurück kommen, weil ich heute bei einer WordPress-Installation ein ähnliches Verhalten hatte, das mit den bisher angesprochenen Lösungsansätzen nichts zu tun hatte:

    Auf der Website ist Cachify installiert und um die Webseiten auf Festplatte zu installieren, füge ich üblicherweise Weiterleitungsregeln in die .htaccess ein. Nun wollte ich heute Morgen besonders flott sein und habe die Weiterleitungsregeln aus einer anderen Installation kopiert. Da bei dieser anderen Installation aber die WordPress-Dateien in einem Unterverzeichnis liegen, hatte ich den Pfad entsprechend angepasst. Ergebnis: Bei jedem Aufruf von Webseiten wurde erst an der falschen Stelle gesucht. Bis zu Übermittlung des ersten Bytes (Time to First Byte, TTFB – lässt sich in den Developer Tools unter Netzwerk abfragen) vergingen über 20 Sekunden, was natürlich völlig inakzeptabel ist.

    Fazit: Neben den sicherlich hilfreichen Informationen zur Webseiten-Performance würde ich nochmal ein besonderes Augenmerk auf mögliche Einstellungen in der .htaccess richten, die hier eine Rolle spielen könnten.

    Thread-Ersteller maehling

    (@maehling)

    besten Dank für die Anregungen! Die htaccess ist ok, hab sie mit der Basic WP htaccess verglichen, ist identisch. Die Installation ist nicht verändert worden. Der Upload-String fur Medien ist Standard-Einstellung(default). Die Media Library ist nicht vollgestopft.
    Der Theme-Support von UpSolution hat hinsichtlich Backend Performance nichts feststellen können. Anscheinend lief es bei denen normal. Hab das Backend im IE (11), Chrome (50) und Firefox (45) mehrmals, und auch auf anderem PC getestet: Im IE und Chrome ist die Seite „events“ meiner Installation nach wie vor kaum zu bearbeiten – dito auf den anderen PCs; hatte zudem die Sicherheitseinstellungen in den Browsern variiert und dann getestet. (Browser-Cache natürlich immer gelöscht).
    Bei Firefox ist die Performance des Backends deutlich besser, die Seite „events“ lässt sich dort einigermaßen gut bearbeiten. Eine Erklärung für die unterschiedliche Backend Performance bei den Browsern habe ich nicht.
    Im Chrome erscheint beim Bearbeiten der Seite mehrmals das Pop-up „Seite reagiert nicht“, im IE „„ein Skript mit langer Laufzeit verhindert, dass financial-stability.org reagiert“.
    Meine letzte Vermutung war, dass der Visual Composer das Backend ausbremst, konnte jedoch bei der Suche im Internet nach möglichen Gründen dies nicht bestätigt finden. (im IE – nur dort – erscheint nach Upload einer Bearbeitung, z.B. eine Textänderung, das Backend mit der Meldung „page uploaded“ realtiv bald, die Seite lädt aber weiter und weiter, und lässt sich währenddessen nicht mit Maus oder Tasten bedienen; der Visual Composer braucht also lange um zu erscheinen.)
    Vielleicht zur Klarheit (worum es nicht geht): Im Frontend beim Aufrufen der Seiten gab es keine Probleme – weder beim Edge, IE, Chrome noch bei Firefox.
    Werde künftig mit Firefox im Backend arbeiten, ggfls. die Seite „events“ auf mehrere Seiten aufteilen. Da ich derzeit keinen Punkt mehr sehe, an dem ich weiter ansetzen könnte, ist das Thema Backend Performance erst einmal für mich abgeschlossen.

    Danke für die ausführliche Rückmeldung.

    Die großen Theme-Anbieter integrieren die Ultimate Addons des VC ja jeder auf seine eigene Weise, und ich halte es für nicht unwahrscheinlich, dass es da bei UpSolution in bestimmten Konstellationen im Backend zu punktuellen Unstimmigkeiten zwischen dem Visual Composer und der speziellen Ultimate-Addons-Entwicklung von US kommen kann.

    Falls du eine lokale Test-Installation hast, könntest du im Backend (Menü „Ultimate“ > „Module“) mal noch gezielt *alle* und dann auch mal *nur diejenigen* Module deaktivieren, die auf der fraglichen Seite aktiviert sind, z.B. die „Advanced Tabs“ etc. Eventuell auch mit „Scripts and Styles“ testen.

    Sorry, nur mal so aus Interesse im Stillen weiter nachgedacht, da das Thema ja für dich abgeschlossen ist 😉

    @bego:
    Guter Tipp für etwaige Fälle, muss man im Hinterkopf behalten, danke!

Ansicht von 4 Antworten - 16 bis 19 (von insgesamt 19)
  • Das Thema „Gibt es ein content limit fuer worpress pages?“ ist für neue Antworten geschlossen.