Metodi di integrazione dei dati dei plug-in con i temi

Vorrei avere alcune opinioni sulle migliori pratiche per lo sviluppo di plugin WordPress che forniscono l'integrazione dei temi.

Per avere un senso quando faccio questa domanda, vorrei iniziare con un ipotetico esempio di uno scenario di cui sono curioso. Immagina di creare un plugin chiamato "Discografia". La discografia registra tre tipi di post personalizzati: "Bande", "Album" e "Tracce". Il plug-in fornisce anche meta-box che forniscono dettagli per ciascun tipo di post, nonché tassonomie personalizzate per organizzare ogni tipo di post. Questi tipi di post sono associati al plug-in Posts 2 Posts . All'interno dell'amministratore, l'utente può aggiungere nuove bande, che possono essere associate agli album, che a loro volta sono associati alle tracce, a cui saranno aggiunti molti altri dati tramite meta box e tassonomie.

Ora, non voglio che questo plugin configuri semplicemente un amministratore per consentire agli utenti di inserire queste informazioni; Vorrei che fornisse alcuni display predefiniti per i dati. Un utente / sviluppatore più avanzato starebbe bene solo con questo amministratore. Sarebbe abbastanza facile per lei prendere quei dati e usarli nel tema; tuttavia, senza alcune visualizzazioni predefinite, questo plug-in sarebbe inutile per la maggior parte degli utenti. Per questo esempio, potresti visualizzare qualcosa di simile (le parentesi mostrano il modo in cui le informazioni potrebbero essere visualizzate in ordine gerarchico dei modelli):

• Bande (single-prefix-band.php, single.php, index.php, shortcode)
• Album (single-prefix-album.php, single.php, index.php, shortcode)
• Tracce (single-prefix-track.php, single.php, index.php, shortcode)
• Elenco di bande (template-band-list.php, page-band-listing.php, page- {id} .php, page.php, index.php, shortcode)
• Elenco album (template-album-list.php, page-album-listing.php, page- {id} .php, page.php, index.php, shortcode)
• Cronologia album (template-album-timeline.php, page-album-timeline.php, page- {id} .php, page.php, index.php, shortcode)

È importante che ci sia una presentazione predefinita per questi tipi di post in quanto i file modello predefiniti non visualizzerebbero tutte le informazioni necessarie per ciascuno dei tipi di post. Ad esempio, il tema Twenty Eleven, per impostazione predefinita, mostrerebbe semplicemente il nome, le categorie, la descrizione e la data di pubblicazione di un album. Non molto utile per un album. Vorrei fornire un unico modello di post che includa la band, la data di uscita, l'etichetta discografica, le versioni degli album, i brani, ecc. Come sviluppatore di plugin ritengo che sarebbe importante fornirlo. So che il modello non funzionerebbe per ogni tema, ma ci dovrebbero essere alcuni valori predefiniti che possono essere ulteriormente integrati con il tema dell'utente.

Ancora una volta, sono curioso di sapere qual è il modo migliore per gestire questa situazione? Penso che potresti fare una delle seguenti cose.

Shortcodes

Gli shortcode potrebbero essere utilizzati come un modo molto flessibile e intuitivo per consentire ai non sviluppatori di aggiungere una band, album, tracce, elenchi di band, ecc. Ovunque nel sito. Sarebbe utile per presentare bande su pagine specifiche o creare pagine separate per ogni banda (non molto efficiente, ma alcuni utenti affrontano le cose in questo modo). Lo shortcode genererebbe HTML, che sarebbe legato a un file CSS fornito che fornirebbe una bella vista predefinita dei dati desiderati. Tutto sarebbe contenuto nei file dei plugin e nulla dovrebbe essere fatto con il tema.

File modello

Il plug-in potrebbe anche essere fornito con file modello. I file modello possono essere contrassegnati e disegnati per una bella vista predefinita. È possibile fornire istruzioni all'utente per spostare i file nella cartella del tema in modo che il tema trovi i modelli giusti quando vengono visualizzati i tipi di post. Potresti persino arrivare a fornire un'interfaccia per consentire all'utente di spostare i file con un solo clic (nota: non creerei i file nella cartella dei temi dell'utente all'attivazione perché l'aggiunta di file al loro tema senza che li inizino è male) .

Puoi anche usare i filtri per utilizzare questi file senza spostarli dalla cartella del plugin, mantenendo tutto autonomo. Ho visto i filtri "template_include" e "{$ type} _template" usati a questo scopo. In effetti, è possibile utilizzare i modelli dalla cartella dei temi e, se non sono presenti, è possibile ricorrere a questi filtri per fornire le visualizzazioni predefinite.

La domanda

Mi piace sapere quali altri pensano siano le migliori pratiche per queste situazioni, se le idee presentate sono problematiche in qualche modo e qualsiasi alternativa che non ho incluso.

Grazie!

Non posso rispondere ad ogni singola Q che hai chiesto, dato che leggere la Q ha impiegato abbastanza tempo finora;), ma provo a darti alcune idee sulla mia esperienza personale con lo sviluppo di plugin gratuiti e open source.

