Perché non hackeriamo il core?

Non riuscivo a credere che questa domanda non avesse già ricevuto risposta su questo sito, ma non l'ho trovata quando ho cercato, quindi ...

Perché è una cattiva idea del crimine contro la natura hackerare il core?

• È davvero fantastico poter aggiornare la tua versione principale? La maggior parte dei miei siti finisce comunque con core orribilmente obsoleti, quindi perché preoccuparsi?
• Anche se è così male per i proprietari di siti, perché la community si preoccupa così tanto? Perché viene chiamato "uccisione dei gattini"? Non è piuttosto iperbolico?
• L'hacking del core è così semplice, non ci piace prendere la strada più semplice per una soluzione ai problemi?
• Non ci sono problemi che possono essere risolti solo tramite l'hacking core? Cosa poi?

In generale, ci sono tre ragioni per non alterare il codice core di Drupal:

• Le tue modifiche andrebbero perse ogni volta che aggiorni Drupal, se non prendi le misure necessarie. Anche nel caso in cui crei una patch per l'attuale versione di Drupal che stai utilizzando, la patch non potrebbe applicarsi alla versione più recente e dovrai creare anche una patch per la nuova versione.

• Le correzioni di sicurezza si applicano al core Drupal come gestito su Drupal.org, ma non potevano applicarsi alla tua versione compromessa. Ciò significa che dovresti verificare che la tua versione non sia interessata dal problema di sicurezza sollevato contro Drupal core.
  Nel caso in cui la tua versione compromessa presenti un diverso problema di sicurezza, sei l'unica persona che riesci a trovarlo, poiché non hai il supporto del team di sicurezza che indaga sui difetti di sicurezza presenti nel codice core di Drupal e in terze parti moduli ospitati su Drupal.org.

• Le modifiche introdotte potrebbero essere incompatibili con Drupal stesso, ma anche con moduli di terze parti, che sono necessari per funzionare con il core Drupal, non con alcuna versione compromessa che è possibile creare.
  Ogni volta che Drupal introduce una nuova funzionalità (che si verifica ancora in Drupal 7 e in Drupal 6, sebbene con meno frequenza), o una nuova modifica dell'API, esiste la possibilità che la versione compromessa sia incompatibile con le recenti modifiche.

Detto questo, è possibile creare una versione compromessa, ma non è questo il compito che può svolgere un singolo sviluppatore, allo stesso modo in cui Drupal non è gestito da una sola persona. In effetti, Pressflow è un versione compromessa di Drupal creata pensando alle prestazioni e per risolvere alcuni problemi di prestazioni che un sito Drupal potrebbe avere.

Non ci sono problemi che possono essere risolti solo tramite l'hacking core? Cosa poi?

Il più delle volte, è possibile modificare le caratteristiche / il comportamento senza modificare il codice core di Drupal. C'è sempre un gancio che consente di modificare le caratteristiche / i comportamenti di Drupal, e questo è il metodo preferito.

Potrei scrivere una risposta massiccia qui, ma pubblicherò questo link: non hackerare mai core !

Il motivo principale suppongo sia che se fai hacking core per fare qualcosa di cui hai bisogno, e poi aggiornalo ... BANG! Le tue modifiche non ci sono più. Perso. Potresti quindi provare a ripristinare il codice dal tuo VCS, ma visto che non puoi ripristinare gli aggiornamenti del database dal core Drupal, stai cercando di ripristinare tutto il codice da VCS e quindi ripristinare i database dai tuoi backup. Per tutto il tempo in cui stai tentando di ripristinare il codice, probabilmente noterai che l'ultimo backup del database pre-aggiornamento non è riuscito e giurerai più di quanto tu abbia mai giurato.

Inoltre - soprattutto - se si hackerano core, Dries e Webchick uccidono entrambi un gattino: -o

"Cosa non può fare l'hacking core per me, lo sviluppatore?"

• Il tuo sito può essere aggiornato per le versioni di sicurezza
• Il tuo sito può essere aggiornato per correggere fastidiosi bug nel core
• Il tuo sito può essere aggiornato per supportare nuovi moduli
• Le tue segnalazioni di bug e le richieste di supporto su core e contrib saranno in grado di rispondere
• Vuoi usare un CMS supportato, ecco perché hai scelto Drupal. Quando fai hacking core, con le parole di webchick , "Se fai hacking core, congratulazioni! Hai creato il tuo fork di Drupal, e ora tu e solo tu sei responsabile di mantenerlo!"

"Cosa non può fare l'hacking core per il mio cliente?"

• Il tuo sito può essere gestito da qualcun altro dopo aver licenziato il tuo cliente / aver vinto la lotteria / essere colpito da un autobus

"Cosa non può fare l'hacking core per la mia comunità?"

• Le segnalazioni di bug forniranno effettivamente informazioni utili per il manutentore dei moduli core o contrib.
• Se trovi un bug legittimo nel core che deve essere corretto, la linea tra "hacking core" e "diventare un collaboratore principale" va bene come semplicemente diffondere le tue modifiche e caricarle come patch in un problema rilevante. Viola! Il core è migliore per i tuoi sforzi e il tuo nome è associato alla restituzione del codice alla community.

