Tabele personalizate de baze de date Export de date

După cum sa menționat în primul articol al acestei serii, una dintre problemele majore cu o tabelă de baze de date personalizate este faptul că acestea nu sunt tratate de manipulatorii de import și export existenți. Acest articol vizează rezolvarea acestei probleme - dar trebuie remarcat că în prezent nu există o soluție complet satisfăcătoare.

Să luăm în considerare două scenarii:

Tabelul personalizat se referă la o tabelă WordPress nativă
Tabelul particularizat este complet independent de tabelele native

Scenariul "cel mai rău caz" este primul. Luați exemplul unei tabele personalizate care păstrează jurnalele activității utilizatorilor. Se referă ID-ul utilizatorului, ID-ul obiectului și tipul de obiect - toate se referă la datele stocate în tabelele WordPress native. Acum imaginați-vă pe cineva care vrea să importe toate datele de pe site-ul lor WordPress într-un al doilea. Este foarte posibil ca atunci când importați o postare, de exemplu, WordPress trebuie să îi aloce un nou ID, deoarece există deja o postare cu acel ID în cel de-al doilea site.

În această situație, ar fi necesar să urmăriți aceste modificări și să actualizați codurile de identificare menționate în tabelul nostru. Acest lucru nu este dificil în sine. din pacate, plug-in-ul WordPress Importator care se ocupă de importul de date de pe alte site-uri WordPress nu are cârligele necesare pentru a face acest lucru posibil. Așa cum sa sugerat în acest comentariu, un potențial lucru în jurul este de a stoca datele în post meta de asemenea. Din păcate, acest lucru are ca rezultat date duplicate și zboară în fața normalizării bazei de date - în general, nu este o idee bună. În cele din urmă, este într-adevăr funcțională într-o minoritate de cazuri de utilizare.

Cel de-al doilea caz evită această complexitate, dar necesită în continuare manipulatori importatori și exportatori personalizați. Acesta este cazul pe care îl vom demonstra în următoarele două articole. Cu toate acestea, pentru consecvența cu restul seriei, vom fi lipiți de tabelul cu jurnale de activitate, chiar dacă este un exemplu de caz (1).

Decideți formatul

Mai întâi trebuie să decidem formatul pe care trebuie să-l folosească fișierul nostru de export. Cel mai bun format depinde de natura (sau "structura") datelor și de modul în care acestea urmează să fie utilizate. În opinia mea, XML este, în general, mai bun, deoarece gestionează relațiile unu-la-multe. Cu toate acestea, uneori, dacă datele sunt tabele, este preferabil CSV - în special pentru ușurința de integrare cu aplicațiile de calcul tabelar. În acest exemplu vom folosi XML.

Mark-Up

Următorul pas este să creați o pagină de admin pentru a permite utilizatorilor să exporte datele în tabelul de jurnal. Vom crea o clasă care va adăuga o pagină sub elementul de meniu "Instrumente". Această pagină va conține doar un buton, solicitând utilizatorului să descarce fișierul de export. Clasa va adăuga, de asemenea, un handler pentru a asculta trimiterea formularului și a declanșa descărcarea fișierului.

Mai întâi, să aruncăm o privire asupra structurii clasei, înainte de a completa detaliile metodelor sale.

 clasa WPTuts_Log_Export_Admin_Page / ** * Suita de hârtie pentru pagină * / static $ hook_suffix = "; încărcare funcțională statică () add_action ('admin_menu', array (__ CLASS __, 'add_submenu')); , 'maybe_download')); funcția statică add_submenu ()  funcția statică maybe_download ()  afișarea funcției statice ()  WPTuts_Log_Export_Admin_Page :: load ();

WPTuts_Log_Export_Admin_Page :: sarcină () inițializează clasele și invită la apeluri la acțiunile corespunzătoare:

add_submenu - Metoda responsabilă pentru adăugarea paginii în meniul Instrumente.
maybe_download - Această metodă va asculta să verifice dacă o solicitare de descărcare a fost trimisă. Aceasta va verifica, de asemenea, permisiunile și noncesele.

Ascultătorul de export trebuie să fie chemat mai devreme și înainte de trimiterea oricăror anteturi, așa cum le vom stabili noi înșine. Am putea să-l prindem init, dar deoarece vom permite ca fișierul de export să fie descărcat în admin, admin_init este mai potrivită aici.

