Come molti di voi sapranno, la scorsa settimana Syed Balkhi ha partecipato a WordCamp Raleigh 2012. Durante l'evento, uno dei suoi tweet ha acceso un bel dibattito. In questo articolo, il nostro fondatore Syed Balkhi discuterà se i tipi di post personalizzati di WordPress debbano risiedere nel file functions.php o nei plugin. Di seguito un tweet che ha dato inizio a questo dibattito:
Non aggiungere tipi di post personalizzati in functions.php -> Dovresti SEMPRE usare un plugin specifico per il sito - http://t.co/bebYXq2F #wcraleigh
— WordPress Beginner (@wpbeginner) 4 novembre 2012
Dopo il tweet, molte persone autorevoli nella community di WordPress sono intervenute. Puoi vedere la conversazione completa qui. Curtis McHale ha fatto un passo avanti e ha approfondito l'argomento nel suo nuovo post sul blog.
La conversazione da Twitter ha sollevato alcuni ottimi punti.
Riepilogo degli argomenti
Argomento plugin: L'utente avrà sempre i dati anche se cambia tema. Potrebbe non apparire altrettanto bello, ma rimarrà lì.
Argomento Functions.php: I dati senza design sarebbero irrilevanti. Confonderebbero ancora di più gli utenti.
Con quale lato sei più d'accordo? Chiaramente entrambe le parti hanno i loro problemi, ma quale è il minore dei due mali?
Ecco perché crediamo che i tipi di post personalizzati debbano SEMPRE risiedere in un plugin specifico per il sito o in un plugin separato.
Lunga vita ai dati
I tipi di post personalizzati sono dati. Nella maggior parte dei casi, i tuoi dati sopravvivranno al design attuale. Avendo cambiato i nostri temi alcune volte, comprendiamo chiaramente questa affermazione. Post, Pagine, Link, Allegati e Revisioni sono tutti tipi di post integrati in WordPress. Oltre a questi, abbiamo tipi di post come Libri, Testimonianze, Offerte, ecc. Ora potresti immaginare se cambiassimo un tema e tutto questo sparisse? Sicuramente, non vorremmo che accadesse.
Avendo sviluppatori nel nostro team, questo non dovrebbe fare molta differenza. Considerando che tutti i nostri temi sono progettati su misura 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 dovremo fare in futuro sarà cambiare lo stile. Non dovremo preoccuparci di copiare e incollare le funzioni da un file all'altro ogni singola volta. E se volessi replicare la funzionalità? Semplicemente prendi il plugin e inseriscilo nel tuo nuovo sito. Cambia lo stile e hai finito.
Regole e Standard
Quando usi la parola SEMPRE come abbiamo fatto nel nostro tweet, può significare sia regola che standard. Sia le regole che gli standard sono fatti per la maggioranza. Ci saranno sempre scenari di casi speciali in cui le regole vengono piegate e gli standard vengono infranti, ma ciò non significa che dovremmo eliminare del tutto gli standard.
Ci sono tonnellate di tipi di post generici che richiedono per lo più lo stesso set di campi meta aggiuntivi. Alcuni esempi che vengono in mente sarebbero: Citazioni, Libri, Ricette, Testimonianze, Portfolio, ecc.
Considerando l'elevato numero di temi per fotografia e portfolio disponibili sul mercato, sia gratuiti che a pagamento, non ha quasi senso far sì che l'utente reinserisca tutte le informazioni dei propri custom post type ogni volta che cambia tema. Diamo un'occhiata a uno scenario di esempio:
Fotografo – L'utente ha configurato un WordPress con funzionalità blog (CPT predefinito “post”). Vuole aggiungere un portfolio dei suoi lavori (richiede un CPT Portfolio). Vuole mostrare testimonianze dei clienti (richiede un CPT Testimonial). Tutte queste informazioni sicuramente sopravvivranno a un cambio di tema. Un anno dopo, l'utente vuole cambiare l'aspetto del suo sito e dargli una rinfrescata. Trova un nuovo tema con tutte le funzioni simili. Nel momento in cui cambia tema, BOOM. Tutti i dati inseriti in precedenza sono scomparsi. C'è un menu chiamato Portfolio e un menu chiamato Testimonial, ma nessun dato è presente. L'utente pensa “SANTO CIELO, ho perso tutto il mio contenuto”. Crea una nuova domanda di supporto nel forum. Invia email a siti come WPBeginner ecc. Se non riceve una buona risposta, dovrà reinserire tutti i dati. Questa è una pessima esperienza utente.
Come risolviamo questo problema?
Soluzione possibile?
Creiamo una nuova base standard. Justin Tadlock ha già iniziato a lavorare su questo problema un po' di tempo fa creando un plugin base per portfolio. Sarà la soluzione perfetta per tutti? NO, ma lo sarà per la maggior parte.
Come chiede Justin nel suo post, quali campi standard dovrebbero essere inclusi nel plugin per portfolio (riferendosi ai meta post). Questo tipo di conversazione deve avvenire tra gli sviluppatori che creano funzionalità simili nei loro temi. Perché copiare e incollare la stessa cosa più e più volte da un tema all'altro quando può essere fatto tramite un plugin? Una volta che diventerà uno standard, altri autori di temi inizieranno ad adattarsi.
Ad esempio, stiamo vedendo un aumento del supporto stilistico per Gravity Forms nei framework di temi WordPress come Genesis e altri. Perché? Perché capiscono che i loro utenti lo stanno utilizzando.
Ci sono alcuni temi WordPress robusti che vengono caricati con funzionalità che riteniamo dovrebbero essere plugin. Temi per bacheche di lavoro, temi per il tracciamento dei problemi, temi per annunci classificati, temi immobiliari, ecc. Dovrebbero essere tutti alimentati da un plugin di base. Sta già accadendo con WooCommerce. WooThemes ha rilasciato numerosi temi che hanno un supporto di stile integrato per il plugin. Altre aziende di temi hanno promesso di rilasciare anche temi per e-commerce basati su WooCommerce. Puoi passare da un tema all'altro e mantenere tutti i tuoi prodotti così come sono. È quasi come se il tema fosse cambiato ma tutto fosse andato al posto giusto. Questa è l'esperienza di cambio tema per cui dobbiamo sforzarci.
Perché non fare la stessa cosa con Portfolio, Testimonianze e altri tipi di post personalizzati generici? È perché è troppo semplice rispetto all'e-commerce, che è 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 una metabox personalizzata con campi per ricette e la collega ai post. Tuttavia, è possibile collegarla a tipi di post personalizzati. Chiunque utilizzi questo plugin può cambiare tema senza dover affrontare un tale problema.
Sarebbe bello vedere temi come AgentPress essere alimentati da un plugin di base centralizzato. Sarebbe fantastico vedere la transizione del cambio tema diventare più facile. Ad esempio, se un utente passa da un tema fotografico a un altro, non dovrebbe essere il caos. Potrebbero verificarsi piccoli errori, ma almeno nel quadro generale, le cose funzioneranno.
Puoi sempre fornire esempi di tipi di post super personalizzati creati per l'uso da parte di un singolo cliente, 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?
Yazmin
Having been on the end of losing my CPTs numerous times as I switched themes, I find it frustrating to have to set up the same functionality over and over again in functions.php.
I completely prefer the plugin route and that is the method I will be using from here on out for my business projects as well.
Joshua Jarvis
Having this exact issue with a real estate theme. The “listings” were all custom types in a theme that is now functionally obsolete. When I went to upgrade the theme I lost all the custom post content, now I have to figure out a way to transfer it all. I have options, but if it were plugin, this wouldn’t be necessary.
Staff editoriale
Extremely sorry about your inconvenience. This is why we wrote this post because we know that it really makes the end-user’s life harder.
Amministratore
Hugh H. Sands
“Non dovremo preoccuparci di copiare e incollare le funzioni da un file all'altro ogni singola volta.”
Non riesco a immaginare qualcuno che scriva codice per un CPT in functions.php quando è così facile isolarlo con gli include
Questo dibattito ruota per la maggior parte del tempo attorno a dati vs design e mi chiedo, essendo abbastanza nuovo a WP, che dire delle prestazioni? I plugin impongono un sovraccarico?
Staff editoriale
Questo articolo dovrebbe rispondere alla tua domanda sui plugin e sulle prestazioni:
https://www.wpbeginner.com/opinion/how-many-wordpress-plugins-should-you-install-on-your-site/
Amministratore
Hugh Sands
Grazie per il link, davvero utile!
Kelvin Alfonso
Ho sempre incluso i CPT tramite un file separato in functions.php, ma penso che passerò alla soluzione dei plugin. Grazie!
Sudhakar
Sono un principiante e non ho alcuna competenza per commentare a favore o contro un plugin o functions.php. Ma mi chiedo se voglio seguire la strada di functions.php e farlo sotto un tema figlio, qual è il problema allora? Perché devo averlo in un plugin, il mio tema figlio non mi salverebbe dai futuri aggiornamenti e modifiche dei temi?
Staff editoriale
Il tuo tema figlio ti salverebbe dagli aggiornamenti futuri del tema. Tuttavia, NON ti salverebbe se cambi tema. Perché cambi il tema figlio se cambi il tema attivo.
Amministratore
Pat Ramsey
Sono un sostenitore della soluzione tramite plugin per i tipi di post personalizzati e le tassonomie. La menzione dell'autore di un plugin specifico per il sito è come lo faccio io. Colloco tutti i tipi di post personalizzati, le tassonomie personalizzate e le metabox in questo plugin, adattato allo scopo del sito. Alla fine il tema del sito cambierà, ma i dati rimangono e sono ancora facilmente accessibili.
shawn
Se gli sviluppatori continuano a ignorare il fatto che separare i "dati" dal "design" è necessario per creare applicazioni modulari, e non importa dove siano collocati i dati, il riutilizzo di quei dati / codice sarà sempre un problema.
Sembra esserci la percezione da parte di alcuni nella community di WP, per un motivo o per l'altro, che si possa accedere ai dati nell'ecosistema WordPress solo se sono racchiusi in un plugin, quindi continuiamo a vedere discussioni come questa che contribuiscono a “La grande diatriba plugin vs tema”.
L'attenzione deve essere posta sull'evoluzione dell'arcaico sistema di plugin di WordPress, sulla creazione di librerie basate su modelli di progettazione modulari che separano codice/dati dal design. Librerie che possono essere utilizzate sia nei temi che nei plugin...
Dibattiti come questi sono inutili nell'era post PHP4 di WP!!! (ri-pubblicato)
Mark Simchock
Re: “Come chiede Justin nel suo post, quali campi standard dovrebbero essere inclusi nel plugin portfolio (riferendosi ai meta post). Questo tipo di conversazione deve avvenire tra gli sviluppatori che creano funzionalità simili nei loro temi.”
Io? Preferirei un plugin ben documentato e ingegnerizzato per essere migliorato piuttosto che un approccio “chiuso”, universale e difficile da usare (quel codice).
Il mio punto è, forse è possibile dire: “Non sto cercando di essere tutto per tutti. Ecco il mio plugin di base. Ecco come puoi personalizzarlo. È progettato per essere personalizzato.” e basta. Non importa cosa fai, è difficile anticipare ogni caso d'uso, ogni esigenza d'uso. Allora perché preoccuparsi? Perché non affrontarlo come un framework (in un certo senso) e lasciare che lo sviluppatore che ne ha bisogno lo personalizzi secondo necessità?
Justin Tadlock
Questo è in realtà il piano. Sto costruendo una base estremamente piccola e facilmente personalizzabile. Ma vorrei sapere quali campi, se ce ne sono, dovrebbero essere standard.
Kevin Maines
Errore di battitura?:
“Considerando che tutti i nostri team sono progettati su misura dal nostro team”
Staff editoriale
Fixed it. Thanks for catching that
Amministratore
Affan Ruslan
Credo che dovrebbe essere su un plugin.
Nel caso in cui l'utente non abbia bisogno dei dati in futuro, può sempre convertire il post di tipo personalizzato nel tipo di post "normale". Esistono plugin per farlo, cerca nel repository e ne troverai almeno uno.
Christophe Debruel
Non mi interessa davvero quello che dice la gente. Il custom post type va in un plugin. Un tema può essere facilmente modificato per adattarsi al custom post type nel frontend. Trovo più logico stilizzare il tema per il CTP piuttosto che avere temi diversi con lo stesso codice CTP.
Ingo
"Pods Framework" potrebbe essere anche una buona soluzione tramite plugin. Per CPT, CT e CF.
http://wordpress.org/extend/plugins/pods/
Staff editoriale
Sì, Pods è fantastico.
Amministratore
Elliott Richmond
Plugin per me. Almeno per un cliente non tecnico, anche se il tema potrebbe non funzionare correttamente, diventerà evidente che c'è un problema e questo li spingerà a coinvolgere uno sviluppatore.
Kailas Mahajan
Dipende tutto dal progetto...
Se si sta gestendo un progetto che necessita di cambiare tema dopo un certo periodo di tempo... si può usare un plugin.
o se il progetto rimane con lo stesso tema... si può usare function.php
Ross W
Tutti parlano di come i dati debbano essere stilizzati dal tema, e di esempi in cui è così e dove i dati e il tema possono essere separati.
Quello che non vedo è qualcuno che parli di casi in cui un tema dipende dalla disponibilità di dati specifici. Diciamo che hai un tema che ha una mappa di paesi e alcuni dati specifici per paese, e che, senza quella mappa e quei dati, il tema perde parte della sua funzionalità chiave.
Sì, potresti ancora farlo con i dati in un plugin, ma è ragionevole che un tema presupponga che esistano alcuni dati? È ragionevole presupporre che il plugin che crea i tipi di dati sia installato e abilitato? (Domande genuine... discutiamone!)
E se il mio cliente, leggermente non tecnico, volesse creare una copia del sito con il suo 'tema'. Abilita il tema su una nuova installazione di WordPress solo per scoprire che un sacco di cose mancano o sono rotte? Pensava che il tema contenesse tutto ciò di cui aveva bisogno affinché il suo sito avesse un aspetto corretto?
Vedo utilizzi per entrambi gli approcci. Per la maggior parte del mio lavoro con i clienti, imposto CPT, meta-box e alcune funzioni per semplificare l'accesso ad essi, in file di libreria e li includo. Questo mantiene tutto il 'materiale' di cui il mio tema ha bisogno per funzionare in un unico pacchetto, ma mantiene semplice spostare i CPT in un nuovo tema, se lo desidero.
Certo, se un CPT sembra che possa essere utilizzato in più temi e non sia così specifico da applicarsi solo ai dati di un singolo cliente, allora lo trasformi in un plugin che può essere distribuito a piacimento.
Non credo che esista una relazione semplice e univoca tra dati e temi. Non è sempre vero che 'ho dei dati che necessitano di stile'... a volte 'il mio stile necessita di dati'.
Pensieri a riguardo?
Andres Hermosilla
Concordo assolutamente sul fatto che avere un pacchetto "completo" sia vantaggioso. Spesso ci sono funzionalità molto specifiche del tema che è meglio integrare direttamente (ad esempio P2 di Auttomatic) rispetto a un tema installato e un plugin per il tema.
Konstantin Kovshenin
Plugin. Punto.
Curtis McHale
Il tuo riferimento ad AgentPress è uno dei motivi per cui sono al 100% a favore dei CPT nei plugin. Ho dovuto affrontare temi come quello ed è così difficile personalizzarli correttamente a meno che tu non rimuova la funzionalità personalizzata dal tema. Il mio cliente ed io abbiamo passato 20 ore a portare il codice a un punto in cui potessimo effettivamente lavorarci.
Birgit
la mia migliore e preferita soluzione raccomandata è il flessibilissimo TOOLBOX: http://wordpress.org/extend/plugins/toolbox/
Staff editoriale
Ottima idea. Vorrei poter capire cosa mostrava lo screenshot senza scaricare il plugin.
-Syed
Amministratore
Birgit
The plugin is a “toolbox” for code snippets, that you do normally in your functions.php.
But with a theme update, custom code in the theme’s function.php might get lost.
So I use within my network installation this plugin, activated it network-wide and then the plugin comes with “modules”, that you can access for example by FTP.
You can create modules as much as you like – I have one for each of my blogs within this network. In this modules (= just .php files, let’s say just like site-specific plugins) you can add all the code, that you normally put in your theme’s function.php.
Then at the options page of the plugin you can activate in each blog, which module you would like to load and whether to load it only for frontend or only for backend or for both.
So I only need to have 1 plugin to serve all blogs with individual code snippets, that normally go to their functions.php – and can decide, where to load these modules.
uff, hope this is understandable, because my English is not the best
Forse questo ti aiuterà a leggerlo: http://tinyurl.com/bf5dflt
Staff editoriale
Brigit, I did translate the WP.org page as well. I understood what the plugin was intended for. However the screenshots were in German, and google is not smart enough to translate images just yet. Same issue is with the link you posted
Sara
Preferisco sempre i plugin a functions.php per qualsiasi cosa che potrebbe materialmente "rompere" il front-end o perdere dati se il tema venisse cambiato. Questo è precisamente per i motivi che citi, e sento anche che è folle per quelli di noi che non sono veri programmatori PHP cercare di risolvere conflitti quando devi commentare parti di functions.php per isolare un problema.
matt
ok, quindi quale plugin cpt consigli?
Staff editoriale
L'idea è che dovresti registrare i CPT in un plugin specifico per il sito. Non esiste ancora un plugin specifico. Ma questa è solo un'idea per creare un plugin di base per tipi di post generici.
Amministratore
Muhammad Waqas
Sono più convinto dell'uso di funzioni locali. ma in questo caso penso che i plugin possano essere più affidabili. Ad esempio, se inizi a usare wp con un framework specifico. Nella maggior parte dei casi è possibile che diventerai uno schiavo per molto tempo a meno che tu non assuma un professionista wp per aiutarti a sfuggire a quel framework senza perdere le tue impostazioni e i tuoi dati. D'altra parte, i plugin possono funzionare con quasi tutti i temi.
Quando ho iniziato a lavorare con wp, ho preferito il framework al plugin. La realtà è che gli sviluppatori di plugin considerano i principianti e le persone meno alfabetizzate quando sviluppano qualcosa. Personalmente credo che la maggior parte degli utenti wp preferisca le modifiche manuali al codice piuttosto che dipendere dai plugin per le funzioni principali dei siti. A lungo termine i plugin non sono affidabili. La penso così..