Due to the crazy good deals that Humble provides, I discovered that I had hundreds of Steam keys that I haven’t registered.
After spending way too long exporting all of my keys from the Humble site, via some JS console trickery, I ended up with a spreadsheet of 1,285 unique Steam keys.
Unfortunately, I’ve randomly activated a number of these over the years as I’ve wanted to… but I don’t know which ones, so I needed a way to bulk register. Luckily, other smarter people have already figured this out: SteamBulkActivator did the job well! The only downside is that after a number of failed activations (10 I believe) there was an hour cooldown.
That means I’ve spent quite a while going through and testing all of my keys. Here’s the breakdown of what I ended up with:
Already Registered – Games I already own, or keys I’ve already registered. There’s a good chance that there are a lot of keys here that are still unregistered. The next thing I’ll need to do is try to figure out how to separate the unregistered keys from the already used ones
Success – I now have 383 new games!
Bad activation key – Humble sometimes provides keys to stores other than Steam. This is likely where these came from.
Duplicate activation code – The key was activated on someone else’s account. I probably gave this key away to someone else because I already had the game.
I wish it were easier to map a key to a game so I could find out what these are, but this is still better than having unused keys laying around that I paid for.
Let’s say you’re going along your day, developing things, and fixing things, and making the world a better place when all of a sudden you get a call from a client that their website is broken!! After a bit of panicking and digging around, it turns out that they’ve been “optimizing” things by disabling random, but critical, plugins on the site.
The Solution
One way that you might fix this is to not install the plugins via the WordPress UI and require() them either in the theme directory, or as an mu-plugin. The downside with this is that you lose the ability to easily and auto-update the plugins (if you’re okay with that). You also the ability to easily see what plugins are active and installed in the admin UI.
The way I’ve got around this is to create this helper function inside an mu-plugin that allows the plugins to be installed and managed in the UI, but not disabled:
<?php/**
* Secures a plugin from accidental disabling in the UI.
*
* If a plugin is necessary for a site to function, it should not be disabled.
* This functionc can also optionally "force" activate a plugin without having to
* activate it in the plugin UI. Forcing activation will cause it to skip all
* core plugin activation hooks.
*
* @param string $plugin Plugin file to secure.
* @param boolean $force_activation Optional. Whether to force load the plugin. Default false.
*/functionemrikol_secure_plugin( $plugin, $force_activation = false ){
$proper_plugin_name = false;
// Match if properly named: wp-plugin (wp-plugin/wp-plugin.php).if ( file_exists( WP_PLUGIN_DIR . '/' . $plugin . '/' . $plugin . '.php' ) && is_file( WP_PLUGIN_DIR . '/' . $plugin . '/' . $plugin . '.php' ) ) {
$proper_plugin_name = $plugin . '/' . $plugin . '.php';
} else {
// Match if improperly named: wp-plugin/cool-plugin.php.if ( file_exists( WP_PLUGIN_DIR . '/' . $plugin ) && is_file( WP_PLUGIN_DIR . '/' . $plugin ) ) {
$proper_plugin_name = $plugin;
}
}
if ( false !== $proper_plugin_name ) {
if ( true === $force_activation ) {
// Always list the plugin as active.
add_filter( 'option_active_plugins', function( $active_plugins )use( $proper_plugin_name ){
// Crappy hack to prevent infinite loops. Surely there's a better way.global $emrikol_is_updating_active_plugins;
if ( true === $emrikol_is_updating_active_plugins ) {
unset( $emrikol_is_updating_active_plugins );
return array_unique( $active_plugins );
}
if ( ! in_array( $proper_plugin_name, $active_plugins, true ) ) {
$active_plugins[] = $proper_plugin_name;
$emrikol_is_updating_active_plugins = true;
update_option( 'active_plugins', array_unique( $active_plugins ) );
}
return array_unique( $active_plugins );
}, 1000, 1 );
}
// Ensure the plugin doesn't get disabled somehow.// TODO: Diff arrays. Only run if the plugin is being removed.
add_filter( 'pre_update_option_active_plugins', function( $active_plugins )use( $proper_plugin_name ){
if ( ! in_array( $proper_plugin_name, $active_plugins, true ) ) {
$active_plugins[] = $proper_plugin_name;
}
return array_unique( $active_plugins );
}, 1000, 1 );
// Remove the disable button.
$plugin_basename = plugin_basename( $proper_plugin_name );
add_filter( "plugin_action_links_$plugin_basename", function( $links )use( $proper_plugin_name, $force_activation ){
if ( isset( $links['deactivate'] ) ) {
$links['deactivate'] = sprintf(
'<span class="emrikol-secure-plugin wp-ui-text-primary">%s</span>',
$force_activation ? 'Plugin Activated via Theme Code' : 'Plugin Secured via Theme Code'
);
}
return $links;
}, 1000, 1 );
}
}
Code language:HTML, XML(xml)
It’s not perfect, but it’s working for me right now. Like, right now on this site as you’re reading this. I’ve added it as an mu-plugin like so:
As you can see, this completely removes the “Deactivate” link in the UI:
The emrikol_secure_plugin() function takes two arguments:
The plugin to secure. This can either be the plugin slug (ex. jetpack) or the full plugin path if the plugin doesn’t follow standard naming conventions (wp-super-cache/wp-cache.php)
A boolean, defaults to false. If it is true the plugin will be forced to activate without user intervention. This can be used to activate a plugin on a new install without having to manually enable it in the UI or via WP-CLI
The problem came up recently about how to make sure plugins activated in the WordPress plugin UI don’t get deactivated if they are necessary for a site to function. I thought that was an interesting thought puzzle worth spending 15 minutes on, so I came up with this function as a solution:
