80689248440: позвольте, для начала спросить, а зачем это надо? Чисто из принципа? Эти несуществующие урлы нигде не светятся, в индекс не попадают. Устранять это нет острой необходимости.
Если зайти просто на страницу, например about, то WordPress будет искать 2 переменные:
Matched Query:
pagename=about
&page=
Поэтому цифры после названия страницы распознаются и принимаются - такая регулярка стоит в rewrite_rule. Потому что контент страницы можно разбить на несколько подстраниц. Ну а другие символы регулярку не проходят, поэтому получается 404. Контент не меняется, потому что страница все же одна. Если надо отрезать цирфы - по упомянутому мною выше способу проверяете ответ из БД, если там аргумент paged будет false - делайте редирект на уровень выше, избавляясь от цифр.
С категориями и другими таксономиями чуть сложней, но принцип тот же.
Установите себе плагин Query Monitor, поможет понять что происходит внутри. А также Rewrite Rule Inspector, в нем можно прямо повводить разные урлы и посмотреть, какое правило подхватывается, какие дальше по списку стоят (WP использует первое из списка которое удовлетворило запрос). Это все поможет отловить конкретные ситуации/условия, в которых нужно добавить 404, а как это сделать - см. через один ответ выше.
squirtazzer: поищите в папке с темой файл home.php или font-page.php. Если их нет - надо смотреть index.php, там скорее всего стоит динамическая выборка на уровне их фреймворка. Методом тыка можно определить безопасное место и в него вставить:
Oleg: при чем тут кеширование кода, я про opcache не говорил нигде. PHP кеширует результат конкретного запроса для последующей работы с ним в рамках текущего цикла выполнения (runtime). Дальше по строкам этого запроса он гуляет без обращения к БД, что вполне нормально, и если через пару строк кода нужен именно тот же запрос - будет использоваться он из runtime кеша (по сути - из переменной в памяти). Если запрос, как у автора, идентичен и повторяется раз за разом - да, это именно тот use case, но автор вопроса уже давно себя поправил и добавил изменяющийся лимит, чтобы запросы были уникальными.
80689248440: правильно, потому что там контент не найден, но подключен то по иерархии шаблон page.php, и берется контент с самого первого найденного фрагмента (остальные - это параметры, а параметры лишь модифицируют контент текущей страницы). Почитайте что ли про rewrite rules в WP. Про ЧПУ в целом, что это такое и как им пользоваться. Вам или какой-то странный роутинг урлов нужен, либо вы концепцию в целом не понимаете. Я потому и попросил вас выше написать кейс, для которого это нужно, так мне легче будет подсказать.
Максим Степанов: уже ближе, но уточню еще. Есть пост типа custom post type, например, product. К нему нужны отзывы покупателей (это могут быть отдельно отзывы или реализованы через обычные комменты), отзывы не являются уникальными (один пользователь может оставить несколько отзывов к одному и тому же продукту). Сам отзыв должен содержать определенныцй набор полей, среди которых - несколько оценочных (рейтингов). Правильно? Суммирование и вывод оценок - это уже отдельная кухня, там ничего необычного.
В папке темы должен быть файл 404.php. Если в .htaccess прописать:
ErrorDocument 404 /index.php?error=404
то сервер будет сам отправлять куда надо. Это раз. Два - можно использовать условие is_404() и редиректить куда угодно (хоть на статическую страницу ошибки), включать заголовки, грузить нужные темплейты. Подробнее тут:
Смысл в том, что на ранний action (который подходит для конкретной ситуации) хукается функция, которая отлавливает ошибку и дальше - делает что надо. Этим путем можно отслеживать все что угодно, и делать тоже все, что захочется. Важно понимать иерархию темплейтов а также WordPress Page Lifecycle. Например, в ссылке вверху, к моменту экшна template_redirect WP уже отпарсил урл, сгонял запрос в БД и содержит объект со всеми данными. Его можно в этом месте разобрать, посмотреть что там есть, чего нет, и соответственно, выдать нужные заголовки и подключить нужный шаблон.
Максим Степанов: платный плагин - тоже выход. Посчитайте, сколько времени он сэкономит и умножьте на свой рейт. Выйдет, что на общение на Тостере вы потратили больше, чем этот плагин стоит :)
По сути - я правильно понимаю, что должны быть отдельно комментарии, отдельно отзывы? Рейтинг отзывов - это рейтинг в отзыве (рейтинг выставляем посту), или рейтинг самого отзыва (то есть, можно оценивать отзыв)? Суммирование - самое простое здесь.
Да, иногда еще слайдер может быть виджетом. То есть, у вас в шаблоне в шапке на главной должен быть widget area (он же сайдбар), в который вы и включите нужный виджет.
squirtazzer: как правило плагины позволяют создать и настроить слайдер в админке, а потом либо автоматом его паяют, либо предоставляют шорткод (shortcode) и/или template tag. Шорткоды ставятся в контент страниц/постов, или выводятся в шаблон с помощью функции do_shortcode(). Template tags прописываются непосредственно в шаблон в нужном месте.
Максим Степанов: ну это уже совершенно другая задача :) одним-двумя плагинами, боюсь, не обойтись - задача специфическая. Но все решаемо, правда придется лезть в код, и неоднократно. Если с кодом проблем нет - подскажу. Если с PHP не дружите - лучше наймите кого-то. Задача не сложная для разработчика, но писать вам кучу кода с инструкциями куда что вставить и помогать вам удаленно дебажить - это ад. Если выберете вариант с разработчиком - можете в контакты стукнуть (в профиле).
В принципе, все не обнаруженные объекты можно форсить на 404, если так уж сильно надо. Во всех шаблонах идет WordPress Loop, в нем есть блок "else". Обычно именно в нем подключается шаблон или текст "ничего не найдено", который и прилетает вместе с 200м кодом. Ничто не мешает еще на уровне получения результатов запроса к БД посмотреть, если ответ не содержит результатов - отправить соответствующий заголовок, прекратить выполнение, или же продолжить выполнение, но вместо стандартного шаблона включить 404й.
Кеширование результатов запроса идет на уровне MySQL, PHP/Nodejs тут при чем? Если кеш настроен у MySQL нормально, то любой клиент от этого бонус получит. Хоть Perl, Python, C# и тд. Сам в себе PHP ничего не кеширует, если дополнительно не подключен APC/APCu, XCache, Memcahced, Redis или другой кеширующий бекенд.
WP Panda: Не совсем так. Loco - это интерфейс для редактирования PO и компиляции в MO. Он абсолютно никак не подымается при заходах юзеров. на фронтенд, грузятся обычным методом MO-файлы. Поставьте Query Monitor и посмотрите запросы. На фронте ни одного обращения связанного с Loco Translate нет и быть не может. И делает он совсем не то, что код выше. Ваш код - подстановка на лету, а это как раз использование лишних ресурсов. Перевод, сделанный вашим методом нигде не хранится. Если делать через Loco Translate - все изменения раз и навсегда вписываются в PO/MO файлы, как и положено. А MO, кстати, можно еще и в кеширующий бекенд сложить, что будет однозначно лучше и быстрее.
Андрей: я уже попытался подсказать выше, вы видимо не заметили :) Пишете пост. Вариант 1 - дату оборачиваете в шорткод, например [humandate date="ваша_дава" time="ваше_время_опционально"]. Шорткоды WP парсит, вам нужно всего лишь написать функцию, которая будет забирать аргументы шорткода и выводить в нужном виде, и этой функции сделать register_shortcode. Второй вариант - весь контент поста пропускать через парсер. WP предоставляет готовый фильтр:
$content = $db_object->post_content;
$content = apply_filters( 'the_content', $content );
В этот фильтр можно захукать свою функцию, которая пробежит по тексту, найдет нужный контент и заменит его. Для этого есть разные методы - регулярные выражения, preg_replace, preg_replace_callback и другие функции. Это уже вопрос на уровне PHP, и в другой раздел. Со стороны WP для этого все готово.
