我一直在深入研究map\\u meta\\u cap过滤器，因为我需要在某些情况下根据上下文扩展用户的功能。这很好，但在我的跟踪中，我注意到$args在回调函数中显示的方式有些奇怪。这是我的筛选器注册（在类中）：

add_filter( \'map_meta_cap\', array(&$this, \'post_map_meta_cap\'), 10, 4 );

下面是它附带的回调函数定义：

public function post_map_meta_cap( $caps, $cap, $user_id, $args ) {
    error_log("Filter fired:  ------>  meta_cap args:  " . json_encode($args));
}

现在，我在管理页面上，显示了列出的所有自定义帖子类型，并将单击其中一篇帖子的“编辑”（id号6）。以下是跟踪：

on page: edit.php?post_type=my_custom_post_type
click on edit post id 6
Filter fired:  map_meta_cap:  ------>  meta_cap args:  [6]
Filter fired:  admin_enqueue_scripts
Filter fired:  admin_head
Filter fired:  in_admin_header
Filter fired:  admin_bar_menu
Filter fired:  wp_before_admin_bar_render
Filter fired:  wp_after_admin_bar_render
Filter fired:  map_meta_cap:  ------>  meta_cap args:  ["6"]
Filter fired:  in_admin_footer
Filter fired:  admin_footer_text
Filter fired:  admin_footer
Filter fired:  admin_print_footer_scripts
on page:  post.php?post=6&action=edit

我正在用以下内容编写$args的值：

json_encode($args)

这是一种快速/简单的方法，可以让任何对象在跟踪/日志中可读。

所以，我发现奇怪的是，正如您第一次启动过滤器时所看到的，$args数组有一个元素，它是integer, 第二次激发时，该数组有一个元素，并且是string, “6”。

为了安全起见，我将结果转换为整数，现在我看到了这一点，但我想知道它为什么会这样做？我们是否希望post id有时是整数，有时是字符串？