Uplaod problem /uplaod/sites/136/sites/136

[sudeervc]

The upload folder adds another layer of "/sites/foldernumber" For example /wp-content/uploads/sites/136/sites/136/2019/. Instead it should be simply /wp-content/uploads/sites/136/2019/

Please fix.

Thanks,
Sudeer.

[Manakio]

After you create your new network, you need to go in and manually go to /network/sites.php and 'edit' your primary network sites (Upload Path) field (see attached image). I used to have a script that would do this automatically but it stopped working. If you crated a site and it's all jacked, you will just need to manually move the files to the correct place and also update the same field in your new site.

[sudeervc]

Well, We dint have this problem until version 1.8.1, Up until plugin version 1.8.1 - when we create a network, the upload path was left blank and all uploads by default gets uploaded to the respective folder in wp-content/uploads/sites/sitenunmber".

We upgraded the plugin to 2.20 like in April of this year and created like 5 networks and all have upload path set to wp-content/blogs.dir/*no" or wp-content/uploads/sites/"no"/sites/*no"

Possible to get it working as like in 1.8.1, to leave it blank and by default gets uploaded to wp-content/uploads/sites/?

Thanks,
Sudeer.

[Manakio]

So I can confirm this is newer behavior. For a while there it was putting files into the blogs.dir folder but now it appears as though it's putting them in both? Actually not sure how or why. It has to do with how it's writing the settings file for the new networks multisite. This should be marked as a potential bug

[christianwach]

@JJJ On a bare bones test install, the paths are set correctly with the removal of these lines. It seems that WordPress itself handles adding /sites/* to the URL and path of assets so appending to upload_path and upload_url_path when creating a new network results in /sites/*/sites/*.

I'm unsure what the consequences of changing the behaviour on existing multi-network installs might be - but for fresh ones, it seems those lines can be removed.

[christianwach]

A follow up note regarding WP-CLI

@JJJ Even when the paths fix above is applied, creating a new network with WP-CLI results in the new network defaulting to the use of blogs.dir unless the ms_files_rewriting option is explicitly set on the new network. For parity with the defaults in WP_MS_Networks_Admin::handle_add_network() I think it's also worth considering:

• Setting the default clone_network to the site ID derived from the --url param
• Setting the default options_to_clone to network_options_to_copy() (or at minimum specifying ms_files_rewriting to avoid the bug you identified)

IOW, replacing these lines with something like:

$clone_network = $assoc_args['clone_network'];
if ( empty( $clone_network ) ) {
	$clone_network = get_current_site()->id;
}
$network_exists = get_network( $clone_network );
if ( ! $network_exists ) {
	WP_CLI::error( sprintf( "Clone network %s doesn't exist.", $clone_network ) );
}

$options_to_clone = false;
if ( ! empty( $clone_network ) && $network_exists ) {
	if ( ! empty( $assoc_args['options_to_clone'] ) ) {
		$options_to_clone = explode( ',', $assoc_args['options_to_clone'] );
	} else {
		$options_to_clone = array_keys( network_options_to_copy() );
	}
}

This also fixes what looks like a bug in the current code where $options_to_clone is only ever set when the network specified by clone_network doesn't exist.