Artikel mit Tag serendipity
Verwandte Tags
autotitle bartleby blogs ursprung buzz commentedit dbclean listsearch projekt markupcomment nl2p photo android feedtragón ice-prefer ice-win icewm idesk-helper image-sacon izulu nachhaltigkeit pc-kombo rsspusher simdock sustaphones pubsubhubbub reallivecomment realtimecomments spamblock_bayes template_editor dsnblog rubyEmails für einen IPv6-Server trotz Cloudflare per Uberspace
Wednesday, 29. April 2020
Ich habe gerade diesen Serendipity-Blog auf einen neuen Server umgezogen (dazu später mehr). Das schwierigste war, die Emails wieder zum Laufen zu kriegen. Deshalb muss ich das unbedingt dokumentieren.
Das Setup sieht so aus: Der Server ist die kleinste Cloud-Compute-Instanz bei Vultr. Ich habe mal wieder den Preis optimiert. Sie kann nur IPv6. Nicht ganz so schlimm, denn die Domain wird von Cloudflare verwaltet, was für jeden AAAA-Eintrag direkt einen A-Eintrag bereitstellt, also Zugang per IPv4. Cloudflare aber ist problematisch, um direkt vom Server Emails zu verschicken. Aber dafür ist noch uberspace dabei, das sowieso meine Emails verwaltet und hier als SMTP-Relay dient.
Ich zeige alles im Detail.
uberspace
Uberspace muss die Domain als Email-Domain führen. Das wird in der Anleitung erklärt und ist nur ein auf uberspace per SSH abzusendender Befehl.
Der vordere Teil der Emailadresse muss auch angelegt sein. Bei mir ist das postmaster@...
. So sieht das in der Verwaltungsoberfläche aus:
Beachte, dass jeder Account bei uberspace bei einem von mehreren Servern liegt. In den Konfigurationen unten werde ich den Servernamen immer mit UBERSPACEHOST
ersetzen, damit niemand aus Versehen den meinen verwendet.
Cloudflare
Ich gehe davon aus, dass Cloudflare als DNS-Server eingerichtet ist. Das variiert je nach Hoster, der die Domain gerade verwaltet, aber man sollte da den Nameserver übertragen können.
Für den Webserver zeigt Cloudflare auf die IP des Server. Für die Email zeigt der MX-Eintrag auf den jeweiligen Uberspace-Host und ein TXT-Eintrag aktiviert SPF:
Mehr muss Cloudflare nicht tun, es braucht auch insbesondere und anders als die Dokumentation für Email-Versand rät keinen Nameserver-Eintrag, der ohne Proxy auf die IP zeigt. Denn der Server versendet die Mails ja nicht direkt.
Server/Postfix
Serendipity ist konfiguriert, Emails als postmaster@onli-blogging.de zu senden. Wordpress müsste man genauso einstellen.
Auf dem Server leitet postfix die Emails an uberspace weiter. Das ist im wesentlichen diese Anleitung. Die /etc/postfix/main.cf muss editiert werden:
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu) biff = no append_dot_mydomain = no readme_directory = no compatibility_level = 2 smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key smtpd_tls_security_level=may smtp_tls_CApath=/etc/ssl/certs smtp_tls_security_level=may smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 mailbox_size_limit = 0 recipient_delimiter = + inet_interfaces = all inet_protocols = all myorgin = /etc/mailname mydestination = onli-blogging, localhost.localdomain, localhost myhostname = onli-blogging.de relayhost = UBERSPACEHOST.uberspace.de:submission smtp_sasl_auth_enable = yes smtp_sasl_security_options = noanonymous smtp_sasl_tls_security_options = noanonymous smtp_sasl_password_maps = hash:/etc/postfix/sasl_password
Nur der letzte Abschnitt ist abgeändert. Dort wird der Mailserver und die eigene Domain als Absender gesetzt. In /etc/mailname steht übrigens nur nochmal die Domain:
onli-blogging.de
In /etc/postfix/sasl_password müssen die uberspace-Zugangsdaten angegeben werden. Das ist einfach die Hauptemail und das SSH-Passwort:
UBERSPACEHOST.uberspace.de:submission UBERSPACE_EMAIL:UBERSPACE_PASSWORD
UBERSPACE_EMAIL
könnte beispielsweise xyznutzer@UBERSPACEHOST.uberspace.de
sein. Diese Datei muss noch umgewandelt werden:
postmap /etc/postfix/sasl_password
Jetzt sollten Emails rausgehen und ankommen!
Rückblick auf das virtuelle Serendipity-Camp (und neues zu utf8mb4)
Wednesday, 25. March 2020
Traditionell treffen sich die Mitstreiter des Serendipity-Projekts einmal jährlich im Linuxhotel in Essen. Geplant war es dieses Jahr am gerade vergangenen Wochenende. Corona hat uns das natürlich unmöglich gemacht. Stattdessen haben wir uns online getroffen, am Samstag per Jitsi Meet, am Sonntag gab es noch etwas Aktivität im Slack-Chat.
Es ist natürlich nicht das gleiche. Und Gedanken, da strukturiert mehr zu bieten als nur da zu sein und eventuell gemeinsam zu diskutieren und entwickeln waren nach dem Schwenk auf online (bei mir zumindest) ganz schnell weg. Trotzdem ist so etwas super wertvoll: Niemals sonst kann man sich so gut abstimmen, selten nehmen sich so viele Zeit für das Projekt. Und es ist schön, die anderen zu hören, auch neue Stimmen waren dabei :)
Im Ergebnis haben wir meiner Meinung nach superwichtige Sachen umgesetzt. Spartacus war stehengeblieben und unser uberspace musste umgezogen werden (von uberspace 6 auf uberspace 7), beides wurde angegangen. Wir haben die neue Version 2.3.3 veröffentlicht, sie vorher getestet und die Änderungen angeschaut. Da steckt besonders viel Arbeit von Thomas drin. Und wir haben – endlich! – Fortschritte mit MySQLs kaputtem utf8 gemacht.
Vor Jahren ist Serendipity bei Nutzung von MySQL in die utf8-Falle gelaufen. Es betrifft wirklich nur diese Datenbank. MySQL hat einen Zeichensatz namens utf8, der aber kein volles utf8 unterstützt, sondern nur Zeichen mit drei Byte. 4-Byte-Zeichen, z.B. Emoji wie 💩, kann man damit nicht speichern (hier geht es, weil ich SQLite benutze), Serendipity schneidet Texte dann ab. Daraus herauszukommen ist schwer, denn: Wenn man auf utf8mb4 umstellt braucht ein Zeichen 4 Bytes, Indexe können aber nur 1000 Bytes lang sein. Ein Index über eine varchar(255)
-Spalte würde dieses Limit schon sprengen! Wir hatten darüber schonmal auf einem Treffen geredet und Garvin hatte eine mögliche Lösung gebaut, Code, der die Indexe anpasst und dann die Datenbank umstellt. Aber diese Lösung lebt nun schon eine Weile in ihrem eigenen Branch und wurde nicht getestet (es zu testen ist schwierig! Vor allem, wenn man wie ich bisher das Problem nicht richtig verstanden hatte).
Jetzt haben wir nochmal darüber geredet und sind über einen Umweg über eine alternative Lösung gestolpert, deren Ansatz hier zu finden ist. Wenn die MySQL/MariaSQL-Datenbank neu genug ist, kann man die Storage Engine auf InnoDB setzen, wodurch Indexe 3000 Byte lang sein dürfen. Genug auch mit utf8mb4 für unser Datenbankschema!
Mittlerweile stellte sich raus, es ist nicht ganz so einfach, es müssen auch ein paar Einstellungen stimmen. Die können wir nicht im Code setzen, aber wir können sie prüfen. Dann wird das wohl sicher funktionieren, wenn es denn geht. Hoffentlich also eine praktische Lösung, die ohne die Versuche beim Treffen (wie mein Scheitern an der Idee, Dirks Blog umzustellen, weil da noch nicht durchgängig utf8 benutzt wird -> sowas muss also beachtet werden) nicht zustandegekommen wäre.
Das Ziel des verlinkten Codes ist es, Neuinstallationen mit utf8mb4 zu erstellen wenn möglich. Ich habe zweitens einen Upgrade-Task gebaut, um bestehende utf8-Installationen auf utf8mb4 umzustellen. Dann brauchen wir nur noch einen dritten Schritt, um von alten Zeichensätzen zu utf8mb4 zu kommen, und alle Blogs hätten vollen Unicode-Support.
Mir hat das Treffen Spaß gemacht. Klasse, alle wiederzusehen, toll auch, sich am Samstag nach dem Corona-Wochenendeinkauf voll auf etwas ganz anderes konzentrieren zu können, und am Sonntag nebenher am utf8-Problem zu basteln.
Auf ein nächstes mal, bald oder nächstes Jahr, online oder in Essen.
Edit: Das schrieben die anderen:
- Thomas auf Netz - Rettung - Recht: Das virtuelle #s9ycamp2020
Serendipity 2.3.1
Wednesday, 21. August 2019
Mit 2.3.1 gibt es ein gar nicht so ganz kleines Patch-Release kurz nach der Veröffentlichung von 2.3.0. Es sind vor allem Schönheitskorrekturen wie das nun wieder mögliche Löschen mehrerer Mediendatenbankeinträge auf einmal. Gerade deswegen ist ein höchsterfreuliches Release, das Thomas in seinem Blog zusammen mit weiteren Entwicklungen näher beschreibt.
Serendipity 2.3
Tuesday, 13. August 2019
Die neue stabile Version 2.3 von Serendipity war nötig. PHP bricht einfach immer mehr als stabile Grundlage weg, überspitzt ausgedrückt – die Versionen werden weniger lange unterstützt und die neuen haben gravierende Änderungen. Also muss Serendipity angepasst werden und die Version mit diesen Anpassungen auch zeitnah erscheinen. In meinem Kopf ist 2.3 solch eine erzwungene Version. Denn nun kann Serendipity mit PHP 7.2, 7.3 und 7.4 laufen, bevor 7.1 wegbricht.
Andererseits ist das der neuen Version gegenüber gar nicht fair. Denn einige der Änderungen – weniger zur Alpha, sondern zur letzten stabilen Version – sollten ziemlich bedeutsam sein und Serendipity deutlich verbessern. Mehr noch, wenn sie in der Zukunft noch mehr Feinschliff erhalten und sich alles mehr noch zu einem organischen Ganzen zusammenfügt. Wo ich mitspielte meine ich damit unter anderem: Die Galleriefunktion (Interface), responsive images (Feintuning), den Maintenance-Modus (für Upgrades) und den neuen voku/simple-cache (Redis!).
Was auch für das Release spricht ist die Commitliste: Es sind viele Verbesserungen vieler Autoren drin. Unter anderem, jeweils ein Beispiel: Mario hat das Timeline-Theme unter PHP 7.2 repariert, Don Chambers es generell aktualisiert, Thomas hat an mehr Stellen Patches beigesteuert als mir klar war (und nebenbei den Überblick behalten auch für 2.1.x sowie das Release gestemmt!), hannob Sicherheitslücken aufgedeckt, Matthias das HTML der Bildunterschriften modernisiert, Garvin die Überarbeitung der Mediendatenbank fertiggestellt und so überhaupt erst möglich gemacht, Mitch hat den Trackbackfresser gefunden und Stephan Brunker nl2br/nl2p verbessert.
Trackback-Fresser in Serendipity gefunden
Monday, 18. March 2019
Mitch hat es in seinem Artikel gut erklärt: Serendipity aß Trackbacks. Das war bekannt, aber die Ursache war bis jetzt unklar. Mitch stolperte aber darüber, als Thomas seine Webhook-Artikelreihe verlinkte und da eben immer nur ein Trackback ankam, ließ nicht locker und fand die Ursache.
Schuldig war eine Spamblockoption. "Keine doppelten Kommentare erlauben" wurde nicht nur auf Kommentare angewandt, sondern auch auf Trackbacks (nicht aber auf Pingbacks!). Wenn dann ein Artikel mehrere Artikel eines anderen Blogs verlinkte schlug diese Einstellung zu, denn es passt ja genau – der Inhalt des Trackbacks ist eben jeweils der gleiche.
Besonders mies war dieser Teil der Abfrage:
$_SERVER['REMOTE_ADDR'] != $_SERVER['SERVER_ADDR']
Die Einstellung griff also nicht im eigenen Blog. Also, nicht in meinem Entwicklungsblog. In diesem Blog hier schon, weil durch Cloudflare die REMOTE_ADDR
eben doch von der SERVER_ADDR
abweicht. Sonst wäre vielleicht das Schema schon vorher klar geworden.
Ich habe nun das Spamblock-Plugin im Master aktualisiert:
- Die Option greift jetzt nur noch bei Kommentaren.
- Außerdem ist sie standardmäßig aus, weil sie selbst bei normalen Kommentaren zu viele valide verbieten wird.
Vielleicht sollten wir sie wie im Artikel argumentiert grundsätzlich intelligenter machen. Andererseits haben wir mit dem Bayes-Plugin und der Spamblock-Bee bereits bessere Alternativen zur Hand.
Vielen Dank an Mitch fürs Debuggen! Genau solche investierte Zeit und Arbeit kann Serendipity derzeit sehr gut gebrauchen.
Gesammelte Update-Wehwechen nach der Serendipity-Woche
Tuesday, 19. February 2019
Alles in allem lief der Blog nach dem Upgrade auf die Alpha gut, aber es gab doch noch ein paar Probleme.
Nicht alle hier genutzten Plugins waren kompatibel mit PHP 7.2. Zuerst bemerkte ich das Sitemaps-Plugin, damit installiert konnte ich keine Artikel abspeichern. Ich patchte das, aber es ist ein notdürftiger Patch und das Plugin braucht einen Maintainer, der es mal durchtestet und aufräumt. Dafür steht jetzt auch ein Issue auf Github.
Das zweite problematische Plugin war mein Bayes-Plugin, das beim Lernen eines Kommentars als Spam oder valid einen Fehler wegen einer Konstante warf, die ein String sein müsste. Der Patch ist hier und damit schon in Spartacus.
Problematischer waren ein paar Installationsspezifische Besonderheiten. Mein Blog benutzt je ein eigenes Theme, einen modernisierten Fork von codeschmiede. Nach dem Upgrade war die Kommentardarstellung falsch, das Datum fehlte und die Seitenleiste sah ebenfalls kaputt aus. Aber nicht direkt, erst nachdem ich wegen eines anderen Fehlers templates_c/ leerte. Tatsächlich war da mein Theme etwas kaputt, was ich dann auch im Testblog nachvollziehen konnte, aber vorher im Blog wohl wegen gecacheter Smarty-Dateien nicht bemerkte.
Drei Commits adressierten weitere Fehler im Kern. Erstmal mussten die Funktionen des internen Caches neu strukturiert werden, weil ich vorher die Cachedauer nicht gesetzt hatte. Jetzt sitzen die Funktionen auch an einer besseren Stelle im Kern und sind so leichter anderswo nutzbar. Dann fand ich einen weiteren Konstanten-Fehler. Und schließlich bemerkte Matthias, dass Seiten die eine 404-Fehlerseite anzeigen sollten stattdessen einen internen Fehler produzierten, was angesichts des Ausbleibens des Fehlers mit 2k11 scheinbar auch mit meinem Theme zusammenhängt. Der simple Patch war leider schwer gefunden.
Es bleibt noch ein Fehler: Gerade kann ich keine Preview dieses Artikel erstellen. Die Fehlermeldung besagt
Ihr Browser hat keinen gültigen HTTP-Referrer übermittelt. Dies kann entweder daher kommen, dass Ihr Browser/Proxy nicht korrekt konfiguriert ist, oder dass Sie Opfer einer "Cross Site Request Forgery (XSRF)" waren, mit der man Sie zu ungewollten Änderungen zwingen wollte. Die angeforderte Aktion konnte daher nicht durchgeführt werden.
Sowas sah ich auch vorher schonmal, aber dann half immer ein erneuten Klicken auf den Vorschau-Button, diesmal nicht. Das könnte an PHP 7.2 hängen oder auch an meiner Überarbeitung des Autologin-Tokens, wobei seltsam ist dass es in meinem Testblog nicht einmal auftrat. Da muss ich nochmal ran.
Der letzte Tag der Entwicklungswoche: Hier läuft jetzt Serendipity-2.2.1-alpha2 und PHP 7.2
Friday, 15. February 2019
Die Installation war der letzte Schritt. Ich hatte ja gestern schon angekündigt, damit die Woche abschließen zu wollen. Was nicht völlige Inaktivität bedeuten soll, aber andere Projekte (Pipes!) kriegen erstmal wieder Priorität.
Das Upgrade auf die aktuelle Version funktionierte, was aber auch kein Wunder ist wenn der Upgrader fast keine Aufgabe durchführen muss. Allerdings begrüßte mich der Blog danach mit einer Fehlermeldung: Er konnte voku/simple-cache nicht laden. Ich hatte vergessen die aktualisierten composer-Dateien hochzuladen, dass das nötig ist war mir gar nicht klar. Schnell nachgeholt scheint erstmal alles zu laufen, wenn nicht wird sich das jetzt zeigen. Aber ich bin zuversichtlich, dass der Code jetzt mindestens reif für eine Beta ist.
Mir hat die Woche Spaß gemacht. Serendipity ist eben ein altes PHP-Projekt, mit allen Vor- und Nachteilen. Zu den Nachteilen gehören die vielen Workarounds für teils jahrealte PHP-Absonderlichkeiten und die Codestruktur und Qualität mancher Ecken im Kern, die dann eben den Standards von PHP-Projekten vor 15 Jahren entsprechen.
Aber die Vorteile zählen eben auch: Es ist ein stabiles und simpel gehaltenes Framework, das extrem aufs Bloggen ausgelegt ist, in dem sich manche Features erstaunlich komfortabel umsetzen lassen. Mit jeder neuen PHP-Version seit PHP 7 bekommen wir eine ganze Menge Verbesserungen der Sprache und in ihrem Ökosystem umsonst, die einzubauen und generell den Code zu verbessern ist lohnenswerte Arbeit. Auch haben sich meiner Meinung nach in den letzten Jahren viele Verbesserungen im Kern angesammelt, welche die Weiterentwicklung desselben, aber auch die Pluginentwicklung besser machen. Zusammengenommen ist die Arbeit an Serendipity derzeit besonders erfreulich. Ich kann jeden nur einladen, sich mal an einer neuen Funktionalität, einem Bugfix oder einem Plugin zu probieren.
Serendipity-Entwicklungswoche, Tag 6: Kleine Verbesserung der Mediendatenbank und des Podcast-Plugins
Thursday, 14. February 2019
Heute reichte es nur für eine kleine gestern überlegte Verbesserung der Mediendatenbank und ich muss mich beim Aufschreiben beeilen, um nicht in den letzten Tag der Entwicklungswoche zu rutschen.
IDs für Nicht-Bilder
Mindestens der aktuelle Code der Mediendatenbank könnte auch Links in Einträgen zu per Mediendatenbank eingefügten Dateien umbiegen, wenn diese umbenannt oder verschoben werden. Dateien meint hier Dateien im Gegensatz zu Bildern, denn bei Bildern geht das ja schon lange. Doch bisher wurden die Dateien ignoriert weil sie beim Einfügen keine ID mit in den Eintrag geschrieben bekommen haben. Das habe ich nun geändert und getestet, dass das Umbenennen tatsächlich den Link umschreibt.
IDs für das Podcast-Plugin
Die IDs für Audiodateien im Eintrag zu haben ist eine Voraussetzung für das Podcast-Plugin, das jetzt die ID auslesen und damit auf die Datei auf dem Server zugreifen kann. Ich habe den Code dafür nur angelegt und damit schonmal den Wrapper für den Player angepasst, das war vorher auf Übersichtsseiten wie der Hauptseite des Blogs noch kaputt. Der nächste Schritt wäre mittels der ID die Originaldatei auszulesen und so Informationen wie die Länge der Aufzeichnung ins Markup des Players aufnehmen zu können.
Unschön an dem ganzen ist, dass ich nach der Entwicklungswoche dann immer noch ein konkret anstehendes Serendipity-Projekt haben werde. Andererseits ist das Podcast-Plugin ganz spannend und ich glaube, dass es mit vertretbarem Aufwand in einen guten Zustand kommen kann. Morgen werde ich mich aber statt dem Plugin meinem Blog widmen, diese Installation auf die Alpha aktualisieren und schauen, ob es dort noch Probleme gibt.
Serendipity-Entwicklungswoche, Tag 5: Nochmal ein nochmal, diesmal XML_RPC und Podcasts
Wednesday, 13. February 2019
Wie gestern habe ich an diesem Tag der Entwicklungswoche mit den bundled-libs angefangen, ungleich gestern habe ich mit einem Entwurf für ein neues Plugin aufgehört.
XML_RPC und PHP 7.2 war doch noch kaputt
Warum auch immer ich vorher keine Fehlermeldung bekam, das XML_RPC-Modul hatte noch andere Inkompatibilitäten als nur den veralteten Konstruktor von vorgestern. An drei Stellen wurde noch das genauso veraltete each
benutzt. Leider ist die letzte Version upstream von 2011 und die Library mit einer anderen auszuwechseln wäre wesentlich mehr Arbeit als es das beim Cache war. Also habe ich einen Patch gebaut. Eine besser gepflegte Version wie phpxmlrpc einzubauen wäre schöner und ich hoffe, jemand anders macht das irgendwann. Mir reicht erstmal die Zeit dafür nicht.
Podcasts
Warum "nochmal Podcasts" wenn ich über Podcasts noch gar nicht sprach? Es ist ein lange geäußerter Wunsch von Dirk und anderen, der schon mehrmals an der Komplexität des Themas scheiterte. Wobei das Fehlen von podcastenden Entwicklern sicher auch nicht hilft, ich zum Beispiel habe nur wenig Ahnung was genau gebraucht wird.
Im Geiste der Woche habe ich diesmal trotzdem angefangen, so gut es eben geht. Herausgekommen ist das hier:
Man kann sich das auch anhören, ich habe vor dem Schreiben des Plugins einen Mini-Podcast über meine Ideen für dieses Plugin aufgenommen.
Was man im Screenshot nicht sieht ist das enclosure im RSS-Feed, aber das ist da. Ebenfalls nicht zu sehen ist etwas weniger erfreulicheres: Das Plugin hat ein konzeptionelles Problem. Weil die Mediendatenbank Audio-Dateien ohne ID in Artikel einfügt fehlt diese ID dem Plugin. Deswegen kann es bisher nur mit der URL arbeiten, es kann noch nicht die Audiodatei auf dem Server direkt anschauen. Aber wir können ja jetzt besprechen ob das wirklich nötig ist, dann würde ich morgen versuchen das im Kern umzubauen.
Wer das Plugin testen will kann sich den Quellcode auf Github anschauen und herunterladen. Es ist definitiv noch nicht fertig, aber wenn es fertig werden soll braucht es Feedback von Podcastern.
Serendipity-Entwicklungswoche, Tag 4: Über die Bundled-Libs zu Smarty und nochmal zum Cache
Tuesday, 12. February 2019
Heute war mein Einsatz ähnlich kurz wie gestern, aber gefühlt was es bisher einer der produktivsten Tage der Entwicklungswoche. Ich kam nämlich zum letzten Punkt meiner Agenda und konnte dort völlig überraschenderweise ein tolles neues Feature einbauen.
Smarty Pflichtupgrade
Aber erstmal zu Smarty. Im Forum hatte chris_goe eine seltsame Datei gemeldet, eine Verknüpfung, die upstream in das damalige Smarty-Release gerutscht war. Seitdem gab es sowieso neue und sogar Sicherheitsupdates beinhaltende neue Versionen. Also löschte ich das gesamte Smart-Verzeichnis und ersetzt es mit einem neuen Release, diesmal auch darauf achtend den Demo-Ordner zu entfernen. Der Commit ist leider unlesbar riesig, weil an irgendeiner Stelle automatisiert die Codeformatierung verändert wurde (ob bei uns im Code oder auf Seite von Smarty werde ich zwecks Ärgervermeidung nicht recherchieren). Immerhin funktioniert s9y mit der neuen Version weiterhin und scheinbar problemlos.
Ein besserer Cache
Smarty zu aktualisieren war Pflicht, nochmal den Cache anzugehen war eine Freude. Eigentlich wollte ich nur Cache/Lite ebenfalls aktualisieren, stolperte dabei aber über voku/simple-cache. Das ist ein mehrere Systeme unterstützender Cache-Layer: Tolle Optionen sind memcached und Redis. Und als Fallback dient OpCache, bei dem ähnlich wie mit Cache/Lite eine Datei erstellt wird. Gut, dazu gibt es nochmal ein Fallback, ein für uns unnützes nicht-persistentes Speichern im Array, aber OpCache sollte überall an sein.
Erst dachte ich "cool, aber wir haben ja schon Cache/Lite und das Projekt sieht etwas zu klein aus". Dann sah ich das:
Wir brauchen sowieso möglichst bald eine neue Cache-Lösung. Warum nicht jetzt? Also durfte voku/simple-cache per composer in die bundled-libs und ich stellte direkt den Code des internen Cache um (der übrigens bei den wenigen Plugins der Standardinstallation auf uberspace mit MySQL wenig bringt, dort ist die Datenbank schnell genug).
Eine aktiv gepflegte Cache-Library zur Hand zu haben ist nicht der einzige Nutzen. Sondern wir kriegen kostenlos die Funktion, Sachen in Memcached und Redis und damit im Arbeitsspeicher zu cachen. Das ist viel schneller als Speichern auf der Platte, egal ob in einer Datei oder Datenbank. Und besonderes interessant für mich: Es ist besonders attraktiv auf Scaleway-Servern und ähnlich langsamen Systemen mit viel verfügbarem Arbeitsspeicher.
Wieviel das bringt muss ich noch testen.
Damit habe ich alle im Vorhinein geplanten Themen der Woche durch. Robert hat sich einen Blick auf die XMLRPC-Schnittstelle für die Editoren gewünscht, davon habe ich aber keine Ahnung und würde vielleicht etwas anderes vorziehen.
Gibt es denn sonst noch Wünsche für die letzten drei Tage?
Serendipity-Entwicklungswoche, Tag 3: Cache und XMLRPC
Monday, 11. February 2019
Heute wird es etwas kürzer als gestern, jedoch konnte ich die Entwicklungswoche fortführen.
XMLRPC und PHP 7.2
Bernd hatte schon eine Weile den deprecated Konstruktor von XMLRPC gemeldet.
Ich bin mir nicht 100% sicher warum ich die Fehlermeldung nicht gesehen habe. Meine Vermutung: Die Library wird nur eingebunden, wenn ein Pingback gesendet oder empfangen wird, also sieht man die Meldung nur als Fehlermeldung wenn man einen Pingback verschickt. Und das passiert nur wenn der Trackback scheiterte, was nur selten vorkommt.
Wie auch immer, ich habe den Konstruktor jetzt einfach wie von modernen PHP-Versionen gefordert auf __construct
umgestellt.
Cache
Danke für die Kommentare zum Artikel gestern. Der Cache des Entryproperties-Plugins ist nun standardmäßig aus und folgt damit der üblichen, von euch definierten Praxis. Dafür wird der interne Cache bei der Installation nun aktiviert.
Das VGWORT-Plugin ist auf meinem Server nun in der aktuellen Version, und trotzdem wird anders als im Testblog die Zeichenanzahl in der Eintragsliste nicht angezeigt. Stellt sich raus, dass ich dafür einen neuen Event backend_view_entry eingeführt hatte der schlicht noch nicht in der hier laufenden Serendipity-Version 2.1.4 drin ist. Am Ende der Woche werde ich diesen Blog aktualisieren.
Serendipity-Entwicklungswoche, Tag 2: Fertige Mediendatenbank, Trackbacks und etwas VGWORT
Sunday, 10. February 2019
Nach der Vorarbeit gestern war deutlich, dass Serendipitys Alpha im Grunde gut funktioniert. Also widmete ich meine Zeit am zweiten Tag der Entwicklungswoche größtenteils der Fertigstellung meiner Überarbeitung.
Die überarbeitete Mediendatenbank
Was meine ich mit "Überarbeitung der Mediendatenbank" überhaupt, da hat sich doch gar nichts geändert? Wenn dieser Eindruck entsteht ist die Überarbeitung gelungen. Ich habe tatsächlich nur Interna geändert, den Code neugeschrieben und organisiert, insbesondere wenn Bilder umbenannt oder in andere Ordner geschoben werden.
Anlass war das Plugin für responsive Bilder. Dafür musste ich in den Code der Mediendatenbank (=ML, für Media Library) hinabsteigen und die Thumbnailerstellung anpassen. Denn das Plugin braucht ja jetzt mehrere Thumbnails, nicht mehr nur eines, um von denen immer das für die Fenstergröße passende auszuwählen. Diese Thumbnails müssen dann auch mit verschoben und umbenannt werden, wenn gleiches mit dem Originalbild passiert. Ohne Serendipity und die Arbeit meiner Vor- und Mitentwickler schlechtreden zu wollen: ich war ein bisschen entsetzt was ich dabei im Code sah.
Beispielsweise war das Herzstück bei Umbenennungen vorher, hier zu sehen, die Funktion serendipity_moveMediaDirectory
. Wohlgemerkt auch dann, wenn eine einzelne Datei und kein Ordner verschoben wird. Was gemeint war steuerte der Parameter $type
, der entweder 'dir'
, 'file'
oder 'filedir'
erwartete. Ist klar. Die Funktion war dann auch noch 403 Zeilen lang und daher absolut nicht einfach zu beherrschen.
Um also die responsiven Bilder unterstützen zu können musste ich das neu organisieren, mindestens entstand der Wunsch diese Stelle im Kern zu verbessern. Ich splittete die Funktionalität in mehrere Teilfunktionen: serendipity_renameDir
, serendipity_renameFile
, serendipity_updateImageInDatabase
, serendipity_updateImageInEntries
, ..., ich denk die Idee wird klar. Diese Funktionen sind jeweils wesentlich kürzer als der alte Blob und sie können in anderen Codestellen aufgerufen werden, wenn eben genau ihre Funktionalität gebraucht wird. Ich würde das gerne anschaulicher zeigen, aber die functions_images.inc.php ist leider zu lang für githistory.xyz.
Ich wurde aber nicht fertig: Erst fehlte die Zugangskontrolle über die ACLs, die ich nie nutze, nicht kannte und deren Fehlen auch nicht bemerkte. Garvin besserte hier nach. Dann vergaß ich schlicht, dass ja nicht nur der Pfad zum Bild umgebogen werden muss, sondern auch der Link. Das reparierte ich vor einer Weile. Was aber bis heute noch fehlte: Wenn ein eingefügtes Bild nicht zu sich, sondern sonstwohin linkt, soll der manuelle Link bei Umbenennung des Bildes ja erhalten bleiben. Genau diese Funktion baute ich heute ein.
Solch ein tiefgreifendes Refactoring ohne bestehende Unit-Tests ist riskant und erfordert sehr viel Aufmerksamkeit. Mittlerweile scheint der neue Code sehr stabil zu funktionieren. Er ermöglicht die neue Funktionalität, macht wohl nichts kaputt, und er wird wesentlich einfacher zu erweitern sein. Aber genau hier ist die Instabilität im Master, der Grund warum wir nicht einfach eine neue Beta oder stabile Serendipity-Version veröffentlichen konnten. Ab heute ginge das hoffentlich.
Trackbacks funktionieren(?)
In meinem Blog beobachte ich das schon etwas länger, aber jetzt las ich es indirekt auch von Thomas und einem Kommentator bei ihm: Irgendwas stimmt nicht mit den Trackbacks. Verschickt Serendipity für einen Artikel mehrere Trackbacks an einen anderen Blog – oder auch an andere Artikel im eigenen Blog – dann kommt nur einer davon durch.
Ich vermutete den Fehler im Kern, testete das in meinem Entwicklungsblog – und alles funktionierte. Ich hatte einen neuen Artikel geschrieben, der zu zwei älteren Artikeln verlinkt, und unter beide wurde ein Trackback gesetzt. Das ist also höchstwahrscheinlich kein Fehler im Kern, sondern ich vermute das Problem beim Server oder einem Plugin. So oder so, auch wenn es sich lohnen würde hier weiter zu forschen, wenn das in einer jungfräulichen Installation funktioniert blockiert es das Release nicht.
VGWORT-Plugin geht erstmal wieder
Im Testblog wurde nach der Pluginstallation sofort eine Fehlermeldung geworfen. Mit einer kleinen Änderung konnte ich die vermeiden und der Zeichenzähler funktionierte danach. Ich bin gespannt, ob das morgen nach dem Pluginupdate auch hier im Blog geht, gehe jetzt aber erstmal von aus.
Eine Frage in die Runde: Benutzt jeder von euch das Plugin Erweiterte Eigenschaften von Artikeln (entryproperties), mit dem dort enthaltenen Cache?
Beim Entwickeln wurde nach dem Umbenennen von Bildern dieser Cache nicht invalidiert, ich dachte erst der Code der ML sei kaputt, aber das lag rein am Cache dieses Plugins. Ich überlege ob man ihn deaktivieren sollte und stattdessen den im Kern integrierten Cache aktiviert. Der ist sowieso mächtiger, und es sollte einfacher sein ihn wenn nötig zu invalidieren. Meinungen?
Serendipity-Entwicklungswoche, Tag 1: Installation, PHP 7.2 und Responsive Images
Saturday, 9. February 2019
Das passierte bisher am ersten Tag der Entwicklungswoche:
Installation
Die Installation lief problemlos. Ich habe mein Dev-Installation auf uberspace komplett gelöscht, nochmal kontrolliert dass PHP 7.2 aktiv ist, und dann den aktuellen Git-Master heruntergeladen und neu installiert. Nach interner Versionierung ist das die Serendipity 2.2.1-alpha2.
Weil SQLite eigentlich immer funktioniert habe ich die Installation nur mit MySQL getestet. Es fielen mir keine Besonderheiten auf, ich landete direkt im Blog. Der von hannob gemeldete Installationsfehler ist also wirklich repariert.
PHP 7.2
Im Backend und auch sonst sind mir keinerlei Probleme bezüglich PHP 7.2 angezeigt worden. Ich habe Artikel geschrieben und bearbeitet, die Medienlibrary genutzt, Plugins installiert und das Autologin-Cookie aktiviert. Ich bezweifel nicht, dass es mit PHP 7.2 noch Probleme geben kann, aber die Kernfunktionalität scheint zu stehen. Vielleicht stolpere ich noch über Fehler, ansonsten freue ich mich über konkrete Hinweise. Vielleicht verschluckt uberspace auch ein paar Fehlermeldungen, die anderswo angezeigt werden?
Responsive Images
Ansonsten habe ich mich mit dem Plugin für die responsiven Bilder beschäftigt, dessen Idee aus dem devcamp in Essen stammt. Bei der Installation war mir aufgefallen, dass das Plugin nicht automatisch aktiviert wurde. Es fehlte in der Liste der Standardplugins, dort habe ich es jetzt hinzugefügt. Es wäre zu schade drum, wenn neue Nutzer diese Funktion nicht zu sehen bekommen, und es schien mir bereits sehr gut zu funktionieren.
Es war für dieses Plugin aber noch ein Bug gemeldet: Bernd hatte entdeckt, dass die srcsets
in Feeds nicht umgeschrieben werden. Im Kern ist das ja ganz bewusst so gehalten, dass die URL zu Bildern relative URLs sind, also /pfad/zum/Bild ohne vorangestelltes http://domain. Das vereinfacht Blogumzüge auf eine neue Domain. Aber wenn ein Feedreader einen solchen Link sieht kann er den ja nur schwer auflösen. Auch wenn es die besseren versuchen werden, denken vielleicht auch die nicht an das relativ neue srcset-Attribut. Die nötige Logik zum Umschreiben der ungewöhnlichen Kommaliste passte nicht ganz in das Schema des bisher genutzten regulären Ausdrucks für href
und src
, daher habe ich den Code zu preg_replace_callback
umgewandelt und in das Plugin eingebaut.
Stolperfalle war $eventData['feed_body']
. Das muss nämlich statt $eventData['body']
manipuliert werden, da der genutzte Event frontend_display:rss-2.0:per_entry
so spät in serendipity_printEntries_rss
aufgerufen wird. Der Code dort arbeitet nämlich erst auf body
, weist das aber gegen Ende feed_body
zu, und die nachher den Feed ausgebende rss.php schaut nur noch auf feed_body
. Das zu verstehen kostete fast so viel Zeit die Konzipierung des gesamten preg_replace_callback
Abschnitts, samt regulärem Ausdruck und Callback-Funktion.