Det finns ingen anledning att fråga varför någon skulle vilja skriva ett plugin för WordPress. Det är en av de främsta funktioner som gör WordPress så flexibelt och bra för ett stort antal projekt. I den första delen av vår serie Vi skapade basen för ett WordPress-plugin som kan identifieras av kärnan. Sedan i den andra delen Vi lärde oss hur vi ändrar kärnans standardfunktionalitet. Idag ska vi titta på pluginalternativ. Det här är en av de vanligaste uppgifterna som plugins behöver utföra.
Vanligtvis behöver du skapa en uppsättning parametrar (alternativ) och ge användaren möjlighet att tilldela lämpliga värden till dem. Värden lagras i databasen och kan hämtas på begäran. Plugin kommer normalt att utföra olika åtgärder baserat på dessa värden, till exempel producera olika utdata.
Vilka verktyg ger WordPress oss för att göra detta scenario möjligt? Det tillåter oss att registrera alternativ med systemet och hämta dem med tilldelat ID - Options API är ansvarig för det. WordPress tillhandahåller också ett inställnings API för att skapa en administratörsguiden för alternativdialoger. Bortsett från det tillåter vi oss att lägga till anpassade objekt i adminmenyn så att plugin kan ha sin egen inställningssida. Slutligen tar WordPress hand om pluginsäkerhet och ger en uppsättning funktioner och rengöringsmetoder för att hantera användarinmatningen på ett säkert sätt.
Låt oss ta en detaljerad titt på varje del.
De Alternativ API är ett standardiserat sätt att lagra anpassade data i databasen. Alla data sparas i wp_options-tabellen under ett visst anpassat namn och kan nås från någonstans i koden. API: s viktigaste funktioner är:
Get_option-funktionen extraherar enkelt från databasen alla uppgifter som lagras under ett visst namn och returnerar det. Funktionen update_option tar ett alternativnamn och dess värde och uppdaterar motsvarande post i databasen. Om det inte finns någon sådan post kommer den att skapas automatiskt. Båda funktionerna kan fungera med arrayer samt enskilda värden. Det betyder att du kan lagra matrisdata under ett enda namn i databasen och API: n kommer att hantera serialiserings- och mineraliseringsåtgärder för dig. Det är en rekommenderad övning för plugins: lagra alla pluginalternativ som en array under ett enda namn.
Du kan skapa en inställningssida eller en grupp sidor för ditt plugin i administratörsmenyn. Om du skapar en grupp sidor bör du först lägga till en högsta sida:
Parametervärdena är självförklarande men du kan referera till källa för detaljer. Nu måste du lägga till interna sidor en efter en på följande sätt:
Som parameter parent_slug måste du använda ID på toppnivånssidan - vid en anpassad toppnivå sida är det det värde du angav som $ menu_slug vid registrering. Om du inte behöver flera sidor kan du skapa en enda inställningssida under en av befintliga sektioner på toppnivå - vanligen under "Inställningar" (alternativ-general.php ska användas som $ parent_slug). Alternativt finns det genvägsfunktioner för att lägga till delsidor under vissa administrativa menyalternativ, i fallet "Inställningar" är det add_options_page () .
De Inställningar API kan du skapa ett gränssnitt för att hantera pluginens inställningar; markera en sida som en inställningssida (för att automatiskt bearbeta inmatning) och utmatningssektioner på den sidan och fält i varje avsnitt för att acceptera användarinmatning. För att uppnå detta är ditt första mål att registrera inställningar med systemet och skapa sektionsfältstruktur för dem:
Referera till Kodex för en detaljerad beskrivning av parametrarna, men logiken är ganska enkel. Först och främst registrerar vi vårt alternativnamn (om det finns många alternativ kan de ordnas i grupper); då registrerar vi avsnitt (er) med ett internt ID och en uppsättning fält för varje sektion; API ger oss möjlighet att ange anpassade återuppringningar för inmatningsvalidering och för att visa varje fält och avsnitt.
Efter registrering av våra alternativ och motsvarande fält måste vi visa dem på inställningssidan - följande funktioner måste ringas inuti
/* register settings */function msp_helloworld_settings_init(){register_setting('msp_helloworld_options','msp_helloworld_options','msp_helloworld_options_validate');add_settings_section('msp_helloworld_authorbox','Author's box','msp_helloworld_authorbox_desc','msp_helloworld');add_settings_field('msp_helloworld_authorbox_template','Template','msp_helloworld_authorbox_field','msp_helloworld','msp_helloworld_authorbox');}add_action('admin_init', 'msp_helloworld_settings_init');/* validate input */function msp_helloworld_options_validate($input){global $allowedposttags, $allowedrichhtml;if(isset($input['authorbox_template']))$input['authorbox_template'] = wp_kses_post($input['authorbox_template']);return $input;}/* description text */function msp_helloworld_authorbox_desc(){echo "Enter the template markup for author box using placeholders: [gauthor_name], [gauthor_url], [gauthor_desc] for name, URL and description of author correspondingly.
";}/* filed output */function msp_helloworld_authorbox_field() {$options = get_option('msp_helloworld_options');$authorbox = (isset($options['authorbox_template'])) ? $options['authorbox_template'] : '';$authorbox = esc_textarea($authorbox); //sanitise output?>
Jag bör påpeka att alla pluginalternativ ska lagras som en array. Trots att vi bara har ett alternativ (authorbox_template), inkluderar vi det i en array och motsvarande fält i avsnittet för demonstrationsändamål. Registreringsfunktionen msp_helloworld_settings_init ska utföras på "admin_init" -kroken. Funktionen msp_helloworld_options_validate tar hand om användarinmatning genom att rengöra den med den infödda wp_kses_post filter som bygger på KSES-biblioteket. Funktionen msp_helloworld_authorbox_desc skapar en beskrivning för formulärets avsnitt och msp_helloworld_authorbox_field matar ut en textarea för att hantera inmatad markup. Observera att vi tilldelar CSS-klasserna "stortextkod" till den så att den inbyggda adminstyling tillämpas.
Allt detta skapar följande skärm i WordPress admin panel.
Vi gör det så att det får mallen från databasen och ersätter platshållardata ([gauthor_name], [gauthor_url], [gauthor_desc]) med motsvarande värden.
/* Create author's box markup */function msp_helloworld_author_block(){global $post;$author_terms = wp_get_object_terms($post->ID, 'gauthor');if(empty($author_terms))return;$name = stripslashes($author_terms[0]->name);$url = esc_url(get_term_link($author_terms[0]));$desc = wp_filter_post_kses($author_terms[0]->description);//get template from option$options = get_option('msp_helloworld_options');$out = (isset($options['authorbox_template'])) ? $options['authorbox_template'] : '';$out = str_replace(array('[gauthor_url]', '[gauthor_name]', '[gauthor_desc]'),array($url, $name, $desc),$out);return $out;}
Slutligen producerar vårt plugin (efter att ha tillämpat några stilar) en bra gästförfattares låda under inläggsinnehåll.
Att lagra och komma åt alternativdata är en mycket vanlig uppgift, som många plugins behöver utföra. Genom alternativmekanismen kan du ge dina användare möjligheten att ställa in plugin till deras behov (vilket de säkert kommer att uppskatta). Även utveckla för dig själv kan du behöva ett sätt att lagra detaljer för en viss installation. Att förlita sig på inbyggda WordPress API och funktioner när du löser sådana uppgifter är ett bra sätt att skapa en hållbar, säker och framtidsskyddad kod.
Vilken typ av plugins vill du se tillgänglig för WordPress? Har du byggt din egen med den här serien? Låt oss veta i kommentarerna nedan.