class-wp-upgrader.php is using the wrong theme directory

[toscho]

There are multiple places in class-wp-upgrader.php with a hard coded path to WP_CONTENT_DIR . '/themes'. Upgrades will fail if the theme directory is actually in another place.

If there is still a wp-content/themes directory, the theme will be installed into that, but the old theme is used and the upgrade nag doesn’t go away.

If there is no such directory the upgrader dies with an error.

In both cases the user is stuck with an outdated theme and no ability to the new one.

Test plugin to reproduce this bug:

<?php
/* Plugin Name: Local Theme Roots */

add_filter( 'theme_root_uri', 't5_switch_theme_root' );
add_filter( 'theme_root',     't5_switch_theme_root' );

/**
 * Create a custom theme directory.
 *
 * @wp-hook theme_root
 * @wp-hook theme_root_uri
 * @author  Thomas Scholz, http://toscho.de
 * @param   string $in URL or path
 * @return  string
 */
function t5_switch_theme_root( $in )
{
	if ( 'theme_root_uri' === current_filter() )
		return 'http://trunk-themes.wp';

	// If we made it so far we are in the 'theme_root' filter.
	$new_root = 'F:\wp.trunk.themes';
	register_theme_directory( $new_root );
	return $new_root;
}

The solution is to use get_theme_root() instead of a fixed path.

The attached patch does exactly that. Tested on latest Trunk.

Replace fixed path with get_theme_root()

I'm not sure how much this is a "bug". Yes, the upgrader expects that wp-content/themes exists, but so does core. We register '/themes' as the first theme root before any regular plugins are loaded.

Even then should each theme upgrade go into the directory where the theme was installed, and the upgrade nag should go away.

+1

Anything that generates a PHP error is a bug.

Even if we ignore that bug, I'd say that toschos patch should be added anyway on different grounds, of good practice and API consistency. get_theme_root 's function shouldn't be duplicate in code elsewhere in core