Tabelle database personalizzate esportazione di dati

Come accennato nel primo articolo di questa serie, uno dei maggiori problemi con una tabella di database personalizzata è il fatto che non sono gestiti da gestori di importazione ed esportazione esistenti. Questo articolo si propone di affrontare questo problema - ma si dovrebbe notare che attualmente non esiste una soluzione completamente soddisfacente.

Consideriamo due scenari:

1. La tabella personalizzata fa riferimento a una tabella nativa di WordPress
2. La tabella personalizzata è completamente indipendente dalle tabelle native

Lo scenario "worst case" è il primo. Prendi l'esempio di una tabella personalizzata che tiene i registri dell'attività dell'utente. Fa riferimento a ID utente, ID oggetto e tipo di oggetto, i quali fanno riferimento a dati archiviati in tabelle native di WordPress. Ora immagina qualcuno che voglia importare tutti i dati dal loro sito WordPress in un secondo. È del tutto possibile che durante l'importazione di un post, ad esempio, WordPress debba assegnargli un nuovo ID, poiché potrebbe esistere già un post con quell'ID nel secondo sito.

In questa situazione sarebbe necessario tenere traccia di tali cambiamenti e aggiornare gli ID a cui si fa riferimento nella nostra tabella. Questo non è di per sé così difficile. Sfortunatamente, il plug-in di WordPress Importer che gestisce l'importazione di dati da altri siti di WordPress non ha i ganci necessari per renderlo possibile. Come suggerito in questo commento, un possibile work-around è di archiviare i dati anche in post meta. Sfortunatamente questo si traduce in dati duplicati e vola di fronte alla normalizzazione del database - generalmente non è una buona idea. Infine, è davvero praticabile solo in una minoranza di casi d'uso.

Il secondo caso evita questa complessità ma richiede ancora gestori di importazione ed esportazione personalizzati. È questo il caso che dimostreremo nei prossimi due articoli. Tuttavia, per coerenza con il resto della serie, resteremo fedeli alla tabella dei log delle attività anche se è un esempio di caso (1).

Decidere il formato

Per prima cosa dobbiamo decidere il formato che il nostro file di esportazione deve prendere. Il formato migliore dipende dalla natura (o dalla "struttura") dei dati e da come deve essere utilizzato. A mio parere, l'XML è generalmente migliore poiché gestisce le relazioni uno-a-molti. Tuttavia, a volte se i dati sono tabulari, allora CSV può essere preferibile, in particolare per la facilità di integrazione con le applicazioni di fogli di calcolo. In questo esempio useremo XML.

Mark-Up

Il passaggio successivo consiste nel creare una pagina di amministrazione per consentire agli utenti di esportare i dati nella tabella dei registri. Creeremo una classe che aggiungerà una pagina sotto la voce di menu "Strumenti". Questa pagina conterrà poco più di un pulsante, chiedendo all'utente di scaricare il file di esportazione. La classe aggiungerà anche un gestore per ascoltare l'invio del modulo e attivare il download del file.

Diamo prima un'occhiata alla struttura della classe, prima di riempire i dettagli dei suoi metodi.

 class WPTuts_Log_Export_Admin_Page / ** * Il suffisso hook della pagina * / static $ hook_suffix = "; static function load () add_action ('admin_menu', array (__ CLASS __, 'add_submenu')); add_action ('admin_init', array (__ CLASS__ , 'maybe_download')); static function add_submenu ()  static function maybe_download ()  static function display ()  WPTuts_Log_Export_Admin_Page :: load ();

Il WPTuts_Log_Export_Admin_Page :: load () inizializza la classe e associa i callback alle azioni appropriate:

• add_submenu - Il metodo responsabile per l'aggiunta della pagina nel menu Strumenti.
• maybe_download - Questo metodo ascolterà per verificare se è stata inoltrata una richiesta di download. Questo controllerà anche permessi e non.

L'ascoltatore di esportazione deve essere richiamato in anticipo e prima che vengano inviate le intestazioni, poiché le imposteremo noi stessi. Potremmo collegarlo dentro, ma poiché consentiremo il download del file di esportazione solo nell'amministratore, admin_init è più appropriato qui.

Aggiungere una pagina al menu è molto semplice. Per aggiungere una pagina sotto Strumenti, dobbiamo solo chiamare add_management_page ().

 funzione statica add_submenu () self :: $ hook_suffix = add_management_page (__ ('Export Logs', 'wptuts-log'), __ ('Export Logs', 'wptuts-log'), 'manage_options', 'wptuts-export ', array (__ CLASS __,' display ')); 

Il $ hook_suffix qui è il suffisso usato per vari ganci specifici per lo schermo, discusso qui. Non lo usiamo qui - ma se lo fai, è una buona idea conservare il suo valore in una variabile, piuttosto che codificarlo a fondo.

In quanto sopra abbiamo impostato il metodo display() per essere il callback per la nostra pagina, definiamo questo dopo:

 display della funzione statica () echo '
