Resposta curta

example.com/bob/files/picture.jpg é o URL canônico preferido para imagens em uma instalação do WordPress Multisite . As duas URLs com blogs.dir na URL são essencialmente idênticas e ambas utilizam a estrutura do sistema de arquivos. O caminho com 'bob' existe porque você fez uma instalação de subdiretório, não uma de subdomínio. Outros caminhos existiriam com base em seus outros sites, por exemplo example.com/fred/wp-content/blogs.dir/5/files/pictures.jpg. Caso contrário, não existem outros caminhos.

Resposta longa

Há muita coisa que podemos explicar sobre esse processo, e eu não tenho 100% de certeza do nível de detalhe que você está procurando, então vou dar uma olhada no básico aqui.

O WordPress Multisite armazena arquivos por blog_id (o "5" depois de "/blogs.dir/") para manter as coisas organizadas e separar os arquivos de sites diferentes. Essa estrutura de diretórios não deve ser pública. O WordPress usa regras de reescrita para rotear ^files/(.+) para wp-includes/ms-files.php?file=$1 e, em seguida, wp-includes/ms-files.php processa e gera a saída da imagem e / ou alguns cabeçalhos úteis. Existem algumas vantagens para isso:

• Em termos de segurança, menos informação é sempre melhor. "wp-content / blogs.dir / 5" é um pequeno TMI - diz que você está executando o WordPress Multisite e que o blog_id é 5.
• A estrutura da URL é idêntica à de uma instalação de site único. Se você fosse mover um site de uma instalação do Multisite para si próprio, você não precisaria atualizar essas referências no banco de dados ou 301 os caminhos antigos para referências externas.
• Você pode mover o diretório de arquivos para fora do acesso público ou deny from all a .htaccess , por exemplo, as pessoas não podem acessar o tamanho original das imagens se você não quiser.
• Você pode adicionar o controle de acesso a arquivos específicos

Há uma desvantagem principal, que é que as imagens / arquivos estão passando pelo PHP (e talvez até mesmo requerem algumas consultas do MySQL), então requer mais recursos. Se você tiver um plug-in de armazenamento em cache instalado, os recursos adicionais deverão ser insignificantes.

Com relação aos filtros, você não pode filtrar nada facilmente no processo por um motivo: nem mu-plugins , plugins ou o seu tema seja carregado *. O melhor que você pode fazer é sobrescrever as constantes em wp-config.php. Aqui estão as constantes mais úteis / relevantes que você pode sobrepor:

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 );

* Embora os plug-ins não sejam carregados, drop- ins fazer. Portanto, enquanto você não pode usar plugins padrão, o WordPress ainda estabelece as bases para fazer o que você precisa, como (como mencionado acima), adicionando o controle de acesso a arquivos sensíveis. O drop-in sunrise.php seria um bom lugar para adicionar esse código.

Na configuração de instalações multisite com o WordPress 3.5 ou posterior, ms-files.php é ignorado diretamente e blogs.dir não é usado.

Em vez disso, os uploads são armazenados em wp-content/blogs/{blog_id} e referidos como tal. Isso significa que há apenas uma maneira de acessar arquivos em uma instalação de subdomínio, e somente dois em subdiretórios são instalados.