Share
I denne delen av serien begynner vi å skrive vår kode. Å være mer spesifikk, vil vi:
Dette vil være en kode tunge opplæring, så åpne din favoritt kodeditor og ta en kopp kaffe!
Før vi går videre til å skrive selve koden, starter vi ved å definere noen konstanter for våre stier. Dette vil hjelpe oss senere når du registrerer våre skript og stilark.
Først åpner du kommende-events.php fil, legg til følgende kode:
Accentsconagua
define ('ROOT', plugins_url (", __FILE__)); definer ('BILDER', ROOT. '/ img /'); definer ('STYLES', ROOT. '/ css /'); definer ('SCRIPTS' ROOT. '/ Js /'); I ovennevnte kode har vi brukt plugins_url () funksjon for å få vår rotkatalogbane. Den aksepterer to parametere, dvs.. $ path og $ plugin.
Siden vi ikke trenger å referere til noen filer, men til rotkatalogen av pluginet, ga vi ikke frem $ path argument og for $ plugin argument, vi ga den nåværende filen. Vi så bare vedlagt navnene til andre kataloger til ROT konstant for sine respektive baner.
WordPress er i stand til å holde forskjellige typer innhold. Vi kan lage så mange innholdstyper som vi trenger, avhengig av scenariet der vi jobber. For å legge til flere innholdstyper (vanligvis kjent som "egendefinerte innleggstyper"), gir WordPress en funksjon register_post_type () som aksepterer to argumenter:
I det andre argumentet, det vil si en rekke ekstra argumenter, definerer vi etikettene for posttypen og andre spesifikasjoner med hensyn til synlighet, evner og taksonomier mv..
Ikommende-events.php fil, legg til følgende kode for å registrere egendefinert innleggstype for hendelser:
$ labels = array ('name' => __ ('Events', 'uep'), 'singular_name' => __ ('Event', 'uep'), 'add_new_item' => __ ('Legg til ny hendelse' 'uep'), 'all_items' => __ ('Alle hendelser', 'uep'), 'edit_item' => __ ('Rediger hendelse', 'uep'), 'new_item' => __ , 'uep'), 'view_item' => __ ('View Event', 'uep'), 'not_found' => __ ('Ingen hendelser funnet', 'uep'), 'not_found_in_trash' => __ Hendelser funnet i søppel ',' uep '))); $ supports = array ('title', 'editor', 'utdrag'); $ args = array ('label' => __ ('Events', 'uep'), 'labels' => $ etiketter, 'description' => __ ('En liste over kommende hendelser', 'uep') ' public '=> true,' show_in_menu '=> true,' menu_icon '=> BILDER.' event.svg ',' has_archive '=> true,' rewrite '=> true,' supports '=> $ støtter); register_post_type ('event', $ args); I koden ovenfor har vi definert etikettene for vår posttype og gjort posttypen synlig for offentlig gjennom å sette inn offentlig nøkkelen til ekte. For skjermbildet for nye innlegg eller etter redigering har vi tatt med tre felt for tittel, innhold og utdrag.
Vær også oppmerksom på at vi har merket de statiske tekstfeltene for oversettelse ved hjelp av tekstdomenet UEP som er unikt for vår plugin. Et 20X20 SVG-ikon er også inkludert i hendelsesmenyen.
De register_post_type () funksjonen må kalles gjennom i det Handlingen for å fungere skikkelig. Så pakk den inn i en funksjon og hek den til i det handling:
funksjon uep_custom_post_type () $ labels = array ('name' => __ ('Hendelser', 'uep'), 'singular_name' => __ ('Event', 'uep'), 'add_new_item' => __ Legg til ny hendelse ',' uep '),' all_items '=> __ (' Alle hendelser ',' uep '),' edit_item '=> __ (' Rediger hendelse ',' uep '),' new_item '=> __ ('New Event', 'uep'), 'view_item' => __ ('View Event', 'uep'), 'not_found' => __ ('Ingen hendelser funnet', 'uep'), 'not_found_in_trash' = > __ ('Ingen hendelser funnet i søppel', 'uep'))); $ supports = array ('title', 'editor', 'utdrag'); $ args = array ('label' => __ ('Events', 'uep'), 'labels' => $ etiketter, 'description' => __ ('En liste over kommende hendelser', 'uep') ' public '=> true,' show_in_menu '=> true,' menu_icon '=> BILDER.' event.svg ',' has_archive '=> true,' rewrite '=> true,' supports '=> $ støtter); register_post_type ('event', $ args); add_action ('init', 'uep_custom_post_type'); Vi har nå vår event post type klar. Naviger til WordPress dashbordet, og du vil se en meny for hendelser under kommentarmenyen:
Etter å ha registrert vår tilpassede innleggstype for hendelser, må vi nå legge til tre metafelt for brukeren å legge til startdato for start, sluttdato og arrangementsted. Disse meta feltene finnes i en tilpasset metaboks. Vi kan enkelt legge til en tilpasset metaboks til WordPress admin ved hjelp av add_meta_box () funksjon.
Den aksepterer sju argumenter som er definert nedenfor:
$ ider den metaboksens id. Det er også id-attributtet for den gjengitte metaboxen på skjermen.$ title er tittelen på metaboxen.$ tilbakeringing er navnet på funksjonen som vil bli brukt til å gjøre innholdet i metaboxet.$ post_type er navnet på posttypen som vi vil legge til denne metaboxen.$ sammenheng er området på siden som vi vil legge til metaboxen. Det er tre sammenhenger: normal, avansere og side. $ prioritet av metaboxen innenfor den givne sammenhengen som kan være noen av høy, kjerne, misligholde eller lav. $ callback_argser en rekke argumenter som kan sendes til tilbakeringingsfunksjonen.I kommende-events.php fil legg til følgende kode etter uep_custom_post_type () funksjon:
funksjon uep_add_event_info_metabox () add_meta_box ('uep-event-info-metabox', __ ('Event Info', 'uep'), 'uep_render_event_info_metabox', 'event', 'side', 'core'); add_action ('add_meta_boxes', 'uep_add_event_info_metabox'); Naviger til Legg til ny side under arrangementer menyen, og du vil se en advarsel for udefinert tilbakeringingsfunksjon. Det er fordi vi ennå ikke har definert vår tilbakeringingsfunksjon for å gjengi innholdet i metaboxen.
La oss gjøre det nå:
funksjon uep_render_event_info_metabox ($ post) // generere et nonce-felt wp_nonce_field (basenavn (__FILE__), 'uep-event-info-nonce'); // Få tidligere lagrede metaværdier (hvis noen) $ event_start_date = get_post_meta ($ post-> ID, 'event-start-date', true); $ event_end_date = get_post_meta ($ post-> ID, 'event-end-date', true); $ event_venue = get_post_meta ($ post-> ID, 'event-venue', true); // hvis det tidligere er lagret verdi, hent det, sett det til gjeldende tid $ event_start_date =! tomt ($ event_start_date)? $ event_start_date: tid (); // vi antar at hvis sluttdatoen ikke er til stede, avslutter arrangementet samme dag $ event_end_date =! tomt ($ event_end_date)? $ event_end_date: $ event_start_date; ?>
I ovennevnte kode genererte vi først et WordPress nonce-felt. Dette er viktig siden vi må sørge for at ingen kaprer vår skjemaforespørsel og dermed kompromitterer sidens sikkerhet.
Vi hentet deretter vårt innleggsmetode for startdato, sluttdato og arrangementsted ved hjelp av funksjonen get_post_meta (). Hvis dette er et nytt innlegg, vil dagens tidsstempel brukes til start- og sluttdato for hendelsen. Ellers hvis innlegget blir redigert, vil tidligere lagrede verdier bli vist i metafeltene.
For meta feltene ga vi tre etiketter og inputfelter med plassholdertekster for å gi brukeren et hint om inngangsformatet.
Nå er det på tide å legge til jQuery UI datepicker-widgeten til startdatoen for begivenhet og hendelsesdatoen for å gi brukeren mer brukervennlighet når innlasting av datoer.
Tilbakekall fra den siste artikkelen diskuterte vi at jQuery UI og jQuery UI Datepicker-widgeten allerede er inkludert i WordPress JavaScript-biblioteket. Vi lastet også ned en tilpasset konstruksjon fra jQuery UI offisielle nettside og droppet stilarkfilen i vår css-mappe. Hvis du ikke har gjort det ennå, ta deg en kopi fra den jQuery UI offisielle nettsiden og plasser stilarket i css-mappen.
Opprett en fil som heter script.js inne i js-mappen. Dette er filen der vi vil initialisere jQuery UI Datepicker-widgeten for start- og sluttdatoen for hendelsen.
Vi vil nå kalkulere JavaScript og det tilhørende stilarket i vår admin ved hjelp av handlingen admin_enqueue_scripts:
funksjon uep_admin_script_style ($ hook) if ('post.php' == $ hook || 'post-new.php' == $ krok) wp_enqueue_script ('kommende hendelser', SCRIPTS. 'script.js' ('jquery', 'jquery-ui-datepicker'), '1.0', sant); wp_enqueue_style ('jquery-ui-calendar', STYLES. 'jquery-ui-1.10.4.custom.min.css', falsk, '1.10.4', 'alle'); add_action ('admin_enqueue_scripts', 'uep_admin_script_style'); Du har kanskje lagt merke til at vi ikke har kalkulert jQuery og jQuery UI datepicker separat, men heller lagt dem til som en avhengighet for script.js fil.
Ved å gjøre det, vil WordPress sørge for at jQuery og jQuery UI Datepicker (sammen med sine egne avhengigheter) blir kalkulert FØR den script.js fil.
Tilbakeringingsfunksjonen aksepterer et argument for sidekroken, dvs. den nåværende siden av instrumentbrettet. Siden vi ikke vil inkludere denne JavaScript-filen på hver enkelt side i dashbordet, sjekker vi først gjennom tilstanden hvis den nåværende siden er post.php eller post-new.php.
På denne måten har vi begrenset JavaScript bare for å bli inkludert i postredigeringen eller nye innleggsbilder, men hva om noen lager eller oppdaterer et vanlig innlegg eller en side? Ovennevnte JavaScript-fil vil også bli inkludert på disse sidene siden kroken er den samme for de to også.
Til det formål vil vi ytterligere sjekke om innlegget som redigeres, er en posttype for hendelse:
funksjon uep_admin_script_style ($ hook) global $ post_type; hvis (('post.php' == $ hook || 'post-new.php' == $ hook) && ('event' == $ post_type)) wp_enqueue_script ('kommende hendelser', SCRIPTS. .js ', array (' jquery ',' jquery-ui-datepicker '),' 1.0 ', sant); wp_enqueue_style ('jquery-ui-calendar', STYLES. 'jquery-ui-1.10.4.custom.min.css', falsk, '1.10.4', 'alle'); add_action ('admin_enqueue_scripts', 'uep_admin_script_style'); Nå vil JavaScript-filen ovenfor bare bli inkludert hvis sidekroken er post.php eller post-new.php og Posten som blir opprettet eller redigert, er av typen begivenhet.
La oss initialisere jQuery UI Datepicker. Åpne script.js fil fra js katalog og legg til følgende kode:
(funksjon ($) $ ('# uep-event-start-date') .datepicker (dateFormat: 'MM dd, yy', onClose: funksjon (valgt dato) $ ('# uep-event-sluttdato ') .datepicker (' option ',' minDate ', selectedDate);); $ (' # uep-event-sluttdato ') .datepicker (dateFormat:' MM dd, yy ', onClose: funksjon selectedDate) $ ('# uep-event-start-date') .datepicker (' option ',' maxDate ', selectedDate););) (jQuery); Vær oppmerksom på at vi har begrenset startdato for hendelsen til ikke å være større enn begivenhetsdatoen og omvendt.
Sjekk om initialiseringen har vært vellykket ved å gå til Legg til ny Hendelsesside og klikk på en av start- og sluttdatoer for hendelsen. Du bør se datapunktvinduet vises, og du kan skrive inn datoen ved å navigere gjennom kalenderen og klikke på ønsket dato.
Så langt har vi skrevet en del kode, men vårt plugin mangler fortsatt den mest grunnleggende funksjonaliteten: For å lagre og oppdatere meta-feltverdiene for hendelsen.
Nå som vi har opprettet vår tilpassede innleggstype og lagt til tre metafelt for begivenhets startdato, sluttdato og arrangement, må vi sørge for at verdiene til disse metafeltene blir lagret i databasen.
WordPress gir en krok til dette formålet som brenner hver gang et innlegg blir lagret. Kroken er lagre post og dens tilbakeringingsfunksjon aksepterer et argument for IDen til innlegget som blir lagret. Ved hjelp av denne kroken kan vi lagre verdiene til våre metafelt i databasen sammen med de vanlige innleggsfeltene, som tittelen og innholdet.
funksjon uep_save_event_info ($ post_id) add_action ('save_post', 'uep_save_event_info'); Men igjen må vi sjekke om posten som blir lagret, er av typen begivenhet. Til det formål vil vi sjekke $ _POST global variabel:
funksjon uep_save_event_info ($ post_id) // sjekke om posten som blir lagret er en 'hendelse', // hvis ikke, returner hvis ('event'! = $ _POST ['post_type']) return; Nå vil vi sjekke for lagringsstatusen, dersom posten blir automatisk lagret, eller det er en revisjon. WordPress gir to betingede koder for det formålet:
wp_is_post_autosave ($ post_id)wp_is_post_revision ($ post_id)Vi kan bruke disse to betingede kodene som følger:
$ is_autosave = wp_is_post_autosave ($ post_id); $ is_revision = wp_is_post_revision ($ post_id);
Men vi må også sørge for at nonce er gyldig. Husk at vi definerte et nonce-felt ved hjelp av wp_nonce_field () fungere når du gjør metaboxet? Vi vil sjekke verdien av samme nonce:
$ is_valid_nonce = (isset ($ _POST ['uep-event-info-nonce']) && (wp_verify_nonce ($ _POST ['uep-event-info-nonce'], basenavn (__FILE__)))))? sant: false;
Sett alle disse tre betingelsene i en enkelt setning, og vi er gode å gå:
hvis ($ is_autosave || $ is_revision ||! $ is_valid_nonce) return;
Etter å ha utført nødvendige operasjoner før lagring av metaværdiene, er vi nå klare til å sette dem inn i databasen:
funksjon uep_save_event_info ($ post_id) // sjekke om posten som blir lagret er en 'hendelse', // hvis ikke, returner hvis ('event'! = $ _POST ['post_type']) return; // sjekker statusen "lagre" $ is_autosave = wp_is_post_autosave ($ post_id); $ is_revision = wp_is_post_revision ($ post_id); $ is_valid_nonce = (isset ($ _POST ['uep-event-info-nonce']) && (wp_verify_nonce ($ _POST ['uep-event-info-nonce'], basenavn (__FILE__)))))? sant: false; // Avslutt avhengig av lagringsstatus eller hvis nonce er ikke gyldig hvis ($ is_autosave || $ is_revision ||! $ is_valid_nonce) return; // sjekker verdiene og utfører nødvendige handlinger hvis (isset ($ _POST ['uep-event-start-date'])) update_post_meta ($ post_id, 'begivenhetsbegynnelse', strtotime ($ _POST [' uep-event-start-date '])); hvis (isset ($ _POST ['uep-event-end-date'])) update_post_meta ($ post_id, 'event-end-date', strtotime ($ _POST [' uep-event-end-date ' ); hvis (isset ($ _POST ['uep-event-arena'])) update_post_meta ($ post_id, 'event-venue', sanitize_text_field ($ _POST ['uep-event-arena'])); add_action ('save_post', 'uep_save_event_info'); Her lagret vi metaverdiene i databasen ved hjelp av funksjonen update_post_meta () som aksepterer fire argumenter som vi har bestått de tre første:
$ POST_ID er id av posten som metaværdien tilhører.$ meta_keyer nøkkelen til det tilpassede metafeltet.$ meta_valueer den nye metaværdien.$ prev_valueEr den forrige metaværdien erstattet.Vær oppmerksom på at vi ikke lagrer datoen i tekstbeskrivelsen, men vi konverterer først til UNIX tidsstempel ved hjelp av PHP strtotime () funksjon. På denne måten blir det langt lettere når man sammenligner datoer mot hverandre mens man utfører meta-spørringen på forsiden.
På dette punktet er den mest grunnleggende delen av opplæringen vår fullført. Det er på tide å legge til noen egendefinerte kolonner på skjermbildet for innleggets dashbord.
Siden hendelsene har sin egen spesifikke informasjon i sine egendefinerte felt, er det hensiktsmessig å vise dem i de egendefinerte kolonnene i innleggets administrasjonsskjerm for bedre tilgjengelighet av brukeren.
Som standard viser WordPress tittelen og datakolonnene for den egendefinerte innleggstypen, men vi vil legge til tre flere kolonner for startdato for startdato, sluttdato og spillested.
Vi kan kontrollere hvilke kolonner som skal legges til og hvilke som skal gjemme seg ved WordPress-kroken manage_edit- $ post_columns hvor $ post er navnet på den egendefinerte innleggstypen. Tilbakeringingsfunksjonen aksepterer en matrise for kolonnene som allerede vises.
funksjon uep_custom_columns_head ($ defaults) unset ($ defaults ['date']); $ standardinnstillinger ['event_start_date'] = __ ('Startdato', 'uep'); $ standard ['event_end_date'] = __ ('sluttdato', 'uep'); $ standard ['event_venue'] = __ ('Sted', 'uep'); returnere $ standardinnstillinger; add_filter ('manage_edit-event_columns', 'uep_custom_columns_head', 10); I ovennevnte kode har vi satt opp standard datakolonnen og i stedet har vi lagt til våre tre tilpassede kolonner.
Men innholdet i de respektive kolonnene vil ikke bli vist før vi definerer det ved hjelp av manage_ $ post_posts_custom_column krok hvor $ post er navnet på den egendefinerte innleggstypen.
funksjon uep_custom_columns_content ($ column_name, $ post_id) if ('event_start_date' == $ column_name) $ start_date = get_post_meta ($ post_id, 'event-start-date', true); ekko dato ('F d, Y', $ start_date); hvis ('event_end_date' == $ column_name) $ end_date = get_post_meta ($ post_id, 'event-end-date', true); ekko dato ('F d, Y', $ end_date); hvis ('event_venue' == $ column_name) $ venue = get_post_meta ($ post_id, 'event-venue', true); ekko $ arena; add_action ('manage_event_posts_custom_column', 'uep_custom_columns_content', 10, 2); Vi har først sjekket kolonnen som blir vist og ekko innholdet tilsvarende. Den siste parameteren i ADD_ACTION () funksjonsanrop er antall argumenter som aksepteres av tilbakeringingsfunksjonen - i vårt tilfelle - det er to.
I denne veiledningen registrerte vi vellykket en tilpasset posttype for hendelser. Vi lærte også å inkludere en tilpasset metaboks og integrert jQuery UI datepicker-widget i WordPress dashboard. Videre, for å gi brukeren større tilgjengelighet, la vi til egendefinerte kolonner i vår post admin skjerm.
Mens vi nesten har fullført dashbordet, er det fortsatt noe igjen for oss å takle - fronten.
I neste del av serien vil vi lage en egendefinert widget for å vise listen over kommende hendelser i sidefeltet. Vi vil se på WP_Query klasse nærmere for å hente innlegg basert på deres meta verdier.
