I miei cinque peggiori errori di sviluppo di WordPress

Oppure, a tutti i server che ho utilizzato in precedenza: uno sguardo indietro con orrore ai cinque peggiori errori di WordPress che ho commesso

Come sviluppatori, commettiamo diversi tipi di errori in diversi momenti della nostra carriera. Nello sviluppo di WordPress, in particolare, commettiamo diversi tipi di errori man mano che cresce la nostra familiarità con la base di codice di WordPress.

Alcuni anni fa ho sentito Matt Mullenweg dichiarare qualcosa secondo cui la maggior parte delle persone ripete i propri errori, le persone più intelligenti imparano dai propri errori e le persone più intelligenti tra noi imparano dagli errori degli altri. Mi piace piuttosto questo, e vorrei aggiungere un corollario: tutti commettono errori, le persone umili condividono quegli errori in privato e i più audaci tra noi li scrivono e li pubblicano in un blog!

Ma c'è tempo per riflettere più tardi. Stai leggendo questo articolo perché vuoi sapere di un incidente ferroviario e io sono l'ingegnere. Senza ulteriori preamboli, unisciti a me in uno sguardo indietro con orrore ai cinque errori più imbarazzanti che ho commesso come sviluppatore di WordPress.

Il tempo in cui ho aggiornato una versione compromessa di WordPress Core

Mi stavo appena diplomando dal fare concerti di programmazione CraigsList molto oscuri, per lavorare effettivamente in una vera agenzia dal vivo. ero arrivato! Ero nervoso all'idea di lavorare da un posto diverso dal mio divano, in qualcosa di diverso dal mio pigiama. Ma anche allora, in genere conoscevo WordPress proprio da WordPress Doing It Wrong e ho trovato piacevolmente auto-esaltante vantarmi delle migliori pratiche di WordPress, come non "hackerare mai il core".

Il mio primo compito di sviluppo di WordPress in questa agenzia è stato quello di riprendere un progetto in stallo, piuttosto complesso per le mie competenze in quel momento. Ha comportato molte personalizzazioni alla registrazione di WordPress e al flusso di accesso. Si diceva che lo sviluppatore precedente avesse ottenuto progressi significativi semplicemente modificando i file principali wp-login .

Sapevo che era insostenibile, quindi il mio primo compito è stato quello di installare un plug-in di backup/ripristino e sostituire il core di WordPress con una versione appena scaricata. Ero fiducioso che non fosse stato ancora eseguito nulla di terribilmente impressionante nel progetto e che sarei stato in grado di imitare il set di funzionalità esistente tramite filtri.

Qualunque sia l'abilità di codifica che avessi avuto o meno a quel punto è diventata rapidamente irrilevante, poiché il mio nuovo datore di lavoro era impazzito. Non capiva il significato di "hacking core" e io non ero abbastanza maturo per spiegarlo in modo digeribile. L'unica cosa che le ha temporaneamente raffreddato la fronte è stato quando le ho assicurato che avrei potuto ripristinare tramite il plug-in di backup/ripristino che avevo installato.

Riesci a indovinare dove sta andando?

Quel plugin, come avrebbe voluto il destino, eseguiva solo il backup della cartella wp-content . Qualunque fossero gli hack di WordPress in quei file core erano spariti per sempre. Ricordo ancora la mia e-mail che le ho inviato (a questo punto mi aveva bandito da tempo nel mio ufficio di casa):

Ragazzi, non posso fare il backup.

Ero davvero pronto a completare il set di funzionalità desiderato tramite filtri e azioni, ma non l'avrebbe sentito. Mi ha licenziato sul posto, ha minacciato di farmi causa e non mi ha mai pagato per due settimane di duro lavoro. Ero così umiliato.

Ci sono molte cose (ormai ovvie) che avrei potuto imparare da questa esperienza. La lezione generale, che un backup non è un backup finché non è stato provato e confermato, è buona. Ma quella che mi ha colpito di più è una lezione specifica su come eseguire esattamente i backup in WordPress, in particolare con il core di WordPress.

Ho imparato ad amare davvero gli ambienti gestiti come WP-Engine, con un solido sistema di backup/ripristino. Molti host boutique hanno vari strumenti da riga di comando e altre funzionalità incentrate sugli sviluppatori per l'esecuzione di backup, ma WP-Engine è il mio preferito. È abbastanza veloce a meno che tu non abbia una rete molto grande. L'interfaccia utente è semplice. Ha un'interfaccia utente, punto: chiunque sappia come usare WordPress può lavorare con questo. Cioè, in contrasto con qualche approccio CLI che è probabilmente molto più veloce, o qualche cosa oscura sepolta in Plesk, i miei clienti possono usarlo, capirlo, monitorarlo e verificare che lo stia usando. Sono un grande fan.

