Централизованное хранение js и css файлов для разных сайтов

Когда (почти всегда :-)) несколько сайтов находится на одной учётной записи хостинга, очень удобно бывает использовать общую библиотеку PHP-функций (а в идеале – фреймворк), доступ к которой из всех сайтов легко организовать по принципу '../' (повторить, сколько понадобится) от DOCUMENT_ROOT.

Но библиотеки образуются не только из PHP. От сайта к сайту, со временем накапливается ряд типичных функций js (что-нибудь вроде getCookie или addLoadEvent) и ряд часто используемых правил css (типа .abs {position:absolute;}, .rigth {text-align:right;}). В результате собираются небольшие библиотеки common.js, styles.css.

Доступ к js и css уже не организуешь по простому принципу '../' от DOCUMENT_ROOT (потому что выше DOCUMENT_ROOT для http-доступа пространства не существует), и клиентские библиотеки приходится дублировать. Это достаточно неудобно: нормальные библиотеки ведь постоянно развиваются, обновляются, и приходится заниматься нудной рутинной синхронизацией.

Существуют ли способы централизованного изменения библиотек js, css в пределах одного хостинга? Можно ли избежать ручного копирования новых версий на каждый сайт?

Варианты решений

1. Понятно, что есть тупой и однозначный способ централизации «в пределах мира» – поместить js и css библиотеки на отдельный домен, и в коде клиентских страниц указывать путь к файлам именно на этом домене. Но такой способ опасен: в случае недоступности «центрального» домена куча сайтов враз приобретёт самый чудовищный вид.

2. Ссылки на служебные файлы в HTML-коде должны всё-таки всегда вести приблизительно в ту же папку, откуда берутся сами страницы. В этом случае, если сервер упадёт, так отключится всё вместе – понятно и предсказуемо. Но вот js и css данные вовсе не обязательно хранить прямо в файлах с соответствующими именами (мы же не храним информацию, например, для интернет магазина в HTML-файлах).

2.1. Можно хранить данные служебных файлов в базе данных. Одна база данных может быть общей для нескольких сайтов. Даже на разных хостингах.

2.2. Файлов клиентских библиотек не так уж и много, и в этом плане БД не нужна. Удобнее хранить и обновлять их в центральном хранилище именно в виде файлов (и редактировать предназначенными для этого специальными программами, а не через CMS).

Реализация

Предположим, у нас два сайта в папках: /home/my_sites/site1/public_html, /home/my_sites/site2/public_html. А общие для сайтов файлы хранятся в папке /home/my_sites/common_lib. Предполагаем также, что в файлах .htaccess каждого сайта есть (достаточно обычный) набор правил, перенаправляющий все запросы на index.php:

RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-l RewriteCond %{REQUEST_FILENAME} !-d RewriteRule .* index.php [L]

В этом случае в файле index.php (или файле, подключаемом к нему по include) можно поместить примерно следующий код (PHP) для вывода js или css данных:

$mime = array( 'js' => 'text/javascript', 'css' => 'text/css' ); $uri = $_SERVER['REQUEST_URI']; $url = parse_url($def['uri']); if (preg_match("/(\w+\.)(js|css)$/i", $url['path'], $id)) { $file = $id[1] . '.' . $id[2]; header('Content-Type: ' . $mime[$id[2]] . '; charset=windows-1251'); print implode(file('/home/my_sites/common_lib/' . $file)); }

Можно забирать данные и с другого домена (другого хостинга) через http. Но, конечно, не в режиме реального времени (а по расписанию). Потому что в случае недоступности удалённого ресурса будут те же грабли, что и в Варианте 1. Есть, правда, вариант, принципиально решающий эту проблему: искать библиотеку на удалённом ресурсе, а при её недоступности использовать «центральное хранилище» своего хостинга. Но тут всё равно в реальном времени будут тормоза (время на проверку доступности удалённого хоста может сильно растягиваться).

Вариант с кэшированием

Файлы js и css могут забирать достаточно большой объём трафика, поэтому в норме они всегда должны быть именно файлами и хорошо кэшироваться (надолго застревать в кэше браузеров). Если примирить это требование с нашей системой централизованного хранения, получится идеальная схема. Создать её, оказывается, не так уж и сложно, просто надо продумать логику:

1. Вся css-js информация должна всё-таки храниться именно в виде обычных файлов и быть доступной на том же домене, что и html-страницы.
2. При обновлении файла в центральном хранилище должна производиться синхронизация (обновление соответствующих файлов на всех сайтах).
3. Ясно, что центральный ресурс не может обновлять все сайты (он может не знать обо всех), а наоборот, сайты должны быть «подписаны» на обновления в центре. То есть сайты должны по какой-то системе проверять обновления.

Система проверки обновлений может быть двух уровней. Первый уровень – хостинга – «непрерывная» или постоянная проверка, при каждом обращении к любой странице сайта. Второй уровень – синхронизации с удалённым хранилищем – проверка по расписанию. Второй уровень достаточно очевиден, по-другому его организовать просто нельзя. А вот с первым есть одна сложность: мы не можем проверить обновление конкретного файла по http-запросу к этому файлу – потому что по http-запросу этот файл будет просто отдан клиенту (даже не Апачем, а nginx'ом!), а PHP (или другой серверный скрипт) об этом ничего знать не будет.

Поэтому логика обновлений первого уровня может быть только «тотальной»: при любом задействовании серверного скрипта (при формировании любой страницы для клиента) проверять все файлы в центральном хранилище хостинга (в нашем примере – папка /home/my_sites/common_lib):

$lib_path = '/home/my_sites/common_lib'; $site_path = '/home/my_sites/site2/public_html'; $handle = opendir($lib_path); while (false !== ($file = readdir($handle))) { if (!preg_match("/\.(js|css)$/i", $file)) continue; $file_lib = $lib_path . '/' . $file; $file_site = $site_path . '/' . $file; $time_lib = (!file_exists($file_lib)) ? 0 : filemtime($file_lib); $time_site = (!file_exists($file_site)) ? 0 : filemtime($file_site); if ($time_lib > $time_site) { $ok = copy($file_lib, $file_site); if ($ok) touch($file_site, $time_lib); //Win!! } } closedir($handle);

Можно и ускорить проверку: создать, например, в папке библиотеки флажок в виде файла upd.ini с текстом внутри "0" или "1". Но кто будет изменять значение этого флага? Ясно, что при копировании файлов по ftp такая схема не сработает. Но вполне может быть работоспособной, если договориться о загрузке обновлённых файлов в центральное хранилище только через веб-интерфейс – тогда при загрузке файлов сам скрипт загрузки вполне может менять значение флажка на "1"; а скрипт проверки с сайта site1 после обновления будет «сбрасывать» флажок на "0". Блин. Но тогда site2 не узнает об обновлении! Значит, это должен быть не флажок, а поле типа timestamp ('2011-12-12 12:00:01'); и такой же проверочный файл upd.ini должен быть на каждом сайте; а скрипты обновления с сайтов должны будут сверять даты центрального файла upd.ini и своего. Н-да. Если проверяемых файлов всего 5 (как у нас сейчас), какая х.р разница, использовать upd.ini или нет?..

D.M., admin

Читать все комментарии (0)

Добавить комментарий:

*Автор:
E-Mail:
*Текст: