Реализовать работу с веб-сайтом в автономном режиме?

Question

Не нужно делать это прямо сейчас, но думая о будущем ...

Каким будет ваш метод для веб-сайта «offline» для небольшого использования пользовательских кодированных cms? Значение дает возможность администраторам войти в панель администратора, ввести сообщение в поле и отправить форму. Затем это сообщение будет отображаться, а не любая другая страница для любого пользователя, если пользователь не является администратором.

Я сделал это раньше и использовал файл if if, затем загружаю содержимое из xml-файла и помещает фона конструкции из-за сообщения в поле входа, которое позволяет администраторам регистрироваться. Когда администратор вводит сообщение в поле хранит текст в xml. Когда они вернули сайт «назад к жизни», он просто удалит xml-файл.

Единственная проблема заключалась в том, что после того, как сайт рос, потребовалось больше обращений, и проверка файла существовала при каждой загрузке каждой страницы. У кого-нибудь есть лучшее решение для меня?

Спасибо.

Answer 1

Предполагая, что это находится на Apache.

Если это вообще возможно, я бы рекомендовал делать это, используя .htaccess файл, который перенаправляет все запросы на «сайт вниз» сообщение.

Что-то вроде:

RewriteRule (.*) /downmessage.php [L] 

(обратите внимание, что любые изображения ресурсы будут перенаправлены, тоже)

По сравнению с проверкой PHP на стороне флага и в автономном режиме сообщения, это быстрее, плюс он имеет огромное преимущество в том, что ресурсы, такие как загруженные изображения и таблицы стилей, уже не достижимы - и в противном случае они могут быть связаны с кэшированными файлами, URL-адресами, картинами Google Images ...

В механизме «offline» на основе PHP, где эти ресурсы не блокируются, e факт, что некоторые ресурсы по-прежнему доступны , если кто-то знает URL, очень сложно объяснить пользователям («но мы взяли сайт, не так ли?»), и если сайт будет снят из-за юридических проблем, связанных с опубликованное изображение (может случиться со всеми!), изображение все равно может быть доступно без знания владельца сайта.

Недостатком этого является то, что на сервере требуется модуль mod_rewrite, а PHP должен иметь доступ для записи к файлу .htaccess: как не всегда так.

Однако, хотя этот метод имеет свои преимущества, основная предпосылка вашего вопроса стоит рассмотреть, прежде чем вносить какие-либо изменения. Вы говорите, что проверка для XML-файла takedown занимает слишком много времени. Я не думаю, что это так.file_exists() чеки встроены в систему и должны не вызвать заметное замедление даже для очень многих запросов. Средняя страница Drupal или WordPress загружает десятки включенных файлов по каждому запросу. Один файл_exists pales в сравнении.

Answer 2

Просто идея:

Вы можете установить флаг в обработчике базы данных (например, maintenance = TRUE), то вы можете контролировать, какие запросы к базе данных разрешены или нет. В большинстве случаев вы хотите разрешить чтение базы данных, пока ваш сайт находится под техобслуживанием.

Примечание: Это будет работать только в том случае, если все ваши запросы к базе данных находятся под контролем.

Answer 3

Возможно, для вас возможно установить значение APC. Поскольку они хранятся в памяти, это будет молниеносно. Но не забывайте, что значения APC не будут сохраняться при перезапуске сервера. Поэтому, если вам нужен «режим поддержки» в течение очень длительного периода времени, вы должны вместо этого сохранить значение в базе данных.

Answer 4

Самый простой способ - проверить наличие (локального) файла (необязательно выводить его содержимое, например/etc/nologin). Если Ops хотят удалить сайт, они могут создавать его независимо на каждом веб-сервере.

Сделайте это в некотором общем коде, который выполняется на каждой странице, прежде чем пытаться получить доступ к базе данных.

Причина этого заключается в том, что операционная система может отказаться от использования базы данных в автономном режиме в течение периода обслуживания, поэтому вы не можете сохранить ее в базе данных.

Проверка наличия локального файла - очень низкая служебная операция, которая не сильно повлияет на производительность обычного корпуса.