Il tempo in cui ho trascinato l'intera piattaforma nella sua directory di fratelli

Ero ancora abbastanza nuovo nel mondo del lavoro professionale ed ero sempre stato un esperto di Windows. Tuttavia, il mio nuovo lavoro era in un negozio di Mac e ho imparato ad amare tutto molto rapidamente. Bene, quasi tutto. Sembrava che avessi molti problemi con il "mouse magico". Avevo la tendenza a perdere la connessione Bluetooth, portando ad azioni di trascinamento accidentali e spesso spaventose una volta ricollegata. Inoltre, ero solo goffo con una nuova abilità motoria.

In questi giorni, il nostro flusso di sviluppo di WordPress includeva ancora la distribuzione alla produzione tramite FTP. Non era raro per me trascorrere intere giornate lavorative a scrivere codice, chattare, rispondere alle e-mail, generalmente girando avanti e indietro con il mio nuovo mouse magico, con Cyberduck aperto alla produzione sul mio desktop. Cavolo, suona male! Ma è così.

Un giorno la nostra intera piattaforma era sparita. Il nostro amministratore di sistema si è affrettato a presumere che si trattasse di una specie di DDoS o qualcosa in generale al suo livello. Per quanto riguarda noi sviluppatori, ci siamo fidati del suo istinto e abbiamo pensato che l'avrebbe scoperto abbastanza presto.

Passarono le ore. Il giorno è venuto e se ne è andato. Ancora giù.

La mattina successiva, le cose sono state ripristinate e il nostro CTO mi ha chiesto gentilmente di unirmi a lei nella sala conferenze. Il nostro amministratore di sistema aveva identificato il problema. Ha estratto i registri FTP e ha osservato che il mio utente aveva spostato l'intera piattaforma in una directory di pari livello. Cioè, wp-content era stato annidato in wp-includes .

Ero mortificato, ma il nostro CTO è stato fantastico. Poteva vedere che in genere ero un dipendente disponibile e responsabile, ma mi ha sfidato ad andare oltre la semplice contrizione e trovare modi per evitare che ciò accadesse di nuovo. Ho trovato due cose davvero utili.

Il primo era individuare un comando CLI per impedire a Cyberduck di consentire movimenti di file da remoto a remoto. Questa è stata una buona misura di sicurezza e l'abbiamo adottata immediatamente come politica aziendale.

Il secondo è che mi sono interessato molto all'implementazione tramite Git. Alla fine, ho finito per scrivere un plugin per WordPress per intrecciare la nostra versione di Bitbucket nel normale flusso di aggiornamento wp-admin . Da allora, non abbiamo quasi più avuto motivo di avere accesso FTP alla produzione. Questo plugin è uno dei miei risultati professionali preferiti. Naturalmente, un'affinità con Git è un prerequisito per gli sviluppatori di oggi.

Il momento in cui ho rimosso tutti i contenuti front-end tramite add_filter()

Pensavo davvero di essere diventato abbastanza intelligente con le mie pratiche WordPress a questo punto. La richiesta era di apporre un “badge” ai post di una certa categoria. Per qualche motivo avevo in mente che solo i noob avrebbero aggiunto un altro condizionale a un file modello per qualcosa del genere, quindi con grande orgoglio ho implementato il seguente filtro:

 add_filter( 'the_content', 'myprefix_add_a_badge' ); function myprefix_add_a_badge( $content ) { global $post; if( ! has_category( 'sponsored', $post ) ) { return false; } $out = $content . myprefix_get_badge(); return $out; }

Vedi qualcosa di sbagliato in questo? L'ho testato rapidamente nella fase di staging per confermare che ai post richiesti fosse applicato il badge. Quindi l'ho distribuito e ho lasciato il lavoro per la giornata. Come puoi immaginare, l'universo è esploso.

In particolare, il risultato è stato che i post senza il badge venivano visualizzati sul front-end senza alcun contenuto! Riesci a vedere perché? Il problema era che invece di restituire $content nella mia condizione di guardia, stavo restituendo false . Ma in realtà ci sono molti strati di errori qui.

