Если вы создаете новую CMS, попробуйте добавить прямо сейчас, с самого начала, возможность хранить статические ресурсы в корне сети и ваши php библиотеки вне этого корня сети . Храните в корневом каталоге только файл index.php.
Итак, что дает сначала это дерево:
path/
\-to/
\-cms/
\-www/
\-index.php
-static\
\-js/ /* cms shared js */
-css/ /* cms shared css */
-images/ /* cms shared images */
\-lib/
\-cms.php /*lots of php files related to the cms*/
Теперь вы хотите работать с несколькими веб-сайтами внутри одной и той же cms и скрыть имя веб-сайта статического ресурса ... Это приводит к двум вопросам:
- почему обработка нескольких сайтов с одной и той же установкой cms, развертывание cms несколько раз, по одному для каждого сайта обычно лучше, ИМХО. Но в любом случае, почему бы и нет.
- зачем скрывать имя сайта в URL статического ресурса?
На второй вопрос я вижу только одну причину, чтобы сделать это, это оптимизированная политика кэширования этих активов. Вы хотите сказать, что www.example1.com/static/images/foo.png - это то же изображение, что и www.example2.com/static/images/foo.png. Что-то, что хорошо настроенный обратный прокси может сделать. Но хороший cms также может обрабатывать общий домен для общих статических ресурсов, например: cdn.example.com/static/shared/images/foo.png.
Теперь вы, возможно, на самом деле имеете ужасный URL, как: http://www.example2.com/cms/www.examples2.com/static/images/foo.png. И да, это довольно уродливо, просто потому, что вы можете попытаться проверить некоторые статические ресурсы с example1.com при просмотре example2.com, изменив ссылку вручную. Таким образом, кто-то может отправить URL http://www.seriouswebsite.com/static/images/adultcontent.com/foo.png с заявлением о том, что серьезныеwebsite.com хранит некрасивую картинку, просто потому, что adultcontent.com обрабатывается на том же сервере с теми же CMS. Теперь это не очень важно, сделано в других cms, как, например, в многодоменном управлении по умолчанию в Drupal, например . Я предполагаю, что у вас есть такая ситуация, которую вы не хотите, и вы хотели бы, чтобы ее обрабатывал URL в такой форме: http://www.example2.com/images/foo.png.
Забудьте об управлении статическими файлами с помощью PHP . Статические файлы действительно быстро обрабатываются веб-сервером, и даже больше - кешем обратного прокси. PHP убьет ваши выступления.
Итак, у вас мультидоменное дерево cms сейчас:
path/
\-to/
\-cms/
\-www/
\-index.php
-static\
\-js/ /* cms shared js */
-css/ /* cms shared css */
-images/ /* cms shared images */
-domain1.com/
\-static\
\-js/
-css/
-images/
-domain2.net/
\-static\
\-js/
-css/
-images/
\-lib/
\-cms.php /*lots of php files related to the cms*/
Одним из решений является rewriteRule для статического контента, с префиксом статического URL-адреса и именем домена, но вы потеряете возможность загружать общие ресурсы cms. Вы все еще можете сделать это, если доменным ресурсам предшествует ключевое слово, например «local».
Итак, чтобы получить:
# private image
/path/to/cms/www/domain1.com/static/images/foo.png => http://domain1.com/static/local/images/foo.png
# shared by the cms
/path/to/cms/www/static/images/foo.png => http://domain1.com/static/images/foo.png
Теперь rewriteRule должен обнаружить часть ' static / local ' и переписать ее в ' static / domain1.com ', когда текущий домен - domain1.com. Что-то подобное (непроверенные):
RewriteRule ^static/local/(.*)$ %{HTTP_HOST}/static/$1 [QSA,L]
Это решение добавляет несколько ограничений: