Dibattiti sui tipi di post personalizzati di WordPress - Functions.php o Plugin?

Dibattiti sui tipi di post personalizzati di WordPress - Functions.php o Plugin? / Opinione

Come molti di voi sanno, la scorsa settimana Syed Balkhi ha partecipato a WordCamp Raleigh 2012. Durante l'evento, uno dei suoi tweets ha scatenato un bel dibattito. In questo articolo, il nostro fondatore Syed Balkhi discuterà se i tipi di post personalizzati di WordPress appartengano al file functions.php o ai plugin. Di seguito un tweet che ha dato il via a questo dibattito:

Non aggiungere Post Tipi personalizzati in functions.php -> Dovresti SEMPRE usare un plugin specifico per il sito - wpbeg.in/vcXr7j #wcraleigh

- WordPress Beginner (@wpbeginner) 4 novembre 2012

Dopo il tweet, ci sono state molte persone rispettabili nella comunità di WordPress. Puoi vedere la conversazione completa qui. Curtis McHale ha fatto un ulteriore passo avanti e ha elaborato l'argomento nel suo nuovo post sul blog.

La conversazione di Twitter ha sollevato alcuni punti importanti.

Riepilogo degli argomenti

Argomento Plugin: L'utente avrà sempre i dati anche se cambiano il tema. Potrebbe non sembrare carino, ma rimarrà lì.

Argomento di Functions.php: I dati senza design sarebbero irrilevanti. Confonderà gli utenti ancora di più.

Da che parte siete più d'accordo? Chiaramente entrambe le parti hanno i loro problemi, ma qual è il minore dei due mali?

Ecco perché crediamo che i tipi di messaggi personalizzati dovrebbero SEMPRE vivere in un plug-in specifico del sito o un plugin separato del tutto.

Long Live Data

I tipi di messaggi personalizzati sono dati. Nella maggior parte dei casi, i tuoi dati sopravviveranno al design attuale. Avendo cambiato i nostri temi alcune volte, comprendiamo chiaramente questa affermazione. Post, pagine, collegamenti, allegati e revisioni sono tutti i tipi di post che vengono integrati con WordPress. Inoltre, abbiamo tipi di post come Libri, Testimonianze, Offerte, ecc. Ora potresti immaginare se cambiamo un tema e facciamo svanire tutti questi? Sicuramente, non vorremmo che succedesse.

Avere sviluppatori nel nostro team, questo non dovrebbe importare molto. Considerando che tutti i nostri temi sono personalizzati dal nostro team, che differenza fa davvero? Il segreto sta in due parole: tempo e centralizzazione. Finché avremo tutti i dati necessari, tutto ciò che dovremmo fare in futuro è cambiare lo stile. Non dovremo preoccuparci di copiare e incollare le funzioni da un file all'altro ogni volta. Cosa succede se si desidera replicare la funzionalità? Basta prendere il plugin e rilasciarlo nel tuo nuovo sito. Cambia lo stile e hai finito.

Regole e standard

Quando usi SEMPRE la parola come abbiamo fatto nel nostro tweet, può significare sia regole che standard. Entrambe le regole e gli standard sono fatti per la maggioranza. Ci saranno sempre scenari di casi speciali in cui le regole sono piegate e gli standard sono infranti, ma ciò non significa che dovremmo eliminare del tutto gli standard.

Esistono tonnellate di tipi di post generici che richiedono principalmente la stessa serie di metadati aggiuntivi. Alcuni esempi che vengono in mente sono: citazioni, libri, ricette, testimonianze, portfolio, ecc.

Considerando l'elevato numero di temi fotografici e di portfolio disponibili nel mercato libero e commerciale, non ha quasi senso fare in modo che l'utente reinserisca tutte le informazioni del tipo di post personalizzato ogni volta che cambia un tema. Diamo un'occhiata a uno scenario di esempio:

Fotografo - L'utente installa un WordPress con funzionalità di blog (CPT "post" predefinito). Vuole aggiungere un portfolio del suo lavoro (richiede un CPT del portfolio). Vuole mostrare testimonianze dei clienti (richiede un CPT Testimonial). Tutte queste informazioni andranno sicuramente al di là del tema del design. Un anno dopo, l'utente desidera modificare l'aspetto del suo sito e aggiornarlo. Trova un nuovo tema che ha tutte le funzioni simili. Nel momento in cui cambia tema, BOOM. Tutti i dati precedenti che ha inserito sono svaniti. C'è un menu chiamato Portfolio e un menu chiamato Testimonials, ma nessuno dei dati è lì. L'utente pensa "HOLY CRAP, ho perso tutto il mio contenuto". Crea una nuova domanda di supporto nel forum. Invia e-mail a siti come WPBeginner ecc. Se non ricevono una buona risposta, dovranno reinserire tutti i dati. Questa è un'esperienza utente schifosa.

Quindi, come risolviamo questo problema?

Possibile soluzione?

Creiamo una nuova base standard. Justin Tadlock ha già iniziato a lavorare su questo problema un po 'indietro creando un plug-in di base portfolio. Sarà la soluzione perfetta per tutti? NO, ma sarà per la maggioranza.

Come Justin chiede nel suo post, quali campi standard dovrebbero essere inclusi nel plugin del portfolio (facendo riferimento a post meta). Questo tipo di conversazione deve avvenire tra gli sviluppatori che creano funzionalità simili nei loro temi. Perché copiare e incollare la stessa cosa più volte da un tema all'altro quando può essere eseguita tramite un plug-in? Una volta che diventa uno standard, altri autori di temi inizieranno ad adattarsi ad esso.

Ad esempio, stiamo assistendo ad un aumento del supporto di stile per Gravity Forms in framework di temi WordPress come Genesis e altri. Perché? Perché capiscono che i loro utenti lo stanno usando.

Ci sono alcuni temi robusti WordPress che vengono caricati con funzionalità che crediamo dovrebbero essere plug-in. Temi di Bacheca di lavoro, Temi di monitoraggio dei problemi, Temi di annunci classificati, Temi immobiliari, ecc. Dovrebbero essere tutti alimentati da un plug-in di base. Sta già accadendo con WooCommerce. WooThemes ha rilasciato numerosi temi che hanno il supporto dello stile incorporato per il plugin. Altre aziende tematiche hanno promesso di pubblicare anche temi di eCommerce basati su WooCommerce. Puoi passare da un tema a un altro e conservare tutti i tuoi prodotti così come sono. È quasi come se il tema fosse cambiato, ma tutto è andato a posto. Questo è il tema che cambia esperienza a cui dobbiamo mirare.

Perché non fare la stessa cosa con Portfolio, Testimonianze e altri tipi di post personalizzati generici? È perché è troppo semplice contro eCommerce è una bestia più grande da conquistare? Chiaramente, l'e-commerce ha troppi campi rispetto agli altri, quindi dovrebbe essere molto più facile per questi tipi di post generici. Si tratta solo di fare uno sforzo consapevole per migliorare le cose.

Dai un'occhiata al plugin ReciPress. Crea un metabox personalizzato con campi di ricette e lo allega con i post. Tuttavia è possibile allegarlo con tipi di post personalizzati. Chiunque usi questo plugin può cambiare i temi senza dover passare attraverso una tale seccatura.

Sarebbe bello vedere temi come AgentPress essere alimentati da un plug-in di base centralizzato. Sarebbe bello vedere la transizione di cambiare temi diventare più facile. Ad esempio, se un utente passa da un tema di fotografia a un altro, non dovrebbe essere il caos. Potrebbero verificarsi errori minori, ma almeno nel quadro generale, le cose funzioneranno.

Puoi sempre fornire esempi di tipi di post super personalizzati creati per l'utilizzo occasionale dei client, ma questa è l'eccezione, non la regola.

Cosa ne pensate di questo argomento? Dove dovrebbe risiedere il codice dei tipi di post personalizzati? Nel file functions.php o nei plugin?