Perché mi sono accontentato di verificare solo che i post ricevessero un badge? Perché non ho verificato che anche altri post rimanessero illesi? Perché sono stato distribuito alla produzione così tardi nel corso della giornata? Perché il nostro controllo di qualità consisteva interamente in me che facevo clic un po' in giro e aggiornavo la pagina?

La risposta a tutte queste domande può essere riassunta come maturità . Ci vuole semplicemente un po' di tempo per stancarsi di commettere questo tipo di errori, prima di essere spinti a investire in cose come i test di regressione visiva e gli unit test. Questo particolare errore è stato una goccia, tra centinaia, che alla fine ha fatto traboccare il vaso e mi ha portato a dedicarmi molto a phpUnit e xDebug. A loro volta, questi strumenti mi hanno insegnato a scrivere codice testabile, che probabilmente ha impedito più bug rispetto ai test stessi.

Il tempo che ho diviso per zero all'interno di un ciclo infinito

La richiesta del cliente era di riformattare il post del blog di WordPress in modo tale che la data leggesse "XYZ fa" anziché "10 novembre 2011". Non ero esattamente sicuro di come raggiungere questo obiettivo, ma ero consapevole del fatto che si trattava di un formato di data che sembrava crescere in popolarità, e infatti il ​​Dr. Google mi ha fornito uno snippet molto rapidamente. Ha funzionato sul mio locale! Aveva molta matematica, in particolare molte divisioni . Non ero esattamente sicuro del motivo per cui funzionasse: c'erano molti cicli nidificati, resti, arrotondamenti e così via. Ma era su Google e sembrava funzionare, e sono stato abbastanza felice di implementarlo in produzione.

Circa 30 minuti dopo, ho ricevuto un Skype ostile dal nostro amministratore di sistema. La produzione era in calo. Morto nell'acqua. Mi ha chiesto se ultimamente stavo dividendo per zero e non avevo idea di cosa potesse riferirsi. Ecco cosa è successo.

Che ci crediate o no, lo snippet illeggibile "ha funzionato sul mio locale" che ho trovato, data una dimensione del campione sufficientemente ampia, era capace di comportamenti aberranti. Forniti con alcune sfortunate combinazioni di giorni, ore e minuti, i loop di Rube Goldberg tentavano occasionalmente di dividere un numero per zero. Richiamo dalla matematica del liceo:

Nell'aritmetica ordinaria, l'espressione non ha significato, poiché non esiste un numero che, moltiplicato per 0, dia a (assumendo a ≠ 0), e quindi la divisione per zero non è definita. - Wikipedia

Quindi cosa significa questo per i computer? Di solito solo un messaggio di errore nei registri, ma nel mio caso era peggio: l'errore matematico interferiva con la mia logica di loop, causando l'esecuzione dei miei loop nidificati senza mai essere completati, un loop infinito che portava a una schermata bianca della morte. E peggiora! Poiché ogni iterazione del ciclo scriveva un errore per la divisione per zero, il registro degli errori è cresciuto fino a raggiungere proporzioni fantastiche e ha iniziato a ostacolare il nostro file system. Ciò ha avuto l'effetto di un attacco DDoS, anche se assurdamente autoinflitto.

La cosa negativa di questo errore è che ha eliminato un sito ad alto traffico. La cosa buona di questo errore è che ha cambiato radicalmente il mio approccio al lavoro. Più di ogni altra cosa, mi vergognavo della mia disponibilità a mettere in pratica senza capire. Ho promesso di non incollare mai più uno snippet senza fare ogni sforzo possibile per comprendere ogni riga, anche seguendo l'autore dello snippet, se necessario.

Inoltre, ho promesso di non spedire mai più codice che non fosse altamente leggibile per gli sviluppatori alle prime armi. Sono diventato ossessionato dagli standard di codifica di WordPress, dalle estensioni dell'editor di testo, dai commenti in linea e dai docblock e persino dalle schede rispetto agli spazi, quel classico rito di passaggio! In sintesi, ho deciso di interessarmi di più a quanto fosse facile leggere il mio codice che a scriverlo . Questa ribellione all'incollare senza capire mi ha portato ad avere un profondo interesse professionale nella gestione delle dipendenze di terze parti, un argomento che ha alimentato varie opportunità di scrittura e di parola per me nel decennio successivo.

Oh, e la cosa davvero divertente di questo errore? Il core di WordPress ha una soluzione one-liner per questo.

Il tempo in cui ho lasciato che un progetto perdesse il controllo fino a quando tutti ne erano stufi

