Imaginați-vă acest scenariu: găsiți un fragment de cod foarte interesant pe unul dintre numeroasele site-uri de tutoriale WordPress și îl copiați în fișierul functions.php al temei dvs.
Fragmentul de cod funcționează conform așteptărilor, iar apoi vă lansați tema spre vânzare pe o piață de teme binecunoscută. Să alegem una la întâmplare și să mergem cu... ThemeForest.
Brusc, tema dvs. devine foarte populară, poate datorită listei masive de „funcționalități” aparent utile pe care le-ați listat pe pagina de vânzări a temei. Odată cu succesul temei dvs., vin și o serie de solicitări de suport, în principal legate de plugin-uri care nu funcționează corect atunci când folosiți tema dvs.
Cum s-a întâmplat asta, vă întrebați? Poate pentru că ați copiat orbește fragmente aleatorii de cod WordPress în fișierul dvs. functions.php fără să vă gândiți sau să anticipați eventualele probleme de compatibilitate.
Un exemplu din viața reală
Așadar, încercam să găsesc un fragment de cod care să extragă toate imaginile atașate dintr-o postare și apoi să le afișeze automat pe acea postare. Am găsit în cele din urmă o bucată de cod pe Stack Overflow, am copiat-o în fișierul meu functions și părea să rezolve problema.
Prima linie de cod era următoarea:
add_filter('the_content', 'strip_shortcodes');Ei bine, a funcționat, nu m-am gândit la nimic. Mai târziu am încercat să încorporez un formular de contact cu un shortcode. Surpriză, nu a funcționat și am petrecut aproximativ o oră încercând să înțeleg de ce. Dacă aș fi citit cu atenție codul pe care îl copiam, aș fi știut.
Acest lucru a fost pentru un site de client, nu o temă lansată, așa că, din fericire, nu a trebuit să mă confrunt cu un potop de solicitări de suport din cauza greșelii mele stupide.
Ce cred dezvoltatorii de plugin-uri comerciale
Iată o declarație de la Carl Hancock (dezvoltator Gravity Forms) pe această temă:
Suportul pentru popularul plugin Gravity Forms înseamnă că vedem mai mult decât partea noastră echitabilă de teme slab codificate. Una dintre problemele principale legate de suport cu care ne confruntăm sunt temele care nu sunt dezvoltate folosind cele mai bune practici, ceea ce duce la probleme de stilizare Gravity Forms și, în unele cazuri, la conflicte care fac ca Gravity Forms să nu funcționeze corect.
Cel mai mare vinovat în aceste situații sunt temele care includ fragmente de cod copiate și lipite de pe site-uri de tutoriale. Dezvoltatorii de teme par să creadă că doar pentru că fragmentul de cod era pe un site de tutoriale, trebuie să fie bun. Din păcate, nu este întotdeauna cazul, iar aceste decizii proaste duc la dureri de cap și probleme de suport pentru utilizatori.
Doriți să limitați potențialul de a întâmpina probleme cu plugin-urile cauzate de o temă slab dezvoltată? Rămâneți la dezvoltatori de teme reputați, cum ar fi Press75, iThemes, Headway Themes, Organic Themes, WooThemes și StudioPress, pentru a numi câțiva. Fiți precaut cu piețele de teme unde experiența și setul de competențe al autorului pot lipsi. În majoritatea cazurilor, primești ceea ce plătești.
Cele mai bune practici de codare
Multe dintre aceste probleme pot fi probabil evitate urmând standardele de codare WordPress. De exemplu, ar trebui să prefixați numele funcțiilor pentru a evita orice conflicte potențiale.
În cazul problemelor de stilizare cu Gravity Forms, este posibil să doriți să evitați anumite stiluri generale pe elementele form și input și, în schimb, să utilizați selectorii ID impliciti WordPress pentru majoritatea stilizărilor formularului dvs.
Acestea includ #searchform, #s, #searchsubmit în caseta de căutare. De asemenea, #commentform #author, #url, #email, #comment, #submit pentru formularul de comentarii.
Concluzie
Dacă sunteți un dezvoltator de teme și nu sunteți prea versat în PHP, aveți grijă când copiați și lipiți aceste fragmente de cod în tema dvs. Chiar dacă nu sunteți grozav la PHP, puteți cel puțin să citiți codul și să încercați să-i dați un sens înainte de a-l utiliza.
De exemplu, dacă descoperiți că shortcode-urile dvs. nu funcționează corect, o linie de cod care menționează „strip_shortcodes” ar putea avea legătură cu asta.
Uneori am impresia că dezvoltatorii de teme WordPress pur și simplu lipesc fragmente aleatorii în fișierul lor functions.php, doar pentru a putea lista o altă „funcționalitate” pe paginile de vânzare ale temei lor.
Deși nu sunt un mare fan al acestui tip de idee, aceasta intră într-o altă discuție despre rolul temelor și plugin-urilor pe site-urile WordPress, pe care o voi rezerva pentru un articol viitor.
Interesant.. Sunt eu însumi un dezvoltator de teme, vă mulțumesc că mi-ați adus acest lucru în atenție…
Am văzut chiar și oameni care copiază și lipesc cod cu notificări de copyright (cerând ca codul să nu fie distribuit!) încă intacte.
@mkjones – problema este că filtrul a fost eliminat sau că eliminarea sa nu a fost anunțată? Îndepărtez aproape întotdeauna filtrul wpautop deoarece distruge automat HTML-ul perfect bun (desigur, spun tuturor că a dispărut).
Ceea ce mă irită cel mai mult este atunci când lipesc Jquery (și alte 20+ scripturi/plugin-uri) direct în antetul temei lor sau într-un loc greu de găsit. Este wp_enqueue_script atât de dificil?
De fapt, am postat un exemplu rapid de Fiasco Jquery Themeforest pe forumurile mele, dacă cineva dorește să îl verifice.
Am vrut doar să adaug încă un lucru care ar putea fi util pentru unii dintre cititorii dvs.
La începutul acestei luni, ajutam un client care a achiziționat o licență de suport pentru pluginul meu. Tema clientului avea în jur de 20 de pluginuri Jquery diferite încărcate în header.php. Niciunul dintre ele nu folosea wp_enque_script.
Majoritatea acestor scripturi erau folosite doar pentru sliderul de pe pagina principală și pagina galerie (care încă nu exista.) Deoarece erau încărcate pe întregul site, scripturile aruncau erori Jquery pe toate celelalte pagini ale site-ului care nu aveau nevoie de aceste scripturi.
În loc să rescriu întregul header.php și pentru că nu știam dacă vreunul dintre scripturi ar putea fi necesar pentru paginile viitoare. Am folosit câteva taguri condiționale pentru a rezolva problema. Folosind taguri condiționale, am reușit să dezactivez toate scripturile arbitrare, când site-ul încărca formularul de înregistrare care era generat de pluginul meu.
De fapt, am postat un exemplu rapid de Fiasco Jquery Themeforest pe forumurile mele, dacă cineva dorește să îl verifice.
Scuze Leland, poți să ștergi prima linie din ultimul meu comentariu? Am crezut că am șters-o înainte de a posta.
Mulțumesc!
Oh MAN, urăsc asta. Cauzează FĂRĂ SFÂRȘIT dureri de cap atunci când personalizezi teme.
Îmi amintesc clasicul:
remove_filter(‘the_content’, ‘wpautop’);
S-a strecurat într-una acum ceva timp. Fără a fi anunțat corespunzător ca o „caracteristică” a temei 🙁
Sunt complet de acord cu tine aici! Am trecut prin asta și am făcut această greșeală singur, doar pentru a mă trezi în dificultate mai târziu.
Lucrurile pe care le poți face cu functions.php sunt grozave, dar trebuie să fii organizat și atent la ceea ce faci dacă nu vrei să petreci ore depanând mai târziu.
Una dintre recomandările pe care le-aș da ar fi să organizați cu atenție aceste fragmente de cod dacă doriți să le păstrați.
Păstrați-le în fișiere separate, bine comentate, testați dublu după implementare. În final, documentarea muncii dvs. plătește întotdeauna, după părerea mea.
Nu aș fi putut spune mai bine. Acest lucru nu se limitează doar la fragmente de cod aleatorii găsite în tutoriale de pe Web. Dezvoltatorii de teme aruncă pur și simplu orice cod în functions.php fără să se gândească — ați crede că ar folosi un hook o dată.