Начална » WordPress » Как да използвате WordPress Hooks за действие в персонализирането на темата

    Как да използвате WordPress Hooks за действие в персонализирането на темата

    WordPress детските теми дават сравнително лесен начин за персонализиране на външния вид и усещането за тема. Ако опциите на темата не ви дават адекватни дизайнерски решения, можете просто да добавите ново правило към файла със стилове по подразбиране на стила на детето, наречен style.css. Но какво се случва, когато искаш да променя функционалността на темата? Това е един от случаите, когато действията на WordPress Ви помагат.

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

    За куките на WordPress

    WordPress куките работят донякъде подобно на куките в реалния живот в смисъл, че можете да хванете рибата, която искате, на точното място, ако правилно ги използвате.

    Можеш премахване на затворена функция (напр. можете да премахнете административната лента на WordPress за потребители с ниско ниво), можете остави го непокътнато и подобри с вашата собствена функционалност (напр. можете да добавите още менюта или области на приспособления към тема), или можете отмени това (напр. можете да промените поведението на основната функция).

    Има два различни вида куки в WordPress: мерки и филтри. В този пост ще разгледаме как можем използвайте куки за действие в персонализирането на темата.

    Как работи WordPress

    Да използвам много прост език, мерки посочи това нещо се е случило по време на жизнения цикъл на WordPress: някои части от сайта са заредени, определени опции или настройки са настроени, приставки или приспособления са инициализирани и т.н..

    Филтри са различни от мерки по своя характер. Те са свикнали преминава през данните, и променяйте, управлявайте или откъсване преди да го направите на екрана или да запишете потребителски данни в базата данни.

    На всеки значителен ориентир на жизнения цикъл на WordPress има или един действие или a филтър кука, към която можем добавете нашия персонализиран код, за да промените поведението по подразбиране на нашите нужди.

    Определените действия и филтри, които се изпълняват по време на заявка, зависят от това коя страница е поискана от потребителския агент: например в заявка за единична публикация има налични куки, свързани с отделни публикации, но куки, свързани с други части на сайта (напр. Административната област) не са.

    Намерете куки за действие

    Справка за действие на WordPress Codex дава подробен преглед на действията, изпълнявани чрез различни заявки. Важното е, че ако искаме да изпълним една задача, която трябва да изпълним кука на правилното място, не преди или след него, в противен случай действието няма да бъде завършено.

    Така например, ако искаме добавете кода на Google Анализ към сайт ние трябва да закачете нашето действие точно преди да е зареден долен колонтитул.

    Ако говорим за персонализиране на темата, куките за действие могат да идват от две различни места: от WordPress Core и самата тема. Има теми, които изобщо нямат куки, но други предлагат на разработчиците някои или много - винаги е изборът на автора на темата. По подразбиране Twenty Fifteen Theme има само една кука за действие за персонализиране на долния колонтитул под името "twentyfifteen_credits".

    Ако искате да преглеждате изходния код, можете лесно да намерите и куки за действие. Към кода се добавят куки за действие с функцията WordPress.

    Ако изпълните бързо търсене на израза „do_action“ в по-усъвършенствания редактор на кодове - както направих в Eclipse по-долу - можете да видите списък с местата, където можете да свържете персонализираната си функция в ядрото. Търсих в / WP-включва / , но можете също така да извършите търсене за / WP-администратор / папка, която съдържа куки за действие, свързани с таблото за управление на WordPress (област на администриране).

    Хубавото е, че имената на екшън куките обикновено са доста очевидни, но има обикновено е добър коментар в кода това може да ви даде повече знания дали дадената кука за действие е добра за причината, поради която искате да я използвате.

    Например кодовият коментар преди куката за действие widgets_init казва, че той “пожари, след като всички стандартни WordPress джаджи са регистрирани”. Ако погледнете кода преди това действие, можете да намерите инициализацията на всички джаджи по подразбиране на WP преди това - така че можете да сте сигурни, че коментарът не е лъжа и ако искате да регистрирате своя собствена джаджа, това ще бъде правилното място.

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

    Добавете свои собствени действия

    Когато искате да добавите свое действие, трябва да го направите създайте потребителска функция и свържете тази функция с определена кука за действие с помощта на функцията add_action () WordPress. Обикновено са добавени персонализирани действия, добавени с функцията add_action () на място когато ядрото извиква съответната функция do_action ().

    Нека видим един прост пример.

    Как да намерим действие Hook ви трябва

    Да предположим, че искате да добавите персонализиран значок към сайта си. Първо, трябва да намерите правилната кука за действие, с която да свържете собствената си функционалност.

    Нека да помислим. Ако искате да добавите favicon към обикновена HTML страница, където бихте я поставили? Разбира се, трябва да го поставите вътре раздел на HTML файла със следната маркировка:

      

    Така че трябва да бъде куката за действие свързани с натоварването на. \ t раздел.

    (1) Отворете справочника за действие и вижте какво може да предложи. Имаме късмет, като че ли разглеждаме действията, можем да намерим само един, wp_head, който въз основа на името му има възможност да бъде свързан с зареждането на раздел.

    (2) Разбира се, нека Проверете документацията в WordPress Codex. Кодексът препоръчва това “използвате тази кука, като изведете функцията echo към браузъра”, така че сега изглежда, че е перфектно за нас. Но нека проверим в изходния код.

    (3) Тъй като тази кука не е свързана с административната област, ще трябва да стартираме търсенето си в / WP-включва / папка. Ако търсим думата "wp-head", ще получим много резултати, тъй като това специфично действие се използва от WP Core многократно.

    Трябва да потърсим мястото, където ще се дефинира, за да търсим израза do_action ('wp_head'). Обърнете внимание, че не сме завършили скобите, тъй като все още не можем да сме сигурни дали това действие има параметри или не.

    Eclipse връща само един резултат, който може да бъде намерен вътре в /wp-includes/general-template.php файл. Коментарът преди определението на куката за действие казва, че това “отпечатва скриптове или данни в главата на предния край”, така че сега можем да сме мъртви сигурни wp_head е куката за действия, от която се нуждаем.

    Проверка за параметри

    Когато добавяте свои собствени действия, трябва да сте сигурни дали куката, която искате да използвате, приема параметри или не. Можете лесно да откриете това, като прегледате функцията do_action ().

    Синтаксисът на функцията do_action () е следният:

     do_action ('name_of_action' [, $ parameter1, $ parameter2,…]) 

    Изисква се само името на действието, параметрите не са задължителни. Ако намерите аргументи в съответното извикване на функцията do_action (), трябва да включете ги в декларацията на персонализираната функция, която създавате.

    Ако не намерите такива, тогава персонализираната ви функция трябва да работи без аргументи. В определението на do_action () на куката за действие wp_head няма параметри.

    Нека го сравним с кука за действие, която взема параметър. Куката за действие, наречена "wp_register_sidebar_widget", приема един параметър, който винаги трябва да преминете към персонализираната функция, която свързвате с куката.

    Да видим разликата в синтаксиса на do_action () на двата случая:

     do_action ('wp_head'); do_action ('wp_register_sidebar_widget', $ widget);

    В първия случай няма параметър, така че потребителската функция ще използва следния синтаксис:

     функция my_function_without_parameters () … 

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

     функция my_function_with_parameters ($ widget) … 

    Как да закачите Вашата персонализирана функция In

    Сега знаем всичко, от което се нуждаем. Нека създадем нашата персонализирана функция, която ще показва favicon на нашия сайт.

    Първо, създайте нова функция без аргументи, след което я свържете с куката за действие wp_head с помощта на функцията add_action () WordPress.

     функция custom_add_favicon () echo '";  add_action ('wp_head', 'custom_add_favicon');

    Ти трябва да прехвърли името на куката за действие към функцията add_action () първо като аргумент, тогава трябва добавете името на вашата персонализирана функция.

    Това са двата задължителни параметъра на add_action (). Той има и два опционални параметъра, приоритет и приети аргументи. Нека видим как да ги използваме.

    Определяне на приоритети

    В много случаи се случва повече от едно действие да е свързано с една и съща кука. Така кой ще бъде изпълнен първи? Тук можем да използваме $ опционален параметър на функцията add_action ().

    Добавяме приоритета като положително цяло число, стойността по подразбиране е 10. Ако искаме дадено действие да бъде изпълнено по-рано, ние му даваме по-ниска стойност, ако искаме тя да бъде изпълнена по-късно, ще му дадем по-висока стойност.

    Така че, ако смятаме, че favicon трябва да е там рано, можем да подобрим предишния си призив add_action () по следния начин:

     add_action ('wp_head', 'custom_add_favicon', 5); 

    Моля, обърнете внимание, че приоритетите винаги трябва да бъдат задайте относително спрямо другите потребителски функции които използват една и съща кука за действие.

    Добавяне на броя на приетите аргументи

    От вас се изисква да добавите броя на приетите аргументи в случай, че използвате кука за действие, която взема параметрите. Нека видим примера, който използвахме преди.

    Куката за действие "wp_register_sidebar_widget" заема един параметър, така че когато свържем нашата персонализирана функция с тази кука, трябва да включим и това като аргумент, когато извикваме функцията add_action ().

    Нашият код в този случай ще изглежда така:

     функция my_sidebar_widget_function ($ widget) // Вашият код add_action ('wp_register_sidebar_widget', 'my_sidebar_widget_function', 10, 1); 

    Имайте предвид, че трябва също добавяте приоритета (тук сме избрали по подразбиране 10), за да сме сигурни, че WordPress знае какво означава всеки параметър. Ако пропуснем приоритета, WordPress може да предположи, че 1 е приоритет което не е вярно, тъй като показва броя на приетите аргументи.

    заключение

    Можете да направите много експерименти с куки за действие в настройката на темата. Например можете да добавите персонализираните си скриптове (JS) и стиловете (CSS) с куката за действие wp_enqueue_scripts или кода на Google Анализ с активната кука.

    Вие не само можете добавете свои собствени действия, но можете и вие премахнете пълните функционалности от WordPress ядрото с използването на функцията remove_action (), която използва същата логика като add_action ().

    Ако сте автор на тема и искате да направите разтеглива тема, може да е добра идея добавете свои собствени куки за действие по съответния шаблон с функцията do_action ().

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

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