Avevo realizzato un progetto davvero affascinante. Dovevo essere il responsabile tecnico e l'ingegnere di sviluppo di WordPress, e avrei avuto uno sviluppatore Amazon AWS Lambda e un profondo esperto di JavaScript che mi riferiva. Questa è stata la prima volta che più persone mi hanno riferito, ed è stato di gran lunga il progetto più complesso su cui avessi mai lavorato. Anche solo riferirsi ad esso come a un progetto WordPress stava sottovalutando notevolmente la questione, ma WordPress era il collante che teneva insieme l'intera cosa, quindi aveva senso per me agire come leader tecnologico.

Poiché il mio ruolo principale era in genere quello di essere rigorosamente un tecnico, e anche perché ho un'affinità per il minimalismo, non mi è mai venuto in mente di implementare qualcosa come Jira o Basecamp o qualsiasi piattaforma reale per la gestione delle attività. Le cose sono andate piuttosto bene per la prima iterazione del progetto. Siamo stati in grado di lavorare sui nostri singoli componenti, fare riferimento al documento delle specifiche del cliente come alla nostra roadmap del prodotto e semplicemente eseguire il ping l'un l'altro tramite Slack quando avevamo bisogno di accoppiare le cose insieme.

Il problema è iniziato quando abbiamo iniziato a mostrare i progressi al cliente e ad implementare il suo feedback. Quello che era iniziato come un team di tre persone ha immediatamente sentito di essere stato portato a un nuovo ordine di grandezza: non era chiaro chi fosse responsabile di quale feedback, quale fosse lo stato dell'implementazione di quel feedback o persino chi stesse parlando con chi . Abbiamo superato più volte il limite di 100 risposte per thread di Gmail!

Le cose cominciarono a mettersi a disagio. Penso che il cliente si sia sentito come se avesse perso il controllo della direzione del progetto e, altrettanto importante, si sia sentito come se avesse perso la visibilità dello stato del progetto. Il mio sviluppatore Amazon ha detto un giorno: "Mi chiedo se dovremmo usare Trello".

Eh , ho pensato. Un team di tre persone ha bisogno di una piattaforma del genere? Ancora una volta, la mia solita tendenza è quella di preferire meno strumenti, meno spese generali, meno complessità. Ma il progetto ci stava già trascinando tutti nel fango, quindi che male c'era nel provarlo?

Ho passato in rassegna tutte le nostre e-mail, tutti i nostri documenti delle specifiche, tutti i nostri disparati thread di commenti e li ho mappati tutti sulle bacheche di Trello. Immediatamente, il progetto è risorto dalla sua tomba digitale perché potevamo comunicare con molto meno sovraccarico mentale. Invece di cercare il testo nella mia casella di posta elettronica o un documento di specifiche per lo più obsoleto, avevamo bacheche, elenchi e schede adorabili. È stato facile vedere lo stato di qualsiasi funzione, incorporare feedback e distribuire nuove attività. Ci siamo sentiti come se fossimo diventati gradualmente ciechi, così lentamente che non ce ne siamo accorti, e poi improvvisamente abbiamo potuto vedere di nuovo.

Certo, il codice non si scriveva da solo, era comunque un progetto molto impegnativo e dovevamo comunque impiegare ogni grammo della nostra abilità tecnica. Ma questo è il punto: poiché finalmente avevamo un'infrastruttura per comprendere il progetto, ora eravamo liberi di applicare le nostre competenze tecniche.

Sono felice di dire che quel progetto è stato portato a termine con piena soddisfazione del cliente. Al giorno d'oggi, considero Trello o Jira un requisito de facto per squadre di due o più.

Vai avanti e impara dagli errori degli altri

Ecco una delle cose più intelligenti che ho sentito insegnare durante il mio periodo nell'esercito: “Va bene che i luogotenenti commettano errori di tenente e va bene che i capitani commettano errori di capitano. Quello che non va bene è che i capitani commettano errori da luogotenente, o che i luogotenenti commettano errori privati.

In altre parole, va bene commettere gli errori comuni che sono una cosa ovvia per il tuo attuale livello di responsabilità. La cosa più importante è come cresci da loro.

Spero che noi sviluppatori impariamo a essere compassionevoli con gli altri quando commettono errori, come si spera che altri siano stati con noi. Spero di rimanere curioso e responsabile quando commetto errori in modo da continuare a innovare oltre. Spero di essere sempre circondato da una comunità stimolante di esperti di WordPress, persone dai cui errori posso imparare ed evitare di commettere me stesso. E non ultimo, spero che altri possano imparare dalla mia esperienza, come gli errori di WordPress che ho condiviso qui.