Anzahl der WordPress Revisionen begrenzenSeit einiger Zeit beherrscht WordPress die Versionierung beim Verfassen von Artikeln und Seiten. WordPress speichert hierbei automatisch immer wieder den aktuellen Stand eines Artikels (die sogenannte Revision), sodass bei Absturz des Browsers, spontaner Akkuschwäche des Notebooks oder ausversehen gelöschten Inhalten jederzeit eine vorhergegangene Revision geladen werden kann.

Im Normalfall speichert WordPress jedoch unendlich viele Revisionen, was, je nach Größe des Blogs, Serverleistung und Anzahl der Artikel, zu einem unnötigen Overhead führen kann.

Mittels folgendem Snippet lässt sich die Zahl der gespeicherten Revisionen pro Artikel einschränken.

Oben stehendes Snippet bewirkt, dass nur noch die jeweils 10 neuesten Revisionen eines Artikels gespeichert werden. (Sofern kein anderer Wert in der wp-config.php hinterlegt wurde.) Ältere Versionen werden gelöscht. Mir persönlich reichen 10 Revisionen vollkommen aus, wer lieber auf Nummer sicher geht, kann auch einen höheren Wert wählen, wobei der positive Effekt des obigen Codes dann immer kleiner werden dürfte.

WordPress Kommentare im Frontend bearbeitenSo sehr ich mich über jeden einzelnen Kommentar in meinen Blogs freue, so sehr hasse ich Spam und Hater-Kommentare. Um diese zu löschen führt, in den meisten Fällen kein Weg am WordPress-Backend vorbei.

Mit folgendem Snippet lassen sich im Frontend (direkt auf dem Blog) für jeden Kommentar ein „Löschen““- und ein „Als Spam markieren“-Link anzeigen. Somit können unpassende Kommentare direkt beim Lesen entfernt werden, ohne in den Kommentar-Editier-Modus oder das WordPress-Dashboard zu wechseln.

Das Snippet ist so gestaltet, dass die beiden Links nur angezeigt werden, wenn ein Nutzer mit ausreichenden Berechtigungen angemeldet ist.

Nun muss die Funktion nur noch an geeigneter Stelle im Theme aufgerufen werden. (Vorzugsweise im Comment-Loop.) Als Parameter muss die ID des jeweiligen Kommentars übergeben werden.

WordPress Version nicht ausgebenStandardmäßig gibt WordPress die eigene Versionsnummer im HTML-Code einer Webseite aus. Dies bringt jedoch mehr Gefahr als nutzen mit sich. So können potenzielle Angreifer nach Bekanntwerden einer Sicherheitslücke in einer bestimmten WordPress-Version gezielt nach Blogs suchen, die mit dieser WordPress-Version betrieben werden.

Aus diesem Grund sollte, sofern kein anderer, triftiger Grund dagegen spricht, die Ausgabe der WordPress-Versionsnummer unterbunden werden. Dies kann durch hinzufügen des folgenden Snippets in der functions.php erreicht werden.

Das Snippet klinkt sich per Filter in die Ausgabe des Versionsstrings ein und ersetzt diesen durch einen leeren String, sodass die Ausgabe der WordPress Version unterdrückt wird.

RSS-Feed später ausgebenMit folgendem Snippet lassen sich Inhalte des Blogs im RSS-Feed später ausgeben. Später meint hierbei, dass ein Artikel, der um 13:30 auf dem Blog veröffentlicht wurde, zum Beispiel erst um 14:30 im Feed erscheint.

Dies mag auf den ersten Blick komisch anmuten, macht aber in diversen Szenarien Sinn. Zum Beispiel ist es denkbar, die Artikel erst mit 20 Minuten Verzögerung im Feed anzuzeigen, da man in den ersten Minuten meist noch 1-2 Fehler bemerkt und behebt, die bei sofortiger Veröffentlichung schon bereits im Feed ausgeliefert worden wären.

Ein zweites Szenario wäre zum Beispiel die Artikel erst einen Tag oder sogar eine Woche später im Feed anzuzeigen. So bekommen Feed-Leser zwar auch alle Inhalte, die Motivation direkt auf den Blog zu gehen (und somit mehr Kommentare abzugeben, etc.) steigt jedoch.

Das Snippet klinkt sich in die Erstellung der Datenbankabfrage zur Ermittlung der Feed-Inhalte ein und erweitert die Abfrage um eine weitere where-Klausel, die auf das Alter der Artikel/Inhalte (=Erstellungszeitpunkt der Artikel) eingeht.

Custom Post Types WordPress IntegrationCustom Post Types sind eine gute Möglichkeit, um in WordPress spezielle, wiederkehrende Artikelmuster zu veröffentlichen. Egal ob es sich um eine DVD-Review mit Bewertungsskala, Kochrezepte oder eine Downloadseite handelt. Custom Post Types können an diversen Stellen einen Sinn ergeben und sind relativ einfach erstellt.

Die Erstellung eines Custom Post Types ist jedoch nur die halbe Miete. Zwar lassen sich nach der Erstellung direkt Artikel im neuen Format erstellen, jedoch werden diese Artikel an diversen Stellen im WordPress-System nicht beachtet. Um Custom Post Types an allen wichtigen Stellen im WordPress-System konsequent einzuführen, sind ein paar Änderungen nötig, die ich nachfolgend kurz erklären will.

Custom Post Types in WordPress Suche aufnehmen

Um Custom Post Types in der normalen WordPress-Suche anzuzeigen, ist es nötig, einen Filter auf die the_search_query-Funktion zu setzen. Dies macht man am besten in der functions.php des jeweiligen Themes.

Nach dem Einfügen des obigen Codes, sollten eure Custom Post Types auch in der WordPress Suche angezeigt werden.

Custom Post Types in RSS-Feed ausgeben

Eine weitere Stelle, an der Custom Post Types standardmäßig nicht auftauchen, ist der RSS-Feed eines WordPress Blogs. Hier schafft ein Filter auf request Abhilfe.

Um Custom Post Types im RSS-Feed auszugeben ist oben stehender Code in die functions.php des jeweiligen Themes einzufügen.

Custom Post Types im „Auf einen Blick“-Widget anzeigen

Um Artikel, die im Custom Post Type Format verfasst sind, auch im „Auf einen Blick“-Widget im Dashboard des Backends anzeigen zu können, ist etwas mehr Code nötig.

Nun sollten auch die Custom Post Types mitgezählt und ausgewertet werden.