This is a valid Atom 1.0 feed.
This feed is valid, but interoperability with the widest range of feed readers could be improved by implementing the following recommendations.
<p><a href="https://blog.jkip.de/wp-content/uploads/2024/07/thunderbird-date ...
<p><a href="https://blog.jkip.de/wp-content/uploads/2024/07/thunderbird-date ...
<p><a href="https://blog.jkip.de/wp-content/uploads/2024/07/thunderbird-date ...
<?xml version="1.0" encoding="UTF-8"?><feed
xmlns="http://www.w3.org/2005/Atom"
xmlns:thr="http://purl.org/syndication/thread/1.0"
xml:lang="de"
>
<title type="text">Jörgs Webnotizen</title>
<subtitle type="text">Blog über Debian GNU/Linux, Webserver und Webprogrammierung</subtitle>
<updated>2024-07-11T07:11:07Z</updated>
<link rel="alternate" type="text/html" href="https://blog.jkip.de" />
<id>https://blog.jkip.de/feed/atom/</id>
<link rel="self" type="application/atom+xml" href="https://blog.jkip.de/feed/atom/" />
<generator uri="https://wordpress.org/" version="6.7.1">WordPress</generator>
<entry>
<author>
<name>Jörg Kruse</name>
</author>
<title type="html"><![CDATA[Datumsformat ISO 8601 in Thunderbird einstellen]]></title>
<link rel="alternate" type="text/html" href="https://blog.jkip.de/datumsformat-iso-8601-in-thunderbird-einstellen/" />
<id>https://blog.jkip.de/?p=1324</id>
<updated>2024-07-11T07:11:07Z</updated>
<published>2024-07-10T14:01:30Z</published>
<category scheme="https://blog.jkip.de" term="Allgemein" /><category scheme="https://blog.jkip.de" term="Debian" /><category scheme="https://blog.jkip.de" term="OSBN" /><category scheme="https://blog.jkip.de" term="Thunderbird" />
<summary type="html"><![CDATA[Das Datumsformat ISO 8601 lässt sich unter Linux Debian global einrichten, indem zuerst mit dpkg-reconfigure locales als zusätzliche Lokale en_DK.UTF-8 hinzugefügt wird, welche anschließend mit localectl als Zeitformat definiert wird: localectl set-locale LC_TIME=en_DK.UTF-8 Bei en_DK handelt es sich mitnichten um dänisches Englisch. Vielmehr wurde diese Lokale erstellt, damit Datumsangaben in einer ansonsten englischen Lokale im […]]]></summary>
<content type="html" xml:base="https://blog.jkip.de/datumsformat-iso-8601-in-thunderbird-einstellen/"><![CDATA[<p>Das Datumsformat ISO 8601 lässt sich unter Linux Debian global einrichten, indem zuerst mit <code>dpkg-reconfigure locales</code> als zusätzliche Lokale <em>en_DK.UTF-8</em> hinzugefügt wird, welche anschließend mit <em>localectl</em> als Zeitformat definiert wird:</p>
<p><code></p>
<pre>
localectl set-locale LC_TIME=en_DK.UTF-8
</pre>
<p></code><span id="more-1324"></span></p>
<p>Bei <em>en_DK</em> handelt es sich mitnichten um dänisches Englisch. Vielmehr wurde diese Lokale erstellt, damit Datumsangaben in einer ansonsten englischen Lokale im ISO 8601 Form <em>YYYY-MM-DD</em> angezeigt werden können, anstelle des verquirlten US-amerikanischen <em>MM/DD/YYYY</em>.</p>
<p>Leider stellt sich das E-Mail-Programm Mozilla Thunderbird hier etwas quer: selbst wenn in den Einstellungen von Thunderbird die Option „Regional settings locale: English (Denmark)“ ausgewählt ist, wird eigentümlicherweise das Format <em>DD/MM/YYYY</em> angezeigt. Es gibt hierzu auch einen <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1426907">sieben Jahre alten Bug-Report</a> mit dem Status „wontfix“ und verschiedenen Workarounds, die einige Zeit später aber auch schon nicht mehr funktionierten.</p>
<p>Das ISO-Format kann aber recht einfach im Config-Editor von Thunderbird eingestellt werden, wie auf support.mozilla.org im Artikel <a href="https://support.mozilla.org/en-US/kb/customize-date-time-formats-thunderbird">Customize Date and Time formats in Thunderbird</a> beschrieben.</p>
<p><a href="https://blog.jkip.de/wp-content/uploads/2024/07/thunderbird-date_time.png"><img fetchpriority="high" decoding="async" src="https://blog.jkip.de/wp-content/uploads/2024/07/thunderbird-date_time.png" alt="Thunderbird Config-Editor" width="702" height="296" class="aligncenter size-full wp-image-1326" srcset="https://blog.jkip.de/wp-content/uploads/2024/07/thunderbird-date_time.png 702w, https://blog.jkip.de/wp-content/uploads/2024/07/thunderbird-date_time-300x126.png 300w" sizes="(max-width: 702px) 100vw, 702px" /></a></p>
<p>Ich füge solche Einstellungen gerne der Datei user.js hinzu, die im Thunderbird-Profil-Verzeichnis ~/.thunderbird/[…].default-default/ gespeichert wird. Diese lassen sich so dann leichter auf andere Profile und Rechner übertragen und aus dem Backup wiederherstellen:</p>
<p><code></p>
<pre>
// iso date and time formats
user_pref("intl.date_time.pattern_override.date_short", "yyyy-MM-dd");
user_pref("intl.date_time.pattern_override.time_short", "HH:mm");
</pre>
<p></code></p>
]]></content>
<link rel="replies" type="text/html" href="https://blog.jkip.de/datumsformat-iso-8601-in-thunderbird-einstellen/#comments" thr:count="2" />
<link rel="replies" type="application/atom+xml" href="https://blog.jkip.de/datumsformat-iso-8601-in-thunderbird-einstellen/feed/atom/" thr:count="2" />
<thr:total>2</thr:total>
</entry>
<entry>
<author>
<name>Jörg Kruse</name>
</author>
<title type="html"><![CDATA[Relaunch von Mozilla Observatory als MDN HTTP Observatory]]></title>
<link rel="alternate" type="text/html" href="https://blog.jkip.de/relaunch-von-mozilla-observatory-als-mdn-http-observatory/" />
<id>https://blog.jkip.de/?p=1314</id>
<updated>2024-07-03T13:02:49Z</updated>
<published>2024-07-03T10:07:02Z</published>
<category scheme="https://blog.jkip.de" term="Allgemein" /><category scheme="https://blog.jkip.de" term="OSBN" />
<summary type="html"><![CDATA[Wie gestern das MDN Blog bekanntgegeben hat, wurde das Mozilla Observatory Tool, welches seit acht Jahren unter der alten Adresse auf observatory.mozilla.org erreichbar war, durch einen Nachfolger ersetzt. Das neue MDN HTTP Observatory auf developer.mozilla.org ermöglicht wie sein Vorgänger den Scan von Websites, bei welchen insbesondere die korrekte Verwendung von sicherheitsrelevanten HTTP-Headern überprüft wird. Neben […]]]></summary>
<content type="html" xml:base="https://blog.jkip.de/relaunch-von-mozilla-observatory-als-mdn-http-observatory/"><![CDATA[<p><a href="https://developer.mozilla.org/en-US/blog/mdn-http-observatory-launch/">Wie gestern das MDN Blog bekanntgegeben hat</a>, wurde das <em>Mozilla Observatory</em> Tool, welches seit acht Jahren unter der alten Adresse auf observatory.mozilla.org erreichbar war, durch einen Nachfolger ersetzt. Das neue <a href="https://developer.mozilla.org/en-US/observatory"><em>MDN HTTP Observatory</em></a> auf developer.mozilla.org ermöglicht wie sein Vorgänger den Scan von Websites, bei welchen insbesondere die korrekte Verwendung von sicherheitsrelevanten HTTP-Headern überprüft wird.<span id="more-1314"></span></p>
<p>Neben der Überarbeitung von Layout und User Experience wurden auch die Tests und die dazugehörige Dokumentation auf den neuesten Stand gebracht. Enfernt wurden die obsoleten X-XSS-Protection- sowie Flash- und Silverlight-Tests. Der Test der Referrer-Policy wurde aktualisiert und hinzugekommen ist ein Test bezüglich der Cross-Origin-Resource-Policy.</p>
<p>Ich habe natürlich auch bereits die Startseite meines Blogs scannen lassen, um zu sehen, inwieweit sich die Änderungen auf das Ergebnis auswirken. Das A+, welches ich letztes Jahr nach einigen Anpassungen erreicht hatte, ist auch auf dem neuen MDN HTTP Observatory erhalten geblieben.</p>
]]></content>
<link rel="replies" type="text/html" href="https://blog.jkip.de/relaunch-von-mozilla-observatory-als-mdn-http-observatory/#comments" thr:count="0" />
<link rel="replies" type="application/atom+xml" href="https://blog.jkip.de/relaunch-von-mozilla-observatory-als-mdn-http-observatory/feed/atom/" thr:count="0" />
<thr:total>0</thr:total>
</entry>
<entry>
<author>
<name>Jörg Kruse</name>
</author>
<title type="html"><![CDATA[LUKS-Passphrase nur einmal beim Booten von Debian eingeben]]></title>
<link rel="alternate" type="text/html" href="https://blog.jkip.de/luks-passphrase-nur-einmal-eingeben-beim-booten-von-debian/" />
<id>https://blog.jkip.de/?p=1305</id>
<updated>2024-06-26T13:33:01Z</updated>
<published>2024-06-26T13:28:19Z</published>
<category scheme="https://blog.jkip.de" term="Allgemein" /><category scheme="https://blog.jkip.de" term="Debian" /><category scheme="https://blog.jkip.de" term="OSBN" />
<summary type="html"><![CDATA[Wenn nachträglich ein zweiter Datenträger in eine Debian-Installation eingebunden wird und dieser ebenso wie der erste Datenträger mit LUKS verschlüsselt wird, so ist bei jedem Systemstart zweimal eine Passphrase für die Entschlüsselung des jeweiligen Datenträger einzugeben. Sofern sich die beiden Passphrasen gleichen, kann mit dem Script decrypt_keyctl eine nur einmalige Eingabe erreicht werden. Aber Achtung: […]]]></summary>
<content type="html" xml:base="https://blog.jkip.de/luks-passphrase-nur-einmal-eingeben-beim-booten-von-debian/"><![CDATA[<p>Wenn nachträglich ein zweiter Datenträger in eine Debian-Installation eingebunden wird und dieser ebenso wie der erste Datenträger mit LUKS verschlüsselt wird, so ist bei jedem Systemstart zweimal eine Passphrase für die Entschlüsselung des jeweiligen Datenträger einzugeben. Sofern sich die beiden Passphrasen gleichen, kann mit dem Script <em>decrypt_keyctl</em> eine nur einmalige Eingabe erreicht werden.<span id="more-1305"></span></p>
<p>Aber <strong>Achtung</strong>: <em>decrypt_keyctl</em> speichert die Passphrase unverschlüsselt im Arbeitsspeicher zwischen. Da Teile des Arbeitsspeichers ggf. auch in den Swap ausgelagert werden können, sollte dieses Script nur verwendet werden, wenn auch der Swap verschlüsselt ist!</p>
<p><em>decrypt_keyctl</em> ist in dem Debian-Paket <em>keyutils</em> enthalten, welches über den Paketmanager installiert werden kann:</p>
<p><code></p>
<pre># apt install keyutils</pre>
<p></code></p>
<p>In Debian 12 / Bookworm können die Einträge in der Datei /etc/crypttab dann mit der Option <em>keyscript=decrypt_keyctl</em> ergänzt werden, wie hier im Beispiel einer SSD- und einer Festplatten-Partition:</p>
<p><code></p>
<pre>nvme0n1p3_crypt UUID=<UUID> none luks,discard,keyscript=decrypt_keyctl
sda1_crypt UUID=<UUID> none luks,keyscript=decrypt_keyctl</pre>
<p></code></p>
<p>In Debian 11 / Bullseye braucht es ggf. zusätzlich die Option <em>initramfs</em></p>
<p><code></p>
<pre>nvme0n1p3_crypt UUID=<UUID> none luks,discard,initramfs,keyscript=decrypt_keyctl
sda1_crypt UUID=<UUID> none luks,initramfs,keyscript=decrypt_keyctl</pre>
<p></code></p>
<p>Vor dem Booten muss dann noch das Initramfs aktualisiert werden:</p>
<p><code></p>
<pre># update-initramfs -k all -u</pre>
<p></code></p>
]]></content>
<link rel="replies" type="text/html" href="https://blog.jkip.de/luks-passphrase-nur-einmal-eingeben-beim-booten-von-debian/#comments" thr:count="0" />
<link rel="replies" type="application/atom+xml" href="https://blog.jkip.de/luks-passphrase-nur-einmal-eingeben-beim-booten-von-debian/feed/atom/" thr:count="0" />
<thr:total>0</thr:total>
</entry>
<entry>
<author>
<name>Jörg Kruse</name>
</author>
<title type="html"><![CDATA[Benutzerdefiniertes Tracking-OptOut in Matomo 5]]></title>
<link rel="alternate" type="text/html" href="https://blog.jkip.de/benutzerdefiniertes-tracking-optout-in-matomo-5/" />
<id>https://blog.jkip.de/?p=1296</id>
<updated>2024-05-29T12:57:15Z</updated>
<published>2024-05-29T12:57:15Z</published>
<category scheme="https://blog.jkip.de" term="Allgemein" /><category scheme="https://blog.jkip.de" term="JavaScript" /><category scheme="https://blog.jkip.de" term="Matomo" /><category scheme="https://blog.jkip.de" term="OSBN" />
<summary type="html"><![CDATA[Bis zur Version 4 der Webanalyse-Software Matomo konnte ein Widerspruch zum Nutzertracking als Iframe in die Datenschutzerklärung oder in eine separate Widerspruchsseite eingebaut werden. Das Aussehen des Iframes konnte dabei mithilfe des Matomo-Plugins CustomOptOut angepasst werden. In Matomo 5 wird dieses OptOut nicht mehr als Iframe eingebunden, sondern über ein JavaScript, welches im Backend von […]]]></summary>
<content type="html" xml:base="https://blog.jkip.de/benutzerdefiniertes-tracking-optout-in-matomo-5/"><![CDATA[<p>Bis zur Version 4 der Webanalyse-Software Matomo konnte ein Widerspruch zum Nutzertracking als Iframe in die Datenschutzerklärung oder in eine separate Widerspruchsseite eingebaut werden. Das Aussehen des Iframes konnte dabei mithilfe des Matomo-Plugins CustomOptOut angepasst werden. In Matomo 5 wird dieses OptOut nicht mehr als Iframe eingebunden, sondern über ein JavaScript, welches im Backend von Matomo erzeugt werden kann. Das hat den Vorteil, dass für die Anpassungen kein extra Plugin mehr notwendig ist. Stattdessen können diese nun direkt über das CSS der eigenen Seite vorgenommen werden.<span id="more-1296"></span></p>
<p>Ein Nachteil des OptOut-Scripts ist allerdings, dass hierbei <em>onclick</em> Attribute im HTML-Code eingebaut werden. Wird die Website mit <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP">CSP-Headern</a> abgesichert, funktioniert das OptOut nur, wenn die Content-Security-Policy durch ein <code>script-src 'unsafe-inline'</code> deutlich abgeschwächt wird. Wer letzteres vermeiden möchte, kann mittels Tracking-Anweisungen über _paq.push() das OptOut-Formular auch selbst erstellen. Eine Anleitung hierzu findet sich im Manual von Matomo:</p>
<p><a href="https://developer.matomo.org/guides/tracking-javascript-guide#optional-creating-a-custom-opt-out-form">Optional: creating a custom opt-out form</a></p>
<p>Das Tracking über Cookies habe ich auf meinen eigenen Websites übrigens komplett <a href="https://matomo.org/faq/how-to/how-do-i-enforce-tracking-without-cookies/">deaktiviert</a>, so dass wiederkehrende Besuche in der Statistik nicht ausgewiesen werden. Da aber wohl auch dem Kurzzeit-Tracking ohne Cookies widersprochen werden können muss, ist an entsprechender Stelle in der Datenschutzerklärung eine OptOut-Checkbox platziert.</p>
]]></content>
<link rel="replies" type="text/html" href="https://blog.jkip.de/benutzerdefiniertes-tracking-optout-in-matomo-5/#comments" thr:count="0" />
<link rel="replies" type="application/atom+xml" href="https://blog.jkip.de/benutzerdefiniertes-tracking-optout-in-matomo-5/feed/atom/" thr:count="0" />
<thr:total>0</thr:total>
</entry>
<entry>
<author>
<name>Jörg Kruse</name>
</author>
<title type="html"><![CDATA[Noch keine Notwendigkeit für IPv6?]]></title>
<link rel="alternate" type="text/html" href="https://blog.jkip.de/noch-keine-notwendigkeit-fuer-ipv6/" />
<id>https://blog.jkip.de/?p=1282</id>
<updated>2024-02-20T15:14:23Z</updated>
<published>2024-02-20T11:10:03Z</published>
<category scheme="https://blog.jkip.de" term="Allgemein" />
<summary type="html"><![CDATA[Noch immer gibt es Webhoster, die IPv6 nicht unterstützen. Nun ist der zur Verfügung gestellte Webspace generell über IPv4-Adressen erreichbar, und dieses sollte ja vollkommen ausreichend sein? die dort gehosteten Webseiten sollten für alle Besucher und Suchmaschinen erreichbar sein. Eine zwingende Notwendigkeit für ein Dualstack von IPv4 und IPv6 scheint es demnach noch nicht zu […]]]></summary>
<content type="html" xml:base="https://blog.jkip.de/noch-keine-notwendigkeit-fuer-ipv6/"><![CDATA[<p>Noch immer gibt es Webhoster, die IPv6 nicht unterstützen. Nun ist der zur Verfügung gestellte Webspace generell über IPv4-Adressen erreichbar, und dieses sollte ja vollkommen ausreichend sein? die dort gehosteten Webseiten sollten für alle Besucher und Suchmaschinen erreichbar sein. Eine zwingende Notwendigkeit für ein Dualstack von IPv4 und IPv6 scheint es demnach noch nicht zu geben?<span id="more-1282"></span></p>
<p>Jetzt hatte ich es allerdings mit einem Fall zu tun, bei dem die fehlende Unterstützung von IPv6 für Ärger sorgte. Ein Kunde hatte seine Domain beim Webhoster A registriert. Er nutzte sowohl den Webspace des Webhosters für eine WordPress-Website, als auch den Mailspace für die E-Mail-Adressen der Domain. Nun sollte die WordPress-Website auf einen Webspace des Webhosters B umziehen, um dort in eine bestehende WordPress-Multisite-Installation integriert zu werden. Die Domain selbst sollte dagegen weiter im Account von Webhoster A verwaltet werden, da u. a. auch die Mails dort verblieben. Eigentlich keine große Angelegenheit: Webhoster A ermöglichte es in den DNS-Einstellungen, den A-Record für die IPv4-Adresse und den AAAA-Record für die IPv6-Adresse auf die Adressen des Webservers von Webhoster B umzustellen.</p>
<p>Die Sache hatte allerdings einen Haken: Webhoster B unterstützte kein IPv6 und Webhoster A ermöglichte es nicht, den bestehenden AAAA-Record zu löschen! Wäre nur der A-Record angepasst worden, wäre nur der Teil der Besucher auf dem Webserver von Webhoster B gelandet, die selbst noch über keine Dualstack-Verbindung verfügten. Alle anderen wären auf dem Webserver von Webhoster A „hängengeblieben“. Der Workaround sah dann so aus, dass beim Webhoster B eine zweite Domain registriert wurde, und beim Webhoster A von der ersten auf die zweite Domain eine HTTP-Weiterleitung eingerichtet wurde. Hätte Webhoster B bereits IPv6 unterstützt, hätte man sich diesen Wechsel der Domain sparen können.</p>
]]></content>
</entry>
<entry>
<author>
<name>Jörg Kruse</name>
</author>
<title type="html"><![CDATA[Log-Level in WordPress einstellen]]></title>
<link rel="alternate" type="text/html" href="https://blog.jkip.de/log-level-in-wordpress-einstellen/" />
<id>https://blog.jkip.de/?p=1269</id>
<updated>2024-01-17T11:18:46Z</updated>
<published>2024-01-17T10:04:22Z</published>
<category scheme="https://blog.jkip.de" term="Allgemein" /><category scheme="https://blog.jkip.de" term="OSBN" /><category scheme="https://blog.jkip.de" term="PHP" /><category scheme="https://blog.jkip.de" term="WordPress" />
<summary type="html"><![CDATA[In der Konfigurationsdatei von WordPress wp-config.php kann eingestellt werden, dass PHP-Fehler ausgegeben oder in einer Datei geloggt werden. Bei der Entwicklung eines Themes oder Plugins empfiehlt sich die Ausgabe direkt auf der Webseite: define( 'WP_DEBUG', true ); Auf einer produktiven Website sollten Fehler dagegen besser nicht ausgegeben, sondern (standardmäßig in der Datei wp-content/debug.log) geloggt werden: […]]]></summary>
<content type="html" xml:base="https://blog.jkip.de/log-level-in-wordpress-einstellen/"><![CDATA[<p>In der Konfigurationsdatei von WordPress <em>wp-config.php</em> kann eingestellt werden, dass PHP-Fehler ausgegeben oder in einer Datei geloggt werden. Bei der Entwicklung eines Themes oder Plugins empfiehlt sich die Ausgabe direkt auf der Webseite:</p>
<p><code></p>
<pre>define( 'WP_DEBUG', true );</pre>
<p></code><span id="more-1269"></span></p>
<p>Auf einer produktiven Website sollten Fehler dagegen besser nicht ausgegeben, sondern (standardmäßig in der Datei wp-content/debug.log) geloggt werden:</p>
<p><code></p>
<pre>define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );</pre>
<p></code></p>
<p>Der Log-Level lässt sich hier allerdings nicht einstellen. Sobald WP_DEBUG als <em>true</em> definiert ist, werden ausnahmslos alle PHP-Fehler ausgegeben bzw. geloggt. WordPress bietet hier keine Möglichkeit, den Error-Level einzustellen. Auch der Einsatz der Funktion <a href="https://www.php.net/manual/en/function.error-reporting.php" rel="noopener">error_reporting()</a> in der Datei wp-config.php bleibt wirkungslos, da der Log-Level anschließend von WordPress überschrieben wird. </p>
<p>Manchmal ist es aber durchaus praktisch, den Error-Level abzusenken. So z. B. bei der Entwicklung eines Plugins, welches ein anderes Plugin voraussetzt, das bei jedem Seitenaufruf zahlreiche <em>deprecated</em> Fehler ausspuckt.</p>
<p>Abhilfe schafft hier ein sogenanntes MU-Plugin („Must Use Plugin“). Diese Plugins können in dem Verzeichnis wp-content/mu-plugins abgelegt werden und werden dann automatisch vor der Ausführung weiterer Plugins ausgeführt. Beispielsweise könnte in diesem Verzeichnis eine Datei error-reporting.php mit folgendem Inhalt abgelegt werden:</p>
<p><code></p>
<pre><?php
error_reporting( E_ALL & ~E_DEPRECATED & ~E_USER_DEPRECATED );</pre>
<p></code></p>
<p>Deprecated Errors werden dann nicht mehr ausgegeben bzw. geloggt.</p>
]]></content>
</entry>
<entry>
<author>
<name>Jörg Kruse</name>
</author>
<title type="html"><![CDATA[PHP-FPM lädt alte Dateien?]]></title>
<link rel="alternate" type="text/html" href="https://blog.jkip.de/php-fpm-laedt-alte-dateien/" />
<id>https://blog.jkip.de/?p=1257</id>
<updated>2024-01-12T10:49:53Z</updated>
<published>2024-01-12T10:27:06Z</published>
<category scheme="https://blog.jkip.de" term="Allgemein" /><category scheme="https://blog.jkip.de" term="PHP" />
<summary type="html"><![CDATA[Das PHP-Modul OPcache beschleunigt die Ausführung von PHP-Scripten, indem es diese vorkompiliert im Arbeitsspeicher vorhält. Unter Debian 12 ist OPCache durch folgende Einstellung in der php.ini standardmäßig aktiviert: opcache.enable = 1 Für ein Produktiv-System mit vielen Zugriffen kann diese Einstellung sicher von Vorteil sein. Auf einem Entwicklungs-System mit wenigen Zugriffen, aber häufigen Änderungen sollte das […]]]></summary>
<content type="html" xml:base="https://blog.jkip.de/php-fpm-laedt-alte-dateien/"><![CDATA[<p>Das PHP-Modul <em>OPcache</em> beschleunigt die Ausführung von PHP-Scripten, indem es diese vorkompiliert im Arbeitsspeicher vorhält. Unter Debian 12 ist OPCache durch folgende Einstellung in der php.ini standardmäßig aktiviert:</p>
<p><code></p>
<pre>opcache.enable = 1</pre>
<p></code><span id="more-1257"></span></p>
<p>Für ein Produktiv-System mit vielen Zugriffen kann diese Einstellung sicher von Vorteil sein. Auf einem Entwicklungs-System mit wenigen Zugriffen, aber häufigen Änderungen sollte das Modul besser deaktiviert werden:</p>
<p><code></p>
<pre>opcache.enable = 0</pre>
<p></code></p>
<p>Andernfalls können leichter Fehler auftreten, deren Ursache nicht so schnell ersichtlich ist. Ich hatte kürzlich mittels Git-Cherry-Pick einen Commit aus dem Haupt-Branch auf den älteren Branch einer Webanwendung übertragen. Beim Testen traten dann Fehler auf, die mich erst vermuten ließen, dass der Commit zuwenig oder zuviel Dateien enthielt. Erst nach einiger Zeit stellte ich fest, dass stattdessen OPcache mir einen Streich spielte, indem es eine (nicht im Commit enthaltene) vorkompilierte Datei des Haupt-Branches lud, die es wohl vor dem Wechsel in den älteren Branch erstellt hatte. Nachdem ich OPcache deaktiviert und PHP-FPM neu gestartet habe, waren die Fehler verschwunden.</p>
]]></content>
</entry>
<entry>
<author>
<name>Jörg Kruse</name>
</author>
<title type="html"><![CDATA[Apache Error AH10411]]></title>
<link rel="alternate" type="text/html" href="https://blog.jkip.de/apache-error-ah10411/" />
<id>https://blog.jkip.de/?p=1244</id>
<updated>2023-12-15T15:45:30Z</updated>
<published>2023-12-15T15:12:34Z</published>
<category scheme="https://blog.jkip.de" term="Allgemein" /><category scheme="https://blog.jkip.de" term="Apache" /><category scheme="https://blog.jkip.de" term="OSBN" />
<summary type="html"><![CDATA[Seit der Version 2.4.54 des Webservers Apache rewritet das Modul mod_rewrite keine Leerzeichen mehr. Im Error-Log wird in so einem Fall dieser Fehler ausgegeben: AH10411: Rewritten query string contains control characters or spaces Ausgelöst wird der Fehler beispielsweise durch folgenden Rewrite in der .htaccess oder VirtualHost-Datei: RewriteEngine on RewriteRule ^/?([^/^\.]+)$ index.php?message=$1 [L] Das Pattern ([^/^\.]+) […]]]></summary>
<content type="html" xml:base="https://blog.jkip.de/apache-error-ah10411/"><![CDATA[<p>Seit der Version 2.4.54 des Webservers Apache rewritet das Modul <em>mod_rewrite</em> keine Leerzeichen mehr. Im Error-Log wird in so einem Fall dieser Fehler ausgegeben:</p>
<blockquote><p>AH10411: Rewritten query string contains control characters or spaces</p></blockquote>
<p>Ausgelöst wird der Fehler beispielsweise durch folgenden Rewrite in der .htaccess oder VirtualHost-Datei:<span id="more-1244"></span></p>
<p><code></p>
<pre>RewriteEngine on
RewriteRule ^/?([^/^\.]+)$ index.php?message=$1 [L]</pre>
<p></code></p>
<p>Das Pattern ([^/^\.]+) erfasst hierbei alle Zeichen, außer den Slash und den Punkt. In älteren Apache-Versionen wurde die URL example.com/error%20ah10411 hierbei auf den Pfad /index.php?message=error%20ah10411 umgeschrieben. Wegen des codierten Leerzeichens %20 in der URL verweigern Apache-Versionen ab 2.4.54 den Rewrite mit einem HTTP-Status-Code 403 „Forbidden“ und der Fehlermeldung AH10411 im Error Log.</p>
<p>Mit einer Beschränkung auf Zeichen ohne das Leerzeichen kann dieser Fehler vermieden werden, z.B.:</p>
<p><code></p>
<pre>RewriteRule ^/?([a-zA-Z0-9-]+)$ index.php?message=$1 [L]</pre>
<p></code></p>
<p>In diesem Fall führt allerdings der Aufruf der URL example.com/error%20ah10411 zu einem HTTP-Status-Code 404 „Not found“</p>
<p>Sollen URLs mit Leerzeichen weiter umgeschrieben werden, können codierte Steuerzeichen mithilfe des <a href="https://httpd.apache.org/docs/2.4/rewrite/flags.html#flag_b">mod_rewrite-Flags <em>[B]</em></a> explizit wieder für den Rewrite zugelassen werden:</p>
<p><code></p>
<pre>RewriteRule ^/?([^/^\.]+)$ index.php?message=$1 [B,L]</pre>
<p></code></p>
<p>Hier erfolgt der Rewrite wieder auf den Pfad /index.php?message=error%20ah10411 und der Apache gibt den HTTP-Status-Code 200 aus.</p>
<p>Das Flag <em>[B]</em> kann seit Apache 2.4.26 sicherheitshalber auch auf einzelne Zeichen beschränkt werden, wie z.B. das Leerzeichen und das „?“:</p>
<p><code></p>
<pre>RewriteRule ^/?([a-zA-Z0-9\ -]+)$ index.php?message=$1 "[B= ?,L]"</pre>
<p></code></p>
<p>Das dritte Argument der RewriteRule muss hierbei wegen des enthaltenen Leerzeichens gequotet werden.</p>
]]></content>
</entry>
<entry>
<author>
<name>Jörg Kruse</name>
</author>
<title type="html"><![CDATA[Script mit async oder defer Attribut in WordPress einbinden]]></title>
<link rel="alternate" type="text/html" href="https://blog.jkip.de/script-mit-async-oder-defer-attribut-in-wordpress-einbinden/" />
<id>https://blog.jkip.de/?p=1216</id>
<updated>2023-11-06T15:52:32Z</updated>
<published>2023-11-06T15:24:32Z</published>
<category scheme="https://blog.jkip.de" term="Allgemein" /><category scheme="https://blog.jkip.de" term="JavaScript" /><category scheme="https://blog.jkip.de" term="OSBN" /><category scheme="https://blog.jkip.de" term="WordPress" />
<summary type="html"><![CDATA[Seit WordPress 6.3 ist es möglich, Scripten, die mit der Funktion wp_enqueue_script() in ein Template oder ein Plugin eingebunden werden, nun auch ein defer oder async Attribut mitzugeben. Im fünften Parameter kann hierzu optional als „strategy“ entweder „defer“ oder „async“ definiert werden, wie im folgenden Beispiel bei der Einbindung der beiden Scripte foo.js und bar.js […]]]></summary>
<content type="html" xml:base="https://blog.jkip.de/script-mit-async-oder-defer-attribut-in-wordpress-einbinden/"><![CDATA[<p>Seit WordPress 6.3 ist es möglich, Scripten, die mit der Funktion <a href="https://developer.wordpress.org/reference/functions/wp_enqueue_script/">wp_enqueue_script()</a> in ein Template oder ein Plugin eingebunden werden, nun auch ein <em>defer</em> oder <em>async</em> Attribut mitzugeben. Im fünften Parameter kann hierzu optional als „strategy“ entweder „defer“ oder „async“ definiert werden, wie im folgenden Beispiel bei der Einbindung der beiden Scripte foo.js und bar.js in ein Template:<span id="more-1216"></span></p>
<p><code></p>
<pre>function my_enqueue_scripts() {
wp_enqueue_script(
'foo',
get_template_directory_uri() . '/js/foo.js',
array(),
"1.2.3",
array( 'strategy' => 'defer' )
);
wp_enqueue_script(
'bar',
get_template_directory_uri() . '/js/bar.js',
array( 'foo' ),
"2.3.4",
array( 'strategy' => 'defer' )
);
}
add_action( 'wp_enqueue_scripts', 'my_enqueue_scripts' );</pre>
<p></code></p>
<p>Vor WordPress 6.3 wäre hierzu etwas umständlich ein nachträglicher Einbau mit einer Funktion wie str_place() über den Hook <em>script_loader_tag</em> notwendig gewesen. Der obige Code wäre entsprechend etwas komplexer ausgefallen:</p>
<p><code></p>
<pre>function my_enqueue_scripts() {
wp_enqueue_script(
'foo',
get_template_directory_uri() . '/js/foo.js',
array(),
"1.2.3"
);
wp_enqueue_script(
'bar',
get_template_directory_uri() . '/js/bar.js',
array( 'foo' ),
"2.3.4"
);
}
add_action( 'wp_enqueue_scripts', 'my_enqueue_scripts' );
function my_add_defer_attribute( $tag, $handle ) {
if ( in_array(
$handle,
array( 'foo', 'bar' ),
true
) ) {
return str_replace( ' src', ' defer src', $tag );
}
return $tag;
}
add_filter( 'script_loader_tag', 'my_add_defer_attribute', 10, 2 );</pre>
<p></code></p>
<p>Von daher eine sinnvolle Erweiterung von wp_enqueue_script(), wie ich finde.</p>
]]></content>
</entry>
<entry>
<author>
<name>Jörg Kruse</name>
</author>
<title type="html"><![CDATA[https:// Seite ohne SSL-Zertifikat weiterleiten?]]></title>
<link rel="alternate" type="text/html" href="https://blog.jkip.de/https-seite-ohne-ssl-zertifikat-weiterleiten/" />
<id>https://blog.jkip.de/?p=1201</id>
<updated>2023-07-27T12:10:32Z</updated>
<published>2023-07-27T09:12:58Z</published>
<category scheme="https://blog.jkip.de" term="Allgemein" />
<summary type="html"><![CDATA[Schon mehrfach wurde in meinem Forum die Frage gestellt, auf welche Weise es möglich sein könnte, beispielsweise von der Webseite https://example.com/ zur Webseite https://example.net/ weiterzuleiten, wenn für die Domain example.com kein SSL-Zertifikat ausgestellt ist. Leider musste ich die Fragesteller mit meiner Antwort enttäuschen. Es ist zwar möglich, im Browser eine Ausnahme für die betreffende Domain […]]]></summary>
<content type="html" xml:base="https://blog.jkip.de/https-seite-ohne-ssl-zertifikat-weiterleiten/"><![CDATA[<p>Schon mehrfach wurde in <a href="https://joergs-forum.de/">meinem Forum</a> die Frage gestellt, auf welche Weise es möglich sein könnte, beispielsweise von der Webseite https://example.com/ zur Webseite https://example.net/ weiterzuleiten, wenn für die Domain example.com kein SSL-Zertifikat ausgestellt ist.<span id="more-1201"></span></p>
<p>Leider musste ich die Fragesteller mit meiner Antwort enttäuschen. Es ist zwar möglich, im Browser eine Ausnahme für die betreffende Domain zu definieren, so dass die Webseite auch ohne gültiges Zertifikat aufgerufen werden kann. Dies wird vermutlich aber keine praktikable Lösung für die meisten Besucher der Website sein. Deswegen bleibt in solchen Fällen meist nur die Einrichtung eines SSL-Zertikats (in diesem Fall für example.com).</p>
<p>Eine Weiterleitung erfolgt typischerweise mit dem HTTP-Statuscode <em>301</em> sowie der Angabe des Weiterleitungsziels im HTTP-Header <em>Location</em>. Im Fall von <a href="https://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol_Secure">HTTPS</a> kann die eigentliche Kommunikation zwischen Webbrowser und Webserver allerdings erst erfolgen, wenn diese verschlüsselt wird, also nach dem SSL/TLS-Handshake. Wenn der Browser mangels gültigen SSL-Zertifikats den Verschlüsselungs-Prozess vorher abbricht, erhält der Webserver keinen HTTP-Request, auf welchen er mit einem HTTP-Response inklusive Weiterleitung reagieren könnte.</p>
<p>Auch alternative Weiterleitungs-Methoden, wie z.B. mit JavaScript, setzen voraus, dass eine HTTP(S)-Verbindung zustande kommt. </p>
]]></content>
</entry>
</feed>
If you would like to create a banner that links to this page (i.e. this validation result), do the following:
Download the "valid Atom 1.0" banner.
Upload the image to your own server. (This step is important. Please do not link directly to the image on this server.)
Add this HTML to your page (change the image src
attribute if necessary):
If you would like to create a text link instead, here is the URL you can use:
http://www.feedvalidator.org/check.cgi?url=http%3A//notizen.joergkrusesweb.de/feeds/rss-1-0.xml