Cum să editezi un plugin WordPress fără să strici procesul de actualizare

Probabil nu.

Metoda recomandată pentru a-ți include îmbunătățirile în plugin este: Trimite remedierile către dezvoltator și cere-i să le încorporeze în versiunea originală. Dacă modificările tale sunt mai degrabă personalizări, acest lucru nu se va întâmpla.

Dacă plugin-ul este scris într-un stil strict OOP, poți crea un al doilea plugin care extinde doar clasele din original așa cum ai nevoie (un fel de plugin copil). Din păcate, majoritatea dezvoltatorilor de plugin-uri nu văd această nevoie și nu scriu codul în consecință. Fii conștient de problema ordinii de încărcare.

Am putea ajuta mai bine dacă ai descrie ce plugin dorești să extinzi și ce anume vrei să modifici.

Din păcate, depinde în totalitate de plugin (sau mai exact, de autorul plugin-ului!) Dacă autorul a gândit proactiv și a creat plugin-ul într-un mod extensibil, atunci da, poți crea propriul tău PLUGIN care adaugă funcționalități la plugin-ul existent.

Ține cont de ce a menționat Toscho - ordinea plugin-urilor contează (linkul din nou este aici).

Cârlige (Hooks)

Cea mai comună metodă de a face un plugin extensibil este adăugarea de cârlige (action și filter hooks) pe care le poți folosi ulterior cu propriul plugin. Dacă ai un editor de cod bun (eu folosesc acum NetBeans), ar trebui să cauți în fișierele sursă ale plugin-ului următoarele: do_action și apply_filters. Dacă autorul plugin-ului a prevăzut aceste cârlige, aceasta este o modalitate foarte convenabilă și ușoară de a suprascrie valorile implicite sau de a injecta propriul cod.

Funcții Pluggable

Dacă autorul plugin-ului este priceput, dar folosește namespace-ul global pentru funcțiile plugin-ului, este posibil să fi încapsulat funcțiile în instrucțiuni condiționale if ( function_exists() ). Pentru a beneficia de acest lucru, trebuie să te asiguri că plugin-ul tău se încarcă primul (ceea ce poate fi o provocare). Tot ce trebuie să faci este să declari funcția cu exact același nume în exact același namespace, iar funcția ta va înlocui cea folosită de plugin.

Extensie

Dacă autorul plugin-ului este un bun programator OOP, este posibil să fi scris codul plugin-ului într-un mod suficient de granular, deschis pentru extensie (deoarece, cum ar spune GOF, este cu siguranță închis pentru modificare). Caută o granularitate ridicată în clasa plugin-ului - adică metode care efectuează sarcini mici și foarte specifice - care pot fi suprascrise în propria ta clasă care extinde clasa plugin-ului. Desigur, după cum menționează Toscho, clasa trebuie să fie arhitecturată într-un mod care permite suprascrierea și implementarea implicită nu trebuie să se auto-invoce complet.

Fork sau Patch

Dacă autorul plugin-ului folosește gitHub sau a deschis sursele într-un alt mod, poți trimite un patch autorului cu modificările propuse (cea mai bună variantă este să modifici plugin-ul pentru a-l face MAI flexibil sau puternic fără a elimina sau modifica funcționalitățile existente), sau poți descărca sursele, modifica header-ul plugin-ului în așa fel încât să nu mai primească actualizări când autorul original lansează o nouă versiune, și preferabil să trimiți versiunea actualizată autorului sau ca entitate separată direct pe WordPress. Atenție, dacă trimiți plugin-ul pe WP, va trebui să ai un site pentru el și să fii pregătit să îl susții dacă alții îl descarcă.

Știu că este o întrebare foarte veche, dar cred că am găsit soluția...

Am un plugin în care unul dintre developeri clienților mei l-a modificat până la limita directoarelor și subdirectoarelor, iar când este actualizat, fișierele sunt șterse și pluginul se defectează. Pentru a face pluginul original independent de orice actualizări de nucleu, am mutat fișierele și folderele modificate într-un plugin separat într-un director numit extension.

Folosind codul găsit la https://gist.github.com/wpsmith/af206df2cf6a38e4e2f0

Am adăugat clasa definită de Tarvis Smith în WPS_Extend_Plugin.php și am inclus-o în pluginul meu. Folosind clasa WPS_Extend_Plugin am direcționat directorul fișierelor/folderelor extinse către folderul țintă extension. Nu am întâlnit încă nicio eroare, dar nu sunt sigur dacă aceasta este modalitatea corectă de a extinde un plugin sau nu!

// Include clasa WPS_Extend_Plugin
require_once( 'classes/WPS_Extend_Plugin.php' );

// Extinde Sitepress Multilingual CMS
new WPS_Extend_Plugin( 'sitepress-multilingual-cms/sitepress.php', __FILE__, '3.9.0', 'CHERRY' );
// Extinde AddThis
new WPS_Extend_Plugin( 'extension', __DIR__, '0.1', 'CHERRY' );

Înțeleg că această întrebare este foarte veche, dar am simțit că acest răspuns ar putea ajuta pe cineva.

Dacă credeți că modificările ar fi utile comunității, vă rugăm să le trimiteți dezvoltatorului. Cu toate acestea, dacă modificările sunt specifice instalării dumneavoastră, puteți continua să citiți mai departe.

Am avut această problemă legată de transferul modificărilor la o versiune actualizată a unei teme. Am efectuat o diferență recursivă (diff) între old_version și modified_old_version, apoi am aplicat patch-ul creat pe noua versiune a temei folosind instrumentul patch.

Instrumentele de patch creează fișiere cu modificări care nu au putut fi aplicate automat. Am avut câteva astfel de cazuri și am putut identifica și aplica manual aceste modificări cu ușurință.

Când faceți modificări, trebuie să vă asigurați că nu schimbați spațierea pentru întregul fișier folosind funcții ale editorului cum ar fi auto-indentarea etc. Adică, faceți modificări doar acolo unde este necesar. Altfel, procesul de transfer al modificărilor va deveni mai consumator de timp ulterior.