Risposta breve
example.com/bob/files/picture.jpg è l'URL canonico preferito per le immagini in un'installazione multisito di WordPress . I due URL con blogs.dir
nell'URL sono essenzialmente identici ed entrambi sfruttano la struttura del filesystem. Il percorso con 'bob' esiste perché è stata eseguita un'installazione nella sottodirectory, non un'installazione sottodominio. Altri percorsi esisterebbero in base agli altri tuoi siti, ad esempio esempio.com/fred/wp-content/blogs.dir/5/files/pictures.jpg. Altrimenti, non esistono altri percorsi.
Risposta lunga
C'è molto che uno può spiegare su questo processo, e non sono sicuro al 100% del livello di dettaglio che stai cercando, quindi approfondirò le basi qui.
WordPress Multisite archivia i file di blog_id
("5" dopo "/blogs.dir/") per mantenere le cose organizzate e separare i file di siti diversi. Questa struttura di directory non è destinata a essere pubblica. WordPress utilizza regole di riscrittura per instradare ^files/(.+)
a wp-includes/ms-files.php?file=$1
, e poi wp-includes/ms-files.php
elabora ed emette l'immagine e / o alcuni header utile. Ci sono alcuni vantaggi in questo:
- In termini di sicurezza, meno informazioni è sempre meglio. "wp-content / blogs.dir / 5" è un po 'TMI - dice che stai usando WordPress Multisite e che
blog_id
è 5.
- La struttura dell'URL è identica a quella di un'installazione a sito singolo. Se dovessi mai spostare un sito da un'installazione Multisito alla propria, non dovresti aggiornare quei riferimenti nel database o 301 i vecchi percorsi per riferimenti esterni.
- Puoi spostare la directory dei file fuori dall'accesso pubblico o
deny from all
in .htaccess
tal modo, ad esempio, le persone non possono accedere alle dimensioni dell'immagine originale se non lo desideri.
- È possibile aggiungere il controllo di accesso a file specifici
C'è uno svantaggio principale, ovvero che le immagini / i file passano attraverso PHP (e forse richiedono anche alcune query MySQL), quindi richiedono più risorse. Se è installato un plug-in di cache, le risorse aggiuntive dovrebbero essere trascurabili.
Per quanto riguarda i filtri, non puoi facilmente filtrare nulla nel processo per un motivo: né mu-plug-in , plug-in o il tuo tema vengono caricati *. Il meglio che puoi fare è sovrascrivere le costanti in wp-config.php. Ecco le costanti più utili / pertinenti che è possibile ignorare:
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 );
* Anche se i plug-in non vengono caricati, i drop-in lo fanno. Pertanto, sebbene non sia possibile utilizzare plug-in standard, WordPress pone comunque le basi per fare tutto ciò di cui hai bisogno, come (come menzionato sopra) aggiungendo il controllo dell'accesso ai file sensibili. Il drop-in sunrise.php
sarebbe un buon posto per aggiungere tale codice.