Как переопределить подключаемую функцию в теме?

Вся документация, с которой я столкнулся, обсуждает переопределение подключаемой функции через ваш плагин.

Что, если вы вместо этого занимаетесь разработкой темы?

Мой functions.php требует другого файла, который переопределяет get_user_by()функцию, определенную в pluggable.php.

Если я пропускаю if( function_exists() )вызов, я получаю сообщение об ошибке «Не удается переопределить ...».

Если я включаю if( function exists() )вызов, то я не получаю ошибки, но, конечно, моя функция тогда игнорируется, так как существует подключаемая версия.

Исходя из удивительного поста Доминика о порядке запуска WordPress , ясно, что pluggable.phpон загружается раньше вашей темы functions.phpи т. Д., Что объясняет ошибку.

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

Дополнительные примечания : Похоже, что аргумент состоит в том, что темы не должны пытаться делать то, что делают плагины. Но этому аргументу более четырех лет (согласно 4-значному номеру трека). Я хотел бы услышать от некоторых активных нападающих, применима ли эта философия до сих пор, учитывая сложную топологию современного ландшафта разработки тем. Я хотел бы верить, что мы развились с тех пор.

Контекст : я разрабатываю одноразовое CMS-решение для клиента, с множеством пользовательских метаданных, настройкой административной части, процессом входа в систему / аутентификации, работами. И, конечно, есть компонент дизайна - вот где вступает тематическая часть. Фактически, это просто не повторно используемые компоненты - они никогда не будут применяться к другому клиенту, они никогда не будут помещены под GPL и с открытым исходным кодом, и они наиболее конечно, не будет распространяться / устанавливаться в других развертываниях WordPress. В лучшем случае есть некоторые лучшие практики, которые я буду использовать в будущих проектах, но это будет исключительно работа со ссылкой / копированием.

Это не похоже на случай использования плагинов для меня. Тема установлена, может быть, дочерняя тема Twenty Eleven, может быть, автономная, ее функции.php вызывает множество включений, каждый из которых обрабатывает свой аспект рассматриваемой CMS. Затем файлы шаблона темы используют пользовательские «теги шаблона», которые определены во включениях. Я не хочу, чтобы файлы темы с зависимостями от того или иного плагина были активированы и т. Д. Просто не имеет смысла встраивать сложности в систему. Конечно, я могу поместить его в папку обязательных плагинов, но это все равно что взломать - сейчас все, что связано с настройками, сделанными для этого проекта, содержится в wp-content/themes/my-theme/. Я также не хочу рассматривать поиск вещей в некоторых папках плагинов.

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

Если вы строите это для одного клиента, вы должны абсолютно воспользоваться mu-plugins.

В WordPress есть много вещей, которые вы не можете сделать functions.php. Сменные функции - одна из них, но, более очевидно, ряд хуков (и действий, и фильтров) срабатывает раньше functions.php. В некоторых случаях эти ловушки запускаются даже перед обычными плагинами, которые затем требуют использования mu-pluginsили плагина, активируемого сетью. В других случаях, даже плагин mu слишком поздно. Возможно, вам нужно что-то в sunrise.php. Или даже что-то (постоянное или иное) в wp-config.php.

Я бы предпочел добавить некоторые хуки к подключаемым функциям, чем чтобы их было проще переопределить. У нас вряд ли когда-нибудь снова появится другая подключаемая функция - они предшествуют хукам, и я почти никогда не видел ситуации, где у них было бы преимущество перед старым добрым хуком (старомодным?).

Я все еще согласен, шесть лет спустя, с Энди Скелтоном - «Есть много различий между файлом функций темы и плагином. Давайте сохраним это так».

Это все в стороне, такого изменения никогда не может произойти. Это сломало бы много вещей. Бесчисленные темы вызывают функции в теле, functions.phpчто может привести к фатальной ошибке, если она pluggable.phpеще не загружена - как current_user_can(), или wp_create_nonce(). Они все потерпят неудачу. И это также сломало бы плагины, которые обычно могли бы вызывать эти функции plugins_loaded. (Просто двигайтесь pluggable.phpниже, wp-settings.phpи я держу пари, что половина ядра сломается - или, по крайней мере, настройщик сломается.)

Наконец, существует неизбежная идея, что тема может включать отдельный файл, подобный тому, pluggable.phpкоторый мы могли бы загружать уже при загрузке плагинов, и, следовательно, могли бы переопределять подключаемые функции. Помимо того, что это плохая идея (см. Первые четыре абзаца этого комментария), она все равно не будет совместимой, поскольку вплоть до setup_themeзацепки можно переопределить, какая тема должна быть загружена, путем фильтрации значений таблицы стилей и шаблона.

К сожалению, это просто неверно, учитывая, как WordPress спроектирован. Хорошая вещь, есть бесчисленные (лучшие) способы сделать это.

(Первоначально опубликовано здесь: http://core.trac.wordpress.org/ticket/2479#comment:5 )

В контексте разового проекта абсолютно уместно добавить код, который необходимо использовать mu-plugins. Если проблема заключается в том, чтобы «иметь все в одном месте», просто сделайте символическую ссылку в mu-pluginsдиректории темы на раскрывающееся меню, чтобы оно появилось при поиске в каталоге темы.

Я не могу придумать способ сделать это слишком рано в последовательности загрузки.

Наиболее близким к разумному решению было бы добавление пользовательского включения в wp-config.php(по коду или запрос пользователя), но сравнение с этим подключаемым плагином, вероятно, имело бы больше смысла.