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

 

Troubleshooting WordPress re-directs (301)

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

PHP is_numeric () fails WordPress version string check

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

Limiting the number of revisions in WordPress

Tired of nine zillion revisions of your posts created on your WordPress site?

Open up wp-config.php with a nice editor like Emacs or Pico/Nano or VI and add:

define('WP_POST_REVISIONS', false );

to disable post revisions completely.

Or, if you just want to limit the number of revisions WordPress keeps:

define('WP_POST_REVISIONS', 3);

 

Of course, this is just a simple Google query away from you:
http://lmgtfy.com/?q=limit+number+of+revisions+in+wordpress

Or, as it happens:
http://bit.ly/Hi9T1Y

So long Serendipity (S9Y), JoHo is converting to WordPress

Well, I guess it had to happen at some point. I’ve been running Serendipity (S9Y) for as long as I can remember “blogging”. At one point I was coding something that looked a lot like some early version of WordPress and S9Y, but I gave up on it. Since there are so many talented developers out there, I didn’t have to wait long for some nice alternatives to show up.

When WordPress 3 arrived, I decided it was time to move away from S9Y. I do a lot of WordPress-related stuff at work, and the time when I thought tinkering with “odd” bits and pieces just because I had nothing better to do has long since passed. These days I do it because I have something better to do but can’t keep my hands away 🙂

During the next few weeks, I’ll get a lot of stuff back here again, but I’d like to extend a big “THANK YOU” to this post:

Serendipity to WordPress – Post import