wordpress

Cloudbridge Mattermost 2.1.0 with Cloudflare support

Cloudbridge Mattermost is a WordPress plugin that provides integration between WordPress and Mattermost.

Cloudbridge Mattermost 2.1.0 has been released with fixes and new features!

New features include support for Cloudflare and verified WordPress 5.8 compatibility.

You can read more about it here: code.webbplatsen.net/wordpress/cloudbridge-mattermost. It is available via the WordPress plugin repository and from GitHub

EasyMap 1.1.0 for WordPress

The EasyMap for WordPress plugin provides uncomplicated Google Maps functionality for your WordPress web site. It allows a great deal of control over Google Maps features and comes with support for pre-defined location address formats as well as a custom template editor.

Basic functionality includes:

  • Up to 200 locations can be displayed
  • Choose to display all or some of the configured locations
  • Choose Google Maps details to be shown
  • Support for Custom CSS
  • Export and Import locations and plugin configuration
  • Support for multiple address formats
  • Compatible with WordPress 5.5+
  • Compatible with PHP 7.2 and 7.4

EasyMap on wordpress.org:
wordpress.org/plugins/easymap/

There’s more EasyMap information available here:
code.webbplatsen.net/wordpress/easymap

Cloudbridge Mattermost

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.

Displaying WordPress roles in the current language

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

 

URL re-writing with nginx, PHP, and WordPress

There are many posts about nginx, re-directs, PHP, and WordPress. There are somewhat fewer posts that talk about (internal) re-writes, where the request by the web browser is mangled to be served by another resource than the one requested.

For example, I may want a request for https://mysite.foo/cool/penguin to actually be served by https://mysite.foo/coolstuff.php?id=penguin, or simply setup an alias such as https://mysite.foo/cool/penguin to be served by https://mysite.foo/cool/linux, but preserve the URL in the browser address bar.

With PHP-FPM and nginx, you run into an additional problem, which is the fastcgi_parm variables that are passed from nginx to PHP-FPM. So even if you have really fancy URL re-writing configured (and working), the end result may not be passed on to PHP-FPM from nginx.

So solve this, you should look into this construct, which is present in many nginx configurations as a default setup:

fastcgi_param REQUEST_URI $request_uri;

Since your needs probably differ from mine, I wont make this post any longer than it has to be, but that fastcgi_param line above may be a good starting point if you’re experiencing problems with nginx, PHP-FPM, and URL re-writing.

Good luck!