Modifica dei file core di WordPress

Perché?

A volte una soluzione semplice per modificare il comportamento di WordPress stesso o di un plugin potrebbe essere quella di modificare direttamente i file del plugin o di WordPress. Quando si presenta un'idea del genere, la solita risposta è:

Non hackerare il core.

Perché è generalmente una cattiva idea cambiare i file core?

Ritenere?

A volte, tuttavia, le cose che possono essere critiche per un sito sono semplicemente impossibili da fare, in un modo carino senza alterare i file core. In una situazione del genere, di cosa devi essere consapevole prima di andare avanti e iniziare a hackerare il core?

Come?

Hai considerato tutte le opzioni, ma l'unica soluzione è l'hacking dei file core. Come dovresti procedere? In che modo avere un nucleo alterato influenzerà i flussi di lavoro, come l'aggiornamento?

core

— googletorp
fonte

Sono fortemente in disaccordo con eventuali raccomandazioni per hackerare il core in quanto non ho ancora trovato una sola cosa su cui non avrei potuto aggirare. Le uniche persone che hanno un core business hacking per un sito di produzione sono quelle che non hanno assolutamente bisogno di leggere nulla su questo argomento in quanto probabilmente sono già nel core team di WordPress. Spiegare alle persone come farlo dà semplicemente a 99 persone su 100 che sicuramente non dovrebbero farlo per razionalizzare le loro decisioni. E odio davvero vederlo abilitato qui. JMTCW.

— MikeSchinkel,

Come follow-up, ecco un esempio di una domanda che è stata la prima risposta "Non è possibile" e ho risposto con un esempio che mostra come: wordpress.stackexchange.com/questions/972/#984 C'è (quasi sempre) un modo per fallo senza hacking core.

— MikeSchinkel,

Se cambi il core, dovrai ripetere le modifiche ogni volta che esegui l'upgrade e renderai l'installazione non standard, quindi è più difficile per le persone aiutarti. Basta creare un plug-in, un widget, un modello, un hook o uno dei tanti metodi wordpress che ti consente di non dover cambiare il core.

— Wadih M.,

Wadih ha ragione. Ho apportato modifiche ad alcuni dei file principali per correggere / migliorare / personalizzare varie cose e sono sempre stato frustrato durante l'aggiornamento perché devo controllare le modifiche e applicare le mie patch ai nuovi file. Ciò è ancora più frustrante quando i nuovi file sono troppo diversi da quelli vecchi e le posizioni delle modifiche non sono più evidenti (o addirittura presenti).

— Synetech

È come temevo; a volte quando non ci sono hook raffinati (come la modifica di I miei siti), gli unici hook che funzionano per il trucco dell'output buffer sono admin_body_classe admin_footerche significa catturare l' intera pagina . L'ho appena provato e ci sono> 2 MB di contenuto che devono essere cercati per la sezione pertinente, quindi analizzati e modificati prima dell'output. Oppure, posso aggiungere una riga di codice nella parte destra di my-sites.phpe utilizzare uno strumento diff per applicare la patch dopo gli aggiornamenti (supponendo che sia stata modificata). È davvero difficile opporsi alla modifica del core in scenari come questo.

— Synetech,

Risposte:

Se devi hackerare il core, considera di farlo in modo da renderlo estensibile per gli altri.

Aggiungi un gancio di azione

Nove volte su dieci, potresti fare quello che vuoi se solo ci fosse una do_actionchiamata extra in un file specifico. In tal caso, aggiungere l'azione, documentarla e inviare una patch tramite Trac . Se c'è una buona ragione per la tua patch (cioè non sei il solo ad usarla mai), probabilmente puoi aggiungerla al core.

Quindi, crea un plug-in personalizzato (non devi rilasciarlo / distribuirlo!) Che si collega a questo nuovo hook ed esegue qualsiasi funzione ti serva per farlo.

Rifattorizzare un file principale

Altre volte, potresti semplicemente avere bisogno di un pezzo di codice per comportarti diversamente. Passare una variabile per riferimento, ad esempio, o restituire un valore anziché eseguirne l'eco. Prenditi del tempo per sederti e riformattare il codice in modo che faccia quello che ti serve per farlo ... quindi invia una patch tramite Trac in modo che il resto di noi possa beneficiare del tuo lavoro.

Vedi un tema svilupparsi qui? L'hacking core non è necessariamente un no-no ... solo qualcosa che la maggior parte degli sviluppatori scoraggia fortemente per i nuovi utenti o programmatori principianti (se ci stai chiedendo come fare qualcosa, ti suggeriremo un plug-in ogni volta prima ancora di considerando di suggerire di hackerare il core).

L'hacking core è il modo in cui WordPress si sviluppa e si evolve, ma è pericoloso per qualcuno che sta imparando PHP o senza esperienza con i file WP. Si prega di iniziare con un plug-in prima di toccare core: se si interrompe un plug-in è possibile disinstallarlo rapidamente (rimuovendo tramite FTP se necessario) ... ma se si interrompe core, possono accadere cose brutte al tuo sito e potenzialmente al tuo anche il database.

