Так она работает о_О )))) 🤣
🍻
На самом деле, смысл не только в том, как откроется одна страница..
Мы избавляемся от обработки Rewrite-правил для остальных адресов (в том числе и для статики, пусть и кэшируемой, но цифры считаются при первой загрузке), которая влияет на циферки во всяких "измеряторах-анализаторах" типа PageSpeed..
С RewriteCond-ами?
p.s. Интересно, что там будет на 5.6
Откуда проценты? ))
Щас тут камнями закидают, ибо 5.6 уже не котируется
p.s. обновления до 5.2.* (с версий 5.*.. не четвёрка же там стояла?) включительно относительно безболезненные в 5.3 пошла ломка обратной совместимости..
регулярка по RFC (тут, например) говорит, что приведённый пример вполне себе валидный..
Может начать с того, что заказать сторонний аудит проекта.. Или просто.. "код посмотреть".. Ибо а) идеального кода не бывает.. 2) баги выявляются не на пустом месте.. истина где-то между..
Если абстрагироваться..
С созданием более-менее просто..
- есть ТЗ (без ТЗ результат - ХЗ) - некое более-менее формализованное описание того, "что нужно";
- есть предварительная оценка (объём/сроки/стоимость)
- есть итерации... (с любой детализацией - этап/неделя/задача.. и оценкой+-)
- есть "хотелки", которые в силу приоритетов заказчика формируют следующий этап.
- есть объём задач и сумма за этап
- есть некий горизонт (пара-тройка следующих этапов)
* есть инфраструктура, деплой, тесты (ибо запилил одну фичу, сломал три.. нужно баги фиксить.. и так - в прогрессии..)
С поддержкой.. интереснее..
- что нужно поддерживать (и зачем?.. и почему оно само не работает) *
- можно ли это автоматизировать/оптимизировать..
- если баги стоят 300к в месяц, то что ж это за баги? ))
* поддержка требует сил и средств.. это нормально.. У машины - ТО, у человека - диспансеризация, витаминки.. мониторинг, критические значения, падения.. всё это отнимает время и требует внимания..
зависит от "степени подобия"...
ибо проект, "подобный" VK (внешне и по ТЗ, соответствующему функциональности рядового пользователя) можно сделать фактически "на коленке" (за солидную сумму, конечно же).. Однако коснись вопросов бэкенда, масштабирования, функциональности для разных ролей и кучи других..
Вы так и не поняли..
1. убираем из .htaccess всё, что связано с Rewrite*
2. /?page=12 без rewrite обрабатывается по умолчанию (IndexDocument в Apache) в index.php ("оно" так работает.. на большинстве хостингов.. но можно настроить и по-другому)
3. WP (в соответствии с настройками движка, если заданы ЧПУ) редиректит на /page/12/ (или заданный в свойствах страницы/поста slug/alias/ЧПУ)
4. Apache не находит адрес и обращается к 404 странице, которую мы задаём через ErrorDocument
5. в 404 странице включается "свой" обработчик, устанавливает HTTP-код 200 и передаёт управление index.php, который по REQUEST_URI (/page/12/ в данном случае, category/blablabla/ /contacts и любых других) выводит нужную (в соответствии с логикой движка) страницу, либо возвращает 404 ошибку, но уже средствами CMS со всеми "плюшками".
Создайте тему - вам быстро предложений "сделаю на WP/Joomla/drupal" накидают.. ))
Больше подробностей))
На самом деле, вопрос исполнителю о детализации счёта вполне нормальный.. (более того, не удивлюсь, если и ответ будет вполне нормальный без противоречий здравому смыслу..)
Gerga, зачем мешать всё-в-одно?
1. запросы /?page=*** без mod_rewrite придут в index.php
2. можно сократить количество каждый раз обрабатываемых правил, изменив их порядок (естественно, без отказа от mod_rewrite)
3. можно оптимизировать правила, чтобы вместо регулярок использовалось сравнение. Это быстрее, но вряд ли даст реально ощутимый прирост скорости.
4. можно сделать полноценную обработку URL-ов без mod_rewrite, используя страницу ошибки 404, в которой уже обрабатывать навигацию.
5. правило Rewrite index.php - обрабатывается mod_rewrite
1. Ещё раз.. если убрать директивы RewriteEngine on - никакие rewrite-директивы обрабатываться не будут.
2. Если поставить строчку с index.php - выше директив, они также обрабатываться не будут.
Вообще речь о том, что "если очень захотеть", то вообще все директивы Rewrite*** можно полностью убрать из .htaccess.. (начиная с Engine on).
Но изначально для оптимизации скорости предлагалось директивы с двойными регулярками вида:
RewriteCond %{QUERY_STRING} ^/?page=1033$RewriteRule ^/?$ detskiy-nevrolog/? [R=301,L]
либо
а) оптимизировать с заменой регулярок на равенство:
RewriteCond %{QUERY_STRING} =page=1033
б) исключить.. а обработку перенести в PHP
Но, возвращаясь к исключению лишних правил...
первая строчка "от wordpress" именно это и делает
RewriteRule ^index\.php$ - [L]
p.s. В любом случае, это не та оптимизация, которой следует заниматься в первую очередь..
Или если шаблон "дырявый" (пусть и купленный), плагин или сам WP (не обновлённый за древностию лет) взломали..
