Datenexport: benutzerdefinierte Datenbanktabelle

Wie im ersten Artikel dieser Serie erwähnt, besteht eines der Hauptprobleme bei benutzerdefinierten Datenbanktabellen darin, dass sie nicht von vorhandenen Import- und Export-Handlern verarbeitet werden. Ziel dieses Artikels ist es, dieses Problem anzugehen, es ist jedoch zu beachten, dass es derzeit keine vollständig zufriedenstellende Lösung gibt.

Betrachten wir zwei Szenarien:

1. Benutzerdefinierte Tabellen verweisen auf native WordPress-Tabellen
2. Benutzerdefinierte Tabellen sind völlig unabhängig von nativen Tabellen

Das „Worst-Case-Szenario“ ist das erste Szenario. Nehmen Sie als Beispiel eine benutzerdefinierte Tabelle, die Benutzeraktivitätsprotokolle enthält. Es verweist auf die Benutzer-ID, die Objekt-ID und den Objekttyp, die alle auf Daten verweisen, die in nativen WordPress-Tabellen gespeichert sind. Stellen Sie sich nun vor, dass jemand alle Daten seiner WordPress-Website in eine zweite Website importieren möchte. Es ist beispielsweise durchaus möglich, dass WordPress beim Importieren eines Beitrags ihm eine neue ID zuweisen muss, da möglicherweise bereits ein Beitrag mit dieser ID auf der zweiten Site vorhanden ist.

In diesem Fall ist es notwendig, solche Änderungen zu verfolgen und die in der Tabelle aufgeführten IDs zu aktualisieren. Das ist an sich nicht so schwierig. Leider fehlen dem WordPress-Importer-Plugin für den Import von Daten von anderen WordPress-Sites die notwendigen Hooks, um dies zu erreichen. Wie in diesem Kommentar vorgeschlagen, besteht eine mögliche Problemumgehung darin, die Daten auch in den Metadaten zu speichern. Leider führt dies zu doppelten Daten und verstößt gegen die Datenbanknormalisierung – im Allgemeinen keine gute Idee. Letztlich ist es nur in wenigen Anwendungsfällen wirklich realisierbar.

Der zweite Fall vermeidet diese Komplexität, erfordert aber dennoch benutzerdefinierte Import- und Export-Handler. Wir werden diese Situation in den nächsten beiden Artikeln demonstrieren. Aus Gründen der Konsistenz mit dem Rest dieser Serie bleiben wir jedoch bei der Aktivitätsprotokolltabelle, auch wenn es sich um ein Beispiel für Fall (1) handelt.

---

Entscheiden Sie sich für das Format

Zuerst müssen wir das Format der exportierten Datei festlegen. Das beste Format hängt von der Art (oder „Struktur“) der Daten und ihrer Verwendung ab. Meiner Meinung nach ist XML im Allgemeinen besser, da es Eins-zu-viele-Beziehungen verarbeiten kann. Wenn die Daten jedoch in Tabellenform vorliegen, kann CSV manchmal vorzuziehen sein, insbesondere wegen der einfachen Integration in Tabellenkalkulationsanwendungen. In diesem Beispiel verwenden wir XML.

---

Preiserhöhung

Der nächste Schritt besteht darin, eine Admin-Seite zu erstellen, damit Benutzer Daten aus der Protokolltabelle exportieren können. Wir erstellen eine Klasse, die eine Seite unterhalb des Menüpunkts „Extras“ hinzufügt. Die Seite enthält lediglich eine Schaltfläche, die den Benutzer zum Herunterladen der Exportdatei auffordert. Die Klasse fügt außerdem einen Handler hinzu, der auf Formularübermittlungen wartet und Dateidownloads auslöst.

Schauen wir uns zunächst die Struktur der Klasse an und geben dann die Details ihrer Methoden ein.

class WPTuts_Log_Export_Admin_Page{

