Chris Coyier (@css) has shared a code snippet that will add loading="lazy" to every scr=" instance in WordPress's content. But this will replace every instance, not only in img or iframe tags, which can lead to some unwanted replacements. Here's my version for that filter: // in theme’s functions.php or a plugin function wbr_add_lazy_loading($content){ $content…
How do you 'unset' changes that a mixin has introduced to an element? TLDR: use a reset parameter in the mixin.
Seit kurzem werden die IP-Adressen, die (m)eine WordPress-Installation standardmässig bei einem Kommentar abspeichert, vorher anonymisiert: /* --------------------------------------------------------------------- * IP Adressen anonymisieren in den Kommentaren * --------------------------------------------------------------------- */ function wbr_anonymize_commentip( $comment_author_ip ) { // ipv4: 123.234.111.222 => 123.234.xxx.xxx // ipv6: ? $out = preg_replace('/^(\d+\.\d+)\.\d+\.\d+$/i','$1.xxx.xxx',$comment_author_ip); return $out; } add_filter( 'pre_comment_user_ip', 'wbr_anonymize_commentip' );/* --------------------------------------------------------------------- * IP Adressen anonymisieren…
For a long time it has bugged me that the css for the recent version of my site was desktop-down. I made some adjustments for adaptive/responsive behaviour three or four years ago, but since the code base of my site is organically growing since I started it on WordPress in 2005… uhm, I think you…
Wow, ein klein wenig Codegeschubse von mir wurde in das neue Release von Hashgrid (v8) aufgenommen und ich stehe als "Contributor" mit im Sourcecode. :-)
Im Zuge der Aufräumarbeiten nach der Geburtstagsparty habe ich mir die w3c-Konformität des Blogs (mal wieder) vorgenommen. Prinzipiell ist der Code von webrocker.de auf striktes XHTML ausgelegt und validiert auch in der Basisversion richtig. Allerdings nicht, sobald einige Plugins in die Ausgabe eingreifen. Aus diesem Grund habe ich gerade das "Eselsohr" des Arbeitskreises Vorratsdatenspeicherung gekickt.…
Um frühzeitig dahinter zu kommen, ob eine Spamwelle anrollt oder ein neuer Exploit ausgenutzt wird, ist es hilfreich, die Server-Logfiles zu Rate zu ziehen. Wenn auf einmal SQL-Statements oder Javascript-Code oder Verweise auf externe Scripte in Variablen-Werten auftauchen kann man davon ausgehen, dass da gerade jemand versucht, per SQL-Injection, XSS oder sonstwie das Blog zu…
Webrocker