Zoals vermeld in het eerste artikel van deze serie, is een van de grootste problemen met een aangepaste databasetabel het feit dat ze niet worden afgehandeld door bestaande import- en exporthandlers. Dit artikel probeert dit probleem aan te pakken, maar er moet worden opgemerkt dat er momenteel geen volledig bevredigende oplossing is.
Laten we twee scenario's overwegen:
Het 'worst case'-scenario is het eerste. Neem het voorbeeld van een aangepaste tabel met logboeken van gebruikersactiviteiten. Het verwijst naar gebruikers-ID, object-ID en objecttype - die allemaal verwijzen naar gegevens die zijn opgeslagen in de oorspronkelijke WordPress-tabellen. Stel je nu voor dat iemand alle gegevens van zijn WordPress-site wil importeren in een tweede. Het is heel goed mogelijk dat bij het importeren van een bericht WordPress er een nieuwe ID aan moet toewijzen, omdat er al een bericht met die ID in de tweede site kan voorkomen.
In deze situatie is het noodzakelijk om dergelijke wijzigingen bij te houden en de ID's waarnaar in onze tabel wordt verwezen bij te werken. Dit is op zichzelf niet zo moeilijk. helaas, de invoegtoepassing WordPress Importer die het importeren van gegevens van andere WordPress-sites afhandelt, mist de nodige haken om dit mogelijk te maken. Zoals in deze opmerking wordt gesuggereerd, is een mogelijke oplossing voor het opslaan van de gegevens ook in post-meta. Jammer genoeg resulteert dit in dubbele gegevens, en vliegt in het gezicht van gegevensbestandnormalisering - over het algemeen geen goed idee. Ten slotte is het alleen echt werkbaar in een minderheid van de use cases.
Het tweede geval vermijdt deze complexiteit, maar vereist nog steeds aangepaste import- en exporthandlers. In dit geval zullen we in de volgende twee artikelen demonstreren. Voor consistentie met de rest van de serie blijven we echter bij de tabel met activiteitenlogs, ook al is dit een voorbeeld van case (1).
Eerst moeten we beslissen welk formaat ons exportbestand moet hebben. Het beste formaat hangt af van de aard (of de 'structuur') van de gegevens en hoe deze moet worden gebruikt. Naar mijn mening is XML over het algemeen beter omdat het omgaat met een-op-veel relaties. Soms echter, als de gegevens tabulair zijn, kan CSV de voorkeur hebben, met name vanwege het gemak van integratie met spreadsheetapplicaties. In dit voorbeeld gebruiken we XML.
De volgende stap is het maken van een beheerderspagina zodat gebruikers de gegevens in de logtabel kunnen exporteren. We zullen een klasse maken die een pagina zal toevoegen onder het menu-item 'Tools'. Deze pagina bevat niet meer dan een knop en vraagt de gebruiker om het exportbestand te downloaden. De klas voegt ook een handler toe om naar de formulierinzending te luisteren en het downloaden van het bestand te starten.
Laten we eerst de structuur van de klas bekijken, voordat de details van de methoden worden ingevuld.
class WPTuts_Log_Export_Admin_Page / ** * Het suffix achtervoegsel * / static $ hook_suffix = "; statische functie laad () add_action ('admin_menu', array (__ CLASS __, 'add_submenu')); add_action ('admin_init', array (__ CLASS__ , 'maybe_download')); statische functie add_submenu () statische functie maybe_download () statische functie weergave () WPTuts_Log_Export_Admin_Page :: load ();
De WPTuts_Log_Export_Admin_Page :: load ()
initialiseert de klasse en haakt callbacks naar de juiste acties:
add_submenu
- De methode die verantwoordelijk is voor het toevoegen van de pagina onder het menu Tools.maybe_download
- Deze methode zal luisteren om te controleren of een downloadaanvraag is ingediend. Hiermee worden ook machtigingen en nonces gecontroleerd. De exportlistener moet vroeg worden opgeroepen en voordat headers worden verzonden, omdat we deze zelf gaan instellen. We zouden het kunnen aansluiten in het
, maar omdat we alleen toestaan dat het exportbestand wordt gedownload in de admin, admin_init
is hier meer geschikt.
Een pagina toevoegen aan het menu is heel eenvoudig. Om een pagina toe te voegen onder Extra hoeven we alleen maar te bellen add_management_page ()
.
statische functie add_submenu () self :: $ hook_suffix = add_management_page (__ ('Export Logs', 'wptuts-log'), __ ('Export Logs', 'wptuts-log'), 'manage_options', 'wptuts-export ', array (__ CLASS __,' display '));
De $ hook_suffix
hier is het achtervoegsel dat wordt gebruikt voor verschillende schermspecifieke hooks, die hier worden besproken. We gebruiken het hier niet - maar als je het doet, is het een goed idee om de waarde ervan in een variabele op te slaan in plaats van deze hard te coderen.
In het bovenstaande hebben we de methode ingesteld display ()
om de callback voor onze pagina te zijn, definiëren we dit volgende:
statische functieweergave () echo ''; screen_icon (); echo ''. __ ('Exporteer activiteitenlogboeken', 'wptuts-log'). '
'; ?>Tot slot willen we luisteren wanneer het bovenstaande formulier wordt ingediend en het exportbestand downloaden starten.
statische functie maybe_download () / * Luister naar formulierinzending * / if (empty ($ _ POST ['action']) || 'export-logs'! == $ _POST ['action']) terug; / * Controleer machtigingen en nonces * / if (! Current_user_can ('manage_options')) wp_die ("); check_admin_referer ('wptuts-export-logs', '_ wplnonce'); / * Trigger download * / wptuts_export_logs ();Het enige wat overblijft is om de functie te maken
wptuts_export_logs ()
die ons .xml-bestand maakt en retourneert.
Het exportbestand maken
Het eerste wat we willen dat onze functie is om de logs op te halen. Als dit het geval is, moeten we de juiste berichtkoppen instellen en deze in XML-indeling afdrukken. Omdat we willen dat de gebruiker een XML-bestand downloadt, stellen we het Inhoudstype in op
text / xml
en Inhoud-beschrijving voorBestandsoverdracht
. We zullen ook een geschikte naam genereren voor het downloadbestand. Ten slotte zullen we enkele opmerkingen toevoegen - deze zijn volledig optioneel, maar kunnen nuttig zijn om de gebruiker te instrueren wat te doen met het gedownloade bestand.Omdat we in het vorige deel van deze serie een API voor onze tabel hebben gemaakt, hoeft onze exporthandler de database niet rechtstreeks aan te raken - we hoeven ook de database niet te ontsmetten
$ args
array aangezien dit wordt afgehandeld door dewptuts_get_logs ()
.functie wptuts_export_logs ($ args = array ()) / * Querylogboeken * / $ logs = wptuts_get_logs ($ args); / * Als er geen logboeken zijn - afbreken * / of (! $ Logs) false retourneren; / * Maak een bestandsnaam * / $ sitename = sanitize_key (get_bloginfo ('name')); if (! empty ($ sitename)) $ sitename. = '.'; $ filename = $ sitename. 'Wptuts-logs.' . datum ('Y-m-d'). '.Xml'; / * Print header * / header ('Content-Description: File Transfer'); header ('Content-Disposition: attachment; filename = ". $ filename); header (" Content-type: text / xml; charset = ". get_option (" blog_charset "), waar); / * Opmerkingen afdrukken * / echo "\ n "; echo"\ n "; echo"\ n "; / * Print de logs * /U zult merken dat we de werkelijke query-array hebben doorgegeven als een argument voor de
wptuts_export_logs ()
functie. We hadden dit hard-gecodeerd kunnen hebben, maar het is logisch om dat niet te doen. Hoewel de bedoeling hier alleen is om te exporteren alles in de tabel geeft het doorgeven van de query als argument ons de mogelijkheid om later de optie toe te voegen om logboeken in een bepaald tijdsbestek of voor een bepaalde gebruiker te exporteren.Bij het maken van het XML-bestand moeten we ervoor zorgen dat er geen waarden tussen de tags worden afgedrukt die de tekens bevatten
&
,<
of>
. Om dit te garanderen, zuiveren we voor ID's de gegevens metabsint
, en de objecttypen en activiteiten metsanitize_key
(omdat we verwachten dat deze alleen kleine alfanumerieke tekens en onderstrepingstekens en koppeltekens bevatten)./ * Logboeken afdrukken naar bestand * / echo ''; foreach ($ logs als $ log) ?> - ';
log_id); ?> activity_date, false); ?> gebruikersnaam); ?> object_id); ?> object type); ?> activiteit); ?> Meer in het algemeen kun je de waarden die worden afgedrukt ontsmetten door ze in te pakken
CDATA
tag met behulp van de volgende functie:/ ** * Wraps de doorgegeven tekenreeks in een XML CDATA-tag. * * @param string $ string String die moet worden ingepakt in een XML CDATA-tag. * @return string * / function wptuts_wrap_cdata ($ string) if (seems_utf8 ($ string) == false) $ string = utf8_encode ($ string); terug '',']]]]>', $ string). ']]>';Eindelijk we
Uitgang()
om verdere verwerking te voorkomen:/ * Klaar - verlaat nu * / exit ();Als u naar onze exportpagina navigeert en op 'Logboeken voor downloaden' klikt, wordt u gevraagd om een XML-bestand te downloaden.
Samenvatting
In deze zelfstudie hebben we gekeken naar het exporteren van gegevens uit onze aangepaste tabel. Helaas, waar de gegevens verwijzen naar de oorspronkelijke WordPress-tabellen, is dit op zijn best problematisch. De hierboven beschreven methode is alleen nuttig voor gevallen waarin de gegevens dit niet doen. Het gebruikte voorbeeld (onze activiteitenlogboeken) valt duidelijk niet in deze categorie, maar wordt alleen gebruikt voor consistentie met de rest van deze reeks.
Wanneer de gegevens doet verwijzing naar native tabellen is het uiteraard noodzakelijk om het samen met de native tabellen te importeren en daarbij de wijzigingen in ID's die plaatsvinden tijdens het importeren bij te houden. Op dit moment is dat niet mogelijk met de bestaande import- en exporthandlers - en dus is de enige werkbare optie om uw eigen handlers te maken. In eenvoudiger gevallen waarin de aangepaste gegevens alleen verwijzen naar een enkel berichttype, is het mogelijk om uw import- en exporthandlers zodanig te ontwerpen dat dit type bericht en uw aangepaste gegevens worden verwerkt en de gebruiker te informeren de native exporteur voor dat berichttype niet te gebruiken.
In het volgende deel van deze serie maken we een eenvoudige importhandler voor het geëxporteerde .xml-bestand.