    /**
     * The page hook suffix
     */
    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();

WPTuts_Log_Export_Admin_Page::load() Initialisieren Sie die Klasse und verknüpfen Sie Rückrufe mit den entsprechenden Vorgängen:

• add_submenu – Methode, die für das Hinzufügen von Seiten im Menü „Extras“ verantwortlich ist.
• maybe_download – Diese Methode überwacht, um zu prüfen, ob die Download-Anfrage übermittelt wurde. Dadurch werden auch Berechtigungen und Nonces überprüft.

Der Export-Listener muss frühzeitig aufgerufen werden, bevor Header gesendet werden, da wir diese Header selbst festlegen. Wir können es mit init 上，但由于我们只允许在管理中下载导出文件，因此 admin_init verbinden, was hier passender ist.

Das Hinzufügen von Seiten zu Ihrem Menü ist ganz einfach. Um eine Seite unter Extras hinzuzufügen, rufen wir einfach add_management_page() auf.

static function add_submenu(){
    self::$hook_suffix = add_management_page( __('Export Logs','wptuts-log'), __('Export Logs','wptuts-log'), 'manage_options', 'wptuts-export', array(__CLASS__,'display') );
}

Das $hook_suffix hier ist ein Suffix, das für verschiedene bildschirmspezifische Hooks verwendet wird, die hier besprochen werden. Wir verwenden es hier nicht – aber wenn Sie es tun, ist es besser, seinen Wert in einer Variablen zu speichern, anstatt ihn fest zu codieren.

Oben legen wir die Methode display() als Callback unserer Seite fest, als nächstes definieren wir sie:

static function display(){

    echo '<div class="wrap">';
        screen_icon();
        echo '<h2>' . __( 'Export Activity Logs', 'wptuts-log' ) . '</h2>';
        ?>

        <form id="wptuts-export-log-form" method="post" action="">
            <p>
                <label><?php _e( 'Click to export the activity logs','wptuts-log' ); ?></label>
                <input type="hidden" name="action" value="export-logs" />
            </p>
            <?php wp_nonce_field('wptuts-export-logs','_wplnonce') ;?>
            <?php submit_button( __('Download Activity Logs','wptuts-log'), 'button' ); ?>
        </form>

    <?php
}

Abschließend möchten wir überwachen, wann das obige Formular übermittelt wird, und den Download der Exportdatei auslösen.

static function maybe_download(){
     /* Listen for form submission */
    if( empty($_POST['action']) || 'export-logs' !== $_POST['action'] )
        return;

    /* Check permissions and nonces */
    if( !current_user_can('manage_options') )
        wp_die('');

    check_admin_referer( 'wptuts-export-logs','_wplnonce');

    /* Trigger download */
    wptuts_export_logs();
}

Jetzt müssen Sie nur noch die Funktion wptuts_export_logs() erstellen, die unsere .xml-Datei erstellt und zurückgibt.

---

Exportdatei erstellen

Das erste, was die Funktion tun soll, ist das Abrufen des Protokolls. Falls vorhanden, müssen wir die entsprechenden Header festlegen und sie im XML-Format drucken. Da wir möchten, dass der Benutzer die XML-Datei herunterlädt, setzen wir den Content-Type auf text/xml，将 Content-Description 设置为 File Transfer. Außerdem generieren wir einen passenden Namen für die heruntergeladene Datei. Abschließend fügen wir einige Kommentare hinzu – diese sind völlig optional, helfen dem Benutzer jedoch dabei, zu erfahren, was mit der heruntergeladenen Datei zu tun ist.

Da wir im vorherigen Teil dieser Serie die API für die Tabelle erstellt haben, muss unser Export-Handler die Datenbank nicht direkt berühren – und sie muss auch nicht bereinigt werden $args 数组，因为这是由 处理的wptuts_get_logs().

function wptuts_export_logs( $args = array() ) {

    /* Query logs */
    $logs = wptuts_get_logs($args);

    /* If there are no logs - abort */
    if( !$logs )
        return false;

    /* Create a file name */
    $sitename = sanitize_key( get_bloginfo( 'name' ) );
    if ( ! empty($sitename) ) $sitename .= '.';
    $filename = $sitename . 'wptuts-logs.' . date( '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' ), true );

    /* Print comments */
    echo "<!-- This is a export of the wptuts log table -->\n";
    echo "<!-- (Demonstration purposes only) -->\n";
    echo "<!--  (Optional) Included import steps here... -->\n";

    /* Print the logs */
}

您会注意到，我们已将实际查询数组作为参数传递给 wptuts_export_logs() 函数。我们可以对此进行硬编码，但不这样做也是有道理的。虽然这里的目的只是导出表中的所有内容，但将查询作为参数传递允许我们稍后添加在特定时间范围内或针对特定用户导出日志的选项。 p>

创建 XML 文件时，我们需要确保标签之间打印的值不包含字符 &、 或 <code>>。为了确保这一点，对于 ID，我们使用 absint 清理数据，并使用 sanitize_key 清理对象类型和活动（因为我们希望这些仅包含小写字母数字、下划线和连字符）。

/* Print logs to file */
echo '<logs>';
foreach ( $logs as $log ) { ?>
    <item>
        <log_id><?php echo absint($log->log_id); ?></log_id>
        <activity_date><?php echo mysql2date( 'Y-m-d H:i:s', $log->activity_date, false ); ?></activity_date>
        <user_id><?php echo absint($log->user_id); ?></user_id>
        <object_id><?php echo absint($log->object_id); ?></object_id>
        <object_type><?php echo sanitize_key($log->object_type); ?></object_type>
        <activity><?php echo sanitize_key($log->activity); ?></activity>
    </item>
<?php }
echo '</logs>';

更一般地，您可以使用以下函数将要打印的值包装在 CDATA 标记内来清理它们：

/**
 * Wraps the passed string in a XML CDATA tag.
 *
 * @param string $string String to wrap in a XML CDATA tag.
 * @return string
 */
function wptuts_wrap_cdata( $string ) {
    if ( seems_utf8( $string ) == false )
        $string = utf8_encode( $string );

    return '<![CDATA[' . str_replace( ']]>', ']]]]><![CDATA[>', $string ) . ']]>';
}

最后我们 exit() 以防止任何进一步的处理：

    /* Finished - now exit */   
    exit();

导航到我们的导出页面，单击“下载活动日志”应提示下载 XML 文件。

---

摘要

在本教程中，我们研究了从自定义表中导出数据。不幸的是，当数据引用本机 WordPress 表时，这充其量是有问题的。上述方法仅适用于数据无法做到这一点的情况。使用的示例（我们的活动日志）显然不属于此类，只是为了与本系列的其余部分保持一致而使用。

当数据确实引用本机表时，显然有必要将其与本机表一起导入，并在此过程中跟踪导入期间发生的 ID 任何更改。目前，现有的导入和导出处理程序无法实现这一点，因此唯一可行的选择是创建自己的处理程序。在自定义数据仅引用单个帖子类型的简单情况下，可以设计导入和导出处理程序来处理该帖子类型以及自定义数据，并通知用户不要使用该帖子类型的本机导出器。

在本系列的下一部分中，我们将为导出的 .xml 文件创建一个简单的导入处理程序。

Das obige ist der detaillierte Inhalt vonDatenexport: benutzerdefinierte Datenbanktabelle. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!