Sometimes when you’re working with a local site, especially with existing data, and need to log in as a user and don’t want to mess with resetting the password (or there’s some weird SSO/MFA that’s getting in the way) you just want it to work.
Well, here you go. This snippet will automatically log you in to WordPress using the admin login. I don’t recommend using this anywhere near production or on a server that’s publicly available–for obvious reasons.
But anyway, here’s the bad idea:
<?php/**
* Force login as admin user on every request.
*/functionlol_bad_idea_force_admin_login(): void{
wp_die( 'This is a really bad idea!' ); // Remove this, it's here to stop copy paste problems for people who don't read the code.// Check if user is not already logged in.if ( ! is_user_logged_in() ) {
// Grab user object by login name.
$user = get_user_by( 'login', 'admin' );
if ( $user ) {
// Set the current user to this admin account.
wp_set_current_user( $user->ID );
// Set the WordPress auth cookie.
wp_set_auth_cookie( $user->ID );
}
}
}
add_action( 'init', 'lol_bad_idea_force_admin_login' );
Code language:PHP(php)
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:
I made a small site recently where I wanted all newly registered users from a specific email domain to automatically be administrators (this is a terrible idea, don’t do it). The user registration was restricted by Single-Sign-On and 2-Factor Authentication, so I felt relatively safe doing this, especially since it was only a “for fun” project.
The interesting bit of code that upgraded users to admins is as follows:
