Opprette kommende hendelser Plugin i WordPress Opprette Widget

I den siste delen av serien så vi på å registrere en egendefinert innleggstype for hendelser. Vi tilpasset dashbordet ved å legge til en tilpasset metaboks og noen tilpassede metafelter for å legge inn hendelsesdata. For å gjøre det enklere for brukeren å legge inn datoer, innlemmet vi jQuery UI datepicker kontrollen i dashbordet, så vel.

Mens WordPress bare viser tittelen og datakolonnen for den egendefinerte innleggstypen i administrasjonsskjermbildet, la vi til våre egne tilpassede kolonner for å vise begivenhets startdato, sluttdato og arrangementsted. Da fullførte vi det meste av vår kommende begivenhetsplugin.

I den siste delen av denne serien vil vi:

se på WordPress widgets API
registrer en widget for å vise en liste over kommende hendelser
spørre databasen for kommende hendelser ved hjelp av WP_Query-klassen
gjør en meta-forespørsel for å sammenligne datoer, så bare hendelsene i fremtiden kommer opp

La oss dykke inn da vi skal gå gjennom prosessen med å bygge en WordPress-widget fra grunnen opp.

WordPress Widgets API

Vi kan tenke på widgets som blokker av kode som er ment å legge til visse funksjoner på et nettsted. Dette kan være alt fra en kalender, sosiale delingsknapper, et klassifiseringssystem eller en vitnemål. En bruker kan enkelt legge til eller fjerne dem fra nettstedet ved å bare dra dem.

WordPress widgets kan gjøres ved å utvide WP_Widget klasse som WordPress gir. Denne klassen inneholder nødvendige metoder og egenskaper for å lage en widget arbeid. Dette inkluderer funksjoner for å initialisere en widget, vise brukergrensesnittet i administrasjonen, oppdatere deres forskjellige forekomster, lagre de nye innstillingene i databasen og vise dem på skrifttypen.

Vi vil utvide fire funksjoner fra grunnklassen for å definere funksjonaliteten til widgeten vår:

__construct ()
form ()
Oppdater()
widget ()

La oss få oversikt over hver av dem:

__construct ()

De __construct () Metoden initierer widgeten. Den setter opp widgetnavn, base id og annen informasjon som beskrivelse og widget klasse, etc..

form ()

Dette er funksjonen som gir innstillingsskjemaet i dashbordet. Skjemaet kan inneholde felt for ulike alternativer for å tilpasse utseendet og funksjonaliteten til widgeten på fronten. De form () Metoden aksepterer et argument for forekomsten av widgeten.

Oppdater()

Denne metoden sørger for at widgeten blir oppdatert når en ny innstilling brukes til en forekomst av widgeten. Den aksepterer to argumenter: en for den gamle forekomsten og en for ny forekomst av widgeten.

widget ()

Denne metoden gir ut widget-innholdet til forsiden av nettstedet. Her definerer vi hva som menes å bli sett av brukerne når de besøker nettstedet. Denne metoden godtar to argumenter:

$ widget_args: Dette er en matrise som inneholder nødvendig informasjon om widgeten
$ forekomst: Instansen av widgeten som skal vises

Vi vil se nærmere på disse metodene og deres argumenter på en stund. For nå, la oss registrere vår widget klasse.

Registrering av widgeten

I rotmappen til pluginet oppretter du en ny katalog som heter inc for inkluderer. I den katalogen, opprett en fil som heter widget-kommende-events.php. Vi vil skrive all vår widgetskode i denne filen for å holde ting rent og håndterbart.

Vi vil begynne med å utvide den overordnede widget-klassen slik:

For å registrere widgeten, vil vi bruke register_widget () fungere sammen med widgets_init krok:

funksjon uep_register_widget () register_widget ('Upcoming_Events');  add_action ('widgets_init', 'uep_register_widget');

De register_widget () funksjonen aksepterer navnet på den utvidede klassen som argumentet.

Inne i Kommende arrangementer klasse, vil vi definere våre fire metoder på de vi hadde en titt i forrige avsnitt:

I neste trinn vil vi skrive kode for hver av dem og vil se nærmere på hvordan de fungerer. Men før det legger du til følgende linje kode på slutten av kommende-events.php hoved plugin-fil for å inkludere widgeten:

inkludere ('inc / widget-upcoming-events.php');

De `__construct ()` Metode

Hvis du har en bakgrunn i OOP så vet du sikkert hva konstruktørene er. For nybegynnere er konstruktører spesialfunksjoner i en klasse som automatisk kalles når et objekt av denne klassen er instantiated.

Siden vi har en klasse for en widget, må vi ha en funksjon som setter opp bestemte ting som id og widgetnavnet når den widgeten er instantiated, og det er her __construct () Metoden kommer inn i spill.

De __construct () metode for foreldreklassen aksepterer tre argumenter:

$ base_id: Den unike id for widgeten
$ title: Tittelen til widgeten i administrasjonsområdet. Bør merkes for oversettelse
$ widget_ops: En matrise som inneholder andre widgetalternativer som widgetsklasse og widgetbeskrivelse osv

Nå som vi vet hva __construct () gjør og hvilke argumenter den aksepterer, la oss skrive kode for det:

offentlig funksjon __construct () $ widget_ops = array ('class' => 'uep_upcoming_events', 'description' => __ ('En widget for å vise en liste over kommende hendelser', 'uep')); foreldre :: __ konstruere ('uep_upcoming_events', // base id __ ('Kommende hendelser', 'uep'), / title $ widget_ops);

I __construct () Metoden for vår widget, vi ringte til __construct () metode for foreldreklassen betegnet av ordnede :: __ konstruksjon () og besto tre argumenter for grunn id, tittel og widget alternativer. Legg også merke til at strengene er merket for oversettelse ved hjelp av __ () funksjon.

De `form ()` Metode

De form () Metoden er der vi definerer kroppen til vår widget som vil vises i WordPress admin. Den aksepterer ett argument $ forekomst for forekomsten av widgeten.

Vi må gi brukeren et tekstfelt for å legge inn widgettittelen. Dessuten bør han eller hun kunne velge mellom antall hendelser han vil vise på nettstedet. Men disse feltene skal også ha noen standardverdier dersom brukeren ikke vil legge inn sin egen.

Først vil vi definere standardverdiene for feltene våre:

$ widget_defaults = array ('title' => 'Kommende hendelser', 'number_events' => 5); $ instance = wp_parse_args ((array) $ instance, $ widget_defaults);

Vi definerte standardene våre i en matrise med nøkler som feltnavn. Vi brukte deretter wp_parse_args () verktøyfunksjon som fusjonerer en rekke argumenter (i vårt tilfelle - $ forekomst) med en rekke standardverdier (i dette tilfellet - $ widget_defaults). Vær også oppmerksom på at vi har skrevet inn den $ forekomst som en matrise.

Det er på tide å gjengi formfelt for tittelen og antall hendelser. La oss begynne med å lage et tekstfelt for tittelen:

Først av alt opprettet vi et avsnitt som et containerelement (selv om du kunne like enkelt som brukt a div). Deretter opprettet vi en etikett for inntastingsfeltet. Vi trenger ikke å gi det et ID manuelt, da WordPress vil ta vare på det selv. Det gir oss noen verktøyfunksjoner for bedre arbeid med feltnavn og ids. Det vil generere et unikt id og navn for hvert felt i skjemaet hver gang vi lager en forekomst av widgeten, slik at vi kan lage så mange som forekomster av den samme widgeten.

Metoden som brukes til å generere feltet id er get_field_id () foran en $ Dette->, som er en måte å fortelle at denne metoden tilhører samme klasse. Denne metoden er allerede definert i basen WP_Widget klasse og siden vi utvidet den med vår egen klasse, blir den lett tilgjengelig. Metoden aksepterer et argument for feltet vi genererer et ID for.

Vi markerte etikettteksten for oversettelse ved å bruke _E () funksjon.

Den neste metoden vi brukte er get_field_name () som fungerer på samme måte som get_field_id () bortsett fra at det genererer en verdi for navnetattributtet til feltet.

Klassen widefat Vi har gitt til inntastingsfeltet er en standard WordPress-klasse som stiler innfeltfeltene i WordPress-administrasjonen.

Deretter for ekkoverdien av inntastingsfeltet ekko vi ganske enkelt innholdet i $ Eksempel [ 'tittel'] mens du passerer den gjennom esc_attr () funksjon for å kode eventuelle uønskede tegn.

For den valgte rullegardinmenyen for å angi antall hendelser som skal vises, legg til følgende kode i form () metode:

Koden er stort sett den samme som koden for tittelfeltet, bortsett fra at vi kjørte en løkke for å lage alternativetiketter. For å sjekke om et alternativ er valgt, brukte vi en annen WordPress-funksjon valgt () som sammenligner to gitt verdier (i dette tilfellet - $ i og $ eksempel [ ''] NUMBER_EVENTS) og legger deretter til valgt Tilordne den nåværende alternativetiketten hvis verdiene er like.

Det handler om form () metode. Vi må nå sørge for at widgeten vår blir oppdatert når en ny endring blir brukt på den.

De `Oppdater()` Metode

De Oppdater() Metoden gjør det slik at vi kan oppdatere verdiene som en widget administrerer. Den aksepterer to argumenter $ old_instance og $ new_instance og returnerer oppdatert forekomst av widgeten.

Koden er ganske enkel:

offentlig funksjon oppdatering ($ new_instance, $ old_instance) $ instance = $ old_instance; $ instance ['title'] = $ new_instance ['title']; $ instance ['number_events'] = $ new_instance ['number_events']; returner $ instance;

Så hver gang en endring har blitt gjort til en forekomst av widgeten av brukeren, vil Oppdater() Metoden vil oppdatere innstillingene i databasen og dermed holde widgeten oppdatert med nye innstillinger.

De `widget ()` Metode

Dette er den viktigste metoden for alle som viser det tilsiktede innholdet på forsiden av nettstedet. Den aksepterer to argumenter $ args og $ forekomst. De $ args array inneholder følgende elementer:

$ name: Navnet på sidebjellet der widgeten vises
$ id: Den respekterte sidebarens ID
$ beskrivelse: Beskrivelsen av sidefeltet
$ class: Sidebar klassen
$ before_widget: HTML som ville komme før widgeten. Kan være en åpningstegn for det inneholdende elementet
$ after_widget: HTML som vil komme etter widgeten. Vanligvis en avsluttende merke av det inneholdende elementet
$ before_title: HTML-en som vil bli plassert før tittelen på widgeten
$ after_title: HTML prioriteres av tittelen på widgeten
$ WIDGET_ID: ID for den aktuelle forekomsten av widgeten. Dette er IKKE grunnleggende id for widgeten
$ WIDGET_NAME: Navnet på widgeten passert når du registrerer widgeten

Hvis du noen gang har registrert et sidebar for et WordPress-tema, så er de første åtte elementene i $ args array bør se kjent for deg. De to siste elementene er widgetsspesifikke.

La oss trekke ut $ args array og bruke widget_title filtrer til widgettittelen:

offentlig funksjon widget ($ args, $ instance) ekstrakt ($ args); $ title = apply_filters ('widget_title', $ instance ['title']);

Nå er det på tide å forberede spørringen for å hente en liste over hendelser. Vi vil bruke WP_Query klasse for dette formålet sammen med meta spørringen:

$ query_args = array ('post_type' => 'event', 'posts_per_page' => $ instance ['number_events'], 'post_status' => 'publiser', 'ignore_sticky_posts' => sann, 'meta_key' => 'event -start-dato ',' orderby '=>' meta_value_num ',' order '=>' ASC '); $ upcoming_events = nye WP_Query ($ query_args);

Siden vi vil sortere hendelsene våre i stigende rekkefølge etter startdatoen, har vi satt meta_key til event-start-date meta verdi av hendelsene våre. Sammen med det har vi fortalt WordPress at vi sammenligner tall her (ikke strengene) ved å sette inn rekkefølge etter til meta_value_num. Hvis du angir rekkefølge etter til bare meta_value, WordPress vil gjøre sammenligningen som om den sammenligner strenger og det er ikke det vi ønsker.

Ovennevnte spørring vil hente gitt antall hendelser i stigende rekkefølge med hensyn til startdatoene. Men vi ønsker også å skjerme ut hendelser som allerede har gått, dvs. deres event-end-date meta verdi er mindre enn dagens tidsstempel. For at dette skal oppnås, vil vi passere et metaforespørsel som vil sjekke for sluttdatoene deres:

$ meta_quer_args = array ('relation' => 'OG', array ('key' => 'event-end-date', 'verdi' => tid (), 'sammenligne' => '> =')); $ query_args = array ('post_type' => 'event', 'posts_per_page' => $ instance ['number_events'], 'post_status' => 'publiser', 'ignore_sticky_posts' => sann, 'meta_key' => 'event -start-dato ',' orderby '=>' meta_value_num ',' order '=>' ASC ',' meta_query '=> $ meta_quer_args); $ upcoming_events = nye WP_Query ($ query_args);

I ovennevnte kode sammenlignet vi event-end-date meta-verdien skal være større enn eller lik den nåværende tidsstempel. Nå, bare hendelsene med deres event-end-date meta verdier større enn dagens tidsstempel, dvs. hendelsene som kommer i fremtiden vil bli hentet.

Nå som vi har hentet hendelsene, la oss begynne å spytte ut innholdet i vår widget:

ekko $ before_widget; hvis ($ title) echo $ before_title. $ tittel. $ After_title; ?>

"> på
-

"> Se alle hendelser

Ovennevnte kode skal være selvforklarende: Vi ekko først innholdet av $ before_widget som en åpningstegn av det inneholdende elementet. Deretter sjekket vi om widgeten har en tittel, i så fall har vi skrevet ut det mens det pakkes inn mellom $ before_title og $ after_title.

Deretter løp vi gjennom hendelsene som vi hadde hentet - utskrift av titler, utdrag og annen informasjon som datoer og spillesteder. På slutten la vi til en link til arkivsiden deres ved hjelp av funksjonen get_post_type_archive_link () som returnerer en permalink til arkivsiden av den oppgitte innleggstypen. Vi pakket inn vår widget ved å ekko $ after_widget avsluttende tag.

La oss skrive noen grunnleggende stiler for vår widget i css / style.css fil:

.uep_event_entry margin-bottom: 21px;  .uep_event_entry h4 margin-bottom: 3px;  .uep_event_entry h4 a tekst-dekorasjon: ingen; farge: arv;  .uep_event_entry .event_venue font-size: 0.9em; farge: # 777777; font-weight: normal; font-style: kursiv;  .uep_event_entry p margin-bottom: 3px! viktig;  .uep_event_entry .uep_event_date font-size: 0.9em; farge: # 777777;

Nå må vi inkludere denne filen på forsiden, men bare når widgeten vår er aktivert for øyeblikket. Vi vil sjekke om vår widget for øyeblikket blir vist på forsiden ved å bruke is_active_widget () funksjon som godtar fire argumenter og alle er valgfrie:

$ tilbakeringing: Widget tilbakeringingen for å sjekke
$ WIDGET_ID: Widget id. Trengs for å sjekke
$ id_base: Basis-ID for widgeten som passert i __construct () metode
$ skip_inactive: Enten å hoppe over de inaktive widgets

Legg til følgende kode under uep_admin_script_style () fungere i kommende-events.php hoved plugin-fil:

funksjon uep_widget_style () if (is_active_widget (",", "uep_upcoming_events", true)) wp_enqueue_style ('kommende hendelser', STYLES. 'upcoming-events.css', false '1.0', 'all');  add_action ('wp_enqueue_scripts', 'uep_widget_style');

Derfor sjekket vi først om widgeten er aktiv. Hvis det er tilfelle, beregnede vi stilarket ved hjelp av wp_enqueue_style () funksjon.

Det handler om widget () metode. Vi har opprettet en widget som viser en liste over kommende hendelser sammen med den andre tilknyttede informasjonen.

Flushing Omskrivningsregler

Vi har nesten fullført vårt plugin og widgeten, men vi har fortsatt et lite problem - klikk på en hvilken som helst hendelse tittel, og du kan få en "side ikke funnet feil." Det er fordi når vi registrerer en posttype via plugin, må vi spyle omskrivningsregler ved plugin-aktivering for riktig bruk av permalinkstruktur.

Du kan få koblingene dine ved å endre permalinkstrukturen, men det er ikke den ideelle måten; Derfor vil vi spyle omskrivningsregler hver gang pluginet vårt er aktivert.

Legg til følgende kode i din kommende-events.php fil:

funksjon uep_activation_callback () uep_custom_post_type (); flush_rewrite_rules ();  register_activation_hook (__FILE__, 'uep_activation_callback');

Så vi registrerte aktiveringskroken for pluginet vårt ved hjelp av register_activation_hook () funksjon som aksepterer to argumenter:

$ fil: Stien til hovedpluginfilen
$ funksjon: Tilbakeringingsfunksjonen som skal kjøres når plugin er aktivert

I tilbakekallingsfunksjonen til kroken leggte vi først tilpasset posttype hendelser inn i databasen ved hjelp av funksjonen uep_custom_post_type () Vi hadde definert tidligere i vår tidligere opplæring.

Vi spylte deretter omskrivningsregler ved hjelp av flush_rewrite_rules () funksjon. Nå vil du kanskje deaktivere plugin-modulen og aktivere den igjen for å sikre at omskrivningsreglene er spylt. Dette gjør at koblingene dine nå skal fungere bra og omdirigere deg til hendelsens enkelt side.

Konklusjon

Dette har vært ganske annen langvarig opplæring der vi skrev mye kode og så på ulike WordPress-funksjoner. Vi opprettet en WordPress-widget fra bunnen av ved å forlenge foreldrene WP_Widget klasse og sett på medlemsfunksjonene som denne klassen gir for å definere funksjonaliteten til vår widget. Vi skrev også en spørring som utnytter kraften til WP_Query klasse for å hente en liste over hendelser filtrert av deres meta verdier.

Med dette konkluderer vi også våre tre delserier. Jeg håper at denne serien vil hjelpe nye lesere der ute som bare har startet med WordPress, og også de som ønsker å forbedre sin kunnskap om WordPress-plugin og widgetutvikling.

Du kan få tilgang til den komplette koden til pluginet på min GitHub-side og nedenfor er noen koblinger for videre utforskning av emnene som er omtalt i denne opplæringen:

WordPress Widgets API
Klassehenvisning: WP_Query
Mastering WordPress Meta Data: En introduksjon til metadata
Objektorientert programmering i WordPress: En introduksjon

Kode