Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. WordPress
Code

Programmare ad Oggetti con WordPress : Costruire il Plugin II

by
Difficulty:BeginnerLength:MediumLanguages:
This post is part of a series called Object-Oriented Programming in WordPress.
Object-Oriented Programming in WordPress: Building the Plugin I
Object-Oriented Programming in WordPress: Document the Plugin I

Italian (Italiano) translation by Piergiorgio Sansone (you can also view the original English article)

Nell'articolo precedente di questa serie, finalmente abbiamo iniziato a preparere le fondamenta del plugin che scriveremo.

In particolare , abbiamo visto l'organizzazione dei files , i componenti ed in dettaglio quello che il plugin dovrà fare. Abbiamo anche generato automaticamente il codice che produrremo in questo tutorial.

Inoltre affinchè il nostro plugin faccia effettivamente qualcosa, realizzandolo, parleremo di un gran numero di principi, tecniche ed idee sulla programmazione ad oggetti.

Nota che in questo tutorial realizzeremo una piccola documentazione. Ne abbiamo fornito i dettagli negli articoli precedenti; tuttavia ne parleremo ancora negli articoli che seguiranno.

Come per gli altri articoli di questa serie, vi prego di avere ben chiari i concetti visti negli articoli precedenti, perchè quanto vedremo successivamente si basa proprio su questi.

Gli argomenti trattati a cui potete far riferimento sono:

  1. L'introduzione
  2. Le Classi
  3. I Types
  4. Le Strutture di Controllo : Istruzioni Condizionali
  5. Le Strutture di Controllo : I Cicli
  6. Funzioni ed Attributi
  7. L'Ambito di applicazione (scopo)
  8. Costruire il Plugin I

Detto questo, riprendiamo da dove abbiamo lasciato.

Da dove cominciamo?

Quando arriva il momento di scrivere il software,indipendentemente dal paradigma utilizzato, non viene fatto in modo lineare. Cioè, non necessariamente iniziamo scrivendo il codice partendo dall'inizio del programma. Spesso, ma non sempre potrebbe essere giusto una delle ultime parti che realizziamo.

Detto ciò, incominciamo a lavorare su ogni file che compone il plugin in modo che prenda forma man mano che progrediamo nello sviluppo. Con ciò , voglio dire che andando avanti con questo articolo, le cose potrebbero sembrare in un primo momento confuse, ma spero diventino un po' più chiare guardando ogni file.

Il Caricatore

La prima classe che completeremo si trova nella directory includes/class-single-post-meta-manager-loader.php Se facciamo un passo indietro all'articolo precedente, questa classe è responsabile del coordinamento delle azioni ed i filtri con il cuore del plugin e la classe di amministrazione

In un certo senso, fornisce una copertura intorno all'hook nativo delle API di WordPress; però, consente di disaccoppiare (e quindi applicare una separazione delle preoccupazioni) le nostre classi così che ognuno possa specializzarsi su uno scopo specifico.

Primo, diamo un'occhiata alla classe :

A questo punto della serie, in base delle discussioni che abbiamo avuto finora dovresti aver notato alcuni elementi chiave della classe.

  • Ci sono due attribuzioni proteceted , ogniuna delle quali fa riferimento ad un array come definito nel costruttore. Una è destinata alle azioni e l'altra per i filtri.
  • Ci sono due funzioni public. Una è designata per facilitare l'aggiunta di un'azione e l'altra per facilitare l'aggiunta di filtri. Nota che ogniuna accetta tre componenti: il nome dell'hook , l'oggetto principale che viene richiamato dalla funzione , e la funzione da chiamare durante l'esecuzione dell'hook. Per maggiori informazioni circa azioni e filtri , guarda questo riferimento.
  • Successivamente, abbiamo una funzione private che viene utilizzata per semplificare le precedenti due funzioni public, in modo tale da avere un posto solo per aggiungere l'hook all'array appropriato.
  • Infine, abbiamo una funzione run utilizzata per cambiare tutti gli hooks definiti. Questo è quello che registrerà tutte le nostre funzioni personalizzate con WordPress.

Mentre continuiamo a costruire il resto del plugnin , vedremo questa classe particolare in uso.

Il Pannello di amministrazione

Questa parte del plugin contiene tutti i files posizionati nella directory admin Se ricordi, dal precedente articolo, per la visualizzazione del contenuto si utilizzano una classe principale , un foglio di stile , e un singolo file.

Vedremo ogniuno di questi file nell'ordine in cui vengono utilizzati partendo dalla classe principale admin.

Single Post Meta Manager Admin

Questa è la classe principale responsabile della registrazione dei fogli di stile , del meta box ed include il file che consente la visualizzazione del contenuto del meta box.

Diamo un'occhiata a tutto il codice e poi faremo la recensione di che cosa fa.

Questa è una classe relativamente semplice, presuppone che si abbia familiarità con wp_enqueue_style and add_mete_box . in caso contrario, riguardate gli articoli collegati e poi tornate a questo post.

Successivamente, date un'occhiata a cosa fa il resto della classe:

  • Notate che c'è un attributo definito private che viene utilizzato per tracciare la versione del plugin. Questo valore passa nella classe del costruttore e viene utilizzato per primo, per assicurarci di includere la versione più recente del plugin quando si richiamano i fogli di stile ed assicurarci di aprire qualsiasi file memorizzato nella chace quando gira il plugin.
  • Dopo, abbiamo una funzione public, utilizzata per registrare il foglio di stile associato al pannello ed abbiamo una funzione public utilizzata per aggiungere il meta box al Post Type Pannello.
  • Infine, esiste un'altra funzione public(che tecnicamente viene richiamata dall'interno della stessa classe) per visualizzare il contenuto del meta box. Il contenuto di questo file è posizionato in un file esterno che vedremo a breve.