Adăugarea unei pagini în meniu este foarte simplă. Pentru a adăuga o pagină sub Instrumente, trebuie doar să sunăm add_management_page ().

 funcția statică add_submenu () self :: $ hook_suffix = add_management_page (__ ('Export logs', 'wptuts-log'), __ ('Export logs', 'wptuts-log' ', matrice (__ CLASS __,' afișare '));

$ hook_suffix aici este sufixul folosit pentru diferite cârlige specifice ecranului, discutate aici. Nu o folosim aici, dar dacă o faci, ideea sa bună este de a-și păstra valoarea într-o variabilă, mai degrabă decât să-l codifice greu.

În cele de mai sus am setat metoda afişa() pentru a fi apelul pentru pagina noastră, definim următoarele:

 afișarea funcției statice () echo '„; screen_icon (); echo "". __ ("Jurnal de activitate de export", "wptuts-log"). '
„; ?>     
   
  În cele din urmă, dorim să ascultăm când este trimis formularul de mai sus și să declanșăm descărcarea fișierului de export.
  funcția statică may_download () / * Ascultă pentru trimiterea formularului * / if (empty $ _ POST ['action']) || 'export-logs'! == $ _POST ['action']) return; / * Verificați permisiunile și nonces * / if (! Current_user_can ('manage_options')) wp_die ("); check_admin_referer ('wptuts-export-logs', '_ wplnonce'
 Tot ce rămâne rămâne de a crea funcția wptuts_export_logs () care creează și returnează fișierul .xml.
 
 Crearea fișierului de export
 Primul lucru pe care vrem să-l facem este să recuperăm bustenii. Dacă există, trebuie să setăm anteturile corespunzătoare și să le tipărim în format XML. Deoarece vrem ca utilizatorul să descarce un fișier XML, vom seta tipul de conținut text / xml și Content-Description la Transfer de fișier. De asemenea, vom genera un nume potrivit pentru fișierul de descărcare. În cele din urmă, vom include câteva comentarii - acestea sunt în întregime opționale, dar pot fi utile în instruirea utilizatorului cu privire la ce să facă cu fișierul descărcat.
 Deoarece în partea anterioară a acestei serii am creat un API pentru masa noastră, managerul nostru de export nu are nevoie să atingă direct baza de date - și nici nu trebuie să dezinfectăm $ args deoarece acest lucru este gestionat de către wptuts_get_logs ().
  funcția wptuts_export_logs ($ args = array ()) / * Loguri de interogare * / $ logs = wptuts_get_logs ($ args); / * Dacă nu există jurnale - abort * / if (! $ Logs) return false; / * Creați un nume de fișier * / $ sitename = sanitize_key (get_bloginfo ('name')); dacă (! gol ($ sitename)) $ sitename. = '.'; $ filename = $ sitename. 'Wptuts-busteni.' . data ("Y-m-d"). '.Xml'; / * Print header * / header ('Content-Description: File Transfer'); antet ("Conținut-Dispoziție: fișier atașat; fișier nume =". $ filename); antet ("Content-Type: text / xml; / * Imprimare comentarii * / echo "\ n "; echo"\ n "; echo"\ n "; / * Imprimați jurnalele * /
 Veți observa că am trecut mulțimea reală de interogări ca argument pentru wptuts_export_logs () funcţie. Am putea codifica greu acest lucru, dar are sens să nu. Deși intenția aici este doar de a exporta Tot în tabel, transmiterea interogării ca argument ne permite să adăugăm mai târziu opțiunea de a exporta jurnale într-un anumit interval de timp sau pentru un anumit utilizator.
 Când creați fișierul XML, trebuie să vă asigurați că nici o valoare imprimată între etichete nu conține caracterele &, < sau >. Pentru a asigura acest lucru, pentru ID-urile cu care ne dezinfectăm datele absint, și tipurile și activitățile obiectului cu sanitize_key (deoarece ne așteptăm ca acestea să conțină numai cifre alfanumerice, subliniere și cratime).
  / * Imprimați jurnalele în fișier * / echo '„; foreach ($ logs ca $ log) ?>  log_id); ?> activity_date, false); ?> numele de utilizator); ?> object_id); ?> object_type); ?> activitate); ?>  „;
 În general, puteți să dezinstalați valorile imprimate prin ambalarea lor în interior CDATA eticheta utilizând următoarea funcție:
  / ** * Împachetează șirul transferat într-o etichetă XML CDATA. * * @param string $ string String pentru a înfășura o etichetă XML CDATA. * stringul retur * / funcția wptuts_wrap_cdata ($ string) if (pare_utf8 ($ string) == false) $ string = utf8_encode ($ string); întoarcere '',]]]]>', $ string). ']]>'; 
 În cele din urmă, noi Ieșire() pentru a preveni orice prelucrare ulterioară:
  / * Terminat - acum ieșire * / exit ();
 Navigând la pagina noastră de export, făcând clic pe "Descarcă jurnalele de activitate" ar trebui să solicite descărcarea unui fișier XML.
 
 rezumat
 În acest tutorial ne-am uitat la exportul datelor din tabelul nostru personalizat. Din păcate, în cazul în care datele se referă la tabelele WordPress native, acest lucru este cel mai bine problematic. Metoda descrisă mai sus este utilă numai pentru cazurile în care datele nu fac acest lucru. Exemplul folosit (jurnalele noastre de activitate), evident, nu se încadrează în această categorie, ci este folosit pur și simplu pentru a asigura coerența cu restul acestei serii.
 Când datele face tabelele native de referință, este evident necesar să le importăm împreună cu tabelele native și, în acest mod, să urmărim orice schimbări în ID-urile care apar în timpul importului. În prezent, acest lucru nu este posibil cu manipulatorii de import și de export existenți - și astfel singura opțiune funcțională este să creați propria dvs. În cazurile mai simple în care datele personalizate se referă doar la un singur post, este posibil ca designerii dvs. de manipulare pentru import și export să se ocupe de tipul respectiv de post și de datele dvs. personalizate și să informeze utilizatorul să nu folosească exportatorul nativ pentru acel post.
 În următoarea parte a acestei serii vom crea un handler de import simplu pentru fișierul .xml exportat.



		
			
	   
	




Cod

Tabele de baze de date personalizate Importarea datelor

Tabele de baze de date personalizate Crearea tabelei