'; screen_icon (); eco '
'. __ ('Esporta log delle attività', 'wptuts-log'). '
'; ?> 
 
   
   
  
Infine, vogliamo ascoltare quando viene inviato il modulo sopra e avviare il download del file di esportazione.
 
 funzione statica maybe_download () / * Ascolta l'invio del modulo * / if (vuoto ($ _ POST ['action']) || 'export-logs'! == $ _POST ['action']) return; / * Verifica permessi e non * * if (! Current_user_can ('manage_options')) wp_die ("); check_admin_referer ('wptuts-export-logs', '_ wplnonce'); / * Download di trigger * / wptuts_export_logs ();
 
Non resta che creare la funzione wptuts_export_logs () che crea e restituisce il nostro file .xml.
 
 
Creazione del file di esportazione
 
La prima cosa che vogliamo è la nostra funzione è recuperare i log. Se ce ne sono, avremo bisogno di impostare le intestazioni appropriate e stamparle in formato XML. Dal momento che vogliamo che l'utente scarichi un file XML, imposteremo il tipo di contenuto su text / xml e Content-Description to Trasferimento di file. Creeremo anche un nome adatto per il file di download. Infine, includeremo alcuni commenti - questi sono del tutto facoltativi, ma possono essere utili per istruire l'utente su cosa fare con il file scaricato.
 
Poiché nella parte precedente di questa serie abbiamo creato un'API per la nostra tabella, il nostro gestore di esportazione non ha bisogno di toccare direttamente il database - né è necessario disinfettare il $ args array come questo è gestito dal wptuts_get_logs ().
 
 function wptuts_export_logs ($ args = array ()) / * Log delle query * / $ logs = wptuts_get_logs ($ args); / * Se non ci sono log - abort * / if (! $ Logs) restituisce false; / * Crea un nome file * / $ sitename = sanitize_key (get_bloginfo ('name')); if (! empty ($ sitename)) $ sitename. = '.'; $ nomefile = $ sitename. 'Wptuts-log.' . data ('Y-m-d'). '.Xml'; / * Stampa intestazione * / intestazione ('Contenuto-Descrizione: Trasferimento file'); intestazione ('Content-Disposition: attachment; filename = ". $ nomefile); header (" Content-Type: text / xml; charset = ". get_option (" blog_charset'), true); / * Stampa commenti * / echo "\ n "; echo"\ n "; echo"\ n "; / * Stampa i registri * /
 
Noterai che abbiamo passato l'array di query effettivo come argomento per il wptuts_export_logs () funzione. Potremmo avere codificato questo, ma ha senso non farlo. Anche se l'intenzione qui è solo quella di esportare qualunque cosa nella tabella, passare la query come argomento ci consente di aggiungere in seguito l'opzione di esportazione dei log in un determinato intervallo di tempo, o per un particolare utente.
 
Quando creiamo il file XML, dobbiamo assicurarci che nessun valore stampato tra i tag contenga i caratteri &, < o >. Per garantire questo, per gli ID con cui disinfettiamo i dati absint, e i tipi di oggetto e le attività con sanitize_key (dal momento che ci aspettiamo che questi contengano solo caratteri alfanumerici minuscoli e caratteri di sottolineatura e trattini).
 
 / * Stampa i registri nel file * / echo ''; foreach ($ registra come $ log) ?>  log_id); ?> activity_date, false); ?> ID utente); ?> object_id); ?> tipo di oggetto); ?> attività); ?>  ';
 
Più in generale è possibile disinfettare i valori da stampare avvolgendoli all'interno CDATA tag usando la seguente funzione:
 
 / ** * Avvolge la stringa passata in un tag CDATA XML. * * @param stringa $ stringa Stringa per avvolgere in un tag CDATA XML. * @return string * / function wptuts_wrap_cdata ($ string) if (sembra_utf8 ($ string) == false) $ string = utf8_encode ($ stringa); ritorno '',']]]]>', $ stringa). ']]>'; 
 
Finalmente noi Uscita() per evitare ulteriori elaborazioni:
 
 / * Finito - ora esci * / esci ();
 
Per accedere alla nostra pagina di esportazione, fare clic su "Scarica registri attività" per richiedere il download di un file XML.
 
 
Sommario
 
In questo tutorial abbiamo esaminato i dati di esportazione dalla nostra tabella personalizzata. Sfortunatamente, dove i dati fanno riferimento a tabelle nativi di WordPress, questo è al massimo problematico. Il metodo descritto sopra è utile solo nei casi in cui i dati non lo fanno. L'esempio usato (i nostri log delle attività) ovviamente non rientra in questa categoria, ma viene usato semplicemente per coerenza con il resto di questa serie.
 
Quando i dati fa tabelle nativi di riferimento è ovviamente necessario importarlo insieme alle tabelle native e, così facendo, tenere traccia di eventuali modifiche degli ID che si verificano durante l'importazione. Attualmente ciò non è possibile con i gestori di importazione ed esportazione esistenti, quindi l'unica opzione praticabile è crearne di propri. Nei casi più semplici in cui i dati personalizzati fanno riferimento solo a un singolo tipo di post, è possibile progettare i gestori di importazione ed esportazione per gestire quel tipo di post, nonché i dati personalizzati e informare l'utente di non utilizzare l'esportatore nativo per quel tipo di post.
 
Nella parte successiva di questa serie creeremo un semplice gestore di importazione per il file .xml esportato.



		
			
	   
	




Codice