Anche se vedremo tutto nel dettaglio più tardi, puoi notare che la funzione che richiama i fogli di stile, non viene riferita a nessun altro luogo. E'qui dove la classe Loader eventualmte entra in gioco.

Singolo Post Meta Manager parziale

Molti sviluppatori amano scrivere il markup delle viste dei meta box con PHP e memorizzarlo in una lunga stringa.

Io non sono un fan di questo approccio, perché le viste (o parziali o modelli, o qualsivoglia li chiami ) sono generalmente utilizzate per visualizzare i dati sono composte da più di un markup, di ogni altra cosa. A tal fine, penso che dovrebbero essere i propri file.

In questo caso , vogliamo avere un file che visualizzi tutti i meta data associati con il post in uso , in un elemento di tabella all'intenro del meta box.

Il markup per questo file è simile al seguente:

Anche se il markup ed il minimo di codice PHP contenuto in questo file dovrebbe essere relativamente auto-esplicativo, ma questo dipende dalla vostra conoscenza delle funzioni get_post_meta e get_the_ID.

Una volta recuperati tutti meta-data del post, dobbimo scorre le informazioni (utilizzando uno dei loop costruiti, che abbiamo visto molto prima) e quindi visualizzare sia la chiave meta che in valore.

Gli stili di un semplice Post Meta Admin

L'ultima cosa che bisogna fare per il contenuto nel meta box è qualla di fornire gli stili del foglio di stile che abbiamo accodato nella classe principale di amministrazione.

Per fare ciò, modificheremo il file css/simple-post-meta-manager.css.

Ovviamente, è molto semplice. Non fornisce nulla di particolare oltre l'impostazione della larghezza della tabella al 100% del suo contenitore ed il grassetto per i valori delle meta chiavi.

Ma questo è sufficente per quello che faremo.

Il Nucleo del Plugin

A questo punto , dobbiamo definire il nucleo del plugin. Questo è il file che definisce la versione del plugin, gli slug del plugin (che viene normalmente utilizzato per la internazionalizzazione, cosi come di altre caratteristiche), istanzia il Loader e registra tutti gli hooks necessari a WordPress.

Diamo un' occhiata al codice, quindi lo rivedremo una volta che abbiamo tutto definito:

La classe contiene i seguenti attributi:

  • La versione indicata del plugin, non solo definisce la versione del lavoro corrente, ma fornisce anche funzionalità come la chace-busting del nostro foglio di stile.
  • Esiste uno slug del plugin, che può essere utilizzato per scopi di internazionalizzazione, cosi come è necessario altre volte quando c'è bisogno di un identificatore univoco. 
  • Un riferimento al caricatore (Loader) che abbiamo definito prima in questo file.

Tutti gli attributi sopra citati sono tutti impostati nel costruttore, ma ci sono anche chiamate a diverse altre funzioni.

  • load_dependencies viene utilizzata per importare tutti i file che vengono utilizzati in tutto questo plugin come il Manager di Admin e il caricatore (Loader).
  • define_admin_hooks è la funzione con cui approfittiamo del caricatore al fine di coordinare le funzioni definite nella nostra Classe Admin a cui accodano i nostri stili e nostri meta box con WordPress. Questo è il modo in cui stiamo separando le preoccupazioni dei nostri plugin e ci assicuriamo che ogni classe abbia un unico scopo.
  • Run è la funzione che imposta tutto in movimento in modo che tutte le funzionalità del plugin siano eseguite quando viene attivato all'interno di WordPress.

Tranne per il fatto ci manca ancora un pezzo finale: come facciamo in realtà ad instanziare la classe Core del plugin e avviare il processo?

Il Boot Loader del plugin

Per fare questo , utilizziamo un file posizionato nella cartella di root del plugin . Molte persone chiamano questo plugin file di ripartenza (bootstrap plugin) ed altre lo chiamano plugin principale.

In qualsiasi modo tu voglia chiamarlo , questo è il file che si registra in WordPress e configura tutto in moto. Diamo un'occhiata al codice e quindi esamineremo che cosa fa in seguito:

Il commento al codice all'inizio del file, serve ad indicare a WordPress che il plugin esiste e fornisce anche sufficenti informazioni circa il plugin che sono visualizzate all'interno del Pannello.

La prima struttura condizionale che vedete previene dall'accesso diretto il file del plugin. Questa non è altro che una semplice misura di sicurezza.

Infine, faremo una call alla funzione require_once per includere il core plugin file che abbiamo visto sopra, e poi definiremo una funzione che istanzierà il Single_Post_Meta_Manager e dopo quello che chiamiamo run che è ciò che mette in moto tutto.

Infine, eseguiremo una call alla funzione che abbiamo definito alla fine del file. Questo avvierà il processo e darà vita al plugin.

Di cosa parleremo dopo ?

A questo punto abbiamo completato le funzionalità del nostro plugin, tuttavia non abbiamo ancora finito. C'è ancora un'altra cosa che dobbiamo fare per essere sicuri di seguire tutte le best practice che vanno nel plugin e che sta fornendo la documentazione.

Nel prossimo post, faremo una pausa dall'articolo dalla forma più lunga, con la scrittura di codice, rivedremo gli standard di documentazione di WordPress, e quindi documenteremo tutte funzionalità del plugin a tutto tondo.

Nel frattempo, Scarica il plugin di esempio, guardate come tutto si combina e assicuratevi di lasciare eventuali commenti o domande che avete finora sul nostro lavoro.

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.