David E. Smith

Installing the Shibboleth SP is a bit beyond normal WordPress stuff, and usually if you’re part of an organization large enough to have a Shibboleth setup you’ll have access to a couple of dedicated security people who can help you through the process.

Anyway, a really quick tour, assuming you’re using Red Hat Enterprise Linux (or CentOS, or something similarly RPM-based):

• Get the appropriate version of the Shibboleth SP software from here
• Install a bunch of RPMs (you’ll need the ‘Shibboleth’ one, obviously, but it will also pull in a lot of dependencies including several other files from that same repo)
• Put the files provided by your IdP (some keys, maybe a couple XML files) in /etc/shibboleth
• service shibd start and maybe chkconfig shibd on

Development, such as it is, is mostly being done on the author’s GitHub.

When I can, I try not to get into custom roles, because (IMO) they’re not very well-supported.

One of my colleagues came up with this, which I haven’t yet tested but which looks promising:

add_filter( 'map_meta_cap', 'disallow_create_users', 10, 2 );
function disallow_create_users( $caps, $cap ) {
   if ( $cap === 'create_users' ) {
    $caps[] = 'do_not_allow';
   }
?
   return $caps;
 }

It looks like most of those options are only available for the paid plugin. For this, I suppose I’ll just have to jot down the form info, then delete the mail actions.

If you’re using Varnish or similar, be sure to test around it (point a host file directly to the back-end) just to be sure it’s not the problem.

(I saw the above response, thought maybe my woes were related to Varnish, but nope. I have the same odd intermittent issues without my caches and load balancers in the way.)

More generally: Any ideas/suggestions on how to troubleshoot this sort of thing? I’ve got a few dozen sites with this plugin, several of which are showing this sort of intermittent 301s-not-working behavior. I haven’t yet found a pattern, and I really don’t know how best to debug this.

There’s a limit, but it’s not (technically) related to the plugin.

PHP has a cap on how many form variables you can submit at a time; that defaults to 1000 in current versions of PHP. (I think it used to be 500, but I can’t find documentation to confirm this.) Each redirect has two form boxes, and there’s probably a couple hidden form vars in there. The net result is that you can’t have more than about 500 redirects with this plugin.

The only workaround is to edit the server’s php.ini configuration, and increase the value of max_input_vars.

The plugin author probably could circumvent this with some JavaScript (have the page turn the submitted inputs into JSON, then have the back-end turn them back, maybe?) but that would probably require a healthy amount of rewriting.

One of my colleagues has already done so. Thanks!

This has been sorta-resolved. The theme actually was doing some INSERTs where I didn’t expect. Obviously, this will fail, as there’s no server configured to accept writes.

It’s resolved in the sense that I know what’s causing the problem, not in that I’ve solved the problem, but it’s out of the scope of this plugin. ??

Following up to my own post here: One of the devs here dug into this a bit more deeply than I did, and concluded this actually was/is a bug in WordPress itself: https://core.trac.www.ads-software.com/ticket/29696

This issue should be fixed in WordPress 4.1.

In the meantime, I’m still working around it with this:

add_filter('pre_user_nicename', 'sanitize_title');

Fortunately, I’m also the guy running the server, so it’s easy enough to ask myself these questions ??

Turns out neither ImageMagick nor php-gd were installed on this server. Installing php-gd seems to have solved the problem.

I’d suggest making the error message a bit more friendly, if possible. Hosting companies tend to install everything, on the (very reasonable) assumption that someone will need every last little thing. Some of us, though, only install server components as needed.

See, that’s why you have a fancy title under your name. ??

Didn’t even occur to me to do it as two separate steps for whatever reason. A few quick search/replaces (I used WP-CLI) for that, and for another even stranger syntax I’d apparently used many years ago, and some small level of consistency and sanity has been brought to my site. Thanks!

I was afraid of that. Mostly because it means I’ll have to do regexes on the database, it’s not just a simple search/replace.

Thanks for the quick response, though.

At a glance, “Add From Server” appears to just use native WordPress stuff for adding the local file to the media library. So the information is added correctly the first time. I don’t immediately see any references in the code to fixing broken/incorrect uploads.

Either nobody else has ever had this problem before (wanting to fix the metadata for non-image files), or it’s Really Hard to solve. ??

I’m going to make a copy of this site on a test server, and make sure I can delete the WordPress entity and re-create it without breaking anything else on the site. (I’m pretty sure nobody is using the media page.)

I think in the future, I’ll just have the system owners send me the files out-of-band, and I’ll import them myself with wp-cli or something.

Installing a new plugin for a one-off seems a bit inelegant. (And in my environment, installing a new plugin involves an annoying amount of paperwork.) But I’ll keep that in mind, should this come up again in the future.

In the meantime, is there a way simply to force WordPress to re-evaluate an existing upload, to get the correct MIME type and file size?

That article has exactly what I need. Thanks! I’m adding this to my “settings enforcement” plugin:

// Set some limits on Automattic Jetpack kitchen-sink module
function disable_jetpack_mods_localpolicy($modules) {
        // hide plugins that are disabled by devmode
        unset($modules['enhanced-distribution']);
        unset($modules['gplus-authorship']); // google plus
        unset($modules['json-api']);
        unset($modules['comments']); // jetpack comments
        unset($modules['sso']); //jetpack sso
        unset($modules['likes']);
        unset($modules['monitor']);
        unset($modules['notes']); // wp.com social thingy?
        unset($modules['photon']);
        unset($modules['post-by-email']);
        unset($modules['publicize']);
        unset($modules['related-posts']);
        unset($modules['after-the-deadline']); // spelling and grammar
        unset($modules['subscriptions']);
        unset($modules['videopress']);
        unset($modules['shortlinks']); // wp.me shortlinks
        unset($modules['stats']);

        // hide plugins that conflict with other WUSTL stuff
        unset($modules['contact-form']);
        unset($modules['custom-css']);
        unset($modules['minileven']); // mobile theme

        return $modules;
}
add_filter('jetpack_get_available_modules', 'disable_jetpack_mods_localpolicy');
add_filter('jetpack_development_mode', '__return_true');
add_filter('jetpack_get_default_modules', '__return_empty_array');