Respuesta corta

example.com/bob/files/picture.jpg es la URL canónica preferida para las imágenes en una instalación de WordPress Multisite . Las dos URL con blogs.dir en la URL son esencialmente idénticas, y ambas aprovechan la estructura del sistema de archivos. La ruta con 'bob' existe porque hizo una instalación de sub-directorio, no una instalación de subdominio. Existen otras rutas basadas en sus otros sitios, por ejemplo, example.com/fred/wp-content/blogs.dir/5/files/pictures.jpg. De lo contrario, no existen otras rutas.

Respuesta larga

Hay mucho que se puede explicar acerca de este proceso, y no estoy 100% seguro del nivel de detalle que está buscando, por lo que voy a explicar lo básico aquí.

WordPress Multisite almacena archivos por blog_id (los "5" después de "/blogs.dir/") para mantener las cosas organizadas y separar los archivos de los diferentes sitios. Esta estructura de directorio no pretende ser pública. WordPress usa reglas de reescritura para enrutar ^files/(.+) a wp-includes/ms-files.php?file=$1 , y luego wp-includes/ms-files.php procesa y genera la imagen y / o algunos encabezados útiles. Hay algunas ventajas a esto:

• En términos de seguridad, menos información siempre es mejor. "wp-content / blogs.dir / 5" es un pequeño TMI: dice que está ejecutando WordPress Multisite y que el blog_id es 5.
• La estructura de URL es idéntica a la de una instalación de un solo sitio. Si alguna vez moviera un sitio de una instalación de sitios múltiples a la suya, no tendría que actualizar esas referencias en la base de datos o 301 las rutas antiguas para referencias externas.
• Puede mover el directorio de archivos fuera del acceso público o de deny from all a .htaccess , por lo que, por ejemplo, las personas no pueden acceder a los tamaños de imagen originales si no lo desean.
• Puede agregar control de acceso a archivos específicos

Hay una desventaja principal, que es que las imágenes / archivos pasan a través de PHP (y quizás incluso requieran algunas consultas de MySQL), por lo que requiere más recursos. Si tiene instalado un complemento de almacenamiento en caché, los recursos adicionales deberían ser insignificantes.

Con respecto a los filtros, no puede filtrar fácilmente nada en el proceso por una razón: ni mu-plugins , plugins , o tu tema se carga *. Lo mejor que puedes hacer es anular las constantes en wp-config.php. Aquí están las constantes más útiles / relevantes que puede anular:

if ( !defined( 'UPLOADBLOGSDIR' ) )
    define( 'UPLOADBLOGSDIR', 'wp-content/blogs.dir' );

if ( !defined( 'UPLOADS' ) ) {
    // Uploads dir relative to ABSPATH
    define( 'UPLOADS', UPLOADBLOGSDIR . "/{$wpdb->blogid}/files/" );
    if ( 'wp-content/blogs.dir' == UPLOADBLOGSDIR )
        define( 'BLOGUPLOADDIR', WP_CONTENT_DIR . "/blogs.dir/{$wpdb->blogid}/files/" );
}

/**
 * Optional support for X-Sendfile header
 */
if ( !defined( 'WPMU_SENDFILE' ) )
    define( 'WPMU_SENDFILE', false );

/**
 * Optional support for X-Accel-Redirect header
 */
if ( !defined( 'WPMU_ACCEL_REDIRECT' ) )
    define( 'WPMU_ACCEL_REDIRECT', false );

* Aunque los complementos no se cargan, drop- ins hacer. Por lo tanto, aunque no puede usar complementos estándar, WordPress aún sienta las bases para hacer lo que necesite, como (como se mencionó anteriormente) agregar el control de acceso a los archivos confidenciales. El drop-in sunrise.php sería un buen lugar para agregar dicho código.

En la instalación de instalaciones multisitio con WordPress 3.5 o posterior, se omite directamente a ms-files.php , y no se usa blogs.dir .

En cambio, las cargas se almacenan en wp-content/blogs/{blog_id} y se denominan como tales. Esto significa que hay solo una forma de acceder a los archivos en una instalación de subdominio, y solo dos en la instalación de subdirectorios.