1. Non fare mai troppo. Le caratteristiche sono la morte di ogni plugin. Crea prima una versione base e testa la reazione dei tuoi utenti. Se il tuo plugin riceve molta attenzione, puoi integrare le funzionalità che sono maggiormente richieste.

2. Evitare di riempire tutti i casi d'uso. Devi mantenere il tuo plugin. WP offre una nuova versione ogni tre mesi. E a volte è difficile seguire tutti i tuoi plugin. Per fare un esempio: una nuova versione dell'API delle impostazioni è attualmente discussa su Trac. Quando questo sarà finito, allora c'è la possibilità che molti sviluppatori di plugin o temi debbano cambiare una grande porzione di codice e alcune persone - come me - hanno persino scritto un livello di astrazione sopra l'API. Quindi è necessario tornare indietro, riscrivere il livello base / astrazione e quindi rielaborare tutto ciò che chiama parti di quello. Prometto che questo è molto lavoro. E ancora di più se è strettamente legato al tuo codice. Quando inizi a compilare molti casi d'uso, hai anche avuto un sacco di evoluzione del codice core WP che devi monitorare, oltre a un sacco di lavoro per mantenere aggiornato il tuo codice.

3. Non tentare mai di raggruppare molti esempi di codice (o modelli) nei plugin o nei temi. Se desideri scegliere come target sviluppatori e utenti finali: utilizza il tuo blog per la documentazione. Gli sviluppatori odiano cose del genere e gli utenti finali non sono mai soddisfatti (vedi: compilare ogni caso d'uso).

4. Dividi saggiamente il codice in singoli file. Regola empirica: un file per una parte. Esempio: styles.php, scripts.php, taxonomies.php, cpts.php, ecc. Carica tutto da una classe "madre" (di fabbrica) e mantieni le tue cose "collegabili". Se hai bisogno di riscrivere le cose, le troverai facilmente. Se gli sviluppatori cercano qualcosa: lo troveranno facilmente. Un sacco di file ben nominati, non farti del male.

5. Se hai un elenco di stili di base (classi), lascialo all'utente . Le probabilità sono semplicemente troppo alte, che gli stili del tema o di altri plug-in intercettino le tue definizioni (non importa quanta specificità hai inserito). Prova a spiegarlo da qualche parte con meno testo possibile.

6. Adoro il tuo plugin. Ma lasciati andare se sei annoiato. :)

Ora - in poche parole - qualcosa sull'idea del tuo plugin in dettaglio:

A. I file modello sono danneggiati. Come ho detto: documentalo sul tuo blog, offri esempi di mark-up e stili lì. Il tuo blog trarrà profitto (e anche tu se hai pubblicità).

B. Gli shortcode sono kool. Non danneggiano nessuno se il plug-in è sparito (nella maggior parte dei casi) e potrebbe essere successivamente esteso / evoluto ai pulsanti TinyMCE (che la gente ama).

C. Rendi chiaro che il tuo plugin ha bisogno di un altro plugin. Fai una domanda e aggiungi una nota a admin_notices (tramite register_activation_hook) se l'altro plug-in non esce (collegalo in questo caso) o non è attivato (puoi farlo per l'utente all'attivazione). Si noti inoltre che questo plug-in proviene da una fonte attendibile e verrà mantenuto per i prossimi anni.

Nota: nulla di ciò che ho scritto è qualcosa di più della mia opinione personale, che riflette la mia esperienza.

Per alcuni aspetti devi valutare l'equilibrio tra la creazione di un plug-in o un tema, se il tuo scenario richiede molte personalizzazioni / funzionalità, di solito è sempre meglio creare un tema. In questo modo l'utente può quindi personalizzare in termini di aspetto, il che è sempre più semplice quindi indurre l'utente a personalizzare la funzionalità (bloccando gli shortcode ovunque), si ha un maggiore controllo delle funzionalità, funziona con altri plugin, ecc.

Un plugin che cerca di integrarsi pesantemente con tutta la varietà di temi sul mercato è destinato a causare molti problemi e onestamente molto lavoro per te.

Ad esempio invece di creare un plug-in molto integrato basato sulla gestione della musica e della discografia, invece creare un tema a tale scopo, questo sta diventando più popolare per i mercati di nicchia che richiedono un lavoro personalizzato. Un esempio del mondo reale sarebbe un tema basato sul settore immobiliare, non c'è modo in cui utilizzerei un plug-in per questo poiché ha un set di funzionalità così profondo, invece è creato da zero come tema, poiché i temi possono trarre vantaggio da tutte le funzionalità dei plugin comunque.

È anche probabile che dal punto di vista del marketing un tema di nicchia farà meglio di un plug-in quando si bilanciano le funzionalità front-end.

Pagine virtuali

Una terza tecnica che ho visto è stata l'assegnazione di una pagina speciale come segnaposto per il plug-in e l'utilizzo del filtro "the_content" per l'output di tutto ciò che è necessario per l'output.

In questo modo, è possibile creare modelli che si fondono con la struttura del tema, poiché non è necessario gestire intestazioni, barre laterali, piè di pagina e div wrapper.

Un ottimo esempio di questo può essere trovato nel plugin bbPress:

http://bbpress.trac.wordpress.org/browser/branches/plugin/bbp-includes/bbp-core-compatibility.php?rev=3434#L931