Fail2WP for WordPress 1.0.0 has been released and is available via the WordPress Plugin repository and code.webbplatsen.net
Fail2WP provides security functionality for WordPress sites and plays nicely with Fail2ban and Cloudflare too!
~/virtual/home/joho | DeltaFelter | Stealth Cookie | FidoNet | Joaquim Homrighausen | joho68
Fail2WP for WordPress 1.0.0 has been released and is available via the WordPress Plugin repository and code.webbplatsen.net
Fail2WP provides security functionality for WordPress sites and plays nicely with Fail2ban and Cloudflare too!
Cloudbridge Mattermost is a WordPress plugin that provides integration between WordPress and Mattermost. It has now been updated with OAuth2 authentication for WordPress via Mattermost.
It has been tested with Mattermost 5.30+ and WordPress 5.5.3 and WordPress 5.6.
Features at a glance:
You can download it from the official WordPress repository:
wordpress.org/plugins/cloudbridge-mattermost
You can also get it from GitHub, should you prefer that source:
github.com/joho1968/cloudbridge-mattermost
WebbPlatsen’s official website for their Open Source projects:
code.webbplatsen.net/wordpress/cloudbridge-mattermost/
The WordPress plugin Shortcode for Font Awesome (SCFA) 1.1.0 has been released:
You can get it from:
The GitHub repo is here: github.com/joho1968/SCFA
Cloudbridge Mattermost is a WordPress plugin that provides integration between WordPress and Mattermost. In the initial release, we focus on login notifications (successful, failed, unknown) from the various WordPress user roles.
We will, of course, be adding more functionality in the future.
You can download it from the official WordPress repository:
wordpress.org/plugins/cloudbridge-mattermost
You can also get it from GitHub, should you prefer that source:
github.com/joho1968/cloudbridge-mattermost
This is the initial release of this plugin.
While writing a WordPress plugin that displays the available user roles, I came across a snag: the user roles that I had fetched from WordPress weren’t translated into the site’s current language.
I’m not quite sure I understand the reasoning behind this since WordPress offers functions to return an array with the actual role as the key, and the display string as the array value, like:
array( 'administrator' => 'Administrator' );
So why can’t WordPress return the “correct” (i18n) language string for the array value … anyway, there’s a solution.
Looking at how WordPress does it under “Settings > General” in the WordPress Admin, I eventually found a call to translate_user_role(), which requires one parameter, the role array name value, e.g. “Administrator”. The function will then return the correct (language context aware) display string.
So to put it into a functional context, it may look something like this:
function i18n_get_wp_roles() { $wp_roles = wp_roles(); if ( is_object( $wp_roles ) ) { $roles = array_keys( $wp_roles->roles ); $role_names = $wp_roles->get_names(); } else { $roles = false; $role_names = array(); } $return_roles = array(); if ( is_array( $roles ) ) { foreach( $roles as $role_k => $role_v ) { if ( ! empty( $role_names[$role_v] ) ) { $return_roles[$role_v] = translate_user_role( $role_names[$role_v] ); } else { $return_roles[$role_v] = 'Unknown role (' . $role_v . ')'; } } } else { error_log( basename(__FILE__) . ' (' . __FUNCTION__ . '): wp_roles() returned empty' ); } return( $return_roles ); }
Sometimes it’s a lot faster to simply get a list of all of your current WordPress settings by using the direct options URL:
https://yoursite.tld/wp-admin/options.php
WordPress will gently nudge you to be careful when using that URL, but it may help you track down settings that should possibly be removed.
Using the APIs over at trafiklab.se can yield some quite useful results. I needed to be able to display the commute stop departure times for public transport in a given place, so I wrote this WordPress plugin called Stopsign. It uses the Trafiklab.se API. The plugin is free (GPLv2) and open source.
Knock yourself out: github.com/joho1968/Stopsign
While trying to configure some internal URL re-writing in nginx for a WordPress site, I ran across an annoying issue:
Regardless of my re-writing efforts, WordPress would issue a re-direct (301) header (?!)
This wouldn’t have been such a big deal if I didn’t want the URL to stay the same in the browser’s address bar. If I didn’t have that requirement, I would naturally have used a simple re-direct.
After spending some time troubleshooting this, and making sure nginx was actually doing what I wanted it to do, I ran across a few posts talking about disabling “canonical redirects” (sic) in WordPress. So adding this snippet to the end of the active theme’s functions.php:
remove_filter('template_redirect','redirect_canonical');
got rid of WordPress re-directs. Unfortunately, another plugin “stepped in” and started doing it instead (this time, it was the Polylang plugin). I’m sure there are a number of other plugins that exhibit this behavior, and it may be possible to circumvent this in many/most/all of them by using something similar to the above snippet, but I still haven’t solved the actual problem.
Using cURL to debug URL re-writing and URL re-direction can save you a lot of time, like this:
curl -I https://yourwebsite.foo
(Please note that the issues I have experienced here are not related to nginx. This would happen in Apache too as the re-directs are issued by the WordPress stack. Once control is handed off to PHP, there’s little the web server can do.)
If you’re playing with nginx, PHP-FPM, and URL re-writing, you may also find this post of interest: URL re-writing with nginx, PHP, and WordPress
The list of things to do to harden a WordPress site with Apache is long, but some things that could be done include:
FileETag None <Files wp-config.php> Require all denied </Files> <Files xmlrpc.php> Require all denied </Files> <LocationMatch "/wp-content/uploads/.*(?i)\.php$"> Require all denied </LocationMatch>
This is, perhaps, obvious to most PHP developers. But it came somewhat as a surprise to me.
Using is_numeric () for validating a WordPress version string, such as ‘4.7’, does not seem to work very well when WordPress introduces minor releases such as ‘4.7.1’.
Since I cannot be bothered to figure out why it behaves in this (erratic, IMHO) way, I have since replaced the call to is_numeric () with a small function using a simple regular expression (regexp):
function wpVersionStringCheck ($vs) { return (preg_match ('/^(\d+\.)+\d+$/', $vs)); }
I’m sure there is a hole in there somewhere, but on the following strings at least, it gives me the desired result:
1.0 is valid
1.0. is invalid
1.0.1 is valid
1.banana.0 is invalid