Utilizarea cârligelor WordPress pentru a curăța codul, activarea și dezinstalarea

Autorii de pluginuri dedică atât de mult timp și energie pentru funcționalitatea principală a produselor lor, încât permit lucrurilor mai puțin importante să scape.

Luați activarea și dezactivarea, de exemplu. În timp ce cârligele de activare sunt larg răspândite - multe plugin-uri trebuie să adauge unele opțiuni, să șterge regulile de rescrie, poate să creeze un tabel de bază de date sau să verifice diferențele de versiuni la instalare - cârligele de dezactivare și dezinstalare sunt mult mai puțin frecvente.

Ideea aici? Mulți autori de pluginuri nu își iau timp să se curețe după ei înșiși. Instalarea WordPress chiar are nevoie de tabelul personalizat pe care l-ați creat după eliminarea pluginului? De ce să nu ștergeți câteva opțiuni care sunt exclusive pentru plugin înainte de a-l arunca la gunoi?

În acest articol, vă voi arăta cum să utilizați cârligele de activare, dezactivare și dezinstalare pentru a vă inițializa pluginul și a curăța lucrurile mai ușor după ce utilizatorii au terminat cu produsul dvs.

• Cârligul de activare
  • Secvența de instalare
  • Spălarea regulilor de rescrie
  • Crearea tabelelor bazei de date
  • Verificări ale dependenței
• Cârligul de dezactivare
• Cârligul de dezinstalare
• Securitate suplimentară
• Este timpul să curățați

Notă: Dacă intenționați să parcurgeți acest articol, vă sugerez insistent să aruncați o privire la secțiunea „Securitate suplimentară” de la sfârșit, care completează codul cu câteva verificări de securitate valoroase. De asemenea, dacă aveți nevoie de ajutor cu cârligele pentru pluginuri WordPress, iată o reîmprospătare rapidă despre utilizarea cârligelor WordPress și cum să activați o funcție în WordPress.

Cârligul de activare

Deși cârligul de activare este destul de simplu, instalarea acestuia este un caz puțin special, așa că va trebui să fim atenți la succesiunea evenimentelor. Înainte de a intra în toate acestea, iată un exemplu simplu:

Cheia tuturor este funcția register_activation_hook() . Primul parametru este calea către fișierul plugin principal; al doilea parametru definește funcția de rulat. Pe plan intern, funcția register_activation_hook() este un înveliș pentru acțiunea „activate_[plugin_name]”, dar din moment ce este puțin mai ușor de utilizat, este neobișnuit să vedeți hook-ul în pluginuri.

Secvența de instalare

Înțelegerea secvenței de instalare este importantă, deoarece împiedică utilizarea metodelor cu care ați fi obișnuit. register_activation_hook() este apelat între utilizator care face clic pe linkul de activare și, în consecință, vede notificarea de activare. Se rulează pe o pagină intermediară, care redirecționează imediat înainte ca orice cârlige să aibă șansa de a rula.

Să ne uităm la un exemplu pentru a vedea de ce este o mare dezamăgire:

Spălarea regulilor de rescrie

O serie de pluginuri creează tipuri de postări personalizate. Stergerea regulilor de rescriere la activare pentru a vă asigura că utilizatorii nu primesc o eroare 404 atunci când vizitează o postare din noul tip de postare personalizată este o mișcare inteligentă.

Codul de mai jos pare logic, dar va eșua.

Pare perfect în regulă. Este creat tipul de postare personalizat și, la activare, ștergem regulile de rescrire. Problema este că tipurile de postări personalizate nu au fost încă create când ștergem regulile de rescrire.

Iată cum arată fluxul procesului:

1. Utilizatorul instalează pluginul.
2. Utilizatorul face clic pe linkul de activare.
3. O pagină intermediară rulează doar cârligul de activare, nimic altceva. Acest lucru șterge regulile de rescriere.
4. Pluginul este activ și codul rulează ca de obicei. Tipul de postare personalizat este înregistrat.

O soluție postată pe Stack Overflow, care este aprobată oficial de WordPress Codex, rezolvă mica noastră problemă. Soluția implică adăugarea unei opțiuni pentru a indica faptul că pluginul tocmai a fost instalat.

Dacă această opțiune există, facem activitățile noastre de activare și apoi o ștergem.

Ceva de genul:

Personal, nu-mi place prea mult această soluție. Problema este că verificarea pe linia opt rulează la fiecare încărcare a paginii. Nu este nimic de îngrijorat, deoarece nu va pune o sarcină mare pe serverele dvs. și nu va încetini site-ul pentru utilizatori. Este o verificare foarte rapidă cu un impact neglijabil asupra performanței. Este, totuși, inutil în 99,9% din timp.

Există o soluție mai bună menționată în Codex în documentația pentru funcția flush_rewrite_rules() . În această soluție, folosim modularitatea funcțiilor noastre pentru a înregistra separat tipul de postare personalizat la activare:

În loc să ne bazăm pe o verificare care trebuie să ruleze tot timpul, folosim funcția de activare pentru a ne înregistra tipurile de postări. Rețineți că odată ce pluginul nostru este activat, tipurile de postări vor fi întotdeauna înregistrate din hook-ul de init .

Acesta este un exemplu trist al Codexului fiind peste tot. În general, WordPress are o documentație bună, dar dacă ceva pare a fi risipitor sau ilogic, nu vă fie teamă să faceți ceva de cercetare.

Crearea tabelelor bazei de date

O altă sarcină pe care o îndeplinesc unele pluginuri este crearea tabelelor de baze de date. De cele mai multe ori, acest lucru este inutil, dar există câteva cazuri de utilizare legitime.

