они по умолчанию будут адресованы в соответствии с настройкой DocumentIndex (в конфиге Apache, который, опять же в зависимости от настроек можно переопределить в .htaccess), в котором, (как правило) в том числе указывается index.php (наряду с index.html, index.htm и т.д.)
Т.е. запросы на /?page=***.. можно обработать
а) добавив в index.php (или, что более правильно, но всё равно "не идеологично" в wp-config) строку вида
include './page-redirect-handler.php';
б) используя auto_prepend_file
Я там чуть выше варианты привёл, как можно и без этого обойтись..
И да, то что wordpress вставил в .htaccess не запрещается редактировать (и даже удалять) при понимании ))
добавить строчку в index.php (или в config)
хоть и не самый лучший выход, но вполне рабочий (вполне возможно, что работать будет до какого-нибудь обновления)..
про альтернативный prepend - сказал.
Есть ещё вариант через обработчик 404 страницы отлавливать...
Но глобально.. смысл даже не в том, чтобы mod_rewrite не грузить совсем, а в том, чтобы 70 редиректов с двумя регулярками каждый перенести в 70 редиректов без регулярок. Хотя, .htaccess позволяет проводить построчное сравнение, но повально где надо и не надо используются регулярки..
Они в index.php придут. В нём можно обработчик include-ть.
или без правок в index.php через prepend_file..
Человек, зайдя в robots.txt, узнает, что у вас там логи лежат )))
Лучше уж через .htaccess.. сделать deny..
Или, как вариант - в каталог складывать и Basic http auth прикрутить..
чё это? Отнюдь.. Его можно как отключить на уровне сервера, так и исключить его использование при обработке .htaccess (а ещё и добавить AllowOverride, чтоб в поддиректориях .htaccess не дёргать)
Сложность в том, что понятие "кэширование" (в общем случае) достаточно широко.. А в случае "веб-хостинга" на него ещё и накладывается ряд ограничений..
Лично сталкивался с ситуацией, описанной на первой странице:
что банально приводило к повторной загрузке и разбору данных при каждом открытии страницы..
У ТС "просто хостинг", какой второй сервер?..
Не исключено, что ТС не в курсе, кто автор системы и как "оно" работает.. Есть ли там вообще кэш.. и "какое там CMS"..
Как минимум, поэтому считаю, что советовать "включить кэш", без понимания "что и где там".. слегка опрометчиво.. Хотя.. может ведь и прокатит )) ---------- Добавлено 21.08.2019 в 00:14 ----------
там хостер письмо прислал про "какой-то лимит CPU".. Вы о чём? )))
Теоретик же )))))
с десяток регекспов в .htaccess // чего уж говорить про ...
и построчное сравнение (поиск по ключу в массиве) на быстром php7.* ))
* без обработки этих регекспов (да и вообще, без загрузки mod_rewrite.. для каждого запроса... ;))
p.s. Можно было и осилить для начала..
p.p.s Можно и в .htaccess использовать сравнение строк, но в подавляющем большинстве примеров (и, как следствие - рабочих сайтов) используются регулярки..
CMS - зло.. Нативный HTML рулит.. И фреймворки тоже код ненужный предлагают...
p.s. Истина где-то рядом (возможно, где-то "между").. но всё хорошо в меру.. Можно и "ручками" нагромоздить.. А может и автоматически сгенерированный код быть вполне сносным..
