manatrance

The screenshot looks the way it does because of my own style customizations; you’ll need to add custom CSS to your site in order to make it look different.

This plugin’s on life support, essentially; I stopped being a WordPress developer a couple years ago. Not sure if I’ll be making any further changes to the plugin or not.

Thanks, Shillianth. I’m glad you found it useful!

What about the configuration was difficult or time-consuming?

I will do some testing on my end and see if I can duplicate the problem.

However, I can’t guarantee that I’ll be able to find and fix it. Since most of my own WordPress sites are hosted on virtual private servers instead of shared hosting, I always have full control over the environment. Shared hosting, like hostinger.es, haphost.com, and 000webhost, usually doesn’t allow their users full access – and they often turn off features like cURL which the plugin relies on.

I’ll see what I can do.

That error occurs when the host machine is unable to resolve a domain name. It could be that your web host (or your VPS, if you’re using one) disallows outgoing cURL requests, or that it’s having DNS problems.

If you have access to that machine via shell, log into it and try this command:

curl -I https://eu.battle.net/api/wow/guild/dun-modr/Daggerfall?fields=members

(all one line/command)

The results will tell you whether the server can talk to the Armory or not. If it can’t, then your host is the problem. If it can, then I’ll try and think of something else.

That’s a reasonable change. I’ll look at making it for the next version.

It looks like there are multiple issues with the race images, and this is one of them. I’ll get it sorted out after the holidays.

New Relic itself is the interface for this, mate. All this plugin does is add some clarification to reporting in New Relic for WordPress sites.

If you don’t use New Relic, this plugin will be useless to you.

That lets me work around the problem nicely. Thanks!

Hmm.

I honestly have no idea what the problem is. Your phpinfo looks correct, and my tests with your shortcodes work just fine.

The only thing I can think of is that it’s because you’re using PHP 5.5, and there may be a deprecated function somewhere in there. I haven’t tested WGR with 5.5 yet.

Strange.

What happens if you try a different guild? Maybe one without accented characters in the name?

While enabling allow_url_fopen will work, getting your web host to enable cURL is a much safer route.

Is this on Multisite, or just two separate WordPress installations?

Figured it out. Below is my virtualhost config that fixed the problem.

server {
        listen 80 default;
        server_name *.example.com example.com;

        root /srv/web/wpmulti;

        access_log      /var/log/nginx/example.access.log;
        error_log       /var/log/nginx/example.error.log;

        index index.html;

        location / {
            index index.html index.htm index.php;
            include global/restrictions.conf;
            include global/wordpress-ms-subdir.conf;
            rewrite ^ https://example.com$request_uri permanent;
        }

        location ^~ /wp-content/plugins/saml-20-single-sign-on {
            location ~ ^(?<script_name>.*?\.php)(?<path_info>/.*)?$ {
                include fastcgi_params;
                fastcgi_param SCRIPT_FILENAME $document_root$script_name;
                fastcgi_param PATH_INFO $path_info;
                fastcgi_param PATH_TRANSLATED $document_root$path_info;
                fastcgi_pass unix:/var/run/php5-fpm.sock;
            }
        }
    }

This is what I replaced the code in nav_tabs.php with:

<?php

$tab = $_GET['page'];
$is_multisite = is_multisite();
$is_network_admin_page = is_network_admin();

if ($is_network_admin_page && $is_multisite) {
    $show_general = false;
    $show_sp = false;
    $show_idp = true;
} elseif (!$is_network_admin_page && $is_multisite) {
    $show_general = true;
    $show_sp = true;
    $show_idp = false;
} else {
    $show_general = true;
    $show_sp = true;
    $show_idp = true;
}
?>
<link rel="stylesheet" href="<?php echo constant('SAMLAUTH_URL') . '/lib/css/sso.css';?>" />
<link href="//netdna.bootstrapcdn.com/font-awesome/3.1.1/css/font-awesome.css" rel="stylesheet">
<div class="wrap">
  <h2 class="nav-tab-wrapper">
    Single Sign-On&nbsp;
    <?php
        if ($show_general) {
            ?><a href="?page=sso_general.php" class="nav-tab<?php if($tab == 'sso_general.php'){echo ' nav-tab-active';}?>">General <span class="badge badge-important" id="sso_errors"><?php if($status->num_errors != 0) echo $status->num_errors; ?></span></a><?php
        }
        if ($show_idp) {
            ?><a href="?page=sso_idp.php" class="nav-tab<?php if($tab == 'sso_idp.php'){echo ' nav-tab-active';}?>">Identity Provider</a><?php
        }
        if ($show_sp) {
            ?><a href="?page=sso_sp.php" class="nav-tab<?php if($tab == 'sso_sp.php'){echo ' nav-tab-active';}?>">Service Provider</a><?php
        }
    ?>
    <a href="?page=sso_help.php" class="nav-tab<?php if($tab == 'sso_help.php'){echo ' nav-tab-active';}?>">Help</a>
  </h2>
</div>

After digging into the code, it appears that the above behavior is correct for a Multisite, but there’s still a bug – the tabs that should be hidden in each view (Network Admin vs sub-site Admin) are not!

There is a simple fix to this.

First, edit nav_tabs.php to only show the appropriate tabs at the right admin level.

Second, add documentation for Multisite usage; it’s not immediately apparent how to get it working.