Ma se ti trovi in una situazione in cui è inevitabile un hack di base, apporta la modifica. Inoltre, pubblica la modifica in una posizione di rilievo (se il tuo blog è ben visibile, ciò potrebbe essere sufficiente ... ma suggerisco Trac perché è così che le modifiche della community vengono inserite nella prossima versione). La tua modifica potrebbe essere il proiettile magico che potrebbe risolvere i problemi in un centinaio di siti diversi ... quindi contribuisci alla community che ti ha aiutato a costruire il tuo sito.

Se la modifica viene eseguita, il tuo hack diventa parte del core e non dovrai preoccuparti in futuro. In caso contrario, almeno hai una documentazione dettagliata su come implementare nuovamente l'hack dopo aver aggiornato WP in 3 mesi.

— EAMann
fonte

— Formulazione

Non hackerare il core.

Bene, perché è un suggerimento per utenti di primo livello, inesperti. Quei core di hacking interromperebbero la loro installazione, non possono garantire che le loro modifiche persistano un aggiornamento ecc.

Certo, hack core!

Sicuramente puoi effettivamente hackerare il core, ad esempio utilizzando un sistema di gestione delle versioni come SVN. Ti aiuta a mantenere le tue modifiche sul codice principale in linea con gli aggiornamenti del progetto. Aiuta anche a creare patch per Wordpress e inviarle al progetto.

L'hacking core sta infatti facendo evolvere Wordpress.

considerazioni

Se non si desidera installare un SVN completo e si sa ancora quali (alcuni) file sono stati modificati, è possibile utilizzare più strumenti di basso livello come Diff / Merge (per win: WinMerge ) o editor con funzionalità di confronto (ad es. Notepad ++ con Compare Plugin ). Su Linux puoi facilmente installare utility da riga di comando che fanno lo stesso. L' editor di Geany viene fornito con una bella integrazione della shell tra l'altro. .

Preferisco Eclipse PDT per i lavori pesanti. Ma non è per la modifica rapida o l'hacking.

Quindi direi che se stai usando gli strumenti giusti e vuoi prenderti cura di hackerare il core è la strada da percorrere. Se stai hackerando qualcosa che è rimasto su un altro server di utenti Noob (sì, Wordpress è piuttosto popolare), basta fornire un plug-in che può essere eliminato facilmente se si rompe qualcosa.

— hakre
fonte

L'hacking core non è MAI una buona soluzione a lungo termine. MAI.

— Fredy31,

@ Fredy31; È l'unico modo per mantenere aggiornata, funzionante e sicura la tua installazione di wordpress. Anche il "lungo periodo" di cui parli qui è davvero lungo se ci vogliono due anni o più tra fornire una patch a Wordpress e farla entrare. Ancora più a lungo per segnalare un problema senza patch. Stai attento.

— Hacre,

Ovviamente l'hacking core è problematico, ma trovo sorprendente la resistenza e il vetriolo ad esso. In quasi tutte le altre aree di FOSS, il fork è attivamente incoraggiato. Perché la personalizzazione di WordPress è così anatema? Ho visto innumerevoli altri progetti fare esattamente come hakre ha suggerito usando un RCS per creare una versione modificata di un programma, tenendo il passo con il bagagliaio. +1 per dare l'avvertimento ovvio ma dire la verità che è davvero possibile e dare l'evidente suggerimento di come può essere fatto con il minor grado di difficoltà.

— Synetech,

Oh, e ho appena ricordato che i temi dei bambini fanno esattamente questo! Quando crei un tema figlio, essenzialmente stai biforcando il genitore e ogni volta che il genitore viene aggiornato, devi copiare manualmente tutte le modifiche al figlio. Quindi questo odio per la modifica del core non è coerente con un altro identico comportamento di WordPress che ha accettato.

— Synetech,

I problemi sono:

Ogni volta che esegui un aggiornamento del core (ad es. A causa di una correzione di sicurezza, ecc.), Dovrai aggiornarlo manualmente, invece di eseguire l'aggiornamento automatico.
Se lo desideri, allora renditi la vita più semplice:
- contrassegnare ogni modifica con un marcatore comune (.eg // PATCH STARTe // PATCH END)
- utilizzare uno strumento come WinMerge per confrontare la fonte esistente con la nuova fonte e copiare tra le modifiche ove necessario.
- dovrai fare attenzione nel caso in cui l'area di codice che stai copiando è cambiata e apportare le modifiche appropriate alle tue patch
- essere consapevoli del fatto che si tratta di un lavoro "senza fine", che richiede tempo fatturabile, a meno che non si possa ricaricare il cliente per questo.
È possibile che si verifichino problemi di incompatibilità con i plug-in che prevedono che il core funzioni in un determinato modo; ciò richiederà ulteriori test

A volte questo è inevitabile al 100%, ma quasi sempre riesco a trovare un altro modo per raggiungere le cose o alterare le specifiche a causa del probabile costo del tempo impiegato a farlo. È solo un incubo per la manutenzione e molte persone scelgono di hackerare il core, invece di cercare la soluzione corretta.

— Dan Smart
fonte