在最近的一个项目中要添加一些新的用户角色，这本是一件很简单的事情，网上有很多教程可以参考。但是在实际的使用过程中却遇到了一个问题：新添加的用户角色所辖的用户无法进入后台，提示权限不足。即便是 WordPress 默认角色中权限最低的“订阅者”也是可以进入后台查看个人资料的。这是怎么回事呢？经过一个多小时的反复实验，最终找到一个解决方法。

以下是这个解决方法的代码片段，请灵活使用。

1
2
3
4

  add_role( 'customer', 'Customer', array() );

  $role = &get_role( 'customer' );
  $role->add_cap( 'custom_cap' );

add_role 的用法在文档中说的很明白，第三个参数是给这个新角色指定一个所拥有权限的数组，比如“订阅者”的权限是 array( 'read' )。但是，如果此时指定了权限（比如 read），这个新角色下的用户是无法进入后台的，也就是出现前面所说的“权限不足”的问题。上述代码片段的第 2、3 行代码可以解决这个问题。

解决方法：在用 add_role 添加新用户角色时暂不指定任何权限，也就是给其第三个参数赋值一个空数组。然后通过 get_role 获取刚刚添加的新用户角色，再使用 add_cap 为其添加相应的权限。如果需要添加多个权限，需要多次调用 add_cap。

以上是对“新添加的用户角色所辖的用户无法进入后台”这个问题的一种解决方法。这可能是 WordPress 的一个 bug。

WordPress 对 i18n 和 l10n 有着很完善的支持。最近在做 V2Press 的时候把 i18n 和 l10n 的流程走了一遍，在此做个记录，备查。

我的开发环境架设在 Mac OS X 上，所以以下操作均在此系统中完成。Windows 系统请酌情参考。

安装组件

WordPress 的 i18n 和 l10n 是通过 GNU gettext 实现的，因此在进行实际工作之前，首先需要安装相关的组件。

XCode

XCode 是 Mac OS 中的常用 IDE 之一，其中也包含了编译相关的库，比如 gcc，在后面会用到 gcc 库，所以首先要安装 XCode。XCode 在购买苹果电脑产品的附带安装盘中有。安装过程中一定要选择安装编译组件。

homebrew

homebrew – The missing package manager for OS X，用来安装 *nix 系统中常用的库包。homebrew 的安装方法请参照 homebrew wiki Installation。

gettext

如果以上所需组件已经安装完毕，那么可以继续以下步骤。打开 Terminal，运行以下命令：

1

brew install gettext

等待片刻，自动编译完成后即可。gettext 被安装在 /usr/local/Cellar 中。

为了能够使用 gettext 中相关的命令，还需要修改 $PATH，打开 ~/.profile 将 /usr/local/Cellar/gettext/0.18.1.1/bin 加入其中：

1

export PATH="/usr/local/bin:/usr/local/sbin:/usr/local/Cellar/gettext/0.18.1.1/bin:/Developer/usr/bin:$PATH"

关闭该文件，在 Terminal 中执行以下命令加载新的 $PATH：

1

source ~/.profile

WordPress i18n 工具

WordPress 的 i18n 和 l10n 相关工具放在 svn 中。这些工具可以方便的为我们添加 textdomain，生成 POT 文件。

在 Terminal 中执行以下命令安装：

1

svn co http://svn.automattic.com/wordpress-i18n/tools/trunk/ ./

以上命令将这些工具安装到当前目录中。

（继续阅读….）

WordPress 的链接格式是很灵活的，几乎可以任意的定制 URL 的格式。如果你所用的服务器支持 mod_rewrite 的话就可以设置“精美”的 URL 格式。WordPress 默认提供了 5 种 URL 格式供选择，而且还可以自由定制。WordPress 还提供了针对“分类”和“标签”的 rewrite base 设置选项。

默认的，WordPress 的分类 URL 格式是 host/category/xxx/，其中 category 就是 rewrite base，这是可定制的部分，例如本站分类 URL 的 rewrite base 就设置为“go”了。同理，可以设置标签 URL 的 rewrite base。

在设置 WordPress 链接格式的时候我遇到一个问题。我设置的 URL 格式是 /t/%postname%，rewrite base 是固定的，不再是占位符，这时文章页面的 URL 是没问题的，页面的 URL 是没问题的，分类、标签的页面 URL 也是没问题的，但是，基于时间的页面就出现问题了，其 URL 结构变成 /t/2012/01 的格式，这个“t”是我不需要的。

查看 wp-includes/rewrite.pnp 第 862 行 get_date_permastruct() 函数的定义可以发现，最终返回的结果加入了 $front，这就是“t”为什么会出现的原因。

861
862
863

....
$this->date_structure = $front . $date_endian;
....

那么只需要覆盖类 WP_Rewrite 的 $date_structure 变量即可。将以下代码片段写入主题的 functions.php：

1
2
3
4
5
6
7
8
9

function ac_re_rewrite() {
  global $wp_rewrite;

  // Not need the $wp_rewrite->front
  $wp_rewrite->date_structure = '%year%/%monthnum%/%day%';

  $wp_rewrite->flush_rules();
}
add_action( 'init', 'ac_re_rewrite' );

如此一来，基于日期的存档 URL 格式就定制好了，利用同样的方法还可以定制作者归档等页面的 URL 格式。

WordPress 3.3 之后，用户可以在个人资料页面设置访问前台时是否显式 Toolbar。如果不想把决定权给用户，可以通过一些代码设置前台不显式 Toolbar，具体方法可以参照“Disable Admin Bar in WordPress 3.3”一文。但是该文提供的方法有个弊端：虽然 Toolbar “不显式”了，但是它所用到的文件（样式表文件和Javascript 脚本文件）一个都没少，而且还多加了一个样式表。

其实，有个更简单、更有效的方法可以完全去除 Toolbar：使用 show_admin_bar() 函数。将以下代码片段加入主题的 functions.php 文件：

1
2
3
4
5
6

// 全局禁用 Toolbar
show_admin_bar( false );

// 只在前台禁用 Toolbar
if ( !is_admin() )
  show_admin_bar( false );

可以根据需要选择禁用全局还是只在前台禁用。

这个方法的好处是，1）代码量少；2）禁用的更彻底，Toolbar 所需的样式表文件和 Javascript 脚本文件均不会加载。