Acest exemplu din articolul Codex despre Crearea tabelelor arată cum pot fi utilizate mai multe apeluri de activare:

Prima funcție, jal_install() creează un nou tabel de bază de date. A doua funcție, jal_install_data adaugă date inițiale la tabel. În loc să folosim register_activation_hook() pentru a adăuga o funcție care conține tot acest cod, putem folosi register_activation_hook mai multe ori.

Aceasta este o practică excelentă pentru modularitate. Pe de o parte, nu trebuie să adăugați date de testare inițiale - este la fel de simplu ca și îndepărtarea cârligului de activare - astfel încât să puteți păstra funcția intactă. Pe de altă parte, sunteți liber să reutilizați aceste funcții oriunde, deoarece sunt separate.

Verificări ale dependenței

O altă sarcină comună pentru funcția de activare este verificarea dependențelor. Pluginul dvs. se poate baza pe o anumită versiune de WordPress, un alt plugin sau chiar pe o anumită versiune de PHP.

Codul de mai jos verifică o versiune minimă WP și PHP și redirecționează utilizatorul (fără a activa pluginul) dacă este necesar:

Cârligul de dezactivare

Cârligele de dezactivare rulează atunci când un utilizator a dezactivat un plugin, dar înainte ca acesta să fie dezinstalat (șters). Cârligele de dezactivare sunt utilizate în același mod ca și cârligele de activare:

Dezactivarea înseamnă că utilizatorul a dezactivat doar pluginul dvs., așa că nu veți dori să faceți atât de mult cât ați face în timpul unei dezinstalări. Poate doriți să ștergeți regulile de rescriere, dar în această etapă, nu veți dori să scăpați de toate opțiunile și de tabelul bazei de date (dacă aveți unul).

Acest lucru este destul de simplu, dar voi acorda o atenție deosebită spălării regulilor de rescriere, deoarece, din nou, acestea sunt problematice.

Codexul recomandă să le faceți așa cum se arată mai jos, dar acest lucru nu funcționează :

Motivul pentru care acest lucru nu funcționează este același ca înainte. Rularea unei dezactivări efectuează init hook, ceea ce înseamnă că, pe măsură ce ne dezactivăm pluginul, înregistrăm și tipul nostru de postare personalizat. Regulile de rescriere sunt eliminate, dar țin cont de tipul de postare personalizat.

Un bilet Trac este în vigoare pentru a rezolva acest lucru, dar până atunci, nu vă pot oferi o modalitate foarte bună de a face acest lucru. Singura modalitate prin care am descoperit că funcționează este să șterg cu totul regulile de rescriere:

Deși acest lucru a funcționat pentru mine în trecut, nu l-aș recomanda. Introduce o incertitudine mai mare decât problema de a avea câteva reguli suplimentare de rescriere. Aș prefera să afișez o notă utilizatorilor prin care le-aș cere să viziteze setările de permalink după dezactivare, ceea ce ar șterge regulile de rescriere. Până când se implementează o soluție mai bună, suntem blocați cu asta... scuze!

Cârligul de dezinstalare

Există două moduri de a rula codul atunci când dezinstalați un plugin. Puteți utiliza cârligul de dezinstalare prin register_uninstall_hook() sau puteți utiliza un fișier dedicat uninstall.php în pluginul dvs. Vă voi arăta pe amândouă, dar metoda preferată este să utilizați fișierul de dezinstalare.

Problema principală cu cârligul de dezinstalare este că „împiedecă rularea fișierului plugin principal în timpul dezinstalării, ceea ce poate fi problematic dacă pluginul rulează cod în spațiul global. De asemenea, este mai bine prin faptul că codul de dezinstalare este centralizat.” – Scott Riley

Codul de mai jos arată procesul de dezinstalare folosind un cârlig de bază:

După cum am discutat, aceasta nu este cea mai bună soluție. O modalitate mult mai bună de a gestiona dezinstalările este să utilizați fișierul uninstall.php . Tot ce trebuie să faceți este să-l creați și va fi folosit dacă este disponibil.

După cum puteți vedea, aceasta este de fapt o soluție mai simplă. Cel mai bun din toate, este autonom.

Securitate suplimentară

Nu am vrut să complic prea mult exemplele prezentate până acum cu probleme legate de securitate, dar ar trebui să luați câțiva pași pentru a vă asigura că numai cei cărora li se permite să facă acest lucru pot executa aceste acțiuni.

Utilizați următorul fragment pentru activare și dezactivare:

Acest bloc de cod se asigură că utilizatorul are permisiunile pentru a efectua această acțiune și că acțiunea a apărut pe pagina corespunzătoare. Acest lucru ar trebui să protejeze împotriva celor mai multe încercări rău intenționate.

Procesul de dezinstalare este special, așa că va trebui să folosim un cod ușor diferit:

Este timpul să curățați

Dacă pluginul dvs. adaugă lucruri la WordPress, atunci este datoria dvs. ca dezvoltator să îl eliminați atunci când un utilizator decide să vă ștergă pluginul.

Utilizarea metodelor de activare, dezactivare și dezinstalare descrise mai sus vă va permite să construiți un sistem care să facă acest lucru în siguranță și în siguranță. De asemenea, recomand să citiți acest fir Stackexchange, care prezintă aceste procese în mediile OOP.

Dacă nu sunteți încă membru WPMU DEV, înscrieți-vă astăzi pentru o probă gratuită, complet fără riscuri. În calitate de membru, veți avea acces la toate pluginurile noastre grozave și la serviciul de găzduire extraordinar de rapid, plus asistență expertă 24/7 pentru toate întrebările și problemele dvs. legate de WordPress.

• Dezvoltatori WordPress
• Cârlige WordPress