După cum știți mulți dintre voi, săptămâna trecută Syed Balkhi a participat la WordCamp Raleigh 2012. În timpul evenimentului, unul dintre tweet-urile sale a stârnit o dezbatere considerabilă. În acest articol, fondatorul nostru Syed Balkhi va dezbate dacă tipurile de postări personalizate WordPress aparțin fișierului functions.php sau pluginurilor. Mai jos este un tweet care a început această dezbatere:
Nu adăugați Tipuri de Postări Personalizate în functions.php -> Ar trebui SĂ FOLOSIȚI ÎNTOTDEAUNA un plugin specific site-ului - http://t.co/bebYXq2F #wcraleigh
— WordPress Beginner (@wpbeginner) 4 noiembrie 2012
După tweet, mulți oameni respectați din comunitatea WordPress au intervenit. Puteți vedea întreaga conversație aici. Curtis McHale a mers un pas mai departe și a detaliat subiectul în noul său articol de blog.
Conversația de pe Twitter a adus în discuție câteva puncte excelente.
Rezumatul argumentelor
Argumentul plugin-urilor: Utilizatorul va avea întotdeauna datele chiar dacă schimbă tema. S-ar putea să nu arate la fel de frumos, dar va rămâne acolo.
Argument Functions.php: Datele fără design ar fi irelevante. Va confuza și mai mult utilizatorii.
Cu ce parte ești mai de acord? Clar ambele părți au problemele lor, dar care este mai micul dintre cei doi răi?
Iată de ce credem că Tipurile de Postări Personalizate ar trebui ÎNTOTDEAUNA să locuiască într-un plugin specific site-ului sau într-un plugin separat.
Trăiască datele
Tipurile de postări personalizate sunt date. În majoritatea cazurilor, datele dumneavoastră vor supraviețui designului actual. După ce ne-am schimbat temele de câteva ori, înțelegem clar această afirmație. Postările, Paginile, Linkurile, Atașamentele și Reviziile sunt toate tipuri de postări incluse în WordPress. Pe lângă acestea, avem tipuri de postări precum Cărți, Testimoniale, Oferte etc. Acum, v-ați putea imagina dacă am schimba o temă și toate acestea ar dispărea? Cu siguranță, nu am vrea ca acest lucru să se întâmple.
Având dezvoltatori în echipa noastră, acest lucru nu ar trebui să conteze prea mult. Având în vedere că toate temele noastre sunt proiectate personal de echipa noastră, ce diferență face cu adevărat? Secretul constă în două cuvinte: timp și centralizare. Atâta timp cât avem toate datele necesare, tot ce ar trebui să facem pe viitor este să schimbăm stilul. Nu va trebui să ne facem griji cu copierea și lipirea funcțiilor dintr-un fișier în altul de fiecare dată. Ce se întâmplă dacă doriți să replicați funcționalitatea? Pur și simplu luați pluginul și îl plasați pe noul dvs. site. Schimbați stilul și ați terminat.
Reguli și Standarde
Când folosești cuvântul ÎNTOTDEAUNA, așa cum am făcut noi în tweet-ul nostru, acesta poate însemna atât regulă, cât și standarde. Atât regulile, cât și standardele sunt făcute pentru majoritate. Vor exista întotdeauna scenarii speciale în care regulile sunt ocolite și standardele sunt încălcate, dar asta nu înseamnă că ar trebui să renunțăm complet la standarde.
Există o mulțime de tipuri de postări generice care necesită în mare parte același set de câmpuri meta suplimentare. Câteva exemple care îmi vin în minte ar fi: Citate, Cărți, Rețete, Mărturii, Portofoliu, etc.
Având în vedere numărul mare de teme de fotografie și portofoliu disponibile pe piața gratuită și comercială, nu are aproape niciun sens să obligi utilizatorul să reintroducă toate informațiile sale personalizate despre tipul de postare de fiecare dată când schimbă o temă. Să analizăm un scenariu exemplu:
Fotograf – Utilizatorul a configurat un WordPress care are o funcționalitate de blog (CPT implicit „post”). El dorește să adauge un portofoliu al lucrărilor sale (necesită un CPT Portofoliu). El dorește să afișeze mărturii ale clienților (necesită un CPT Mărturie). Toate aceste informații vor supraviețui cu siguranță unui design de temă. Un an mai târziu, utilizatorul dorește să schimbe aspectul site-ului său și să-l reîmprospăteze. Găsește o temă nouă care are toate funcțiile similare. În momentul în care schimbă tema, BOOM. Toate datele anterioare pe care le-a introdus au dispărut. Există un meniu numit Portofoliu și un meniu numit Mărturii, însă nicio dată nu este acolo. Utilizatorul se gândește „LA NA IBA, mi-am pierdut tot conținutul”. Creează noi întrebări de suport pe forum. Trimite e-mailuri către site-uri precum WPBeginner etc. Dacă nu primesc un răspuns bun, vor trebui să reintroducă toate datele. Aceasta este o experiență neplăcută pentru utilizator.
Deci, cum rezolvăm această problemă?
Soluție posibilă?
Creăm o nouă bază standard. Justin Tadlock a început deja să lucreze la această problemă cu ceva timp în urmă, creând un plugin de bază pentru portofoliu. Va fi soluția perfectă pentru toată lumea? NU, dar va fi pentru majoritate.
Așa cum întreabă Justin în postarea sa, ce câmpuri standard ar trebui incluse în plugin-ul de portofoliu (referindu-se la post meta). Acest tip de conversație trebuie să aibă loc între dezvoltatorii care creează funcționalități similare în temele lor. De ce să copiezi și să lipești același lucru iar și iar dintr-o temă în alta când se poate face printr-un plugin? Odată ce devine un standard, alți autori de teme vor începe să se adapteze la el.
De exemplu, vedem o creștere a suportului de stil pentru Gravity Forms în cadrele de teme WordPress precum Genesis și altele. De ce? Pentru că înțeleg că utilizatorii lor îl folosesc.
Există teme WordPress robuste care vin încărcate cu funcționalități pe care noi credem că ar trebui să fie pluginuri. Teme pentru Job Board, Teme pentru Urmărirea Problemelor, Teme pentru Anunțuri Clasificate, Teme pentru Imobiliare, etc. Toate ar trebui să fie alimentate de un plugin de bază. Acest lucru se întâmplă deja cu WooCommerce. WooThemes a lansat numeroase teme care au suport de stilizare încorporat pentru plugin. Alte companii de teme au promis să lanseze, de asemenea, teme de comerț electronic bazate pe WooCommerce. Puteți trece de la o temă la alta și să păstrați toate produsele așa cum sunt. Este aproape ca și cum tema s-ar fi schimbat, dar totul a căzut la locul potrivit. Aceasta este experiența de schimbare a temei pentru care ar trebui să luptăm.
De ce să nu faceți același lucru cu Portofoliu, Testimoniale și alte tipuri generice de postări personalizate? Este pentru că este prea simplu în comparație cu eCommerce, care este o bestie mai mare de cucerit? Clar, eCommerce are mult prea multe câmpuri în comparație cu celelalte, deci ar trebui să fie mult mai ușor pentru aceste tipuri generice de postări. Este doar o chestiune de a depune un efort conștient pentru a îmbunătăți lucrurile.
Aruncați o privire la pluginul ReciPress. Acesta creează o metabox personalizată cu câmpuri pentru rețete și o atașează postărilor. Cu toate acestea, este posibil să o atașați la tipuri de postări personalizate. Oricine folosește acest plugin poate schimba temele fără a trece prin atâtea bătăi de cap.
Ar fi frumos să vedem teme precum AgentPress alimentate de un plugin de bază centralizat. Ar fi grozav să vedem tranziția schimbării temelor devenind mai ușoară. De exemplu, dacă un utilizator trece de la o temă de fotografie la alta, nu ar trebui să fie un haos. Pot apărea erori minore, dar cel puțin, în ansamblu, lucrurile vor funcționa.
Puteți oferi întotdeauna exemple de tipuri de postări super personalizate create pentru utilizare de către un client unic, dar aceasta este excepția, nu regula.
Ce părere aveți despre acest subiect? Unde ar trebui să rezide codul pentru tipurile de postări personalizate? În fișierul functions.php sau în plugin-uri?
Yazmin
Fiind de nenumărate ori în situația de a pierde CPT-urile mele pe măsură ce schimbam temele, găsesc frustrant să trebuiască să configurez aceeași funcționalitate iar și iar în functions.php.
Prefer în totalitate calea plugin-ului și aceasta este metoda pe care o voi folosi de acum înainte și pentru proiectele mele de afaceri.
Joshua Jarvis
Am exact aceeași problemă cu o temă imobiliară. „Listările” erau toate tipuri personalizate într-o temă care este acum funcțional depășită. Când am mers să actualizez tema, am pierdut tot conținutul postărilor personalizate, acum trebuie să găsesc o modalitate de a le transfera pe toate. Am opțiuni, dar dacă ar fi un plugin, acest lucru nu ar fi necesar.
Personal editorial
Ne pare extrem de rău pentru inconvenientul dumneavoastră. Acesta este motivul pentru care am scris acest post, deoarece știm că face viața utilizatorului final mai grea.
Admin
Hugh H. Sands
„Nu va trebui să ne facem griji cu privire la copierea și lipirea funcțiilor dintr-un fișier în altul de fiecare dată.”
Nu-mi pot imagina pe cineva scriind cod pentru un CPT în functions.php când este atât de ușor să-l izolezi cu include-uri
Această dezbatere se concentrează de cele mai multe ori pe date vs. design și mă întreb, fiind destul de nou în WP, ce se întâmplă cu performanța? Plugin-urile impun o suprasarcină?
Personal editorial
Acest articol ar trebui să vă răspundă la întrebarea despre plugin-uri și performanță:
https://www.wpbeginner.com/opinion/how-many-wordpress-plugins-should-you-install-on-your-site/
Admin
Hugh Sands
Mulțumesc pentru link, foarte util!
Kelvin Alfonso
Am inclus întotdeauna CPT-uri printr-un fișier separat în functions.php, dar cred că voi trece la ruta plugin-urilor. Mulțumesc!
Sudhakar
Sunt un începător și nu am expertiză pentru a comenta pro sau contra unui plugin sau functions.php. Dar mă întreb dacă vreau să merg pe calea functions.php și să o fac sub o temă copil, care este problema atunci? De ce am nevoie să fie într-un plugin, nu m-ar salva tema mea copil de upgrade-urile și modificările viitoare ale temelor?
Personal editorial
Tema ta copil ar salva-o de actualizările viitoare ale temei. Cu toate acestea, NU te va salva dacă îți schimbi temele. Deoarece schimbi tema copil dacă schimbi tema activă.
Admin
Pat Ramsey
Sunt un adept al rutei prin pluginuri pentru tipurile de postări personalizate și taxonomii. Mențiunea autorului despre un plugin specific site-ului este modul în care procedez. Plasez orice tipuri de postări personalizate, taxonomii personalizate și metabox-uri în acest plugin, adaptat scopului site-ului. În cele din urmă, tema site-ului se va schimba, dar datele rămân și sunt încă ușor accesibile.
shawn
Dacă dezvoltatorii continuă să ignore faptul că separarea „datelor” de „design” este necesară pentru a crea aplicații modulare, și nu contează unde sunt plasate datele, reutilizarea acelor date / cod va fi întotdeauna o problemă.
Se pare că există o percepție în rândul unora din comunitatea WP, dintr-un motiv sau altul, că poți accesa date în ecosistemul WordPress doar dacă sunt încapsulate într-un plugin, așa că vedem în continuare discuții de genul acesta care contribuie la „Marea dezbatere plugin vs. temă”.
Accentul trebuie pus pe evoluția sistemului arhaic de plugin-uri al WordPress, pe crearea de biblioteci bazate pe modele de design modulare care separă codul / datele de design. Biblioteci care pot fi utilizate atât în teme, cât și în plugin-uri.
Dezbaterile de genul acesta sunt inutile în era PHP4 a postărilor WP!!! (re-post)
Mark Simchock
Re: „Așa cum întreabă Justin în postarea sa, ce câmpuri standard ar trebui incluse în plugin-ul de portofoliu (referindu-se la post meta). Acest tip de conversație trebuie să aibă loc între dezvoltatorii care creează funcționalități similare în temele lor.”
Eu? Aș prefera un plugin bine documentat, proiectat pentru a fi îmbunătățit, decât o abordare „închisă”, universală, greu de lucrat cu ea (acel cod).
Punctul meu este, poate este posibil să spunem: „Nu încerc să fiu totul pentru toată lumea. Iată plugin-ul meu de bază. Iată cum îl poți personaliza. Este conceput pentru a fi personalizat.” și să ne oprim aici. Indiferent ce faci, este dificil să anticipezi fiecare caz de utilizare, fiecare nevoie de utilizare. Deci, de ce să te chinui? De ce să nu abordezi asta ca pe un cadru (de un fel) și să lași dezvoltatorul care are nevoie să personalizeze după cum este necesar?
Justin Tadlock
Acesta este de fapt planul. Construiesc o bază extrem de mică și ușor de personalizat. Dar, aș dori să știu ce câmpuri, dacă există, ar trebui să fie standard.
Kevin Maines
Greșeală de scriere?:
„Având în vedere că toate echipele noastre sunt proiectate personal de echipa noastră”
Personal editorial
Fixed it. Thanks for catching that
Admin
Affan Ruslan
Cred că ar trebui să fie pe un plugin.
În cazul în care utilizatorul nu are nevoie de date în viitor, el poate oricând să convertească tipul de postare personalizat la tipul de postare „normal”. Există un plugin pentru a face acest lucru, căutați în depozit și veți găsi cel puțin unul.
Christophe Debruel
Nu prea îmi pasă ce spun oamenii. Tipul de postare personalizat merge într-un plugin. O temă poate fi ușor modificată pentru a se potrivi tipului de postare personalizat în frontend. Mi se pare mai logic să stilizez tema pentru CTP decât să am teme diferite cu același cod CTP.
Ingo
„Pods Framework” ar putea fi, de asemenea, o soluție bună de plugin. Pentru CPT, CT și CF.
http://wordpress.org/extend/plugins/pods/
Personal editorial
Da, pods este grozav.
Admin
Elliott Richmond
Plugin pentru mine. Cel puțin pentru un client non-tehnic, deși tema s-ar putea să nu funcționeze corect, va deveni evident că există o problemă și acest lucru îi va determina să angajeze un dezvoltator.
Kailas Mahajan
Totul depinde de proiect…
dacă cineva gestionează un proiect care necesită schimbarea temei după o anumită perioadă de timp… poate folosi un plugin.
sau dacă proiectul se limitează la o singură temă... se poate folosi function.php
Ross W
Toată lumea vorbește despre cum datele trebuie stilizate de temă și exemple unde este cazul și unde datele și tema pot fi separate.
Ceea ce nu văd este pe cineva care vorbește despre cazuri în care o temă depinde de disponibilitatea unor date specifice. Să spunem că aveți o temă care are o hartă a țărilor și niște date specifice țării, iar fără acea hartă și acele date, tema își pierde o parte din funcționalitatea sa cheie.
Da, ați putea face în continuare acest lucru cu datele dintr-un plugin, dar este rezonabil ca o temă să presupună că există anumite date? Este rezonabil să presupunem că plugin-ul care creează tipurile de date este instalat și activat? (Întrebări sincere…discutați!)
Ce se întâmplă dacă clientul meu, ușor non-tehnic, dorește să creeze o copie a site-ului cu „tema” lor. Ei activează tema pe o nouă instalare WordPress doar pentru a descoperi că o mulțime de lucruri lipsesc sau sunt defecte? Ei credeau că tema conținea tot ce aveau nevoie pentru ca site-ul lor să arate corect?
Pot vedea utilizări pentru ambele abordări. Pentru majoritatea lucrărilor mele cu clienții, configurez CPT-uri, meta-box-uri și câteva funcții pentru a simplifica accesarea lor, în fișiere de bibliotecă și le includ. Acest lucru păstrează tot „materialul” de care tema mea are nevoie pentru a funcționa într-un singur pachet, dar îl face simplu de mutat CPT-urile la o nouă temă, dacă doresc.
Desigur, dacă un CPT pare că ar putea fi folosit pe mai multe teme și nu este SO specific încât să se aplice doar datelor unui singur client, atunci îl transformați într-un plugin care poate fi implementat la cerere.
Nu cred că există o relație simplă, unidirecțională între date și teme. Nu este întotdeauna cazul că „am niște date care necesită stilizare”... uneori „stilul meu necesită niște date”.
Păreri despre asta?
Andres Hermosilla
Sunt absolut de acord că există un beneficiu în a avea un pachet „complet”. Adesea există funcționalități foarte specifice temei care sunt mai bine legate direct (adică P2 de la Auttomatic) vs. o temă instalată și un plugin de temă.
Konstantin Kovshenin
Pluginuri. Punct.
Curtis McHale
Referința dumneavoastră la AgentPress este unul dintre motivele pentru care sunt 100% în favoarea CPT-urilor în plugin-uri. Am avut de-a face cu teme de genul acesta și este atât de greu să le stilizezi corespunzător, decât dacă elimini funcționalitatea personalizată din temă. Clientul meu și cu mine am petrecut 20 de ore pentru a aduce codul la un punct la care am putea lucra efectiv la el.
Birgit
soluția mea cea mai bună și preferată, recomandată, este extrem de flexibilul TOOLBOX: http://wordpress.org/extend/plugins/toolbox/
Personal editorial
Idee grozavă. Mi-aș dori să pot înțelege ce arăta captura de ecran fără a descărca pluginul.
-Syed
Admin
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
Poate că acest lucru te va ajuta să citești: http://tinyurl.com/bf5dflt
Personal editorial
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
Prefer întotdeauna plugin-urile în locul fișierului functions.php pentru orice lucru care ar putea „rupe” material în partea frontală sau ar pierde date dacă tema ar fi schimbată. Acest lucru se datorează exact motivelor pe care le citați, și de asemenea, consider că este o nebunie pentru cei dintre noi care nu sunt cu adevărat programatori PHP să încerce să depaneze conflicte atunci când trebuie să comentezi secțiuni din functions.php pentru a izola o problemă.
matt
ok, deci ce plugin cpt recomanzi?
Personal editorial
Ideea este că ar trebui să înregistrați CPT-uri într-un plugin specific site-ului. Nu există încă un plugin specific. Dar aceasta este doar o idee aruncată despre crearea unui plugin de bază pentru tipuri de postări generice.
Admin
Muhammad Waqas
Sunt mai convins de utilizarea funcțiilor locale. dar în acest caz cred că plugin-ul poate fi de încredere mai mult. De exemplu, dacă începeți să folosiți wp cu un anumit framework. În cele mai multe cazuri, este posibil să deveniți un sclav pentru mult timp, până când angajați un profesionist wp pentru a vă ajuta să scăpați de acel framework fără a vă pierde setările și datele. Pe de altă parte, plugin-urile pot funcționa la aproape orice temă.
Când am început să lucrez cu wp, am preferat framework-ul în locul plugin-ului. Realitatea este că dezvoltatorii de plugin-uri iau în considerare începătorii și persoanele mai puțin alfabetizate atunci când dezvoltă ceva. Eu personal cred că majoritatea utilizatorilor wp preferă modificări manuale de cod decât să depindă de plugin-uri pentru funcțiile de bază ale site-urilor. pe termen lung, plugin-urile nu sunt fiabile. Așa simt eu..