Share
In questa parte della serie inizieremo a scrivere il nostro codice. Essendo più specifici, noi:
Questo sarà un tutorial pesante per codice, quindi apri il tuo editor di codice preferito e prendi una tazza di caffè!
Prima di passare alla scrittura del codice attuale, inizieremo definendo alcune costanti per i nostri percorsi. Questo ci aiuterà in seguito quando registreremo i nostri script e fogli di stile.
Innanzitutto, apri il imminente-events.php file, aggiungi il seguente codice:
Accentsconagua
define ('ROOT', plugins_url (", __FILE__)); define ('IMAGES', ROOT. '/ img /'); define ('STYLES', ROOT. '/ css /'); define ('SCRIPTS', ROOT. '/ Js /'); Nel codice sopra, abbiamo usato plugins_url () funzione per ottenere il nostro percorso di directory di root. Accetta due parametri, ad es. $ path e $ plug-in.
Dal momento che non è necessario fare riferimento a nessun file, ma alla directory root del nostro plugin, non abbiamo fornito il file $ path argomento e per il $ plug-in argomento, abbiamo fornito il file corrente. Abbiamo quindi semplicemente aggiunto i nomi di altre directory al RADICE costante per i loro rispettivi percorsi.
WordPress è in grado di contenere diversi tipi di contenuti. Possiamo creare tutti i tipi di contenuto di cui abbiamo bisogno a seconda dello scenario in cui stiamo lavorando. Per aggiungere altri tipi di contenuto (generalmente noti come "tipi di post personalizzati"), WordPress fornisce una funzione register_post_type () accetta due argomenti:
Nel secondo argomento, vale a dire l'array di argomenti aggiuntivi, definiamo le etichette del tipo di post e altre specifiche relative alla visibilità, alle capacità e alle tassonomie ecc..
Nelimminente-events.php file, aggiungere il seguente codice per registrare il tipo di messaggio personalizzato per gli eventi:
$ labels = array ('name' => __ ('Events', 'uep'), 'singular_name' => __ ('Event', 'uep'), 'add_new_item' => __ ('Aggiungi un nuovo evento', 'uep'), 'all_items' => __ ('Tutti gli eventi', 'uep'), 'edit_item' => __ ('Modifica evento', 'uep'), 'new_item' => __ ('Nuovo evento') , 'uep'), 'view_item' => __ ('Visualizza evento', 'uep'), 'not_found' => __ ('Nessun evento trovato', 'uep'), 'not_found_in_trash' => __ ('No Eventi trovati in Trash ',' uep ')); $ supports = array ('title', 'editor', 'excerpt'); $ args = array ('label' => __ ('Eventi', 'uep'), 'etichette' => $ etichette, 'descrizione' => __ ('Un elenco di eventi imminenti', 'uep'), ' public '=> true,' show_in_menu '=> true,' menu_icon '=> IMMAGINI.' event.svg ',' has_archive '=> true,' rewrite '=> true,' supports '=> $ supporta); register_post_type ('evento', $ args); Nel codice precedente, abbiamo definito le etichette per il nostro tipo di post evento e reso visibile il tipo di post al pubblico attraverso l'impostazione di pubblico chiave per vero. Per la schermata nuovo post o modifica, sono stati inclusi tre campi per titolo, contenuto ed estratto.
Si noti inoltre che abbiamo contrassegnato i campi di testo statici per la traduzione utilizzando il dominio del testo UEP che è unico per il nostro plugin. Un'icona SVG 20X20 è stata inclusa anche nel menu Eventi.
Il register_post_type () la funzione deve essere chiamata attraverso il dentro azione per farlo funzionare correttamente. Quindi avvolgerlo in una funzione e agganciarlo al dentro azione:
function uep_custom_post_type () $ labels = array ('name' => __ ('Events', 'uep'), 'singular_name' => __ ('Event', 'uep'), 'add_new_item' => __ (' Aggiungi nuovo evento ',' uep '),' all_items '=> __ (' Tutti gli eventi ',' uep '),' edit_item '=> __ (' Modifica evento ',' uep '),' new_item '=> __ ('Nuovo evento', 'uep'), 'view_item' => __ ('Visualizza evento', 'uep'), 'not_found' => __ ('Nessun evento trovato', 'uep'), 'not_found_in_trash' = > __ ('Nessun evento trovato nel cestino', 'uep')); $ supports = array ('title', 'editor', 'excerpt'); $ args = array ('label' => __ ('Eventi', 'uep'), 'etichette' => $ etichette, 'descrizione' => __ ('Un elenco di eventi imminenti', 'uep'), ' public '=> true,' show_in_menu '=> true,' menu_icon '=> IMMAGINI.' event.svg ',' has_archive '=> true,' rewrite '=> true,' supports '=> $ supporta); register_post_type ('evento', $ args); add_action ('init', 'uep_custom_post_type'); Ora abbiamo il nostro tipo di post evento pronto. Vai al dashboard di WordPress e vedrai un menu per gli eventi sotto il menu dei commenti:
Dopo aver registrato con successo il nostro tipo di post personalizzato per gli eventi, ora dobbiamo aggiungere tre meta campi per l'utente per aggiungere la data di inizio dell'evento, la data di fine e la sede dell'evento. Questi metadati sono contenuti in un metabox personalizzato. Possiamo comodamente aggiungere un metabox personalizzato all'amministratore di WordPress usando il add_meta_box () funzione.
Accetta sette argomenti che sono definiti di seguito:
$ idè quell'id del metabox. È anche l'attributo id per la metabox renderizzata sullo schermo.$ titolo è il titolo del metabox.$ callback è il nome della funzione che verrà utilizzata per rendere il contenuto del metabox.$ post_type è il nome del tipo di post a cui vogliamo aggiungere questo metabox.$ contesto è l'area della pagina a cui vogliamo aggiungere il metabox. Ci sono tre contesti: normale, progredire e lato. $ priorità del metabox all'interno del contesto dato che può essere qualsiasi di alto, nucleo, predefinito o Basso. $ callback_argsè un array di argomenti che possono essere passati alla funzione di callback.Nel imminente-events.php file aggiungere il seguente codice dopo il uep_custom_post_type () funzione:
function 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'); Vai a Aggiungere nuova pagina sotto il eventi menu e verrà visualizzato un avviso per la funzione di callback non definita. Questo perché non abbiamo ancora definito la nostra funzione di callback per rendere il contenuto del metabox.
Facciamolo ora:
function uep_render_event_info_metabox ($ post) // genera un campo nonce wp_nonce_field (basename (__FILE__), 'uep-event-info-nonce'); // ottiene valori meta precedentemente salvati (se ce ne sono) $ 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); // se c'è un valore precedentemente salvato, quindi recuperarlo, altrimenti impostarlo sull'ora corrente $ event_start_date =! vuoto ($ event_start_date)? $ event_start_date: time (); // supponiamo che se la data di fine non è presente, l'evento termina lo stesso giorno $ event_end_date =! vuoto ($ event_end_date)? $ event_end_date: $ event_start_date; ?>
Nel codice precedente, abbiamo prima generato un campo nonce di WordPress. Questo è importante dal momento che dobbiamo assicurarci che nessuno stacchi la nostra richiesta di modulo compromettendo così la sicurezza del sito.
Abbiamo quindi recuperato il nostro post meta per la data di inizio, la data di fine e la sede dell'evento utilizzando la funzione get_post_meta (). Se questo è un nuovo post, verrà utilizzato il timestamp corrente per le date di inizio e fine dell'evento. Altrimenti se il post è in fase di modifica, i valori salvati in precedenza verranno mostrati nei metadati.
Per i metadati, abbiamo reso tre etichette e campi di input con testo segnaposto per dare un suggerimento all'utente sul formato di input.
Ora è il momento di aggiungere il widget datepicker dell'interfaccia utente jQuery alla data di inizio dell'evento e al campo della data di fine dell'evento per garantire all'utente maggiore facilità nell'introdurre le date.
Ricordiamo l'ultimo articolo, abbiamo discusso che l'interfaccia grafica di jQuery e il widget Datepicker dell'interfaccia utente jQuery sono già inclusi nella libreria JavaScript di WordPress. Abbiamo anche scaricato una build personalizzata dal sito web ufficiale di jQuery UI e abbiamo rilasciato il file di stile nella nostra cartella css. Se non lo hai ancora fatto, prendi una copia dal sito ufficiale di jQuery UI e metti il foglio di stile nella cartella css.
Crea un file chiamato script.js all'interno della cartella js. Questo è il file in cui inizializzeremo il widget Datepicker dell'interfaccia utente jQuery per le date di inizio e fine del nostro evento.
Ora accodare JavaScript e il foglio di stile associato nel nostro amministratore utilizzando l'azione admin_enqueue_scripts:
function uep_admin_script_style ($ hook) if ('post.php' == $ hook || 'post-new.php' == $ hook) wp_enqueue_script ('prossimi-events', SCRIPTS. 'script.js', array ('jquery', 'jquery-ui-datepicker'), '1.0', vero); wp_enqueue_style ('jquery-ui-calendar', STYLES. 'jquery-ui-1.10.4.custom.min.css', false, '1.10.4', 'all'); add_action ('admin_enqueue_scripts', 'uep_admin_script_style'); Avrai notato che non abbiamo messo in coda separatamente jQuery e jQuery UI datepicker, ma piuttosto li abbiamo aggiunti come dipendenza per script.js file.
In questo modo, WordPress farà in modo che jQuery e jQuery UI Datepicker (insieme alle sue dipendenze) vengano accodati PRIMA del script.js file.
La funzione di callback accetta un argomento per il hook della pagina, ovvero la pagina corrente del dashboard. Poiché non vogliamo includere questo file JavaScript su ogni singola pagina del dashboard, per prima cosa controlliamo la condizione se la pagina corrente è post.php o post-new.php.
In questo modo, abbiamo limitato il JavaScript solo per essere incluso nelle schermate di post editing o nuovo post, ma cosa succede se qualcuno crea o aggiorna un post o una pagina normale? Il suddetto file JavaScript verrà incluso anche in quelle pagine poiché il gancio è lo stesso anche per quelle due.
A tale scopo, controlleremo ulteriormente se il post che si sta modificando è un tipo di evento:
function uep_admin_script_style ($ hook) global $ post_type; if (('post.php' == $ hook || 'post-new.php' == $ hook) && ('event' == $ post_type)) wp_enqueue_script (script 'imminenti-eventi', SCRIPTS. ' .js ', array (' jquery ',' jquery-ui-datepicker '),' 1.0 ', vero); wp_enqueue_style ('jquery-ui-calendar', STYLES. 'jquery-ui-1.10.4.custom.min.css', false, '1.10.4', 'all'); add_action ('admin_enqueue_scripts', 'uep_admin_script_style'); Ora il file JavaScript sopra sarà incluso solo se l'hook della pagina è post.php o post-new.php e il post che viene creato o modificato è di tipo evento.
Inizializziamo jQuery UI Datepicker. Apri il script.js file dal js directory e aggiungere il seguente codice:
(function ($) $ ('# uep-event-start-date') .datepicker (dateFormat: 'MM dd, yy', onClose: function (selectedDate) $ ('# uep-event-end-date ') .datepicker (' option ',' minDate ', selectedDate);); $ (' # uep-event-end-date ') .datepicker (dateFormat:' MM dd, yy ', onClose: function ( selectedDate) $ ('# uep-event-start-date') .datepicker ('option', 'maxDate', selectedDate););) (jQuery); Si noti che abbiamo limitato la data di inizio dell'evento a non essere maggiore della data di fine dell'evento e viceversa.
Controlla se l'inizializzazione ha avuto successo andando al Aggiungere nuova pagina dell'evento e facendo clic su una delle date di inizio o di fine dell'evento. Dovresti vedere apparire la finestra di DatePicker e puoi inserire la data navigando nel calendario e cliccando sulla data desiderata.
Finora, abbiamo scritto una buona quantità di codice, ma al nostro plug-in mancano ancora le funzionalità fondamentali: per salvare e aggiornare i valori del metadato dell'evento.
Ora che abbiamo creato il nostro tipo di post personalizzato e aggiunto tre campi meta per la data di inizio dell'evento, la data di fine e la sede dell'evento, dobbiamo assicurarci che i valori di questi metadati vengano salvati nel database.
WordPress fornisce un hook per questo scopo che si attiva ogni volta che viene salvato un post. Il gancio è save_post e la sua funzione di callback accetta un argomento per l'ID del post che viene salvato. Usando questo hook, possiamo salvare i valori dei nostri metadati nel database insieme ai normali campi del post come il titolo e il contenuto.
funzione uep_save_event_info ($ post_id) add_action ('save_post', 'uep_save_event_info'); Ma ancora, dobbiamo controllare se il post che viene salvato è di tipo evento. A tale scopo, controlleremo il $ _POST variabile globale:
function uep_save_event_info ($ post_id) // controlla se il post che si sta salvando è un 'evento', // se non lo è, quindi restituisce if ('event'! = $ _POST ['post_type']) return; Ora controlleremo lo stato di salvataggio, ad esempio se il post viene salvato automaticamente o è una revisione. WordPress fornisce due tag condizionali per questo scopo:
wp_is_post_autosave ($ post_id)wp_is_post_revision ($ post_id)Possiamo usare questi due tag condizionali come segue:
$ is_autosave = wp_is_post_autosave ($ post_id); $ is_revision = wp_is_post_revision ($ post_id);
Ma dobbiamo anche assicurarci che il nonce sia valido. Ricorda che abbiamo definito un campo nonce usando il wp_nonce_field () funzione durante il rendering del metabox? Controlleremo il valore della stessa nonce:
$ is_valid_nonce = (isset ($ _POST ['uep-event-info-nonce']) && (wp_verify_nonce ($ _POST ['uep-event-info-nonce'], basename (__FILE__))))? vero falso;
Metti tutte e tre queste condizioni in una singola dichiarazione e siamo a posto:
if ($ is_autosave || $ is_revision ||! $ is_valid_nonce) return;
Dopo aver eseguito le operazioni necessarie prima di salvare i metadati, siamo ora pronti per inserirli nel database:
function uep_save_event_info ($ post_id) // controlla se il post che si sta salvando è un 'evento', // se non lo è, quindi restituisce if ('event'! = $ _POST ['post_type']) return; // verifica lo stato di 'salvataggio' $ 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'], basename (__FILE__))))? vero falso; // esce a seconda dello stato di salvataggio o se il nonce non è valido se ($ is_autosave || $ is_revision ||! $ is_valid_nonce) return; // verifica i valori ed esegue le azioni necessarie se (isset ($ _POST ['uep-event-start-date'])) update_post_meta ($ post_id, 'event-start-date', strtotime ($ _POST [' uep-event-start-date '])); if (isset ($ _POST ['uep-event-end-date'])) update_post_meta ($ post_id, 'event-end-date', strtotime ($ _POST ['uep-event-end-date'])) ); if (isset ($ _POST ['uep-event-venue'])) update_post_meta ($ post_id, 'event-venue', sanitize_text_field ($ _POST ['uep-event-venue'])); add_action ('save_post', 'uep_save_event_info'); Qui, abbiamo salvato i metadati nel database usando la funzione update_post_meta () accetta quattro argomenti di cui abbiamo superato i primi tre:
$ post_id è l'id del post a cui appartiene il meta valore.$ meta_keyè la chiave del meta campo personalizzato.$ meta_valueè il nuovo meta-valore.$ prev_valueè il precedente valore meta da sostituire.Si noti che non stiamo salvando la data nella descrizione testuale, ma in primo luogo la convertiamo nel timestamp UNIX usando il PHP strtotime () funzione. In questo modo, diventerà molto più facile confrontando le date l'una contro l'altra mentre esegui la metamotazione sul front-end.
A questo punto, la parte più fondamentale del nostro tutorial è stata completata. È ora di aggiungere alcune colonne personalizzate alla schermata degli eventi del dashboard.
Poiché gli eventi hanno le proprie informazioni specifiche contenute nei loro campi personalizzati, è opportuno mostrarli nelle colonne personalizzate nella schermata di amministrazione post per una migliore accessibilità da parte dell'utente.
Per impostazione predefinita, WordPress mostra il titolo e le colonne della data per il tipo di post personalizzato, ma aggiungeremo altre tre colonne per la data di inizio dell'evento, la data di fine e la sede.
Possiamo controllare quali colonne aggiungere e quali nascondere con l'hook di WordPress manage_edit- $ post_columns dove $ postale è il nome del tipo di post personalizzato. La funzione di callback accetta un array per le colonne che sono già mostrate.
function uep_custom_columns_head ($ defaults) unset ($ defaults ['date']); $ defaults ['event_start_date'] = __ ('Data di inizio', 'uep'); $ defaults ['event_end_date'] = __ ('Data fine', 'uep'); $ defaults ['event_venue'] = __ ('Venue', 'uep'); restituisce $ defaults; add_filter ('manage_edit-event_columns', 'uep_custom_columns_head', 10); Nel codice precedente, abbiamo disinserito la colonna della data predefinita e, invece, abbiamo aggiunto le nostre tre colonne personalizzate.
Ma il contenuto delle rispettive colonne non verrà mostrato finché non lo definiremo usando il manage_ $ post_posts_custom_column hook dove $ post è il nome del tipo di post personalizzato.
function 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); data dell'eco ('F d, Y', $ start_date); if ('event_end_date' == $ column_name) $ end_date = get_post_meta ($ post_id, 'event-end-date', true); data di eco ('F d, Y', $ end_date); if ('event_venue' == $ column_name) $ venue = get_post_meta ($ post_id, 'event-venue', true); echo $ venue; add_action ('manage_event_posts_custom_column', 'uep_custom_columns_content', 10, 2); Per prima cosa abbiamo controllato la colonna che viene mostrata e quindi riecheggiamo il contenuto di conseguenza. L'ultimo parametro nel add_action () la funzione call è il numero di argomenti accettati dalla funzione di callback - nel nostro caso - è due.
In questo tutorial, abbiamo registrato con successo un tipo di messaggio personalizzato per gli eventi. Abbiamo anche imparato a includere un metabox personalizzato e un widget datepicker dell'interfaccia utente jQuery integrato nel dashboard di WordPress. Inoltre, per garantire all'utente maggiore accessibilità, abbiamo aggiunto colonne personalizzate nella nostra schermata di amministrazione post.
Mentre abbiamo quasi completato la dashboard, c'è ancora qualcosa da fare per noi: il front-end.
Nella prossima puntata della serie, creeremo un widget personalizzato per visualizzare l'elenco degli eventi imminenti nella barra laterale. Guarderemo il WP_Query classe più da vicino per recuperare i post in base ai loro meta-valori.
