WordPress Beitrags Feed für Seiten

WordPress bietet standardmäßig die Möglichkeit Beiträge in einem sogenannten Feed abzurufen. Das ist hilfreich, wenn man seine Webseite automatisiert publizieren möchte, z.B. in Link-Aggregatoren oder Suchmaschinen. Nutzt man in WordPress allerdings Seiten statt Beiträge (Pages statt Posts im Englischen), dann steht diese Funktion nich zur Verfügung. Es gibt Plugins mit denen man das Problem beheben kann. Die machen aber meist noch mehr und je nachdem was man möchte sind sie auch kostenpflichtig. Für mich hat sich daher diese Lösung durchgesetzt:

/ ** * CHANGES TS ** 
* 
* Add RSS Feed for Pages 
*/ 

add_action( 'pre_get_posts', 't5_pages_in_feed' ); 

/** 
* Set post type to 'page' if it was requested. 
* 
* @param object $query 
* @return void 
*/ 

function t5_pages_in_feed( &$query ) { 
  if ( isset ( $_GET['post_type'] ) && $_GET['post_type'] === 'page' && is_feed() ) { 
    $query->set( 'post_type', 'page' ); 
    $post_ids = array(22,75,87); 
    $query->set('post__not_in', $post_ids); 
  } 
}

 

Das habe ich am Ende der functions.php angefügt (Vor Änderungen an dieser Datei sollte immer ein Backup gemacht werden). Damit kannst Du auch „Seiten“ im Feed zeigen. Bei der Variablen $post_ids musst Du noch die IDs der Seiten eintragen, die Du nicht im Feed willst. Bei mir ist das Impressum, Datenschutz und Kontakt (22, 75 und 87)
Die ID bekommst Du, wenn Du mit der Maus im WP Admin in der Seiten-Liste über den Titel fährst und den Link anschaust. Also z.B. ist der Link für meine Datenschutzseite so: https://abc.de/wp-admin/post.php?post=87&action=edit
Wenn ich die nicht haben will, muss also die 87 in die Liste.

Den Feed erreichst Du dann über https://abc.de/feed/?post_type=page
Der Parameter hinter dem Fragezeichen kümmert sich darum dass der Feed die Seiten (also Pages) enthält. Die beiden Feeds sind nun kongruent. Der normale Feed (ohne Parameter) enthält weiterhin die Beiträge (Posts), der andere die Seiten. Möchte man einen Feed für alles, dann wird das etwas aufwändiger. Je nach technischer Expertise bietet sich in einem solchen Fall dann vielleicht doch ein Plugin an.

Ein neuer Blog, warum?

Wer meine Webseite schon länger kennt, der weiss, dass ich stets darauf aus war alle Funktionalität in TYPO3 abzubilden. Zum einen, weil es sich dabei oftmals um eine Herausforderung handelte, die mein TYPO3 Wissen immer wieder auf die Probe stellte und erweiterte. So war es auch mit dem Blog.

Wie alles begann

TYPO3 hat mir stets als herausragendes Content Management System gedient und das tut es heute noch. Aber als die Blogosphäre begann sich aufzublähen wollte ich mit meiner Webseite auch ein Teil davon werden. Zunächst versuchte ich dabei wesentliche Funktionen eines Blogs mit den üblichen Bordmitteln umzusetzen. Das machte reichlich Arbeit, denn man muss ja eine Übersichtsseite produzieren mit Verlinkungen auf die Unterseiten, Blogrolls per Typoscript einbinden. Ein Unterfangen das schnell an Übersichtlichkeitsgrenzen stieß. Kommentare gabs über ein Gästebuchformular, das auf jeder Seite eingebettet war. Trackback und Pingback waren unter

eine kleine Evolution: tt_news

Eines Tages stolperte ich über eine Webseite die Beschrieben hat, wie man einen Blog mit tt_news umsetzen könnte. Man würde sich die ganze Seitenanlegerei sparen und anteasern ginge sozusagen automatisch, und im weitesten Sinne ist ein Blogeintrag ja sowas wie eine Neuigkeit. Gesagt, getan. Alles umgestellt und schon waren wesentliche Blogfunktionalitäten mit von der Partie. Man konnte automatisch zwischen den Einträgen navigieren. Kategorisierung war auch am Start und eine Teaserseite war auch schon mit dabei. Lange war das die Variante meiner Wahl, bis plötzlich eine Meldung durch das Internet kursierte.

