update_core capability for WordPress user

update_core user capability

WordPress Codex gives us nothing about update_core capability for WordPress user, except WordPress version of its appearing in the code – 3.0. I suppose according to its name, that update_core capability is used to decide, if user can update core WordPress file using built-in WordPress upgrade feature or not. What do you think?

Thoughts are just thoughts, while they are not confirmed by practice and strong experiment. Thus, I decided to check this obviouse guess, satisfy my curiosity and investigate, how and for what purpose WordPress uses update_core capability really. Result of my little investigation will be shown to you below.

update_core capability for WordPress user was found at 8 PHP files. WordPress really uses it to check if user has right to fulfil automatic update of WordPress itself. Additionally this capability is checked to decide if output notice to the user about WordPress core updates available.

That’s it. Is it too short in order to be true? But that’s full information for update_core capability on the ordinal WordPress user level, even if he is WordPress admin.
If you are WordPress developer or you are a curious person and has some knowledge of PHP, I have a lot of code phragments from WordPress core files for you, which illustrate how and with what purpose WordPress uses update_core user capability.

Let’s go through WordPress source code together and look where update_core capability is used. Text search through all PHP files inside WordPress 3.4.1 installation folders gave me this list of files:

wp-admin/about.php;
wp-admin/includes/schema.php;
wp-admin/includes/update.php;
wp-admin/menu.php;
wp-admin/network/menu.php;
wp-includes/capabilities.php;
wp-includes/update.php

wp-admin/about.php

This is WordPress “About” page familiar to all of us. There is “Go to Dashboard → Home” link at the bottom of this page. If user has update_core capability, this code adds additional “Return to Dashboard → Updates” (“Return to Updates” for multi-site) link, in case “About” page was opened after WordPress core update:

<?php if ( current_user_can( 'update_core' ) && isset( $_GET['updated'] ) ) : ?>
<a href="<?php echo esc_url( self_admin_url( 'update-core.php' ) ); ?>"><?php 
	is_multisite() ? _e( 'Return to Updates' ) : _e( 'Return to Dashboard &rarr; Updates' );
?></a> |
<?php endif; ?>

wp-admin/includes/schema.php

As commented at file header: “WordPress Administration Scheme API. Here we keep the DB structure and option values”. We see confirmation for words from Codex here – update_core capability was added to WordPress with version 3.0:

/**
 * Create and modify WordPress roles for WordPress 3.0.
 *
 * @since 3.0.0
 */
