Maximale Länge von Einträgen: Änderungen durch vers. 2.0?

[Czorneboh]

Hallo miteinander?

Ich habe jetzt einen Artikelentwurf im Blog, der aktuell 69.928 Zeichen enthält und in ein paar Tagen fertig und veröffentlicht werden soll. Das liegt über dem bekannten Zeichen-Maximum für Einträge von 65.535.

Ich beziehe mich auf Garvins Angabe vor ein paar Jahren.
http://board.s9y.org/viewtopic.php?f=2& ... gth#p49438

Bisher war und ist noch mein längster veröffentlichter Artikel eine Länge von 65.252 Zeichen lang, laut meiner Blogstatistik.

Ich weiß, dass die Länge des Eintrags mehrfach im Forum erörtert worden ist. Ich habe jetzt nicht alles dazu gesichtet; vielleicht ist mit dem Update inzwischen hier etwas anders?!

Ich habe neuerdings das Gefühl, als wenn mir, als ich schon über dem Maximum lag, beim nächsten Bearbeiten dieses längsten Entwurfes unten etwas verloren ging.
Ich werde mir den Entwurfs-Text jetzt mal in eine Writer-Datei sichern, um das kontrollieren zu können, ob unten Text wegfällt, wenn ich oben und zwischendrin was einfüge. (Aber schon seit ein paar Tagen der Bearbeitung liege ich über dem Limit. Es gibt keine "Zurückfallen" auf die Maximumgrenze, laut der Statistik [Zeichenzählung]).

Dann muss ich diesen Eintrag, der für sich ein Teil einer Serie wird, eben notfalls noch mal auf zwei Einträge aufteilen.

Besteht nach wie vor jetzt in der Version 2.0 noch diese Maximumgrenze?
Gab es inzwischen vielleicht Updates für MySQL, durch die die Maximumgrenze erhöht worden ist?

Ich bin noch bei 1.78 und will nach der Veröffentlichung des Updates auf 2.01 updaten. PHP-Version 5.3.3.7+ squeeze 25.

Czorneboh

[yellowled]

Disclaimer: Nicht so richtig meine Baustelle, Garvin kann dazu wahrscheinlich mehr sagen.

Besteht nach wie vor jetzt in der Version 2.0 noch diese Maximumgrenze?

Die maximale Länge liegt, wenn ich Garvins Post dazu richtig verstehe, nicht direkt an s9y.

Der Eintragseditor bzw. korrekter: der Teil des Eintragseditors, der den Inhalt des Eintrags aufnimmt, ist ein Formularfeld vom Typ textarea. Diese können in einem HTTP-Request nicht mehr als die berüchtigten 65.535 Zeichen enthalten. Das gilt überall im Web, nicht nur in s9y; insofern hat es auch nichts mit der Version von s9y zu tun. (Zumal sich in 2.0 nichts daran geändert hat, dass es ein textarea ist.)

Gab es inzwischen vielleicht Updates für MySQL, durch die die Maximumgrenze erhöht worden ist?

Selbst wenn (soweit ich sehe: nein), dann müssten wir diese MySQL-Version als Mindestanforderung setzen und die anderen unterstützten Datenbankversionen müssten dieses Limit ebenfalls aufheben bzw. das neue Limit unterstützen.

Ich bin noch bei 1.78 und will nach der Veröffentlichung des Updates auf 2.01 updaten.

Soweit ich sehe, wird 2.0.1 Stand jetzt noch eine Weile dauern.

YL

[onli]

Diese können in einem HTTP-Request nicht mehr als die berüchtigten 65.535 Zeichen enthalten.

Ich glaube nicht, dass das stimmt. Die textarea wird via POST an s9y gesendet, und POST-Requests sollten nicht ein solches Limit haben.

Wenn Limits drauf sind, dann liegt das eher an PHP oder der Datenbank - und ich habe im Kopf, dass das Datenbankproblem durch einen anderen Feldtyp gefixt wurde. Aber schon vor 2.0.

[yellowled]

Wenn Limits drauf sind, dann liegt das eher an PHP oder der Datenbank - und ich habe im Kopf, dass das Datenbankproblem durch einen anderen Feldtyp gefixt wurde. Aber schon vor 2.0.

Ist ja recht simpel zu testen, wenn ich das richtig verstehe: Man hole sich z.B. auf http://www.blindtextgenerator.de einen Text von exakt 65535 Zeichen Länge ab und speichere den in einem Eintrag. Das geht. Dann erhöhe man diesen um ein paar Zeichen und speichere erneut ab. Oder?

In meiner Testinstanz mit 2.0 geht das, eine 1.x-Instanz habe ich nicht mehr.

YL

[Timbalu]

I now changed s9y 1.6 for new installations to use LONGTEXT by default...
Garvin

