Tilpassede databasetabeller Eksportere data

Som nevnt i den aller første artikkelen i denne serien er et av de store problemene med en egendefinert databasetabell det faktum at de ikke håndteres av eksisterende import- og eksportbehandlere. Denne artikkelen tar sikte på å løse dette problemet - men det bør bemerkes at det for øyeblikket ikke finnes en helt tilfredsstillende løsning.

La oss vurdere to scenarier:

Den tilpassede tabellen refererer til et innfødt WordPress-bord
Det tilpassede bordet er helt uavhengig av de innfødte bordene

Det verste fallet er det første. Ta eksempel på et tilpasset bord som holder logger over brukeraktivitet. Den refererer til bruker-ID, objekt-ID og objekttype - som alle refererer til data lagret i native WordPress-tabeller. Forestill deg nå at noen ønsker å importere alle dataene fra deres WordPress-side til en annen. Det er helt mulig at når du importerer et innlegg, for eksempel, må WordPress tildele det en ny ID til den, siden det allerede finnes et innlegg med den IDen på det andre nettstedet.

I denne situasjonen vil det være nødvendig å holde oversikt over slike endringer og oppdatere IDene referert i vårt bord. Dette er ikke så vanskelig. dessverre, WordPress Importer plugin-modulen som håndterer å importere data fra andre WordPress-nettsteder mangler de nødvendige krokene for å gjøre dette mulig. Som antydet i denne kommentaren, er det en mulighet for å lagre dataene i postmeta også. Dessverre resulterer dette i dupliserte data, og flyr i møte med database normalisering - vanligvis ikke en god ide. Endelig er det bare virkelig brukbart i et mindre antall brukstilfeller.

Det andre tilfellet unngår denne kompleksiteten, men krever fortsatt tilpassede import- og eksporthåndterere. Det er slik at vi skal demonstrere i de neste to artiklene. For konsistens med resten av serien vil vi imidlertid holde seg til aktivitetsloggbordet selv om det er et eksempel på tilfelle (1).

Bestemmer formatet

Først må vi bestemme formatet som vår eksportfil skal ta. Det beste formatet avhenger av naturen (eller "strukturen") av dataene og hvordan den skal brukes. Etter min mening er XML generelt bedre siden det håndterer en-til-mange relasjoner. Men noen ganger hvis dataene er tabulære, kan CSV være å foretrekke - spesielt for at det er enkelt å integrere med regnearkprogrammer. I dette eksemplet bruker vi XML.

The Mark-Up

Det neste trinnet er å opprette en admin side for å tillate brukere å eksportere dataene i loggbordet. Vi lager en klasse som legger til en side under menypunktet Verktøy. Denne siden vil inneholde litt mer enn en knapp, og ber om at brukeren laster ned eksportfilen. Klassen vil også legge til en handler for å lytte til skjemainnsendelsen og utløse filnedlastingen.

Først må vi ta en titt på klassens struktur, før du fyller ut detaljene i metodene sine.

 klasse WPTuts_Log_Export_Admin_Page / ** * Sidekrok suffiks * / statisk $ hook_suffix = "; statisk funksjonslast () add_action ('admin_menu', array (__ KLASS __, 'add_submenu')); add_action ('admin_init', array (__ CLASS__ , 'maybe_download')) statisk funksjon add_submenu ()  statisk funksjon maybe_download ()  statisk funksjonsvisning ()  WPTuts_Log_Export_Admin_Page :: load ();

De WPTuts_Log_Export_Admin_Page :: load () initialiserer klassen og kroker tilbakeringinger til de aktuelle handlingene:

add_submenu - Metoden som er ansvarlig for å legge til siden under Verktøy-menyen.
maybe_download - Denne metoden vil lytte til å sjekke om en forespørsel om nedlasting er sendt. Dette vil også sjekke tillatelser og nonces.

Eksportlytteren må ringes tidlig og før noen overskrifter sendes, da vi skal sette dem inn selv. Vi kunne koble den på i det, men siden vi bare lar eksportfilen lastes ned i administrasjonen, admin_init er mer hensiktsmessig her.

