Як змінити підключену функцію в темі?

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

Що робити, якщо замість цього ви займаєтесь розробкою тем?

Моїм функціям.php потрібен інший файл, який перекриває get_user_by()функцію, визначену в pluggable.php.

Якщо я пропущу if( function_exists() )виклик, я отримую помилку "Неможливо змінити ...".

Якщо я включаю if( function exists() )виклик, то я не отримую помилок, але, звичайно, моя функція потім ігнорується, оскільки версія плагіна існує.

Виходячи з дивовижної публікації Домініка в порядку запуску WordPress , зрозуміло, що pluggable.phpзавантажується перед вашою темою functions.phpтощо, так що це пояснює помилку.

Отже, питання полягає в тому, як ви можете скористатися цією приємною архітектурою підключення всередині теми, не вдаючись до написання плагінів, які потім потрібно поєднати або встановити разом з темою?

Подальші зауваження : Отже, здається, що аргумент полягає в тому, що теми не повинні намагатися робити те, що роблять плагіни. Але цьому аргументу більше чотирьох років (згідно 4-значний номер trac). Мені б хотілося почути від важких нападників, чи ця філософія все ще застосовується, враховуючи складну топологію сьогоднішнього ландшафту розвитку теми. Я хотів би повірити, що ми розвинулися відтоді.

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

Це не здається мені випадком використання для плагінів. Тема встановлена, можливо, дочірня тема «Двадцять одинадцять», можливо, окрема, її функції. Тоді у файлах шаблонів тем використовується спеціальні «теги шаблонів», які визначені у входить. Я не хочу мати тематичні файли, що залежать від того, який плагін або інший активується тощо. Це просто не має сенсу будувати складність в системі. Звичайно, я можу помістити його в папку з обов'язковим використанням плагінів, але це все ще відчуває себе злом - саме зараз все, що стосується налаштувань для цього проекту, міститься в wp-content/themes/my-theme/. Я також не хочу розглянути питання про пошук матеріалів у деяких папках плагінів.

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

Якщо ви будуєте це для одного клієнта, вам слід абсолютно скористатися mu-plugins.

У WordPress є багато речей, які ви не можете зробити functions.php. Функції, що підключаються, є однією з них, але більш очевидно, що ряд гачків (як дії, так і фільтри) стріляють раніше functions.php. У деяких випадках ці гачки навіть спрацьовують перед звичайними плагінами, а потім потрібно використовувати mu-pluginsабо мережевий плагін. В інших випадках навіть му-плагін занадто пізно. Можливо, вам щось потрібно 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#commentwhat )

У контексті одноразового проекту абсолютно доречно кинути код must-use у mu-plugins. Якщо "мати все це за один раз" викликає занепокоєння, просто зробіть символьне посилання в темі dir до mu-pluginsвипадаючого, щоб воно з’явилося під час пошуку в каталозі тем.

Я не можу придумати спосіб досягти цього, занадто рано в послідовності завантаження.

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