Leichte Verbesserung: Timtab

Da machte also eine Extension im TYPO3 Umfeld von sich reden, die die Hoffnung weckte annähernd an die Funktionen einer Blogsoftware wie WordPress heranzureichen. Dabei machte die Extension nicht wesentlich viel anders als ich es vorher schon gemacht habe. tt_news und ve_guestbook wurden kombiniert und mit ein paar zusätzlichen Features verklebt. So richtig rund lief das ganze aber nie. Zumindest nicht bei mir.

Das non-plus ultra: t3blog

Als die schweizer Firma snowflake mit ihrer Extension t3blog aufschlugen ging ein raunen durch die TYPO3 Gemeinde. Eine Extension, die alle Funktionen eines Blogs mitbringen soll? Ohne Hacks und Knauperei? Ohne Kannibalisierung anderer Extensions? Das klang wie ein Traum.
Tatsächlich konnte man mit wenig Aufwand aus einem frisch aufgesetzten TYPO3 einen Blog machen. Posts, Kommentare, Teaserseiten, Blogroll, Navigation. Alles mit nur einer Extension. Trackback und Pingback sollte es auch können, hat aber zumindest bei mir nie funktioniert. Aber das war bis dato das Komfortabelste, was ich gesehen hatte.
Beim Einbau in eine bereits bestehende Seite stellte sich dann allerdings schnell heraus das t3blog nicht in erster Linie als Ergänzung für eine bestehende TYPO3 Seite gebaut wurde, sondern das Ziel eher war eine TYPO3 Instanz komplett als Blog zu nutzen.

Mein Ehrgeiz war geweckt und nach einigen Nächten hatte ich den Beweis erbracht, dass man – mit entsprechendem Aufwand – sehr wohl in der Lage ist t3blog relativ sauber in eine bestehende TYPO3 Webseite einzubauen. Für den Moment war ich zufrieden. Über anfängliche Kinderkrankheiten konnte man dann auch hinwegsehen.

Nach einiger Zeit hat sich dann aber eine gewisse Schreibfaulheit eingeschlichen. Ich hatte zwar alle Freiheiten, konnte meine Blogposts frei mit verschiedenen Contentelementen gestalten und das alles in der gewohnten TYPO3 Umgebung. Allerdings war das dann doch auch irgendwie kompliziert um mal eben schnell einen Post zu schreiben. Zumal ich zu der Zeit öfters mit dem Zug unterwegs war und das TYPO3 Backend für die regelmässigen Netzausfälle dann doch auch irgendwie etwas sperrig war. Auf iPad oder gar iPhone will man das dann auch eigentlich garnicht bedienen. So gammelte der Blog so vor sich hin.

Weg mit dem Herbstlaub

Schon zu Beginn der Blog-Ära und auch immer mal zwischendurch habe ich mit WordPress experimentiert. Ich habe sogar bei Anfragen teilweise je nach Anforderung explizit zu diesem System geraten. Und plötzlich kamen ein paar verschiedene Punkte zusammen, die mich wieder dazu veranlasst haben einen Blick auf WordPress zu werfen.

  • Wir verwenden es in der Firma als Blogging Plattform
  • Es gibt für WordPress einen iPad und iPhone Client um relativ komfortabel auch mal unterwegs was zu schreiben
  • Ich wollte zusätzlich mit responsive Design experimentieren und auch den gesamten Webauftritt deutlich erfrischen
  • Snowflake selbst hat sich WordPress als Blogging Plattform zugewandt

Finally … WordPress

