ВОПРОС И ОТВЕТ
Иногда возникают такие вопросы, которые вас раздражают и снова выслеживают в дальнейшей жизни, и это один из таких вопросов.
Этот вопрос заставил меня задуматься об альтернативном решении проблемы. Как я уже говорил, настраиваемые поля и мета-блоки предназначены для хранения небольших фрагментов метаданных, а не в качестве расширения для публикации контента, где вы можете выполнять шорткод и функции. Кроме того, как я уже говорил, ваш метод неверен и не должен использоваться
Что мне показалось интересным в вашем посте, так это то, что вы использовали пользовательские поля и мета-блоки, чтобы непреднамеренно отображать пользовательский контент из пользовательского ввода. Поэтому я сидел и думал о возможном способе заставить эту работу работать и правильно использовать данные настраиваемых полей и данные метабокса.
Это моя идея:
СЦЕНАРИЙ:
ПРИМЕЧАНИЕ: это можно изменить, чтобы удовлетворить любые потребности
В одном посте пользователь хочет / требует динамически показывать пользовательский контент после поста в соответствии со своими потребностями. Это должно быть динамичным. Содержание должно быть пользовательским запросом, и пользователь должен выбрать, что показывать, когда он хочет, и что он хочет.
ВОЗМОЖНОЕ РЕШЕНИЕ:
Шорткоды здесь не будут работать, так как шорткоды не могут быть выполнены в пользовательских полях. Ни один из них не будет do_shortcode
работать, так как он не динамический и жестко запрограммированный, чего мы не хотим. Как и в вашем вопросе, мы собираемся использовать пользовательские поля. Еще раз подчеркиваю, не используйте настраиваемое поле для выполнения пользовательского запроса или шорткоды
ПЛАН:
Мы будем использовать настраиваемое поле для сохранения только аргументов нашего запроса, вот и все. Итак, мы создаем настраиваемое поле с именем custom_query_arguments
. На экране вашего редактора постов вы увидите свое настраиваемое поле, готовое к использованию.
Следующим шагом будет добавление пользовательских аргументов запроса в наше поле. Допустим, нам нужно показать 3 сообщения из категории 1, отсортированные по названию. Таким образом, наши аргументы запроса должны выглядеть следующим образом: ( в строковом формате )
'posts_per_page=3&cat=1&orderby=title'
Это то, что вы должны теперь ввести в свое настраиваемое поле. После ввода сохраните значение вашего настраиваемого поля
Далее будет создан пользовательский запрос в вашем single.php. Что здесь необходимо, нам нужно получить значение из нашего настраиваемого поля, которое фактически является аргументами нашего запроса, и передать его в новый экземпляр WP_Query
для получения сообщений. Нам также нужно проверить, действительно ли у нас есть значение, сохраненное в этом настраиваемом поле, если настраиваемое поле пустое, ничего не показывать
КОД:
Вы можете попробовать что-то подобное в single.php сразу после одного поста.
$args = get_post_meta( get_queried_object_id(), 'custom_query_arguments', true );
// check if the custom field has a value
if( ! empty( $args ) ) {
$q = new WP_Query( $args );
if( $q->have_posts() ) {
while( $q->have_posts() ) {
$q->the_post();
the_title();
}
wp_reset_postdata();
}
}
Если пользователь хочет удалить пользовательский запрос, он может просто удалить значение пользовательского поля и оставить его пустым. Если ему нужно показать тот же запрос, но из категории 10 и в общей сложности 5 сообщений, он может просто заменить исходное значение следующим
'posts_per_page=5&cat=10&orderby=title'
Несколько замечаний:
При вводе информации в эти пользовательские поля и мета-блоки важно использовать правильный синтаксис и формат. Синтаксические ошибки или неверная информация приведут к нежелательному выводу или даже к фатальным ошибкам. Важно, чтобы ваши клиенты знали о такой информации
ОРИГИНАЛЬНЫЙ ОТВЕТ
Я не понимаю, что вы пытаетесь достичь, но из того, что я могу вам сказать, это две разные вещи
ОПЦИЯ 1
apply_filters('the_content', $content);
используется для применения фильтров содержимого к необработанному нефильтрованному почтовому контенту, который обычно исходит от использования $post->post_content
. Эти фильтры включают в себя известный фильтр, wp_autop
который добавляет p тегов кthe_content()
apply_filters('the_content', $content);
обычно используется в сочетании с тем, get_posts
где кто-то работает непосредственно с WP_Post
объектами, не используя, setup_postdata( $post )
что делает теги шаблона the_content()
доступными для использования
ВАРИАНТ 2
do_shortcode
используется для добавления шорткода в любом месте файлов шаблонов вне текстового редактора в конце экрана редактора страниц, в основном фильтруя шорткоды через их хуки.
Правильное использование заключается в следующем
Пример: добавление шорткода галереи в файл шаблона
echo do_shortcode( '[gallery]' )
РЕДАКТИРОВАТЬ 1
Из ваших комментариев я бы тогда вообще не использовал шорткод.
Если вы не собираетесь добавлять шорткод через текстовый редактор и добавляете его напрямую (жесткий код) через do_shortcode
файл шаблона, я бы предпочел просто добавить функцию в шаблон
Пример:
Если у вас есть следующая функция шорткода
function footag_func( $atts ) {
return "foo = {$atts['foo']}";
}
add_shortcode( 'footag', 'footag_func' );
Вы можете просто вызвать функцию прямо в шаблоне, как
echo footag_func();
Это намного быстрее, так как шорткод не нужно анализировать
РЕДАКТИРОВАТЬ 2
Если честно, вы полностью делаете это неправильно из своего редактирования. Вот почему я не мог понять ваш первоначальный вопрос
Иногда мне нужно добавить метаданные поста для записей / страниц / пользовательских типов постов, чтобы они могли добавлять шорткоды (слайдер, контактную форму и т. Д.) Или просто текст. Это текстовое поле.
Чтобы шорткод работал, я использую опцию 1 .....
Пользовательские поля не являются текстовыми полями и, конечно же, не предназначены для использования в шорткодах, а также для ползунков или контактных форм. Пользовательские поля никогда не должны использоваться для замены текстового редактора в сообщениях и страницах.
Как я уже говорил ранее, apply_filters('the_content', $content);
предназначен для применения форматирования к необработанному содержимому публикации.
У вас есть два варианта здесь
Используйте do_shortcode
непосредственно в файлах шаблонов, что я бы не рекомендовал, так как использование функции происходит быстрее, поскольку шорткод не нужно анализировать
Используйте шорткод прямо в текстовом редакторе для конкретной страницы / поста
Я бы настоятельно рекомендовал вам по-новому взглянуть на свои структуры и на то, чего вы хотите достичь. Пользовательские поля не являются текстовыми редакторами и не могут выполнять шорткоды или ползунки.
Я бы рекомендовал изучить пользовательские виджеты или систему, которую вы можете использовать с пользовательскими полями.