Zum Inhalt springen

Archiv für das Tag "Code"

Reset properties and values from a scss mixin

CSS code on screen

How do you 'unset' changes that a mixin has introduced to an element?

TLDR: use a reset parameter in the mixin.

WordPress Kommentare DSGVO konformer machen

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' );

Das ist noch Work In Progress. Wenn man die IP komplett weg haben will, geht auch ein

/* ---------------------------------------------------------------------
* IP Adressen löschen in den Kommentaren
* --------------------------------------------------------------------- */
function wbr_delete_commentip( $comment_author_ip ) {
return '';
}
add_filter( 'pre_comment_user_ip', 'wbr_delete_commentip' );

Zwar habe ich noch ein Plugin am Start, welches die IPs nach einigen Tagen aus der DB löscht, aber ...

Ch-ch-ch-changes

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 get the picture. So all I did back then was to consider how the site should look on smaller screens, and making modifications inside max-width media queries, keeping all of the desktop-related stuff as the default styles, outside any media queries.
Of course when starting ...

Stolz wie Bolle

Wow, ein klein wenig Codegeschubse von mir wurde in das neue Release von Hashgrid (v8) aufgenommen und ich stehe als "Contributor" mit im Sourcecode. :-)

Das Großreinemachen geht weiter

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. Ok, nicht nur aus diesem Grund, vor allem hat mich die Ecke, so wichtig und richtig auch die Thematik dahinter ist, genervt. Ich werde einen Ersatz als Banner oder so in meine Linkleiste aufnehmen, über ein Jahr lang eselohrte es nun ...

DIY: Post-Requests mitloggen

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 cracken.
Im Falle von GET Variablen sieht man das noch ganz gut in den Standard-Server Logs, dagegen schweigen sich diese bei POST Variablen über den Inhalt derselben aus.

Will man also Einblick bekommen, mit welchen POST-Variablen das Blog so gefüttert wird, muss man selbst tätig werden. Dafür habe ich mir ein kleines Script gebastelt, das:

Den Post-Request sowie ein paar Informationen, wo er herkommt und wo er hinsoll, in eine Datei schreibt
Mir eine E-Mail mit diesen Informationen schickt

Angeregt wurde das ganze durch die Diskussion über die neuesten WordPress-Exploits bei village-idiot.org. Insbesondere der Ansatz, die Logging-Funktion in die wp-config.php einzubinden, fand ich dort - ich hatte es zunächst in die index.php eingebunden, die aber bei jedem Update aufs Neue geändert werden müsste. Da die wp-config.php in der Regel bei einem Update nicht geändert wird, überlebt die Logging-Funktion also auch künftige Updates.

Ich versuche das hier mal zu skizzieren. Benötigt werden Kenntnisse in PHP, ein Zugang zum Server, der das Ändern von Datei- und Verzeichnisrechten erlaubt und der Zugriff auf ein Verzeichnis ausserhalb der htroot (des Verzeichnisses, welches über das Internet per Browser erreichbar ist).
Das ist nichts für Anfänger!