Здається, Wordpress дозволяє вмісту вирішувати багато URI-файлів при встановленні MU. Наприклад:

 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

Усі, здається, прямують до того самого місця. Чи більше псевдонімів? Який з них є канонічним? Чи є якісь із цих випадкових? Чи є відповідні фільтри?

Коротка відповідь

example.com/bob/files/picture.jpg є кращою канонічною URL-адресою для зображень у програмі WordPress Multisite . Два URL-адреси з blogs.dirURL-адресою по суті є однаковими, і обидві використовують структуру файлової системи. Шлях з 'bob' існує тому, що ви зробили встановлення підкаталогу, а не встановлення піддомену. Інші шляхи існуватимуть на ваших інших сайтах, наприклад example.com/fred/wp-content/blogs.dir/5/files/pictures.jpg. Інакше інших шляхів не існує.

Довга відповідь

Про цей процес можна багато пояснити, і я не на 100% впевнений у рівні деталізації, яку ви шукаєте, тому я поясню основи тут.

WordPress Multisite зберігає файли blog_id("5" після "/blogs.dir/"), щоб зберігати впорядковані речі та розділяти файли різних сайтів. Структура цього каталогу не має бути загальнодоступною. WordPress використовує переписування правил для маршрутизації ^files/(.+)до wp-includes/ms-files.php?file=$1, а потім wp-includes/ms-files.phpобробляє і виводить зображення і / або деякі корисні заголовки. У цьому є кілька переваг:

• Щодо безпеки, то менше інформації завжди краще. "wp-content / blogs.dir / 5" - це трохи TMI - це говорить про те, що ви працюєте з WordPress Multisite і що blog_idце 5.
• Структура URL ідентична структурі установки для одного сайту. Якби ви коли-небудь переміщали сайт із установки Multisite на власну, вам не доведеться оновлювати ці посилання в базі даних або 301 старі шляхи для зовнішніх посилань.
• Ви можете перемістити каталог файлів із загальнодоступного доступу або deny from allчерез нього .htaccess, наприклад, люди не можуть отримати доступ до оригінальних розмірів зображень, якщо ви цього не хочете.
• Ви можете додати контроль доступу до певних файлів

Є один головний недолік, який полягає в тому, що зображення / файли проходять через PHP (і, можливо, навіть потрібно кілька запитів MySQL), тому для цього потрібно більше ресурсів. Якщо у вас встановлений плагін кешування, додаткові ресурси повинні бути незначними.

Що стосується фільтрів, ви не можете легко фільтрувати нічого в процесі з однієї причини: ні mu-плагіни , ні плагіни, ні ваша тема не завантажуються *. Найкраще, що ви можете зробити, це перевизначення констант у wp-config.php. Ось найбільш корисні / відповідні константи, які ви можете перекрити:

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

* Навіть незважаючи на те, що плагіни не завантажуються, плагіни роблять. Тому, хоча ви не можете використовувати стандартні плагіни, WordPress все ще закладає основу робити все необхідне, як-от (як згадувалося вище), додаючи контроль доступу до чутливих файлів. Цей пункт sunrise.phpбуде гарним місцем для додавання такого коду.

У встановленні багатомісних установок з WordPress 3.5 або новіших версій, ms-files.phpвін обходить безпосередньо, і blogs.dirне використовується.

Натомість завантаження зберігаються wp-content/blogs/{blog_id}та називаються такими. Це означає, що існує лише один спосіб отримати доступ до файлів при встановленні субдомена, і лише два - в підкаталозі.