Opened 15 years ago
Closed 15 years ago
#14840 closed defect (bug) (fixed)
Constant UPLOADS not working for the main site if MULTISITES is not enabled
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | 3.0.2 | Priority: | high |
Severity: | major | Version: | 3.1 |
Component: | Upload | Keywords: | |
Focuses: | Cc: |
Description (last modified by )
You can enable Multisite support by defining the constant
"MULTISITE“ within wp-config.php. Thus if you don't have multisite support enabled the Constant isn't set and defined(constant("MULTISITE“)) returns false. However on line 89 of the file wp-settings.php the constant "MULTISITE“ is defined and set to „false“ if your wp is not a multisite wp.
// Initialize multisite if enabled. if ( is_multisite() ) { require( ABSPATH . WPINC . '/ms-blogs.php' ); require( ABSPATH . WPINC . '/ms-settings.php' ); } elseif ( ! defined( 'MULTISITE' ) ) { define( 'MULTISITE', false ); }
Due to this the overwriting of the upload path which is possible by defining the constant "UPLOADS“ doesn't work for the main site because the if clause in in line 2146 of wp-includes/functions.php
if ( defined('UPLOADS') && !$main_override && ( !isset( $switched ) || $switched === false ) ) { $dir = ABSPATH . UPLOADS; $url = trailingslashit( $siteurl ) . UPLOADS; }
isn't true even if the CONSTANT 'UPLOADS' is defined because $main_override is true and thus !$main_override is false. $main_override is true because line 2127 of the same file is in this case true.
$main_override = defined( 'MULTISITE' ) && is_main_site();
From my point of view it would be better to use
$main_override = MULTISITE && is_main_site();
used Version: a development version (3.1-alpha) (SVN TRUNK Sept. 10 2010)
Change History (5)
#2
@
15 years ago
- Cc wpmuguru added
- Component changed from General to Upload
- Keywords CONSTANT UPLOADS no Multisite main blog removed
- Milestone changed from Awaiting Review to 3.0.2
- Priority changed from normal to high
- Severity changed from normal to major
#3
@
15 years ago
Actually, the check in wpdb works because it is wrapped in an is_multisite() call, hence functionally valid.
Appears to have limited impact. These are functionally valid checks:
./wp-admin/menu.php:198: if ( ( ! is_multisite() || defined( 'MULTISITE' ) ) && defined('WP_ALLOW_MULTISITE') && WP_ALLOW_MULTISITE && is_super_admin() ) ./wp-includes/wp-db.php:643: if ( defined( 'MULTISITE' ) && ( 0 == $blog_id || 1 == $blog_id ) ) ./wp-settings.php:88:} elseif ( ! defined( 'MULTISITE' ) ) { ./wp-includes/load.php:611: if ( defined( 'MULTISITE' ) ) ./wp-admin/network.php:21:if ( is_multisite() && ! defined( 'MULTISITE' ) ) ./wp-admin/includes/upgrade.php:1114: if ( $wp_current_db_version < 14139 && is_multisite() && is_main_site() && ! defined( 'MULTISITE' ) && get_site_option( 'siteurl' ) === false )
Thus the only issue is this line.
I see what's going on here.
We utilize a conditional defined('MULTISITE') check not to check if the site is running multisite, but if the site is running multisite AND is not an upgraded MU installation. In select cases, we handle MU and 3.0 multisite installs differently.
When we forced MULTISITE to always be defined in [14000], I didn't take into account this.
We could introduce a is_legacy_multisite() function that we can use for select defined('MULTISITE') checks, as I'm afraid this isn't the only location that has this code. I think the only other instance however is wpdb::get_blog_prefix, which should be fired prior to us defining MULTISITE as false. So it works in that instance.
If we add an is_multisite() check to $main_override, this bug is fixed.