Acest articol descrie modul de detaliere a procesului de creare a unui modul simplu pentru DLE cu cache și propriile șabloane. În primul rând, vom analiza modulul fără un șablon și apoi îl vom adăuga cu propriul nostru șablon. Rezultatul articolului va fi un modul funcțional fără admin, apelat oriunde pe site prin șirul de conectare.
Firește, rezultatul muncii modulului este mai bun decât caching-ul, deoarece nu avem nevoie de cereri inutile la baza de date. De asemenea, nu avem nevoie de un șablon de module, dar pentru un exemplu voi da codul modulului cu un șablon, deoarece conexiunea corectă a șablonului este, de asemenea, foarte importantă și, cu un modul mai mult sau mai puțin complex, economisește o mulțime de resurse prin reducerea codului modulului însuși.
Cercul de sarcini este definit, puteți începe să scrieți codul. Amintiți-vă că DLE are un API. și pare logic să folosiți un API gata pentru această sarcină, însă recomand că nu o folosiți deloc (în special!) în module complexe.
De ce nu folosiți DLE_API
Este simplu - este foarte curba de lucru care nu se dezvolta la fel de mult de la versiunea 8.2 (ca din acest scris, versiunea curentă a motorului - 10.0 și în comparație cu versiunea anterioară fixată doar un bug cu imposibilitatea înregistrării unui utilizator prin API-ul, nici o modificare nu sunt efectuate).
Utilizarea lui_api crește semnificativ cantitatea de memorie RAM consumată. care este absolut, deloc bine.
Metodele descrise în dle_api diferă de funcția originală.
Sfat general: dacă aveți nevoie de o metodă sau o funcție de la dle_api - copiați-o în modulul dvs.
Poate că evoluțiile mele modeste vor fi suficiente pentru un set de metode și funcții care pot fi folosite în viitor, dar acesta este un subiect pentru un articol separat.
Noi scriem codul
Înainte de a scrie orice modul (cu excepția fișierelor care sunt responsabile de ajax), trebuie, fără întârziere, de la început să scrieți o linie:
Acest lucru va împiedica utilizatorul să acceseze direct fișierul modulului, ceea ce înseamnă că acesta nu va putea să transfere parametrii proprii în modul și să hackeze site-ul prin acest modul. Cred că importanța acestui moment este dificil de supraestimat, dar cu toate acestea, mă confrunt adesea cu lipsa unui astfel de design în codul modulului.
Configurare și cache
Am decis să mă ocup de acest punct în detaliu, tk. aceasta este una dintre cele mai frecvente întrebări adresate dacă o persoană decide să-și scrie propriul modul.
Configurația modulului este scrisă cel mai bine într-o matrice - aceasta va face posibilă crearea unei memorii cache fără probleme pentru fiecare apel al modulului cu un set diferit de configurații, în cazurile noastre pentru fiecare utilizator.
Voi explica de ce. Să presupunem că am scris un modul, este stocat în cache, iar linia de creare a cache-ului arată astfel:
în cazul în care:
- $ var1. $ var2. $ var3. $ var4 - variabile de modul.
- $ myModule - text care ar trebui să fie stocat în cache.
iar linia de creare a cache-ului va fi:
Deci nu trebuie să urcăm deloc în acest cod, totul se va întâmpla automat.
Utilizați prefixele și sufixele memoriei cache - aceasta va asigura că cache-ul este șters automat și, de asemenea, permite (dacă este necesar) crearea de cache-uri separate pentru diferite grupuri de utilizatori.
Pentru claritate, să aruncăm o privire la imagine:
Deci, în cazurile noastre avem nevoie de arhivele prefixelor. cache-ul modulului trebuie să fie resetat numai când se adaugă sau se elimină știri (mi-a plăcut, puteți utiliza atât calendar cât și rss). Codul de creare a config-urilor și a cache-urilor nu va fi dat în așa fel încât să nu se confundă cu articolul, tot codul modulului poate fi vizualizat mai jos.
Textul cache-ului este rezultatul lucrării modulului, care va fi scris în cache, totul este simplu.
cache ID-ul sau numele - aici este cel mai bine să treacă cacheName variabila $, despre care a fost scris mai sus, iar $ config variabilă [ „piele“] - acest lucru pentru a avea cache-uri diferite pentru diferite site-ul șabloane.
cache Prefixul - poate lua două valori, adevărate sau false, în cazul în care a trecut la true, pentru fiecare grup de utilizatori va crea un fișier cache, este necesar, în cazul în care diferite grupuri de utilizatori au nevoie pentru a afișa conținut diferit.
Blank universal pentru un modul cu memorie cache, fără șablon
Având în vedere toate cele de mai sus, putem crea un simplu spațiu pentru modulul care va utiliza memoria cache, dar nu va folosi șablonul în activitatea sa. Numai 15 linii de cod! Este destul de simplu, nu?
O mică deviere:
Vă sfătuiesc să utilizați același tip de variabile de module și variabile de configurare a modulelor, adică
pare mult mai ușor de citit decât
Cu toate acestea, eu nu folosesc linia de jos în dle, deoarece o dată din acest motiv, filtrul din dork a lucrat și modulul nu a funcționat, deși acesta este doar un caz izolat.
Acum puteți tipări rezultatul în mod normal:
Aici trebuie remarcat faptul că, în cazul cache-ul va fi scris un singur deget de la picior - DLE nu va „conta cache“ și de a crea unul nou, deci trebuie să scrie altceva decât zero.
Codul final al modulului nostru va fi următorul: Numai 20 de linii de cod - și vom obține o soluție gata la o problemă specifică.
Codul modulului funcționează complet și poate fi folosit într-un proiect real, dar acest cod este dat să vă familiarizați cu principiile corect de scris module pentru DLE.
Acest lucru ar putea fi finalizat, dar mai sus am promis să arat codul modulului folosind propriul meu șablon.
Articole similare
Trimiteți-le prietenilor: