В этом и проблема.
1. WordPress читает правила сверху вниз, по порядку. И сравнивает.
2. При регистрации пост-тайпа ваши новые правила будут сверху. С них он и начнет.
3. При нахождении первого же совпадения, дальнейшие проверки прерываются, и WP продолжает работу, используя совпавшее правило.
4. Правило без /mark/ будет идентично правилу обычных страниц (page)
5. Соответственно, при попытке зайти на страницу, получите 404 - потому что WP будет смотреть ваш custom post type с таким слагом, а не страницу, такой записи в mark он не найдет, поэтому выдаст 404.
6. Если вы поставите ваши правила в низ массива rewrite_rules - произойдет обратное. При запросе страниц все будет ок (потому что первое правило в списке будет по страницам, его WP и подхватит), а при запросе вашего CPT будет 404 - потому что WP возьмет его слаг и спросит страницу с таким слагом. Ее, естественно, не будет - отсюда 404.
Это если говорить о механизме из коробки.
Впрочем, WP - это всего лишь кучка PHP-кода, поэтому в теории можно сделать все, что угодно. Можно хукаться в дальнейшие фазы обработки запроса и там делать дополнительные проверки. Посмотрите тут для начала: https://kellenmace.com/remove-custom-post-type-slu...
Даниил Вершинин: Естественно. Потому что query_posts заменяет основной запрос (и попутно ломает все, что на нем завязано, начиная с пагинации - именно поэтому его не стоит использовать, особенно если вы не понимаете архитектуру ядра WP). А get_posts() - это не деструктивная функция, она вызывает новый WP_Query, отдельного от основного. Поэтому в вашем случае оно и не работает. Вам нужно модифицировать основной запрос, для этого есть хук pre_get_posts. Вот в нем и устанавливайте ваши параметры.
Только не Попов. Последствия его обучения вылазят боком многим клиентам, а нам потом приходится это говнецо разгребать. Потому что клиенты приходят со слезами на глазах и умоляют исправить то, что наделали эти последователи Попова. Дилетанты.
iBird Rose: Да, ответ получился слишком общий, потому что сразу на два комментария. По поводу качества это адресовано больше devalone.
Что касается стоимости - совсем не факт. Рейты на рынке разные, как в экосистеме WP, так и в экосистемах фреймворков. На тех же Ларе, Симфони или Yii есть рейты и по $20, и по $200. То же касается WP. Если отталкиваться от объема работы, то на фреймворке он будет все же больше, имхо. Да, и под WP есть куча плагинов (в том числе адекватных, которые можно и нужно использовать), и под фреймворки есть куча готовых либ, которые существенно уменьшат объем работы. Плюс, с WP вполне можно использовать composer packages, что еще больше упрощает жизнь, если научиться этим правильно пользоваться (в связке с WP).
В общем, я не совсем понимаю откуда у вас такое утверждение, на чем оно базируется.
iBird Rose: devalone: Не несите ерунду. Если за дело возьмется нормальный WordPress-разработчик (именно разработчик, хорошо знающий WP) а не имплементатор (который "разрабатывает" сайты на WP устанавливая кучу говноплагинов), то все будет в полном порядке.
Влад: Они вставляют параграфы там, где надо, за исключением буквально нескольких моментов - изоражений, таблиц и тд. Проще фильтровать именно этим путем - на выводе контента убирать P там, где он не нужен.
Ох плюсую :) У самого на поддержке крупный сайт с WPML (10+ языков) + масса ACF. Работает, и даже быстро. Но мысль перевести в будущем на Multisite меня не покидает ни на секунду. Упростит жизнь прям на порядки.
Юрий Янин: +1 к ответу ThunderCat . Вообще всегда перед тем, как писать цикл, убедитесь что для решения задачи нету специально заточенной функции. Потому что в большинстве случаев она есть.