So habe ich mir einige Tage gegönnt und mich mit WordPress bekannt gemacht. Wenn man keine speziellen Anforderungen hat, ist man auch sehr schnell am Start. Ich habe mir zunächst mal das erstbeste responsive Design Template geschnappt und versucht es an meine Vorstellungen anzupassen. Teilweise war ich dabei der Verzweiflung nahe. Zum Glück habe ich dann – nachdem ich zugegebenermaßen einiges gelernt habe – noch ein Template gefunden, dass den grössten Teil meiner Wünsche abdeckt. Dazu noch ein paar Plugins und fertig. Herzlich Willkommen im neuen Blog

Was euch jetzt erwartet

Zunächst habe ich jetzt ein neues Spielzeug, das ich vermutlich in der nächsten Zeit häufiger nutzen werde. Ihr könnt also zuallererst mal mehr Aktivität erwarten. Da ich meine Bloggingtätigkeit nun in ein System verlagere, dass genau für diese Zwecke ausgelegt wurde, sollten auch die typischen Blogrelevanten Funktionen nun einfach funktionieren. Hinzu kommt, dass ich mich auch dazu entschieden habe, meine Fotos nicht mehr in TYPO3 anzeigen zu lassen, sondern ebenfalls hier im Blog.

Wenn ich jetzt wieder ein bisschen Zeit finde, dann werde ich das Design der Webseite ebenfalls anpassen und beide Systeme miteinander verknüpfen. Bis dahin bitte ich euch, den grafischen Bruch zu entschuldigen.

Zu guter letzt könnt ihr meinen Blog dank responsive Design nun auch auf Mobilgeräten in angepasster Form bewundern. Über eure Erfahrungen und Feedback freue ich mich natürlich jederzeit.

Outlook Express zu Thunderbird Umzug

Nachdem ich nun ca. 2 Stunden dran rumgebastelt habe eine Outlook Express Mailbox zu Thunderbird umzuziehen und ich vermutlich nicht der erste bin, der sowas in seinem Leben mal machen muß, habe ich mich entschlossen eine kleine Hilfestellung zu schreiben, aber zuerst mal das Problem.

Das Problem – warum nicht gleich Thunderbird?

Ein enger Familienangehöriger hat seit einigen Jahren seinen eMail-Verkehr über Outlook Express auf einem Windows PC abgewickelt. Obwohl IMAP als primäres Protokoll eingerichtet war, wurden lokale Ordner angelegt, in die eMails einsortiert wurden. Vor kurzem entscheidet sich der Computer dazu keine Lust mehr auf Funktionieren zu haben. Ein neuer Rechner soll demnächst angeschafft werden. Diesmal aber kein Windows PC mehr. Es soll ein Mac sein.
Alles kein Problem, denkt sich der erfahrene Administrator: IMAP für Mails ist ja schließlich eingerichtet und die Daten von der Festplatte können wir ja auch noch retten. Ja, denkt er, bis ihm die lokalen Ordner beim Stöbern auffallen. Die müssen ja jetzt irgendwie wieder rekonstruiert werden, aber auf dem Mac gibts kein Outlook Express. Qué lastima!

Voraussetzung und Werkzeug

Für wen sind die nächsten Schritte gedacht und was braucht man dazu? Wenn Du ungefähr folgende Ausgangssituation hast bist Du schonmal richtig:

  • .dbx Dateien aus einem Outlook Express Profil oder Backup
  • Den Wunsch die Mails in Zukunft in Thunderbird zu haben (z.B. Mac)

Bevor wir loslegen brauchen wir folgende Werkzeuge:

  • Eine Windowsinstallation (z.B. VM oder Rechner von einem Bekannten)
  • Das dbxconv Tool von Ulrich Krebs [1]
  • Das Zielsystem mit einem installierten und mit einem Account eingerichteten Thunderbird

Die Lösung

Von jetzt an geht’s eigentlich ganz schnell. Einfach die folgenden Schritte ausführen und freuen:

  • .dbx Dateien und dbxconv Tool in ein gemeinsames Verzeichnis auf dem Windowsrechner legen
  • Ein Terminal starten und im Verzeichnis „dbxconv *.dbx“ ausführen (Bestimmte dbx Dateien lassen sich nicht umwandeln, weil sie von Outlook Express für die interne Verwaltung verwendet werden und keine Mails enthalten, z.B. folders.dbx)
  • Die .mbx Dateien auf dem Zielsystem im Thunderbird-Profil ablegen. Unter MacOS befindet sich dieses unter ~/Library/Thunderbird/Profiles/<PROFIL_NAME>/Mail/Local Folders
  • Beim starten von Thunderbird werden die Mails jetzt in Ordnern angezeigt, die so heißen wie die Datei.