Ognuno è un vincitore quando non fai hacking core!

Attualmente sto lavorando su un sito Web principale compromesso. Ho difficoltà a scoprire come qualcosa di semplice come il font viene impostato. Trascorro anche alcuni giorni a correggere un bug che è stato introdotto dall'hack core. L'ho trovato cercando una stringa nell'intero codice drupal.

Se non segui la struttura standard della programmazione in drupal, come può qualcun altro trovare e modificare le modifiche che introduci? Questo è particolarmente doloroso perché in drupal ogni singolo file php può implementare un hook. Prova a scoprire quale sta causando problemi.

"Non ci sono problemi che possono essere risolti solo dall'hacking del core? Cosa succede allora?"

Per rispondere a questa domanda, sì, a volte ci sono problemi che devi superare, questo significa che devi hackerare il core (o un modulo contrib).

In questo caso credo che sia giusto hackerare fino a quando inserisci molti commenti nel tuo codice compromesso e documenti tutto ciò che cambi.

Ad esempio, per qualsiasi modifica di core o contrib che faccio creo una patch. Se è generico e utile ad altre persone, lo invio a drupal.org in un problema, altrimenti è per uso personale.

Quindi eseguo il commit del file patch sul mio controllo versione insieme alla modifica del codice.

Questo significa che posso vedere cercando file patch se qualcosa è stato violato.

Inoltre, aggiungo anche un elenco di hack alla documentazione per sviluppatori per il sito (dovresti davvero avere la documentazione per sviluppatori per il bene di altri che potrebbero funzionare sul sito e per te stesso quando inevitabilmente dimentichi le cose).

In questa documentazione di hacking, elencherò ogni hack con ciò che fa l'hacking e perché, i moduli / file interessati, il nome del file patch che contiene il codice di hacking e un collegamento a un problema relativo a drupal.org se ce n'è uno (quasi sempre nel mio caso c'è).

Quindi tu e chiunque altro lavori sul sito in futuro hai un elenco completo di hack e non devi preoccuparti di rompere accidentalmente qualcosa con un aggiornamento.

Quindi, per il processo di aggiornamento, controllo il mio elenco di hack e ho una rapida occhiata ai file patch in tutti i moduli che sto aggiornando. Se c'è un hack e ha un problema con drupal.org, controllo il problema per vedere se l'ultima versione ha la patch inclusa, nel qual caso esplodo con l'aggiornamento e lo rimuovo dal mio elenco di hack certo guardando i messaggi di commit di drupal.org ciò che è stato eseguito era lo stesso della versione della patch che stai usando, o almeno funzionalmente lo stesso).

Se la patch non è stata impegnata, tutto ciò che devo fare è aggiornare i moduli e riapplicare le patch. In molti casi le patch si applicheranno comunque in modo pulito e il processo è semplice, ma a volte è necessario rileggere le patch per la nuova versione e quindi eseguire il commit della nuova versione della patch nel repository locale (insieme alla pubblicazione nel relativo problema di drupal.org ove applicabile).

Un'altra cosa che mi piace fare se ho patch o patch più sostanziali che interagiscono con la funzionalità principale di un modulo (o solo moduli personalizzati che si estendono su un modulo drupal.org), è controllare le note di rilascio del modulo aggiornato ( ciò significa che tutte le versioni tra la versione corrente e la versione a cui si sta eseguendo l'aggiornamento) e assicurarsi che non vi sia nulla che possa violare il codice. Nota: molti manutentori dei moduli sono bravi in ​​questi giorni nel dare note complete sulla versione, ma ci sono ancora molte cose che rilasciano le note sulla versione. In questo caso in alcuni casi passo attraverso tutti i messaggi di commit dalla mia versione corrente (questo di solito è solo nei casi in cui ho un codice complesso che interagisce profondamente con un altro modulo). Nota:

Quindi, dopo l'aggiornamento (su una copia di sviluppo del sito), testare accuratamente. Alla fine imparerai cosa significa completamente dopo che alcuni bug sono passati.

Quindi, quando è stato testato a sufficienza, aggiorna il sito live o spingi gli aggiornamenti locali verso l'alto o qualunque sia il tuo processo di distribuzione.

Il motivo per cui tutti dicono di non farlo, anche se è più facile: perché la maggior parte delle persone non ha un sistema come quello che ho descritto, quindi quando arriva il momento di fare aggiornamenti o il sito viene consegnato a qualcun altro per lavorare su, diventa un incubo e molto tempo (a volte un'enorme quantità di tempo) deve essere speso per risolvere bug e rintracciare gli hack e capire perché sono lì, ecc.

Se erediti mai un sito del genere, capirai completamente :)

Se guadagni da vivere installando e creando siti Web Drupal, è necessario tenerli aggiornati. Se la maggior parte dei tuoi siti finisce per essere terribilmente obsoleta, non sei professionale.