WordPress 2.6: Revisions-Feature deaktivieren
24. July 2008 | Autor: ritchie
Die aktuelle Version unseren Lieblings-CMS bringt zwei Features mit, die – gelinde gesagt – recht unausgegoren sind. Da wäre zum einen mal die neue Caption-Funktion (Bildunterschriften für hochgeladen Fotos) und zum anderen die “Revisions”, automatisch generierte Posting-Snapshots bei jedem Save bzw. Autosave. Im offiziellen WordPress-Support-Forum entspann sich dazu eine recht erhitzte Diskussion:
während Moderator Otto gewohnt nerd-unfreundlich (er ist wohl schon seit den Zeiten des Usenet dabei) argumentiert, dass die Revisions immer und für jeden super seien, bin ich da wie viele User ganz anderer Meinung: ich erstelle meine Posts sowieso im Texteditor, daher brauche ich keine zusätzlichen Kopien, die mit der Zeit die Datenbank ganz beträchtlich aufblähen. Die Autosave-Funktion reicht mir völlig, um zu verhindern, dass ich einen Firefox-Tab mit nicht gespeichertem Posting irrtümlich schließe. Viel schlimmer allerdings: die Revisions verwirren mein In-Series Plugin: dort tauchen die Revisions plötzlich auch in der Serienliste auf.
Eine aus/ein Option verkompliziere das Backend unnötig, erklärt Otto – da find ich persönlich die “händische” Variante viel komplizierter. Wer die in punkto “wie gehen Starrköpfe mit dem Feedback der Community um?” äußerst interessante Diskussion im Detail nachverfolgen will, kann das hier tun. Bei Wikis machen Revisions zweifellos mehr sind, die meisten Blogs werden aber nicht von 50 Autoren kollektiv geschrieben – ein Opt-in wäre mehr als angebracht. Dass die Revisions nicht mal in einer eigenen Table, sondern mit dem Type “revision” in der wp_postings gespeichert werden, ist wirklich crappy.
WordPress Revisions ausschalten und Autosave-Intervall ändern
Um die für viele WordPresser lästigen Revisions loszuwerden, genügt ein neuer Einträge in der wp-config.php:
define (’WP_POST_REVISIONS’, 0);
Wem die automatische Speicherung zu häufig stattfindet, der kann diesem Feature mit folgender Zeile ein Intervall vorgeben. (600 steht dabei angeblich für 1h, ich hab’s aber nicht überprüft:
define(’AUTOSAVE_INTERVAL’, 600);
Um die bereits angelegten Revisions wieder los zu werden, hilft ein simpler SQL-Query, den man im phpmyadmin ausführt. Wer ein anderes Datenbank-Präfix verwendet, muss dieses natürlich entsprechend anpassen (in Rot markiert).
Delete from wp-posts where post-status=’revision’
Caveat: Auch wenn sich’s nur um einen kleinen “Eingriff” handelt, legt der vorsichtige (oder durch Schaden klug gewordene) Blogger immer vorher eine DB-Kommandozeilen-Dump an.
Die WordPress Caption-Funktion
Captions sind Bildunterschriften – das betreffende Feld in der Uploadmaske wir zentriert unter dem jeweiligen Foto dargestellt und kann gegebenenfalls via der zugehörigen CSS-Klasse formattiert werden. Benötigt man bei einem Bild (zum Beispiel beim Teaser, bei einem Thumbnail etc.) keine Unterschrift, so möchte man meinen, dass es reichte, das Feld einfach freizulassen. Weit gefehlt: dann bleibt nämlich auf das alt=”" Argument des Image-Tags leer. SEO-technisch äußerst ungünstig…
Das verkompliziert den Workflow: füllt man das Feld aus, muss man nachher den Caption-Tag weglöschen, lässt man’s leer, will die Alt-Angabe manuell befüllt werden. Zwar existiert eine Lösung, um die Captions komplett abzudrehen – doch die erfordert einen Eingriff in die functions.php, ist also nicht “updateresistent”. Außerdem macht das entweder/oder hier sowieso keinen Sinn: die saubere Lösung bestünde ganz eindeutig darin, entweder getrennte Eingabefelder für Caption- und Alt-Content vorzusehen, oder das Caption-Feld mit einer Checkbox “insert caption” auszustatten – hoffentlich schafft die nächste WP-Version da Abhilfe.
Veröffentlicht in blogging mit WordPress, datenschmutz, digitalia | 
Schlagworte: Blog, Editor, Revision, SEO, Speicherung, WordPress, wp-config 
Danke für den Tipp. Ärgert mich persönlich auch sehr.
A) Wie Du schon geschrieben hast, die Wünsche der Community werden irgendwie entweder nicht beachtet oder scheisse umgesetzt
B) Neue Features sind nur schwer zu finden oder zu handeln http://www.discobeats.de/wordp.....es-nur-wo/
Anstatt sich immer mehr mit Google ins Bett zu legen sollten die sich mal wieder was besseres einfallen lassen
direkt antworten
Ganz deiner Meinung! Viele Features werden unausgegoren und halbfertig veröffentlicht… da passieren echt eine Menge vermeidbarer Fehler. Machen die denn keinerlei Betatest vor dem Release? Was wirklich nötig wäre, da hat Otto sehr recht, wären zusätzliche Indizes, und zwar standardmäßig. (Manche DB-Plugins legen die eh an.)
direkt antworten
Schon wieder ein Update? die Wordpress Version 2.5 ist doch auch noch nicht so alt. Naja so lange es ordentlich und stabil läuft kann es uns ja nur recht bleiben
direkt antworten
Schön, dass es für dieses “Zwangs-Feature” bereits Abhilfe gibt. Die meisten Blogger schreiben sowieso nur alleine an ihren Beiträgen, und die Datenbank wirds freuen. Ich werde das Revisions deaktivieren. Habe es bisher nie benötigt und werde künftig sicher auch ohne auskommen.
direkt antworten
Nutze wordpress.com und hab mich schon ein paar mal mit verwirrenden botschaften rumgeschlagen, dass die eine revision aktueller sei als die an der ich arbeite. dann kann man die beiden vergleichen, aber das tut sich nu wirklich keinerR an, oder? abschalten, abschalten!
direkt antworten
jetzt kommen mir zweifel, oder war es doch mit wordpress.org system? man hat einfach viel zu viele blogs heutzutage!
direkt antworten
Bei der MU-Variante auf wp.com ist das aber echt lästig, weil du das Revisions-Feature dort gar nicht abdrehen kannst.
direkt antworten
Ergänzung zur Säuberung der Datenbank von alten Revisions
In meinem Fall (betrifft mehrere Wordpress-Installationen) sind die Tabellen- und Feldnamen mit Unterstrich getrennt statt mit Bindestrich. Außerdem wird die Kennzeichnung von Revisions nicht in dem Feld “post_status” gespeichert sondern in “post_name”.
Mit folgender SQL-Anweisung werden sämtliche Revisions aus der Post-Tabelle gelöscht. Vorher unbedingt Backup anlegen(!) und prüfen, ob im Feld “post_name” Einträge wie “26-revision” oder “12-autosave-3″ vorhanden sind. Dann funktioniert auch folgendes Statement einwandfrei:
DELETE FROM 'wp_posts' WHERE ('post_name' LIKE '%-revision%' OR 'post_name' LIKE '%-autosave%')direkt antworten
Aslo mir hat die Versionierung heute schon einmal geholfen.
direkt antworten
Ja, in vielen Fällen *würde* sie ja auch Sinn machen, *wenn* denn die Revisionen in einem Table stünden… ich hab ja letztens hier diese Codepage-Katastrophe mit UTF8 und mySQL gehabt – und ich bin verdammt froh, dass im Post-Table, den ich mir Search&Replace in einzelne Nullen zerhackt und dann wieder zu UTF8 zusammengesetzt hab
(ich kann mich nur mehr verschwommen erinnern, nach 12 Stunden Ascii-Texteditor S&R überkam mich plötzlich ein spontaner Erleuchtungsanfall. Oder totale Wackness. Weiß nicht mehr genau.), nicht auch noch die Revs drin waren.
direkt antworten
Die genannten Argumente zum alt-Tag unterstütze ich. Vielleicht ist nur mir das aufgefallen: Wenn ich mit Lightbox-2 ein Bild mit aufgefülltem Caption-Feld einfüge, ist der Abstand zum Text gleich Null, ohne Caption sieht das dann mit Abstand ordentlich aus. Vielleicht liegt es nicht an WP2.6?
direkt antworten
Ups… das ist noch ärgerlicher. Lightbox zusammen mit Cpation hab ich noch gar nicht ausprobiert… ich vermute aber schon sehr stark, dass es mit der Art der Caption-Formattierung zu tun hat.
direkt antworten
Danke auch für diesen Tipp!
direkt antworten