morgana_lf: у нормальных хостеров должно работать без проблем. Я не большой специалист по shared, но Agava вроде нормальные. WordPress в плане требований к PHP весьма и весьма прост, в нем нет ничего такого, что может быть заблокировано у хостера на уровне настроек. И уж тем более нет ничего такого в этих функциях. Они просто определяют базовый путь к теме, ничего сверхестественно, вполне себе примитивный функционал. Поэтому проблема где-то еще.
Попробуйте в шаблоне поставить:
<?php
var_dump( get_template_directory_uri() );
?>
и посмотреть что выведет.
Да, и в вашем фрагменте нету точки с запятой в конце вызова функции и стоит лишний пробел перед /img.jpg. Должно быть:
morgana_lf: Если ничего не помогло, то у вас совсем что-то не в порядке. Или с кодом, или с сервером. Тему сами пилите? Если да, то надо искать однозначно корень проблемы. Если тема чужая - тоже надо искать, хотя будет чуть сложнее. Или вообще сменить к чертям. Если же проблема на стороне сервера - менять хостинг 100%.
Суть в том, что get_template_directory_uri() / get_stylesheet_directory_uri() должны работать железно.
Антон: во, это уже более полезная информация. Установите еще Query Monitor. ЗАйдите на этот адрес, и в панельке админской у вас будет выпадающее меню Query Monitor. Он покажет какое rewrite rule сработал, какие параметры запроса отпарсились, какой объект был запрошен, какие запросы в базу и тд. Сделайте скриншоты, будем смотреть. Если я правильно понимаю, у вас сами правила ЧПУ есть и работают, но когда WordPress парсит URL в понятные ему переменные, формирует запрос(ы) в БД, то в ответ получает пустой результат. Вот в этом надо убедиться. И дальше копать в сторону запроса, почему он пустой.
Устновите плагин для тестирования правил перезаписи урл (Rewrite rule testing) и посмотрите, что срабатывает при введении этого урл. Будет понятно точно, где проблема - нет таких правил вообще (см. коммент выше) или они все-таки есть, но запрос почему-то возвращает "не найдено" (скорее всего конфликт плагинов)
На системном уровне проблема в отсутствии маски EP_PERMALINK, не генерируются нужные permastructures. По умолчанию у WooCommerce они есть. В вашем случае, возможно, какой-то плагин перезаписывает.
KOBZAR_09: видео-уроков не видел. Уверен, на ютубе что-то должно валяться (правда, на английском - на русском вероятность найти стремится к нулю). Если вам надо совсем просто, поищите еще плагины в стиле Wiki, FAQ - их много бесплатных в родном репозитории wordpress.org/plugins
Pshkll: Pods не менее мощный чем ACF, по некоторым фичам даже мощнее. Хотя с точки зрения UI и удобства интерфейса для простого пользователя - похуже, попроще. Для разработчиков же лучше - там внутри много полезного на уровне кода. Ну и, самое главное, он бесплатный. Что из них использовать - дело ваше. У меня ACF Pro, хотя все чаще делаю ручками, через свой код.
Pshkll: для этого нужен ACF Pro (платная версия), в котором есть Option pages. Поля добавленные на эту страницу будут храниться в wp_options и доступны через get_option() или get_field( 'field_name', 'options' ). У Pods эта фича бесплатная. У CMB2 кажется тоже.
WP Panda: Ну, я исхожу из той позиции, что если автор вообще задает подобный вопрос, то текущего функционала Customizer API + Kirki ему должно хватить с головой. К тому же, future proof.
По поводу settings api / frameworks - в этом и смысл. Можно сделать чисто под себя на базе АПИ, а можно взять готовый инструмент. Имхо, какой использовать - дело субъективное. И, хоть я согласен по поводу Redux, остальные пользуются огромной популярностью. Тот же Titan, например, для начинающих оказывается удобнее в освоении.
По ACF, Pods etc - если говорить с позиции разработчика, то соглашусь, конечно же. Но, тем не менее, эти плагины, являясь мощными комбайнами, решают вопрос настроек - с помощью своих Options pages и произвольных полей, значения которых, например, тот же ACF хранит в wp_options. Учитывая разнообразие полей + удобный интерфейс + отсутствие необходимости быть разработчиком или нанимать такового (noob friendliness) данный вариант вычеркивать нельзя.
stas3k: Это называется "кастомный функционал". Он был, есть и будет в любом проекте, это нормально. У того же WooCommerce прекрасная система хуков и фильтров, которая позволяет включиться в нужном месте и выполнить нужное действие (взять комиссию, например).
Inwork277: если делать с бесплатной версией ACF то да, можно и так. Хотя, ИМХО, это костыль. Например, если используется меню с автоматическими ссылками на страницы - придется добавлять эту страницу в игнор. Значение данного поля не кешируется "из коробки", то есть, +1 запрос в БД, еще парочка частных случаев (не факт, что они всплывут, но потенциально узкие места таки есть). Как по мне, то проще сделать через Settings API (см. мой ответ). С помощью генератора делается за 2 минуты, работает заметно лучше - с флагом autoload = yes грузится на раннем этапе и складывается в кеш, откуда с ним намного удобнее работать. Ну и своя страничка настроек как-то логичнее для такой задачи.
