正如本系列的第一篇文章中提到的，自定义数据库表的主要问题之一是它们不由现有的导入和导出处理程序处理。本文旨在解决这个问题，但应该指出的是，目前还没有完全令人满意的解决方案。
让我们考虑两种情况：
- 自定义表格引用本机 WordPress 表格
- 自定义表格完全独立于原生表格
“最坏情况”是第一种情况。以保存用户活动日志的自定义表为例。它引用用户 ID、对象 ID 和对象类型 - 所有这些都引用存储在本机 WordPress 表中的数据。现在想象一下，有人想要将其 WordPress 网站中的所有数据导入到第二个网站中。例如，完全有可能在导入帖子时，WordPress 必须为其分配一个新的 ID，因为第二个站点中可能已经存在具有该 ID 的帖子。
在这种情况下，有必要跟踪此类更改并更新表中引用的 ID。这本身并不那么困难。 不幸的是，用于处理从其他 WordPress 站点导入数据的 WordPress Importer 插件缺乏必要的挂钩来实现这一点。正如此评论中所建议的，一种潜在的解决方法是将数据也存储在后元中。不幸的是，这会导致重复数据，并且违背数据库规范化——通常不是一个好主意。最后，它仅在少数用例中真正可行。
第二种情况避免了这种复杂性，但仍然需要自定义导入和导出处理程序。我们将在接下来的两篇文章中演示这种情况。但是，为了与本系列的其余部分保持一致，我们将坚持使用活动日志表，即使它是情况 (1) 的示例。
决定格式
首先我们需要决定导出文件采用的格式。最佳格式取决于数据的性质（或“结构”）及其使用方式。在我看来，XML 通常更好，因为它可以处理一对多关系。然而，有时如果数据是表格形式，那么 CSV 可能更可取，特别是因为它易于与电子表格应用程序集成。在此示例中，我们将使用 XML。
加价
下一步是创建一个管理页面，以允许用户导出日志表中的数据。我们将创建一个类，该类将在“工具”菜单项下方添加一个页面。该页面仅包含一个按钮，提示用户下载导出文件。该类还将添加一个处理程序来侦听表单提交并触发文件下载。
首先让我们看一下类的结构，然后再填写其方法的详细信息。
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() 初始化类并将回调挂钩到适当的操作：
-
add_submenu– 负责在“工具”菜单下添加页面的方法。 -
maybe_download– 此方法将监听检查是否已提交下载请求。这还将检查权限和随机数。
需要在发送任何标头之前尽早调用导出侦听器，因为我们将自己设置这些标头。我们可以将其挂接到 init 上，但由于我们只允许在管理中下载导出文件，因此 admin_init 在这里更合适。
向菜单添加页面非常简单。要在“工具”下添加页面，我们只需调用 add_management_page()。
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') );
}
这里的 $hook_suffix 是用于各种屏幕特定钩子的后缀，这里讨论。我们在这里不使用它 - 但如果您使用它，最好将其值存储在变量中，而不是对其进行硬编码。
在上面我们将方法 display() 设置为我们页面的回调，接下来我们定义它：
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
}
最后，我们希望监听上述表单何时提交并触发导出文件下载。
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();
}
剩下的就是创建函数 wptuts_export_logs() 来创建并返回我们的 .xml 文件。
创建导出文件
我们希望函数做的第一件事是检索日志。如果有的话，我们需要设置适当的标头并以 XML 格式打印它们。由于我们希望用户下载 XML 文件，因此我们将 Content-Type 设置为 text/xml，将 Content-Description 设置为 File Transfer。我们还将为下载文件生成合适的名称。最后，我们将添加一些注释 - 这些完全是可选的，但有助于指导用户如何处理下载的文件。
由于在本系列的前一部分中，我们为表创建了 API，因此我们的导出处理程序不需要直接接触数据库 - 也不需要清理 $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 文件创建一个简单的导入处理程序。
