Wordpress semble laisser le contenu être adressé par de nombreux URI dans une installation MU. Par exemple:

 example.com/wp-content/blogs.dir/5/files/picture.jpg
 example.com/bob/files/picture.jpg
 example.com/bob/wp-content/blogs.dir/5/files/pictures.jpg

Tous semblent se diriger vers le même endroit. Y a-t-il plus d'alias? Lequel est canonique? Y en a-t-il par accident? Existe-t-il des filtres pertinents?

Réponse courte

example.com/bob/files/picture.jpg est l'URL canonique préférée pour les images dans une installation WordPress Multisite . Les deux URL avec blogs.dirdans l'URL sont essentiellement identiques et exploitent toutes les deux la structure du système de fichiers. Le chemin d'accès avec «bob» existe parce que vous avez effectué une installation de sous-répertoire, pas une installation de sous-domaine. D'autres chemins existeraient en fonction de vos autres sites, par exemple example.com/fred/wp-content/blogs.dir/5/files/pictures.jpg. Sinon, aucun autre chemin n'existe.

Longue réponse

Il y a beaucoup de choses à expliquer sur ce processus, et je ne suis pas sûr à 100% du niveau de détail que vous recherchez, alors je vais vous expliquer les bases ici.

WordPress Multisite stocke les fichiers par blog_id(le "5" après "/blogs.dir/") pour garder les choses organisées et séparer les fichiers des différents sites. Cette structure de répertoires n'est pas destinée à être publique. WordPress utilise des règles de réécriture pour acheminer ^files/(.+)vers wp-includes/ms-files.php?file=$1, puis wp-includes/ms-files.phptraite et génère l'image et / ou certains en-têtes utiles. Il y a quelques avantages à cela:

• En termes de sécurité, moins d'informations c'est toujours mieux. "wp-content / blogs.dir / 5" est un petit TMI - il dit que vous utilisez WordPress Multisite et que le blog_id5.
• La structure de l'URL est identique à celle d'une installation sur un seul site. Si vous deviez déplacer un site d'une installation multisite vers la sienne, vous n'auriez pas à mettre à jour ces références dans la base de données ou 301 les anciens chemins pour les références externes.
• Vous pouvez déplacer le répertoire de fichiers hors de l'accès public ou deny from allle .htaccessfaire ainsi, par exemple, les gens ne peuvent pas accéder aux tailles d'image d'origine si vous ne le souhaitez pas.
• Vous pouvez ajouter un contrôle d'accès à des fichiers spécifiques

Il y a un inconvénient principal, c'est que les images / fichiers passent par PHP (et peut-être même nécessitent quelques requêtes MySQL), donc cela nécessite plus de ressources. Si un plugin de mise en cache est installé, les ressources supplémentaires doivent être négligeables.

En ce qui concerne les filtres, vous ne pouvez pas facilement filtrer quoi que ce soit dans le processus pour une raison: ni les mu-plugins , les plug -ins ou votre thème ne sont chargés *. Le mieux que vous puissiez faire est de remplacer les constantes dans wp-config.php. Voici les constantes les plus utiles / pertinentes que vous pouvez remplacer:

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

* Même si les plugins ne sont pas chargés, les drop-ins le font. Par conséquent, bien que vous ne puissiez pas utiliser de plugins standard, WordPress jette toujours les bases pour faire tout ce dont vous avez besoin, comme (comme mentionné ci-dessus) en ajoutant le contrôle d'accès aux fichiers sensibles. Le drop-in sunrise.phpserait un bon endroit pour ajouter un tel code.

Dans les installations multisites, la configuration avec WordPress 3.5 ou version ultérieure ms-files.phpest directement ignorée et blogs.dirn'est pas utilisée.

Au lieu de cela, les téléchargements sont stockés wp-content/blogs/{blog_id}et désignés comme tels. Cela signifie qu'il n'y a qu'une seule façon d'accéder aux fichiers sur une installation de sous-domaine et seulement deux sur l'installation de sous-répertoire.