Ab jetzt muß man sich entscheiden, was man möchte. Ich persönlich würde jetzt neue Ordner auf dem Server anlegen und dann die Mails dort hinein kopieren/verschieben. Aber vorsicht, je nachdem um wie viele Mails es sich handelt kann das abhängig von der Internetanbindung einige Zeit in Anspruch nehmen.

Referenzen

[1] http://www.ukrebs-software.de/german/dbxconv/dbxconv.html

Mutt löscht eMails schnell und sauber

Welcher Systemadministrator kennt das nicht: Ein Service wird als bestimmter Benutzer installiert und läuft dann so vor sich hin ohne signifikante Ausfallerscheinungen, ggfs. noch unter Beteiligung eines Cron-Jobs. Irgendwann bekommt man mit (z.B. durch logwatch), dass das Postfach dieses Benutzers plötzlich ein bisschen umfangreicher geworden ist. Ein Blick in die Mailbox verrät, es handelt sich um Ausgaben des Cron-Jobs, die nach Beendigung jedes Durchlaufs per eMail an den Cron-Job Besitzer zugestellt werden. Man erhält also recht viele, kleine, hutzelige eMails, im aktuellen Fall 64000. Mit einem eMail-Client jede einzeln zu löschen dauert vermutlich ewig. Mit ‚mutt‘ läßt sich das aber recht elegant lösen.

Shift+d
~s .*

Mit Shift+d (also einem großen D) wechselt man in einen Modus in dem man eine Löschregel angeben kann. In unserem Fall prüfen wir den Betreff (~s) und löschen alles (.*). Auf diese Weise könnte man z.B. auch alle Mails löschen die „SPAM“ in ihrer Betreffzeile enthalten (.*SPAM.*).

Lust auf mutt bekommen?

Für weiterführende Informationen bzgl. mutt und der verwendbaren Patterns seien euch folgende URLs ans Herz gelegt:
mutt patterns
mutt manual

PostgreSQL update problem on CentOS

Als ich heute in meiner Linux-VM auf die aktuelle pgdg postgreSQL Version aktualisieren wollte, wurde ich mit folgender Fehlermeldung abgespeist:

warning: rpmts_HdrFromFdno: Header V3 DSA signature: NOKEY, key ID e8e345b8
pgdg84/gpgkey
Public key for pgdg-centos-8.4-2.noarch.rpm is not installed

Das Problem liegt darin begründet, dass die Maintainer ihre Pakete mit einem neuen vereinheitlichten Key signieren, der allerdings bei einem Update nicht sofort vorliegt. Es gibt die Möglichkeit das Paket herunterzuladen und es nicht über yum sondern direkt per rpm zu installieren. Zum anderen kann man den Key auch auf dem Server einspielen und danach den Update-Prozess erneut starten. Zweitere Methode ziehe ich persönlich vor:

  1. Den Key hier runterladen: CMD-PGDG-KEY
  2. Als User root folgenden Befehl ausführen: rpm –import CMD-PGDG-KEY
  3. Update erneut starten: yum update

Wer sich für die erste Variante interessiert, kann die Schritte hier nachlesen.

Komische Standardeinstellung Apache+Debian Etch

Durch einen Serverabsturz bin ich heute auf eine etwas verwirrende Standardeinstellung im Apache gestoßen, die laut einigen Foren offenbar nur Debian Etch betrifft.

MaxRequestsPerChild 0

macht den Apache in einigen Situationen zu einem Speicherfresser. Das ganze geht soweit, das der Kernel keinen neuen Speicher mehr allociieren kann, kein Speicher mehr für andere Anwendungen zur Verfügung steht und das System damit lahmgelegt wird. Das ganze äußert sich zunächst dadurch das außer PING nichts mehr funktioniert. Ein Server reboot richtet dann wieder alles, allerdings ist es dann nur eine Frage der Zeit, bis das Problem erneut zuschlägt. Wer in seinem „syslog“ Meldungen finden, die wiefolgt aussehen:

kernel: Mem-info:
kernel: Node 0 DMA per-cpu:
kernel: cpu 0 hot: high 0, batch 1 used:0
kernel: cpu 0 cold: high 0, batch 1 used:0
kernel: Node 0 DMA32 per-cpu:
kernel: cpu 0 hot: high 186, batch 31 used:179
kernel: cpu 0 cold: high 62, batch 15 used:49
kernel: Node 0 Normal per-cpu: empty
kernel: Node 0 HighMem per-cpu: empty
kernel: Free pages:        8012kB (0kB HighMem)
kernel: Active:117054 inactive:113464 dirty:0 writeback:0 unstable:0 free:2003 slab:5445 mapped:1 pagetables:11467
kernel: Node 0 DMA free:3996kB min:24kB low:28kB high:36kB active:3980kB inactive:3840kB present:6556kB pages_scanned:9555 all_unreclaimable? yes
kernel: lowmem_reserve[]: 0 993 993 993
kernel: Node 0 DMA32 free:4016kB min:4016kB low:5020kB high:6024kB active:464236kB inactive:450016kB present:1017008kB pages_scanned:1088596 all_unreclaimable? yes
kernel: lowmem_reserve[]: 0 0 0 0
kernel: Node 0 Normal free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no
kernel: lowmem_reserve[]: 0 0 0 0
kernel: Node 0 HighMem free:0kB min:128kB low:128kB high:128kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no
kernel: lowmem_reserve[]: 0 0 0 0
kernel: Node 0 DMA: 1*4kB 1*8kB 1*16kB 0*32kB 0*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 1*2048kB 0*4096kB = 3996kB
Feb 24 15:19:42 catfish kernel: Node 0 DMA32: 2*4kB 15*8kB 9*16kB 5*32kB 10*64kB 1*128kB 1*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 4016kB
kernel: Node 0 Normal: empty
kernel: Node 0 HighMem: empty
kernel: Swap cache: add 3754206, delete 3754206, find 550796/967590, race 100+121
kernel: Free swap  = 0kB
kernel: Total swap = 2104504kB
kernel: Free swap:            0kB
kernel: 261872 pages of RAM
kernel: 5006 reserved pages
kernel: 46543 pages shared
kernel: 0 pages swap cached
kernel: printk: 180 messages suppressed.
kernel: oom-killer: gfp_mask=0x201d2, order=0
kernel:
kernel: Call Trace:
kernel:  [<ffffffff802a666e>] out_of_memory+0x33/0x216
kernel:  [<ffffffff8020e020>] __alloc_pages+0x220/0x2a9
kernel:  [<ffffffff80210db1>] __do_page_cache_readahead+0x95/0x206
kernel:  [<ffffffff8022683e>] sync_page+0x0/0x42
kernel:  [<ffffffff8025cad3>] io_schedule+0x28/0x33
kernel:  [<ffffffff8022683e>] sync_page+0x0/0x42
kernel:  [<ffffffff8025cd6a>] __wait_on_bit_lock+0x5b/0x66
kernel:  [<ffffffff8023d749>] __lock_page+0x5e/0x64
kernel:  [<ffffffff802116ed>] filemap_nopage+0x148/0x314
kernel:  [<ffffffff80208718>] __handle_mm_fault+0x375/0x91a
kernel:  [<ffffffff8020a69c>] do_page_fault+0x39d/0x706
kernel:  [<ffffffff8025c35e>] thread_return+0x0/0xe7
kernel:  [<ffffffff802588e5>] error_exit+0x0/0x84

der sollte mal in sein Apache Konfigurationsfile schauen und darüber nachdenken den besagten Wert z.B. wiefolgt abzuändern:

MaxRequestsPerChild 100

Damit wird verhindert, dass der Prozess Amok läuft, denn nach 100 Requests wird er einfach abgesetzt und ein neuer tritt an seine Stelle. Mal sehen, ob das jetzt auch hilft…