function populate_roles_300() {
	$role =& get_role( 'administrator' );
 
	if ( !empty( $role ) ) {
		$role->add_cap( 'update_core' );

wp-admin/includes/update.php

As commented at file header: “WordPress Administration Update API. The admin side of our 1.1 update system”.
1st time, update_core capability is used at function core_update_footer(). If user has not rights to update WordPress core files, there is no variations for him at WordPress footer. He see “Version 3.4.1” always, as function stops its execution in this case:

84
85
86

function core_update_footer( $msg = '' ) {
	if ( !current_user_can('update_core') )
		return sprintf( __( 'Version %s' ), $GLOBALS['wp_version'] );

Other variants of this footer could be: “You are using a development version N.N.N. Cool! Please stay updated” or “Get Version N.N.N” with links to the correspondent core files update stuff.
2nd, function update_nag() checks update_core capability and stops in user has not it under multi-site environment, or shows information about new WordPress version available with invitation to update for user with update_core capability and just notification without link for other users under single-site environment.

function update_nag() {
	if ( is_multisite() && !current_user_can('update_core') )
		return false;
 
	global $pagenow;
 
	if ( 'update-core.php' == $pagenow )
		return;
 
	$cur = get_preferred_from_update_core();
 
	if ( ! isset( $cur->response ) || $cur->response != 'upgrade' )
		return false;
 
	if ( current_user_can('update_core') ) {
		$msg = sprintf( __('<a href="http://codex.wordpress.org/Version_%1$s">WordPress %1$s</a> is available! <a href="%2$s">Please update now</a>.'), $cur->current, network_admin_url( 'update-core.php' ) );
	} else {
		$msg = sprintf( __('<a href="http://codex.wordpress.org/Version_%1$s">WordPress %1$s</a> is available! Please notify the site administrator.'), $cur->current );
	}

Other notice “You are using WordPress N.N.N. Update to Latest” is shown from function update_right_now_message() for user with update_core capability only:

function update_right_now_message() {
	$msg = sprintf( __('You are using <span class="b">WordPress %s</span>.'), $GLOBALS['wp_version'] );
 
	if ( current_user_can('update_core') ) {
		$cur = get_preferred_from_update_core();

The last occurence of update_core capability at wp-admin/includes/update.php is function maintenance_nag() with notice about failed WordPress update and link to retry it again for user with update_core capability or just ask to notify site administrator for others:

function maintenance_nag() {
 global $upgrading;
if ( ! isset( $upgrading ) )
  return false;
if ( current_user_can('update_core') )
  $msg = sprintf( __('An automated WordPress update has failed to complete - <a href="%s">please attempt the update again now</a>.'), 'update-core.php' );
else
  $msg = __('An automated WordPress update has failed to complete! Please notify the site administrator.');

wp-admin/menu.php

As commented at file header: “Build Administration Menu”.
If user has update_core capability he will see “Update” menu item at “Dashboard” menu item of administrator menu:

36
37
38

if ( ! is_multisite() ) {
	$submenu[ 'index.php' ][10] = array( sprintf( __('Updates %s'), "<span class='update-plugins count-{$update_data['counts']['total']}' title='{$update_data['title']}'><span class='update-count'>" . number_format_i18n($update_data['counts']['total']) . "</span></span>" ), 'update_core',  'update-core.php');
}

wp-admin/network/menu.php

This file is commented as “Build Network Administration Menu”. WordPress checks update_core capability here to decide if show to user “Available Updates” menu item under “Update” menu of Network management menu for multi-site configuration of WordPress:

58	$submenu[ 'upgrade.php' ][10] = array( __( 'Available Updates' ), 'update_core', 'update-core.php' );

wp-admin/update-core.php

Header comments for this file is: “Update Core administration panel”. update_core capability for WordPress user is checked here at very begin. If user has not such capability, execution of this script is stopped.

21
22

  if ( ! current_user_can( 'update_core' ) )
	wp_die( __( 'You do not have sufficient permissions to update this site.' ) );

wp-includes/capabilities.php

It is “WordPress Roles and Capabilities” file. function map_meta_cap() which maps meta capabilities to primitive capabilities has update_core capability inside its text:

 // Fall through if not DISALLOW_FILE_EDIT.
 case 'update_plugins':
 case 'delete_plugins':
 case 'install_plugins':
 case 'update_themes':
 case 'delete_themes':
 case 'install_themes':
 case 'update_core':
	// Disallow anything that creates, deletes, or edits core, plugin, or theme files.
	// Files in uploads are excepted.
	if ( defined('DISALLOW_FILE_MODS') && DISALLOW_FILE_MODS ) {
		$caps[] = 'do_not_allow';
		break;
	}

Key moment WordPress develper should know – if constant “DISALLOW_FILE_MODS” is defined and it’s equal to 1 or true, then update_core capability will not work – map_meta_cap() returns ‘do_not_allow’ always in this case, inspite of the fact, that user has update_core capability or he has not.

wp-includes/update.php

Comment form WordPress developers for this file is: “A simple set of functions to check our version 1.0 update service”. update_core capability is checked at function wp_get_update_data() which collects counts and UI strings for available updates and doesn’t show information about available WordPress updates if user has not update_core capability:

  if ( function_exists( 'get_core_updates' ) && current_user_can( 'update_core' ) ) {
	$update_wordpress = get_core_updates( array('dismissed' => false) );
	if ( ! empty( $update_wordpress ) && ! in_array( $update_wordpress[0]->response, array('development', 'latest') ) && current_user_can('update_core') )
		$counts['wordpress'] = 1;
}

Thus, our little trip inside the dense forest of WordPress core source code is finished.
Happy blogging!

Regards,
Vladimir.

Tags: capability, Security, user capability, WordPress

This entry was posted on Sunday, August 5th, 2012 at 09:56 and is filed under General, WordPress, WordPress Capabilities. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.