Как я могу заблокировать старую установку wordpress, которую я не собираюсь обновлять?

Привет! Я думаю, что ваш вопрос действительно полезен, поскольку он представляет собой очень правильный и ясный сценарий.

Объем вашего вопроса важен:

1. отключен доступ на запись в базу данных.
2. Я согласен с отключением комментариев с этого момента.

Второй момент не так важен для моего ответа, поскольку вы, вероятно, могли бы понимать пользовательский контент как "ваш" контент.

Пока вы используете mod_rewrite для отображения своего блога (Довольно Постоянные ссылки - это крылатая фраза в мире WordPress) у вас есть возможность быстро завершить работу, сохранив свой блог полностью.

Я предлагаю сделать статическую копию вашего блога, используя очень фундаментальную технику веб-хостинга/php/статики. В основном это использование преимуществ абстракции через веб-серверы/HTTP: Браузеру все равно, используете ли вы веб-приложение больше (здесь: блог wordpress) или веб-сервер обслуживает статические страницы только.

В Wordpress это уже каким-то образом встроено. Все это работает на уровне сервера в httpd.conf или .htaccess:

Веб-сервер проверяет, существует ли файл. Если это так, он вернет статический файл. Если нет, то вместо этого он вызовет wordpress. Если вы сравните это со стандартной настройкой wordpress.htaccess для довольно постоянных ссылок:

RewriteBase /blog/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /blog/index.php [L]

Вы можете видеть, что сначала проверяется наличие несуществующего файла и каталога. Теперь представьте, что index.php не просто вернул бы запрошенное содержимое местоположений, но при этом сохранит содержимое в виде файла в файловой системе, для которого предыдущие проверки вернули бы значение TRUE, чтобы обслуживать статический файл вместо вызова веб-приложения.

Итак, магия уже присутствует. Однажды существующий, это "кэш", срок действия которого никогда не истекает, пока вы не удалите статические файлы.

Этот принцип, кстати, очень старый. Некоторые знают, что это "путь PHP". Первый запрос генерирует полную страницу, второй запрос, вероятно, даже больше не будет нуждаться в mod_rewrite. Я тоже ничего не придумал, чувак, мне очень понравился этот документ Ральфа С. Энгельшаля, датированный декабрем 1997 года, ищите регенерацию контента на лету:

Регенерация содержимого на лету

Описание:

Здесь появляется действительно эзотерическая функция: динамически генерируемые, но статически обслуживаемые страницы, т.Е. Страницы должны доставляться как чистые статические страницы (читать с файловой системы и только что пройдены), но они должны динамически генерироваться веб-сервером, если отсутствуют. Таким образом, у вас могут быть сгенерированные CGI-страницы, которые статически обслуживаются, если только один (или одно из заданий) не удалит статическое содержимое. Затем содержимое обновляется.

Решение:

Это делается с помощью следующего набора правил:

 RewriteCond %{REQUEST_FILENAME}   !-s
 RewriteRule ^page\.html$          page.cgi   [T=application/x-httpd-cgi,L]

Здесь просьба к page.html приводит к внутреннему запуску соответствующей страницы.cgi, если page.html все еще отсутствует или имеет размер файла null. Хитрость здесь в том, что page.cgi - это обычный CGI-скрипт, который (в дополнение к своему стандартному выходу) записывает свои выходные данные в файл page.html . Как только он был запущен, сервер отправляет данные page.html . Когда веб-мастер хочет принудительно обновить содержимое, он просто удаляет page.html (обычно это делается закадычным другом).

(цитируется из связанного документа, просто найдите его)

Таким образом, в основном с помощью этого подхода вы можете решить свою проблему. Если вы получите 100 % охват URL-адресов и поэтому все ваши документы сгенерированы, вы даже можете отключить mysqldb. Это то, к чему я бы стремился: полная статическая версия вашего веб-сайта. Это даже упрощает переход на "архивный" сервер, так что какой-то сервер просто обслуживает и выполняет свою работу.

Как заморозить статику в Wordpress?

Вот небольшой фрагмент кода, который в основном вводит "вывод на диск" в любое приложение на основе PHP. Не стесняйтесь использовать его для всего, что вы видите подходит:

class htmlCached {
    static $instance;

    public static function bootstrap() {
        $file = $_SERVER['REQUEST_URI'];
        if ( '/' == substr($file, -1)) {
            $file .= 'index.html';
        }
        $self = dirname($_SERVER['PHP_SELF']).'/';

        if ($self != substr($file, 0, strlen($self))) {
            return;
        }

        $local = substr($file, strlen($self));

        // var_dump($file, $local, $self, $_SERVER);
        self::$instance = new htmlCached($local);
    }

    private $_file = '';
    public function __construct($file) {
        $this->_file = $file;
        ob_start(array($this, 'callback'));
    }
    public function callback($buffer) {
        $file = $this->_file;
        file_put_contents($file, $buffer);
        chmod($file, 0644);  // octal; correct value of mode
        return $buffer;
    }
}

Вам может понадобиться это, чтобы немного адаптировать для wordpress (так как это не из установки wordpress), но в основном в нем есть все, что вам нужно:

1. wp-config.php это самая первая точка входа, которую вы можете взломать index.php для более прямого подхода, а также. Введите определение класса в index.php . Index.php является так называемым интерфейсным контроллером для большинства приложений worpdress.
2. добавьте htmlCached::bootstrap(); спереди. это сделает свою работу. Работа заключается в следующем:
   1. htmlкэшированный включит буферизацию вывода с помощью процедуры обратного вызова.
   2. приложение работает в обычном режиме
   3. HTMLCACHED видит, когда приложение завершает работу (то есть, когда wordpress все сделал, это довольно глупое приложение, поэтому вы можете выполнять эти трюки)
   4. При завершении работы htmlCached сохраняет ответ сервера на диск (рядом с отправкой его в браузер).
   5. При следующем запросе apache будет обслуживать статическое содержимое.

Так что это легко для мгновение. Что вам нужно перепроверить с wordpress, так это CSS-файлы, JS-скрипты и, возможно, изображения/файлы (многосайтовые!).

Если вы не используете многоузловые или сложные плагины кэширования, возможно, вам уже пора идти.

Проверьте, какие файлы/URL-адреса были запрошены за время существования вашего сайта. Составьте список, запросите все файлы один раз. Работа сделана.

Затем удалите все файлы .php.

Уничтожьте базу данных.

Вы только что заблокировали свой сайт.

Если ваш Структура постоянных ссылок не заканчивалась на .html для всех ссылок, я бы предложил сохранить все файлы как .html (.html добавлен в запрос), а затем соответствующим образом настроить файл .htaccess. Итак, чтобы проверить наличие ЗАПРОСА-URL + .html для -f и, если он не существует, запустить экземпляр htmlCached WP (который также добавляет .html в имя файла, если этого еще нет в моем примере кода).

Счастливой реализации. Сначала сделайте резервную копию (как обычно). Для миграции вы можете сделать свою базу данных доступной только для чтения, установив соответствующие права для пользователя MySQL. Я бы сделал это в промежутке, так что вам не нужно спешить с реализацией этого. Например, узнать обо всех URL-адресах, которые были запрошены примерно за 10 лет, может быть непросто и может занять некоторое время.