google site:board.s9y.org "LONGTEXT"

Wie umständlich ist die Umstellung von TEXT auf LONGTEXT?

Ganz einfach, via phpMyAdmin:

Code: Select all

ALTER TABLE serendipity_entries 
CHANGE `body` `body` LONGTEXT,
CHANGE `extended` `extended` LONGTEXT;

[yellowled]

Nebenbei bemerkt: Wenn man allen Ernstes gut 65.000 Zeichen für einen einzigen Artikel braucht (und dabei nicht ein Großteil für Markup innerhalb des Artikels drauf geht), sollte man dringend darüber nachdenken, den erweiterten Eintrag zu nutzen. Zumindest aber sollte man die Anzahl der pro Seite angezeigten Artikel auf eine eher kleine Zahl setzen.

Es sei denn natürlich, mobile Besucher sind einem egal. Das sollten sie heutzutage aber nicht mehr sein.

YL

[Czorneboh]

Selbstverständlich nutze ich neben dem Feld für "Eintrag" auch das Feld "erweiterter Eintrag". Das Plugin für erweiterte Einträge ist seit jeher eines der wichtigsten für mein Blog.

Ich war jetzt davon ausgegangen, dass sich die Zählung der Zeichen auf beide Felder in der Summe bezog. Kleiner Denkfehler. Aber dennoch: Den "Eintrag" nutze ich nur als Teaser, wenn ich will im Archiv (Einträge nach Monaten oder Kategorien), wo ich pro Seite 5 Artikel zeige, nicht die langen Texte haben.

Wenn ich Ian jetzt richtig verstehe, gibt es inzwischen kein Problem mehr mit der Längenbeschränkung seit Version 1.6?! Ich habe nach Ians Antwort nach LONGTEXT gegooglelt und die hier genannte Maximalzeichenangabe ist ja gigantisch, reicht für ein Buch schreiben, nicht wahr?

Nein, ich schreibe zunächst für mich die Texte, dann, weil ich eine message habe. Weil der lange Artikel eine Sammlung von Argumenten und Beweisen ist, die veröffentlicht gehört. Ich lasse mir aber keine Vorschriften machen. Wer lange Texte nicht auf dem Smartphone lesen will, der liest entweder sowieso schon keine langen Texte mehr (, weil die Geduld und Konzentration fehlt?!) oder der/die beschafft sich ein Tablett-PC, nutzt noch ein Notebook oder liest sowieso keine langen Texte an einem device (, vielleicht Bücher). - Wenn ein Interesse an dem Thema besteht, worüber ich schreibe, gibt es auch eine Motivation, das passende device für das Aufnehmen langer Texte zu nutzen. So sehe ich das.

[Timbalu]

Wenn ich Ian jetzt richtig verstehe, gibt es inzwischen kein Problem mehr mit der Längenbeschränkung seit Version 1.6?!

Korrektur: "Wenn ich Garvin jetzt richtig verstehe..." Aber den wichtigsten Teil hast du unterschlagen: "for new installations"!
Deshalb hatte ich ein zweites Zitat für die unweigerliche Frage nach vohandenen Blogs eingefügt.

[yellowled]

Selbstverständlich nutze ich neben dem Feld für "Eintrag" auch das Feld "erweiterter Eintrag". Das Plugin für erweiterte Einträge ist seit jeher eines der wichtigsten für mein Blog.

Es gibt kein Plugin für erweiterte Einträge, das ist eine Kern-Funktionalität. Was es allerdings gibt und was für Dich evtl. interessant wäre: serendipity_event_entrysplit

Erlaubt die Aufteilung eines langen Artikels in mehrere Unterseiten sowie das Einfügen eines Inhaltsverzeichnisses

Wenn ich Ian jetzt richtig verstehe, gibt es inzwischen kein Problem mehr mit der Längenbeschränkung seit Version 1.6?!

Wenn das Blog mit einer s9y-Version >= 1.6 installiert wurde offenbar nicht. Ansonsten hilft anscheinend der von Ian genannte SQL-Code, den man per z.B. phpMyAdmin ausführen kann. (Ich sage „anscheinend“, weil ich es nicht ausprobiert habe.)

Wer lange Texte nicht auf dem Smartphone lesen will, der liest entweder sowieso schon keine langen Texte mehr (, weil die Geduld und Konzentration fehlt?!) oder der/die beschafft sich ein Tablett-PC, nutzt noch ein Notebook oder liest sowieso keine langen Texte an einem device (, vielleicht Bücher).

Es sei Dir unbenommen, das zu sehen, wie Du willst – aber letzten Ende willst Du doch wie alle Schreibenden vor allem eines, und das sind Leser. Wer Deine Texte lesen will, wird das tun, und zwar auf dem Device seiner Wahl. Wer noch eher so halbinteressiert ist, könnte sich eventuell entscheiden, einen Artikel nicht zu lesen, weil es auf dem Device seiner Wahl eher unbequem zu lesen ist.

YL

[Czorneboh]

Danke für Eure Antworten.

Ich bin gerade am Wiederherstellen der Teile, die am Ende des erweiterten Eintrags "herausgefallen sind", wo ich weiter oben weiter schrieb, seit ich die Maximumgrenze erreicht habe. Dazu benutze ich das Plugin "Versionierung". Es gibt in den letzten Tagen jeweils mehrere Versionen. Ich gehe von Tag zu Tag vor, um zu erkennen, wieviel jeden Tag unten verloren ging.

Diese Teile setze ich wieder zusammen und teile sie in zwei Artikel auf. Wenn ich die dann wieder mit sauberen code hergestellt habe, will ich mit PHPMyAdmin in die Datenbank hineinschauen und sehen, ob ich auf LONGTEXT umstellen kann, Ians Vorschlag folgend.

Hinweis zum Lernen/Verstehen:
Trotz der Rückversionierung dieses längsten Artikel (im Entwurfsstadium) jetzt ändert sich in der Statistik dort, wo die längsten (30) Artikel mit der Zeichenanzahl gelistet sind, die Zeichenanzahl nicht mehr. Steht immer noch bei 69.517, wie vor der Rückversionierung. Es sollten weniger Zeichen sein.

Wie oft aktualisiert sich die Datenbank? Wird sich die Zeichenanzahl noch ändern, wenn sich die Datenbank automatisch nach einem bestimmten Intervall aktualisiert? Kann ich den im s9y-Backend festlegen?

Ergänzender Hinweis, meine Frage zur Datenbankaktualisierung betreffend:
Nach Auswahl der früheren Version von der ich mir den Text unten zur "Rettung" kopieren konnte, habe ich nicht auf "Speichern" geklickt und bin gleich zur Statistik gegangen. Deswegen ist die letzte Version von heute Nacht wohl doch nicht überschrieben worden (, obwohl es eine entsprechende Warnung sofort gibt, wenn man eine andere Version auswählt. Also die Warnung scheint nur dann zu greifen, wenn der Artikel wieder gespeichert wird. Korrekt?).

Nach Rückkehr zu dem Artikel von der Statistik-Seite wird wieder die letzte Version (von heute Nacht) angezeigt.

Die Warnung sollte dann genauer heißen:

"Wenn Sie fortfahren, wird der aktuelle Eintrag mit dem Inhalt der ausgewählten Version überschrieben, sobald gespeichert wird. Wollen Sie fortfahren?"

[Czorneboh]

Der längste Artikel meines Blogs hat laut Blogstatisik 71.616 Zeichen und wird voll angezeigt, aufgeteilt auf 2 Seiten.

https://www.ost-impuls.de/archives/657- ... l#extended

Er ist Teil einer Serie. Bei anderen Teilen bin ich darüber hinaus geraten und dabei rutschte unten Text wieder heraus, so dass ich den Artikel wieder aufteilen musste, wie oben beschrieben, mit Hilfe des Plugins für die Versionierung.

In meine Datenbank habe ich deswegen noch nicht geschaut, um nach den Einstellungen zu sehen.

Der zweitlängste Artikel hat 68.405 Zeichen, verteilt auf 6 Seiten. Hier fehlt am Ende ein Stück. Vielleicht passierte das durch Fettmarkierungen? Videos von Youtube sind auch eingebunden.

Unklar ist, ob die Splitfunktion Einfluss auf das "Fassungsvermögen" hat.

Ich habe wiederholt bemerkt, dass bei Artikeln, die mit dem betreffenden Plugin zum Seitenaufteilen formatiert waren, diese Formatierung weggefallen ist, wenn ich nur an einer Stelle, wo die automatische Formatierung zu Darstellungsfehlern führte (z.B. bei eingebundenen Videos oder Überschrift mit BOLD), einen manuellen Umbruch mit <!--nextpage--> machte.

So wurden z.B. aus einem langen Artikel mit 5 oder 6 Seiten nur noch der Artikel mit 2 Seiten. So wohl passiert beim längsten Artkel mit den jetzt 71.616 Zeichen (s.o).

Ich bin nicht sicher, ob ich das erst bemerkte nach dem Upgrade von 1.78 auf 2.02. Wann ich das zum ersten Mal bemerkte, habe ich nicht notiert.

[Ergänzung: Im Link steht hinten "extended", aber ich suchte den Artikel über dem Suchfeld und als Ergebnis wird es mir mit 2 Seiten angezeigt, wenn ich auf der Seite mit 4 gefundenen Artikeln in den Artikel hineinklicke.]