удалить нумерацию страниц из одной записи в блоге

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

Я также сделал вход только для пользователей с учетными записями, которые я должен создать сам. Видите, к чему я клоню?

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

Но я не хочу, чтобы моя тема показывала «Следующий» и «Назад» для всех сообщений в отдельных сообщениях блога.

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

Как кратко обсуждалось в комментариях, WordPress создан для продвижения и предоставления нескольких интерфейсов для своего контента, чтобы была возможность находить и получать доступ к записям различными способами. Это включает (но не обязательно ограничивается) такие вещи, как:

• “Мета-теги”, встроенные в разметку каждой страницы, которые помогают другим сайтам, службам и сканерам интерпретировать и перемещаться по сайту.
• REST API, который облегчает прямой программный доступ к данным.
• Основная функциональность WordPress по превращению пар ключ/значение в URL (в частности, “querystring”/”search string”) прямо в запрос к записям.
• Реальный внешний вид и интерфейс сайта, представленного конечным пользователям (все навигационные ссылки, кнопки и так далее).

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

Роли и возможности

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

К счастью, API WordPress Роли и возможности предоставляет механизм для решения этой проблемы. Группируя пользователей в Роли и указывая WordPress, что эти Роли могут получить доступ и как они могут взаимодействовать с этими вещами (Возможности, назначенные Роли, по сравнению с Возможностями, назначенными в качестве требований к контенту и взаимодействиям), WordPress будет применять эти ограничения ко всем своим интерфейсам. Если у Роли пользователя нет возможности видеть некоторые записи, эти записи будут скрыты от пользователя во всех интерфейсах – никакое навигационное средство не выдаст их существование пользователю, и попытка пользователя получить доступ к ограниченному контенту напрямую будет отклонена.

Непосредственные препятствия к использованию этого подхода для удовлетворения ваших нужд заключаются в том, что WordPress не поставляется с надежным пользовательским интерфейсом для управления Ролями и Возможностями, и “из коробки” механизм Ролей и Возможностей не имеет функциональности для ограничения Возможностей на уровне термина (т.е. отдельных категорий). Но, как и многое в WordPress, система Ролей и Возможностей сама по себе расширяема.

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

Готовые плагины

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

Кастомная разработка

Создание такой функции самостоятельно, вероятно, будет несколько запутанным из-за кривой обучения, связанной с системой Ролей и Возможностей, но в целом я думаю, что это может быть довольно прямо достигнуто добавлением списка Ролей в мета-данные терминов, а затем сравнением этих ролей с пользователем в фильтре map_meta_cap, создастся либо текущая мета-возможность read_post текущей записи, либо возможность do_not_allow для обеспечения того, могут ли они читать запись. Я думаю, что это было бы несколько хакерским, но, возможно, можно сделать намного более устойчивым, введя новые примитивные и мета-возможности для терминов.