[wp-trac] [WordPress Trac] #25650: When switching between blogs, wp_upload_dir 'baseurl' and 'url' may be pointing to the current blog not the switched one

[WordPress Trac]

#25650: When switching between blogs, wp_upload_dir 'baseurl' and 'url' may be
pointing to the current blog not the switched one
--------------------------+------------------------------
 Reporter:  igmoweb       |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Upload        |     Version:  3.6.1
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:  multisite
--------------------------+------------------------------

Comment (by ideag):

 The above patch only affects the behavior of `_wp_upload_dir()` function
 in one specific case:
 1. `upload_url_path` option is not explicitly set for a site;
 2. At least one of these are true:
   a. `upload_path` option is not set;
   b. `upload_path` option is set to `'wp-content/uploads'` (the default
 for that option);
   c. `upload_path` option value is equal to `ABSPATH`

 In that specific case I'm replacing `WP_CONTENT_URL` constant with a call
 to `content_url()`, which (before patching) always resolves back to the
 `WP_CONTENT_URL` constant, but additionally sets the url scheme with
 `set_url_scheme()` and is filterable via the `content_url` filter hook.

 This patch further changes the behaviour of `content_url()` in one
 specific case. On multisite, when switch_to_blog() is called and was
 `WP_CONTENT_URL` NOT explicitly defined in `wp-config.php`, it does not
 rely on the constant (which was set back when we have not switched to a
 different blog yet and does not make sense anymore), but calls
 `get_option('siteurl')` for the **current** blog directly.

 Behaviour of `content_url()` in different scenarios:

 ||= No =||= Multisite? =||= `ms_is_switched()` =||= `WP_CONTENT_URL` =||=
 Current behaviour =||= Patched behaviour =||
 || 1 || No || No || Explicitly defined in `wp-config.php` ||
 `WP_CONTENT_URL` || `WP_CONTENT_URL` ||
 || 2 || No || No || Dynamically defined in `default-constants.php` ||
 `WP_CONTENT_URL` which resolves to `get_option( 'siteurl' ) . '/wp-
 content'` || `WP_CONTENT_URL` which resolves to `get_option( 'siteurl' ) .
 '/wp-content'` ||
 || 3 || Yes || No || Explicitly defined in `wp-config.php` ||
 `WP_CONTENT_URL` || `WP_CONTENT_URL` ||
 || 4 || Yes || No || Dynamically defined in `default-constants.php` ||
 `WP_CONTENT_URL` which resolves to `get_option( 'siteurl' ) . '/wp-
 content'` || `WP_CONTENT_URL` which resolves to `get_option( 'siteurl' ) .
 '/wp-content'` ||
 || 5 || Yes || Yes || Explicitly defined in `wp-config.php` ||
 `WP_CONTENT_URL` || `WP_CONTENT_URL` ||
 || 6 || Yes || Yes || Dynamically defined in `default-constants.php` ||
 `WP_CONTENT_URL` which resolves to `get_option( 'siteurl' ) . '/wp-
 content'` where `get_option()` gets data from the original site ||
 `get_option( 'siteurl' ) . '/wp-content'` where `get_option()` gets data
 from the switched-to site ||

 I think it would be OK to stop relying on the constant in all cases where
 it is set dynamically in the `default-constants.php` file as it does
 resolve to the same `get_option()` call anyway, but I was trying to limit
 this patch as much as possible to just fix the issue at hand. If you think
 it is wise to make it broader, I can expand the patch to cove those cases
 as well.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/25650#comment:19>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform