Mark Jaquith makes plugins. He also makes a plugin about making plugins, called I Make Plugins, which auto-formats your ‘local’ plugin pages, so you don’t have to write anything, and just pull in the WordPress repository readme for your plugin. It’s almost like the Victor/Victoria of plugins. Anyway, my issue was I don’t use pages for my plugin listing, I use CPTs. And in order to use Mark’s plugin, I had to hack it.
So I did the smart thing, and emailed him with an “I love your plugin! Here’s what I had to change to make it work with a CPT, though.” A couple days later, Mark replied with “Use these filters instead. Untested!” He also bailed me out when I screwed it up, so he gets an Internet today.
Even though I’ve never actually messed with filters in this way (actions yes, filters I’m still learning), I sat down with my coffee and started reading. Yes, I actually read things before I jump in, contrary to what my friends think.
This turned out to be pretty simple, when you got around to it. Since Mark called apply_filters(NAME,PARAMS), all I had to do was add_filter(NAME,MYFUNCTION) and then make a function, passing the PARAMS and parsing as I needed. Mark fixed my original code (which was hellishly not optimized) and fixed my weird preview issue by returning an option I forgot.
Post Type
First I had to set the post type. In this case, Mark defaults to pages, I default to plugins. Yes, I named a post type ‘plugins.’ It works.
add_filter( 'i-make-plugins__post_type', 'halfelf_imp_posttype' );
function halfelf_imp_posttype() {
return 'plugins';
}
This takes in the arguments as $args, resets it to plugins, and returns the new value.
Get Plugins
Mark also has a ‘post parent’ so where I just use the CPT’s archive page for https://halfelf.org/plugins, he has an actual page with sub-pages. I don’t need post parent, so per Mark’s suggestion, I need to remove it from ‘get plugins.’
add_filter( 'i-make-plugins__get_plugins', 'halfelf_imp_getplugins' );
function halfelf_imp_getplugins( $options ) {
unset( $options['post_parent'] );
return $options;
}
Since the parameters I’m pulling in are an array, I have to use unset instead of making it a null value.
Is Plugin
The last check is to verify this is a plugin, and we can return the content. The normal string for this checks if the parent of the page is the ‘page parent’ (set earlier normally, unset by me). I just swapped it for a ‘is this a plugin?’ There are two parameters in this one, and the second is the post ID, which I need to check post type.
add_filter ('i-make-plugins__is_plugin', 'halfelf_imp_isplugin', 10, 2);
function halfelf_imp_isplugin( $is_plugin, $post ) {
$post = get_post( $post );
return $post->post_type === 'plugins';
}
Originally I had a call to is_preview() because, for some reason, it was overwriting all my post previews. While that only annoys me, it really annoys me! Thankfully once Mark fixed my ‘Get Plugins’ call, it all started working.
If you’ve been using WordPress seriously for a while, or Multisite for more than twenty minutes, you know about this weird thing called MU Plugins. That used to mean ‘Multi User’, as in WordPressMU, the predecessor to WordPress Multisite. The short version is that any plugin you put in there is ‘Automatically On’ for your site. On a Multisite Network, this means it’s on for all sites. On a single site, it means it’s on and you can’t turn it off.(
This was written without any special insider knowledge. I’ve simply watched, paid attention, and kept track for the last two years. Often when I report a plugin, Mark and Otto are nice enough to explain things to me, and I’ve listened.
There’s an argument that ‘Trust requires transparency’ when it comes to security (
To fix all this, you’d need to basically reboot the plugins directory, turn them all off, review each of the 18,000+ plugins, and turn them back on. Then you need an Otto or Nacin going through each one to make sure every check in is okay, every update and every change isn’t spamming. Oh yes, that’s what happens to theme devs, didn’t you know? All releases are approved before they go live. Can you see the plugin developers agreeing to that? That’s a nonsense complaint of mine, actually. If tomorrow the rules changed, maybe half the plugins in the repo would vanish and never come back, but most of the rest would be fine. Of course, we would need a dedicated team of people to do nothing but review and approve plugins to keep up with the traffic.
But why worry about a simple list of removed plugins? Because the first thing I would do, if I was a nefarious hacker, would be to script a pull from that list and scan the web looking for sites that use the plugins, thus implementing a vector for attack. See, we already know people don’t update plugins as often as they should (which is why Yoast’s ‘fix’ isn’t as good an idea as we’d hope), but now not only are we leaving people at risk, we’re opening them to even more risk. If we email them to tell them the plugin’s risky, we have the same problem.