Å legge til en side på menyen er veldig enkel. For å legge til en side under Verktøy trenger vi bare å ringe add_management_page ().

 statisk funksjon add_submenu () self :: $ hook_suffix = add_management_page (__ ('Export Logs', 'wptuts-log'), __ ('Export Logs', 'wptuts-log'), 'manage_options', 'wptuts-export' ', array (__ KLASSE __,' skjerm '));

De $ hook_suffix her er suffikset som brukes til forskjellige skjermspesifikke kroker, diskutert her. Vi bruker det ikke her - men hvis du gjør det, er det en god idé å lagre verdien i en variabel, snarere enn å kodes hardt.

I det ovennevnte har vi angitt metoden vise() For å være tilbakeringingen til vår side, definerer vi dette neste:

 statisk funksjon display () echo ''; screen_icon (); ekko ''. __ ('Eksporter aktivitetslogger', 'wptuts-log'). '
'; ?>     
   
  Til slutt vil vi lytte etter når skjemaet ovenfor er sendt og utløse eksportfilnedlastingen.
  statisk funksjon maybe_download () / * Lytt til skjemainnlevering * / hvis (tomt ($ _ POST ['action']) || 'eksportlogger'! == $ _POST ['action']) returnere; / * Kontroller tillatelser og nonces * / if (! Current_user_can ('manage_options')) wp_die ("); check_admin_referer ('wptuts-eksport-logger', '_ wplnonce'); / * Trigger nedlasting * / wptuts_export_logs ();
 Alt som gjenstår er å skape funksjonen wptuts_export_logs () som lager og returnerer vår .xml-fil.
 
 Opprette eksportfilen
 Det første vi ønsker vår funksjon er å hente loggene. Hvis det er noen, må vi sette de riktige overskriftene og skrive dem ut i XML-format. Siden vi vil at brukeren skal laste ned en XML-fil, setter vi inn innholdstypen til text / xml og innholdsbeskrivelse til Filoverføring. Vi vil også generere et passende navn for nedlastingsfilen. Til slutt vil vi inkludere noen kommentarer - disse er helt valgfrie, men kan være nyttige for å instruere brukeren om hva de skal gjøre med den nedlastede filen.
 Siden i den forrige delen av denne serien har vi opprettet en API for vårt bord, trenger ikke vår eksportbehandler å berøre databasen direkte - og vi må heller ikke desinfisere $ args array som dette håndteres av wptuts_get_logs ().
  funksjon wptuts_export_logs ($ args = array ()) / * Query logger * / $ logs = wptuts_get_logs ($ args); / * Hvis det ikke er logger - abort * / hvis (! $ Logs) returnerer false; / * Opprett et filnavn * / $ sitename = sanitize_key (get_bloginfo ('name')); hvis (! tomt ($ sitenavn)) $ sitenavn. = '.'; $ filnavn = $ sitenavn. 'Wptuts-logger. . dato ('Y-m-d'). 'XML'; / * Skriv ut overskrift * / header ('Content-Description: File Transfer'); header ("Content-Disposition: attachment; filnavn =". $ filnavn); header ("Content-Type: text / xml; charset =". get_option ("blog_charset"), sant); / * Skriv ut kommentarer * / echo "\ n "; ekko"\ n "; ekko"\ n "; / * Skriv ut loggene * /
 Du vil legge merke til at vi har passert selve spørringsarrangementet som et argument for wptuts_export_logs () funksjon. Vi kunne ha hardkodet dette, men det er fornuftig å ikke. Selv om hensikten her er bare å eksportere alt i tabellen gir passering av spørringen som et argument oss muligheten til senere å legge til muligheten for å eksportere logger i en bestemt tidsramme eller for en bestemt bruker.
 Når du lager XML-filen, må vi sørge for at ingen verdier som skrives ut mellom kodene inneholder tegnene &, < eller >. For å sikre dette, sanitiserer vi dataene med ID Absint, og objekttyper og aktiviteter med sanitize_key (siden vi forventer at disse bare inneholder små bokstaver og understreker og bindestreker).
  / * Skriv ut logger til fil * / ekko ''; foreach ($ logger som $ logg) ?>  log_id); ?> activity_date, false); ?> bruker-ID); ?> object_id); ?> objekt); ?> aktivitet); ?>  ';
 Mer generelt kan du sanitere verdiene som skrives ut ved å pakke dem inn CDATA tag ved hjelp av følgende funksjon:
  / ** * Wraps den overførte strengen i en XML CDATA-tag. * * @param string $ string String å pakke inn i en XML CDATA tag. * @returnstreng * / funksjon wptuts_wrap_cdata ($ streng) if (seem_utf8 ($ string) == false) $ string = utf8_encode ($ string); komme tilbake '',']]]]>', $ streng). ']]>'; 
 Endelig vi exit() for å forhindre ytterligere behandling:
  / * Ferdig - nå avslutte * / exit ();
 Hvis du navigerer til vår eksportside, klikker du på Last ned aktivitetslogger, bør du laste ned en XML-fil.
 
 Sammendrag
 I denne opplæringen har vi sett på å eksportere data fra vårt tilpassede bord. Dessverre, hvor data refererer til native WordPress-tabeller, er dette i beste fall problematisk. Metoden som er skissert ovenfor er bare nyttig i tilfeller hvor dataene ikke gjør dette. Eksemplet som brukes (våre aktivitetslogger) hører selvsagt ikke inn i denne kategorien, men brukes bare for konsistens med resten av denne serien.
 Når dataene gjør referanse innfødte tabeller er det åpenbart nødvendig å importere det sammen med de innfødte tabellene, og ved å holde øye på eventuelle endringer i ID som oppstår under importen. For tiden er det ikke mulig med eksisterende import- og eksportbehandlere - og så er det eneste mulige alternativet å lage din egen. I enklere tilfeller der de egendefinerte dataene bare refererer til en enkelt innleggstype, er det mulig å designe import- og eksporthåndteringsprogrammene dine for å håndtere denne posttypen, samt dine egendefinerte data og informere brukeren om ikke å bruke den innfødte eksportøren for den posttypen.
 I neste del av denne serien skal vi opprette en enkel importhåndterer for den eksporterte .xml-filen.



		
			
	   
	




Kode

Tilpassede databasetabeller Importere data

Tilpassede databasetabeller Opprette tabellen