Wp-rocket: Htaccess поврежден при обновлении

Это снова произошло на одном из сайтов моих клиентов, обновившись с 3.0.5.1 до 3.1.

В файле .htaccess остались только директивы WP Rocket 3.1, исключив другие перенаправления и стандартный код WordPress .htaccess.

В результате каждая страница на ее сайте содержала ошибку 404, за исключением ее домашней страницы, что приводило к простоям около двух часов, пока нам не сообщили и не исправили ее. :(

Я знаю, что это сложно воспроизвести, но нам действительно нужно решение. Может быть, каждый раз, когда WP Rocket вносит изменения в файл .htaccess, он может делать локальную резервную копию, а затем сравнивать новые / старые файлы, а затем принимать меры, если код вне кода WP Rocket изменился?

Здесь та же проблема. Сегодня это уже четвертый раз происходит с одним из поддерживаемых мной сайтов. Как и выше, я обновился до 3.1.1, и все директивы были удалены, кроме WP Rocket и WordPress. Похоже, проблема с кодом, обновляющим файл из предыдущих версий.

@ecotechie Вы уверены, что директивы WordPress не были удалены? Я думаю, Cloudways, возможно, уже добавили это к тому времени, когда вы это сделали. Раньше, когда я сталкивался с этой проблемой, там был только код WP Rocket - все остальное пропало.

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

Ага! Это снова случилось с другим клиентом. Вчера вечером она обновилась до WP Rocket 3.1.2 - и в ее файле .htaccess остались только директивы WP Rocket, а все остальное было удалено.

Ее сайт не работал (за исключением ее домашней страницы) более 12 часов из-за этого ... и мне также пришлось вытащить копию ее файла .htaccess из резервной копии, чтобы восстановить остальные директивы, которые были в файле. (Повторное сохранение настроек постоянной ссылки приводит к резервному копированию сайта, но у нас были другие вещи в файле, которые были потеряны, когда WP Rocket удалил все.)

@Tabrisrp & @webtrainingwheels , есть ли способ повысить его в списке приоритетов?

МОЙ БОГ. Еще один клиент столкнулся с этой проблемой! Хорошо, что у нас есть резервные копии их файлов .htaccess ...

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

Все ли они размещены на одном хостинг-провайдере?

Единственная функция, которая записывает в htaccess, - это https://github.com/wp-media/wp-rocket/blob/master/inc/functions/htaccess.php#L13

И часть, которая выполняет удаление контента, - это $ftmp = preg_replace( '/# BEGIN WP Rocket(.*)# END WP Rocket/isU', '', $ftmp );

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

Хорошим тестом, чтобы определить, действительно ли проблема, будет проверка соответствия регулярного выражения одному из затронутых htaccess, например, на таком сайте, как https://www.phpliveregex.com/ .

Привет @Tabrisrp - спасибо, что

Большинство (возможно, все) сайтов, на которых мы столкнулись с этим, размещены на Cloudways, либо на серверах Vultr, либо на Linode.

И да, это действительно похоже на то, что функция preg_replace убирает все.

Вот один из поврежденных файлов .htaccess (мне пришлось переименовать его, чтобы загрузить сюда):
htaccess.txt

Я возился с сайтом phpliveregex.com, и, похоже, он отлично работает с этим файлом .htaccess:
https://www.phpliveregex.com/p/p1o
(нужно переключиться на preg_replace, но тогда он работает)

Да, действительно, для этого файла htaccess он работает правильно. Проблема может быть позже в работе.

Можете ли вы воспроизводить проблему каждый раз, если вы обновляете / откатываете между версиями, или это происходит случайно?

Спасибо @Tabrisrp.

Мы не пытались воспроизвести проблему на каких-либо сайтах (в конце концов, это живые сайты, и мы просто хотели, чтобы они снова заработали). Однако, если это произойдет снова на другом сайте, мы можем быстро попробовать.

На данный момент я догадываюсь, что это либо (1) связано с определенной настройкой сервера, либо (2) метод, в котором выполняется обновление. (Страница пакетных обновлений и страница плагинов - и если одновременно выполняются другие обновления). Я только что отправил по электронной почте двум последним клиентам, чтобы узнать, помнят ли они, как именно они запускали обновления.

Кроме того, я только что отправил Василису еще несколько примеров файлов .htaccess по его просьбе. Хотя в них не так много настроек, и они очень похожи на многих других клиентов, у которых не было проблем (например, перенаправления http-> https).

Узнал от одного клиента о процессе ее обновления:

Я сделал обновления из Панели управления> Обновления. Я обновил сразу несколько плагинов, это были: Wp Rocket, SEO от Yoast и Social Warfare (я их точно помню). Также было обновление Social warfare pro, но оно не работало. Итак, из 4 плагинов 3 обновились, а WP Rocket испортился.

В настоящее время я склоняюсь к проблеме, связанной с сервером, поскольку, AFAIK, все случаи, которые у нас были для этого, были на Cloudways.

Полученный htaccess действительно содержит правила WP Rocket, но все остальное исключено, верно?

Все недавние случаи точно были на Cloudways. Те, что произошли недели / месяцы назад, я точно не помню, но, скорее всего, они тоже были Cloudways.

И да, полученный файл .htaccess содержит новые правила WP Rocket (с самым новым номером версии), и все.

Это снова случилось с другим клиентом. Такая же точная ситуация. Она на хостинге Cloudways. Она обновилась до 3.1.3 и в итоге получила файл .htaccess, в котором были только материалы WP Rocket - все остальное было удалено. Прикреплены файлы до / после .htaccess.

Она сказала: «Я была на странице« Все плагины ». Я сначала обновила один плагин (не помню, какой) после установки первого флажка во всплывающем окне UpDraft. Затем я обновила плагин WP Rocket. -in, но сначала снял флажок во всплывающем окне, чтобы мне не пришлось ждать, пока будет запущено дополнительное резервное копирование ».

(Похоже, она запускала обновления плагинов по одному, и все обновлялось правильно, как мне показалось.)

htaccess_original.txt
htaccess_broken-by-update.txt

@Tabrisrp Проблема, кажется, усугубляется. В праздничные выходные это повторилось (по крайней мере) еще на двух клиентских сайтах, когда они обновили WP Rocket. Оба находятся на Облачных дорогах.

Не уверен, что эта информация помогает, но: Один из них работает:

• Apache / 2.4.10 (64-битный # 1 SMP Debian 3.16.51-3 + deb8u1)
• PHP 7.0.31-1 ~ dotdeb + 8.1
• MySQL 5.6.41.

Другой сайт работал:

• Apache / 2.4.10 (64-разрядная версия # 1 SMP)
• PHP 7.2.9-1 + 0 20180901081207.4 + jessie ~ 1.gbpdaac35
• MySQL 5.6.41

Сейчас мы отчаянно нуждаемся в решении и / или обходном пути ... как я могу помочь решить эту проблему?

По крайней мере, может ли WP Rocket сохранить локальную резервную копию файла .htaccess перед внесением изменений? Тогда хоть восстановление будет намного быстрее / проще.

Спасибо!

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

Спасибо, Реми. Я свяжусь с ними - с кем вы разговаривали? Попробую подключиться к тому же человеку.

(Это также произошло на сайте другого клиента.)

Эй, может быть проблема с правами доступа к файлам? В Cloudways главный пользователь на сервере - это что-то вроде master_xndjwemw, но WordPress работает под своим собственным пользователем (независимо от имени пользователя «приложения»). Я часто сталкиваюсь с неприятностями, когда пользователь WordPress создает файлы (например, при установке плагина из репозитория), которые затем принадлежат имени пользователя приложения, а затем, когда я использую FTP, вошел в систему с учетной записью master_, master_ У учетной записи недостаточно прав для редактирования этих файлов. Может, это как-то связано со всем этим?

К сожалению, это продолжает оставаться серьезной проблемой; это случилось снова на сайте другого клиента вчера, и снова сегодня утром на другом сайте.

И служба поддержки Cloudways, и мне не удалось воспроизвести проблему с какой-либо последовательностью.

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

На этом этапе, поскольку мы не можем изолировать основную причину проблемы, не могли бы вы хотя бы добавить проверку ошибок, чтобы в случае ее возникновения было найдено автоматическое решение?

@Tabrisrp - Это снова произошло на сайте другого клиента сегодня утром - она ​​обновила WP Rocket и бум, все остальное в ее файле .htaccess пропало. Точно такая же проблема, хотя раньше я не видел, чтобы этот сайт был затронут. Это также на Cloudways.

На этом этапе, поскольку мы не можем изолировать основную причину проблемы, не могли бы вы хотя бы добавить проверку ошибок, чтобы в случае ее возникновения было найдено автоматическое решение?

У клиента есть сайт на Cloudways. Я обновил WP Rocket с 3.1.4 до 3.2.2 без проблем.

Однако, когда я открыл файл _htaccess_ с помощью Notepad ++, я увидел следующее:

Выше NUL были правила htaccess WP Rocket.

Я удалил NUL s, сохранил его в новом файле и diff проверил два файла _htaccess_ с помощью Meld:

Оригинальный _htaccess_ можно скачать по этой ссылке:
https://mega.nz/#!SpVUnS5S!42C5hVJlEXhL5EssO6QtDtKIc2Z_cho2UiRlykIDlK0

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

Связанный билет:
https://secure.helpscout.net/conversation/711583715/86840?folderId=2135277

Спасибо, что добавили это! Как бы то ни было, я не встречал этой конкретной проблемы раньше ни на одном из наших сайтов, на которых были проблемы с обновлением с удалением остальной части .htaccess.

Возможный случай: https://secure.helpscout.net/conversation/717560494/88121?folderId=273761

Спасибо!! 😃

Просто был другой клиент на Cloudways с этой проблемой. Это происходило реже, но очевидно, что это все еще проблема.

😢

Да, только что повторилось с другим сайтом. Клиент обновился, и бум, файл .htaccess потерял все, кроме (нового) кода WP Rocket.

... и это все еще происходит. Другой клиент на Cloudways обновился с v3.3.3 до v3.3.3.1 ... точно такая же проблема.

@webtrainingwheels есть еще идеи?

@webtrainingwheels @Tabrisrp Не могли бы вы повторно открыть этот билет? К сожалению, это точно не решено.

Только что случилось снова на другом сайте. Также размещен на Cloudways. Обновлено 3.3.2 до 3.3.3.1.

Интересно, что этот сайт был обновлен с помощью Staging Pilot, который сначала обновляется на промежуточном сервере, а затем отправляет обновленные файлы плагинов на действующий сайт. Я думаю, что это первый раз, когда обновление Staging Pilot столкнулось с проблемой.

... и это случилось снова, на другом сайте, который был обновлен с помощью Staging Pilot.

Это был третий сайт, на котором возникла эта проблема в последнем обновлении 3.3.3.1.

Привет @Tabrisrp похоже, что коммит, закрывающий эту проблему, проверяет только стандартную копию WordPress в файле .htaccesss, а не какой-либо пользовательский код, который удаляется. Это правильно? Если так, это не решит проблему. Кроме того, у меня только что был удален файл .htaccess на другом сайте, и он взял с собой все директивы, кроме WP Rocket.

Случай, который кажется похожим:
https://secure.helpscout.net/conversation/977417384/126315/

Это было на Dreamhost .

Это все еще проблема. Мы только что обновили клиент с 3.4.4 до 3.5.1. Проверил сайт после обновления, и все вроде нормально. Через пару часов она написала нам по электронной почте, потому что работала только ее домашняя страница. Разумеется, из файла .htaccess было удалено все, кроме кода WP Rocket.

Произошло и на другом сайте на прошлой неделе.

У меня была аналогичная проблема, которая могла быть связана с этим. Мой клиент связался со мной и сообщил, что веб-сайт не работает и работает только домашняя страница. Я проверил файл htaccess, и в нем не хватало около 500 нижних строк из 1000 с чем-то строк. Таким образом, первые 500 или около того строк содержат код WP Rocket и некоторые перенаправления, в то время как другая половина, содержащая больше перенаправлений и директив wordpress, отсутствует. Веб-сайт размещен на облачном сервере / сервере цифрового океана.

Связанный билет: https://secure.helpscout.net/conversation/1192263109/172159/

Аналогичная проблема с другим сайтом. .htaccess состоял из 636 строк, но обновление удалило все, кроме первых 134. Остались новые директивы WP Rocket и некоторые строки Redirect 301 . Это кажется чем-то новым, поскольку раньше он удалял ВСЕ директивы, кроме новых WP Rocket, но это оставило некоторые строки позади, как то, что случилось с @goddas выше.

С удовольствием отправлю файлы по электронной почте, если хотите ....

https://secure.helpscout.net/conversation/1297510459/198847?folderId=377611
Это случилось с этим клиентом за последние 2 обновления. Размещено на 02switch.
Это невозможно воспроизвести после первой попытки обновления. Откат и повторное обновление будут успешными.
Что происходит с нашей стороны только в самом первом обновлении каждой версии?

@blogtutor Сообщил, что это все еще происходит с ними:
https://secure.helpscout.net/conversation/1302688547/200372?folderId=3326173

Возможно связанный билет: https://secure.helpscout.net/conversation/1319380832/205461/
Сайт размещен на OVH.

[WIP] Я расследую похожий случай, произошедший на OVH: https://secure.helpscout.net/conversation/1302165472/200249/#thread -3776342425

Пожалуйста, найдите комментарий клиента и мои выводы в примечании здесь: https://secure.helpscout.net/conversation/1319380832/205461/#thread -3804061230

Обновление: я получил ответ от одного из клиентов ( билет ).

Я запретил WP Rocket писать в файл htaccess на их сайте. Несмотря на это, через несколько недель файл был поврежден.
Другие плагины записывались в этот файл.

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

Возможно связанные - https://secure.helpscout.net/conversation/1335422175/211113/

Возможно, связано: https://secure.helpscout.net/conversation/1366892923/223063/

снова произошло для клиента при обновлении до 3.8: https://secure.helpscout.net/conversation/1368024563/223391

Это продолжает происходить с нашими клиентами на серверах Cloudways. Я не могу не подчеркнуть, насколько это проблематично! Это переводит весь сайт (сохранить домашнюю страницу) в автономный режим и приводит к сильной панике владельца сайта, часто требующей экстренного реагирования / поддержки в нерабочее время.

ПОЖАЛУЙСТА, ПОЖАЛУЙСТА, ИСПРАВИТЬ ЭТО! Я ПРОШУ ТЕБЯ.

Кроме того, вы действительно говорили об этом с Cloudways? Ясно, что в их настройке есть что-то уникальное - даже это "просто" nginx перед apache ... Их поддержка на переднем крае не принесет пользы, но, возможно, вы могли бы поработать с одним из их старших специалистов или разработчиков?

Я отправил электронное письмо нескольким менеджерам по работе с клиентами и заместителям вице-президентов - с удовольствием отправлю их контактную информацию, если это будет полезно.

Связанный билет: https://secure.helpscout.net/conversation/1366892923/223063/
Хост: O2switch

Связанный билет: https://secure.helpscout.net/conversation/1374886981/225451?folderId=3326173
Ведущий: Hetzner.

Связанный билет: https://secure.helpscout.net/conversation/1389568405/229477?folderId=2135277
Хозяин: Dreamhost

Связанный билет: https://secure.helpscout.net/conversation/1391871951/230082?folderId=3864740
Хост: WPopt, использующий веб-сервер Litespeed.

Связанный билет: https://secure.helpscout.net/conversation/1392031396/230125?folderId=3864740
Хозяин: OVH

Потенциально связанный билет: https://secure.helpscout.net/conversation/1401738049/232928/

Связанный билет: https://secure.helpscout.net/conversation/1404506358/233660?folderId=2135277

Хозяин: Variomedia AG

Связанный билет - https://secure.helpscout.net/conversation/1429056639/240402/
Bluehost - PHP 7.2.34

Новый подход к этому вопросу:

Найдите решение ✅

Используйте insert_with_markers () для записи наших правил в flush_rocket_htaccess() . Эта функция взята из ядра WP и представляет собой более продвинутую версию того, что мы делали (включая некоторую блокировку файла).

Новая функция будет выглядеть примерно так:

function flush_rocket_htaccess( $remove_rules = false ) { // phpcs:ignore WordPress.NamingConventions.PrefixAllGlobals
    global $is_apache;

    /**
     * Filters disabling of WP Rocket htaccess rules
     *
     * <strong i="11">@since</strong> 3.2.5
     * <strong i="12">@author</strong> Remy Perona
     *
     * <strong i="13">@param</strong> bool $disable True to disable, false otherwise.
     */
    if ( ! $is_apache || ( apply_filters( 'rocket_disable_htaccess', false ) && ! $remove_rules ) ) {
        return false;
    }

    if ( ! function_exists( 'get_home_path' ) ) {
        require_once ABSPATH . 'wp-admin/includes/file.php';
    }

    if ( ! function_exists( 'insert_with_markers' ) ) {
        require_once ABSPATH . 'wp-admin/includes/misc.php';
    }

    $htaccess_file = get_home_path() . '.htaccess';
    $insertion     = '';

    if ( ! $remove_rules ) {
        $insertion = get_rocket_htaccess_marker();
    }

    // Update the .htaccess file.
    return insert_with_markers( $htaccess_file, 'WP Rocket', $insertion );
}

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

Это также должно быть сделано в рамках нашего рефакторинга кода, связанного с htaccess (# 2759), и для него должны быть добавлены модульные / интеграционные тесты.

Оцените усилия ✅

Для этой конкретной части усилия составляют [S]

Вероятно, связанный: https://secure.helpscout.net/conversation/1443506061/244478/

Вероятно, связано: https://secure.helpscout.net/conversation/1453543452/247525