Immagina questo scenario: trovi un frammento di codice davvero interessante su uno dei tanti siti di tutorial di WordPress e lo incolli nel file functions.php del tuo tema.
Il frammento di codice funziona come pubblicizzato, e poi rilasci il tuo tema in vendita su un noto marketplace di temi. Scegliamone uno a caso... ThemeForest.
Improvvisamente il tuo tema diventa molto popolare, forse a causa della massiccia lista di "funzionalità" apparentemente utili che hai elencato nella pagina di vendita del tuo tema. Con il successo del tuo tema, arrivano anche una serie di richieste di supporto, per lo più relative a plugin che si rompono mentre si usa il tuo tema.
Come è successo, ti chiedi? Forse perché hai incollato ciecamente blocchi casuali di codice WordPress nel tuo file functions.php senza effettivamente pensare o anticipare potenziali problemi di compatibilità.
Un esempio di vita reale
Quindi, stavo cercando di trovare un frammento di codice che estraesse tutte le immagini allegate da un post e le visualizzasse automaticamente su quel post. Alla fine ho trovato un pezzo di codice su Stack Overflow, l'ho incollato nel mio file functions, e sembrava risolvere il problema.
La prima riga di codice era la seguente:
add_filter('the_content', 'strip_shortcodes');Oh beh, ha funzionato, non ci ho pensato. Più tardi ho provato a incorporare un modulo di contatto con uno shortcode. Sorpresa, non ha funzionato e ho passato circa un'ora a cercare di capire perché. Se avessi effettivamente letto il codice che stavo incollando, lo avrei saputo.
Questo era per il sito di un cliente, non per un tema rilasciato, quindi per fortuna non ho dovuto affrontare un diluvio di richieste di supporto a causa del mio stupido errore.
Cosa pensano gli sviluppatori di plugin commerciali
Ecco una citazione di Carl Hancock (sviluppatore di Gravity Forms) su questo argomento:
Supportare il popolare plugin Gravity Forms significa che vediamo più del nostro giusto numero di temi codificati male. Uno dei principali problemi legati al supporto che incontriamo sono i temi che non sono sviluppati secondo le migliori pratiche, il che si traduce in problemi di stile di Gravity Forms e in alcuni casi conflitti che impediscono a Gravity Forms di funzionare correttamente.
Il principale colpevole in queste situazioni sono i temi che includono frammenti di codice copiati e incollati da siti di tutorial. Gli sviluppatori di temi sembrano pensare che solo perché il frammento di codice era su un sito di tutorial, debba essere buono. Sfortunatamente non è sempre così e queste decisioni sbagliate comportano mal di testa e problemi di supporto per gli utenti.
Vuoi limitare la possibilità di incontrare problemi con i plugin causati da un tema sviluppato male? Attieniti a sviluppatori di temi affidabili come Press75, iThemes, Headway Themes, Organic Themes, WooThemes e StudioPress, per citarne alcuni. Diffida dei marketplace di temi dove l'esperienza e le competenze dell'autore potrebbero essere carenti. Nella maggior parte dei casi, ottieni quello per cui paghi.
Migliori pratiche di codifica
Molti di questi problemi possono probabilmente essere evitati seguendo gli standard di codifica di WordPress. Ad esempio, dovresti utilizzare prefissi per i nomi delle tue funzioni per evitare potenziali conflitti.
Nel caso di problemi di stile con Gravity Forms, potresti voler evitare determinati stili generici sugli elementi form e input, e utilizzare invece i selettori ID predefiniti di WordPress per la maggior parte degli stili del tuo modulo.
Questi includono #searchform, #s, #searchsubmit nella casella di ricerca. Anche #commentform #author, #url, #email, #comment, #submit per il modulo dei commenti.
Conclusione
Se sei uno sviluppatore di temi e non hai molta familiarità con PHP, fai attenzione quando copi e incolli questi snippet di codice nel tuo tema. Anche se non sei un esperto di PHP, puoi almeno leggere il codice e cercare di capirlo prima di usarlo.
Ad esempio, se scopri che i tuoi shortcode non funzionano correttamente, una riga di codice che menziona “strip_shortcodes” potrebbe avere qualcosa a che fare con questo.
A volte ho la sensazione che gli sviluppatori di temi WordPress incollino semplicemente snippet casuali nel loro file functions.php, solo per poter elencare un'altra "funzionalità" nelle pagine di vendita del loro tema.
Anche se non sono un grande fan di questo tipo di idea, si entra in un'altra discussione sul ruolo di temi e plugin sui siti WordPress, che mi riservo per un post futuro.
Interessante.. sono io stesso uno sviluppatore di temi, grazie per avermelo fatto notare…
Ho persino visto persone copiare e incollare codice con avvisi di copyright (che chiedono che il codice non venga condiviso!) ancora intatti.
@mkjones – il problema è che il filtro è stato rimosso, o che la sua rimozione non è stata pubblicizzata? Rimuovo quasi sempre il filtro wpautop perché distrugge automaticamente HTML perfettamente valido (ovviamente lo dico a tutti che è stato rimosso).
Ciò che mi irrita di più è quando incollano Jquery (e altri 20 script/plugin) direttamente nell'header del loro tema o in qualche punto difficile da trovare. È così difficile usare wp_enqueue_script?
Ho pubblicato un rapido esempio di un Fiasco Jquery di Themeforest nei miei forum, se qualcuno vuole dare un'occhiata.
Volevo solo aggiungere un'altra cosa che potrebbe essere utile ad alcuni dei vostri lettori.
All'inizio di questo mese stavo aiutando un cliente che aveva acquistato una licenza di supporto per il mio plugin. Il tema del cliente aveva circa 20 diversi plugin Jquery caricati in header.php. Nessuno di loro utilizzava wp_enque_script.
La maggior parte di questi script veniva utilizzata solo per lo slider della home page e la pagina della galleria (che non esisteva ancora). Poiché venivano caricati in tutto il sito, gli script generavano errori Jquery in tutte le altre pagine del sito che non necessitavano di questi script.
Piuttosto che riscrivere l'intero header.php e poiché non sapevo se alcuni degli script potessero essere necessari per pagine future. Ho usato alcuni tag condizionali per risolvere il problema. Utilizzando i tag condizionali, sono stato in grado di disattivare tutti gli script arbitrari, quando il sito caricava il modulo di registrazione che veniva generato dal mio plugin.
Ho pubblicato un rapido esempio di un Fiasco Jquery di Themeforest nei miei forum, se qualcuno vuole dare un'occhiata.
Scusa Leland, puoi rimuovere quella prima riga del mio ultimo commento? Pensavo di averla rimossa prima di pubblicare.
Grazie!
Oh MAN, odio questo. Causa INFINITI mal di testa quando si personalizzano i temi.
Mi sembra di ricordare il classico:
remove_filter(‘the_content’, ‘wpautop’);
Infiltrandosi in uno tempo fa. Senza essere adeguatamente pubblicizzato come una 'funzionalità' del tema 🙁
Sono completamente d'accordo con te qui! Sono già passato per questa strada e ho commesso io stesso questo errore, solo per trovarmi nei guai più tardi.
Le cose che puoi fare con il tuo functions.php sono fantastiche, ma devi essere organizzato e attento a ciò che fai se non vuoi passare ore a fare il debug in seguito.
Una delle raccomandazioni che darei sarebbe quella di organizzare attentamente questi frammenti di codice se si desidera conservarli.
Conservali in file separati, ben commentati, testa due volte dopo l'implementazione. Alla fine, documentare il proprio lavoro paga sempre, secondo me.
Non avrei potuto dirlo meglio io stesso. Questo non è limitato a frammenti di codice casuali trovati nei tutorial sul Web. Gli sviluppatori di temi inseriscono casualmente qualsiasi codice in functions.php senza pensarci - si potrebbe pensare che userebbero un hook ogni tanto.