WordPress:Migrating Plugins and Themes to 2.5

来自站长百科
跳转至: 导航、​ 搜索

Introduction[ ]

介绍[ ]

When a new major version of WordPress is released, such as WordPress 2.1 or 2.2, you may find that your Themes and Plugins no longer work the way you are used to. It could be that they are completely broken, because something in WordPress that was fundamental to them changed, but it's also possible that you can get them working again by updating some settings, or maybe just a small edit.

发行一个新的主要版本的WordPress,如WordPress2.1或者2.2,你可能发现你的主题和插件不再向以前那样运行。可能因为插件和主题完全毁坏了,因为WordPress中对它们而言至关重要的部分更改了,但是通过上传一些设置,或者只是简单地编辑一下,你可能有能够使得这些插件和主题正常运行。

This article is part of a series on WordPress:Migrating Plugins and Themes. It covers changes between WordPress WordPress:Version 2.3 and WordPress:Version 2.5, and what you need to do to Plugins and Themes to get them working in Version 2.5. (Note: There was no WordPress version 2.4 - it was skipped.)

这篇文章是升级插件和主题系列的一部分。包括2.3版本2.5版本之间的变化,你需要做的就是,使得插件和主题能够在2.5版本中运行。(注意:没有WordPress2.4版本,这个版本被取消了。)

If the Theme or Plugin you are using was developed by someone else, there are several places to look for information:

如果你使用的主题或者插件是其他人开发的,你可以从下面的这些地点查找信息:

  • Your Plugin or Theme's home page
  • 你的插件或者主题的主页

If you are the author of your Theme or Plugin, or if you have modified or customized your Theme, then this article will help you upgrade your Theme/Plugin for 2.5. If your Theme or Plugin is distributed publicly, after getting it working you may want to add it to the Compatibility lists above, so your users will know it is working and which version they should be running.

如果你是主题或者插件的作者,或者如果你更改或者自定义了主题,那么这篇文章会帮助你将主题/插件升级到2.5。如果你的主题或者插件是公开发行的版本,使得插件和主题运行之后,你希望将插件或者主题添加到上述的兼容性列表,这样你的用户会了解这些插件或者主题能够运行以及应该在哪个版本上运行。

Fixing Up Your Theme or Plugin[ ]

升级你的主题或者插件[ ]

There is one major new functionality addition in WordPress:Version 2.5 for Themes (Avatars), and several changes that affect plugins (the rest of the sections below).

2.5版本为主题(Avatars)添加了新的主要的函数,2.5版本中几个其它变化也会影响插件(下面这个部分的其它部分)。

Avatars[ ]

Avatars[ ]

WordPress 2.5 has built-in support for "avatars", which are small icons for people who comment on your blog, retrieved from a web service. The default service is Gravatar; plugins can override this.

WordPress本身支持"avatars",avatar是小的图标,代表在你的博客上发表评论的人,来自网络服务。默认服务是Gravatar;插件可以废除这个。

If avatar functionality is enabled in the administrative menus, the avatar can be displayed by the theme next to each comment. Theme authors can add lines like this inside the comment loop of the comments.php file, to support this new functionality (see the Default and Classic themes in WordPress 2.5 for examples):

如果管理菜单中激活了avatar功能,每个评论旁边的主题都可以显示avatar(虚拟图像)。主题作者可以将这样的行添加到comments.php文件的评论loop中,以支持这个新的功能(请看看WordPress2.5中的默认和经典主题,作为例子):

<?php if(function_exists('get_avatar')){
  echo get_avatar($comment, '50');
} ?> 


<?php if(function_exists('get_avatar')){
  echo get_avatar($comment, '50');
} ?> 

The first input to the get_avatar function can be the comment author's email address, the author's WordPress user ID, or a complete comment data structure. The second argument is the size of avatar to display, up to 80 pixels. There is also an optional third argument giving the default avatar image file to display if the comment author doesn't have one.

get_avatar函数中第一个输入的内容是评论作者的电子邮件地址,作者的WordPress用户ID,或者完整的评论数据结构。第二个参数值是需要显示的avatar的大小,最大为80像素。如果评论作者没有avatar,可选择的第三个参数会显示默认的avatar图像。

Admin Menu Changes[ ]

管理菜单变化[ ]

The main change affecting plugins in the (at time of writing) upcoming WordPress version 2.5 is the complete overhaul of the administration screens and menus of WordPress. The menus have been reorganized slightly; most plugins will probably still function correctly, if they used the standard methods of WordPress:Adding Administration Menus, but some may need to adjust.

即将发行的WordPress2.5版本,对插件有影响(在编写的时候)的主要变化是完全地修补了管理界面和WordPress菜单。菜单稍微重组了;大多数插件可能仍然能够正常地运行,如果这些插件使用标准的添加管理菜单的方法,但是大多数插件可能需要调整。

Admin Screens[ ]

管理界面[ ]

Any plugin that had added a section to the post editing screen, or other administration screen, will probably find that the formatting and markup changes on the administration screens in WordPress 2.5 have made their section so that it no longer "blends in" and looks like it belongs with the built-in WordPress sections on the screen. Also, some of the hooks that plugins would have used in versions 2.3 and earlier to add information to various screens have been removed, in favor of a new API which uses the function add_meta_box to define a section that can be added to the post, page, or link editing screen. (Until this function has its own documentation page, you can find it, and its documentation header, in wp-admin/includes/template.php).

任何将部分添加到文本编辑界面或者其它管理界面的插件,可能发现WordPress2.5版本中格式和标记的变化使得它们的部分不再"调和" 而且看起来像是界面上内置的WordPress部分。同时插件在2.3版本以及更早的版本中使用的一些用于向各种界面添加信息的hooks已经被移除,有利于新的使用函数 add_meta_box定义可以添加到文章,页面或者链接编辑界面的部分的API。(只有这个函数拥有自已的文档页面,你才可以找到,它的文档标题,在wp-admin/includes/template.php中)。

So, plugin authors will either need to release a new version of their plugins for WordPress 2.5, or (preferably) put some decision logic into their plugin that will detect the version and use the right formatting. A good way to do that is to detect whether the new function add_meta_box has been defined. For example:

if (function_exists('add_meta_box')) {
 // 2.5 logic, calling add_meta_box to define the screen
} else {
 // 2.3 logic, calling add_action( 'dbx_post_advanced' ) or similar
} 

因此,插件作者需要为WordPress2.5版本发行一个新的插件,或者(更适宜)在插件中置入一些决定逻辑,使得插件能够探测版本并且使用不同的格式。更好的方法是侦测是否定义了新的函数add_meta_box。如:

if (function_exists('add_meta_box')) {
 // 2.5 logic, calling add_meta_box 定义界面
} else {
 // 2.3 logic, calling add_action( 'dbx_post_advanced' ) 或者类似的
} 

Note: Be sure to run the function_exists test late in the WordPress initialization process! That function is not loaded at the time of plugin initialization. So it is suggested that you do this inside of an 'admin_menu' action, or the new 'admin_init' action.

注意:在稍后WordPress初始化过程中确定运行了function_exists测试!这个函数不是在插件初始化的时候载入的。因此,建议你在'admin_menu' action或者新的'admin_init' action内容操作。

Activation Global Scope[ ]

Activation Global Scope[ ]

Another change that might affect some plugins is that in WordPress 2.5, the Activation hooks for plugins are run in non-global scope within a function (they used to be run in the global scope). This means that if your plugin has an activation hook, and the function it calls relies on global variables that are defined within your plugin file, you may find that they are not working properly. All you need to do is, at the global scope level in your plugin, add a "global" declaration for those variables, and you should be OK. For instance:

WordPress2.5中另一个可能影响插件的变化是,插件的激活hooks是在非全局范围内一个函数内部运行的(以前是在全局范围内运行)。这意味着,如果你的插件有个激活hook,而且hook调用的函数依赖与你的插件文件内定义的全局变数,你可能发现hook不能够正常运行。你需要做的是,在你的插件的全局范围级别,为这些变数添加"全局"声明,就能够正常运行了。如:

global $my_plugin_variable;
$my_plugin_variable = 3;

function my_plugin_activation_function() {
   global $my_plugin_variable;

   // rest of activation function
}


global $my_plugin_variable;
$my_plugin_variable = 3;

function my_plugin_activation_function() {
   global $my_plugin_variable;

   // 激活函数的其余部分
}

Hook Changed: restrict_manage_posts[ ]

已更改的Hook: restrict_manage_posts[ ]

The behavior of the restrict_manage_posts hook was changed between WordPress 2.3 and WordPress 2.5. See the March 2008 comments and attachments on http://trac.wordpress.org/ticket/6196 for an explanation of the change, and sample plugins for 2.3 and 2.5 illustrating the change.

restrict_manage_posts hook 操作在WordPress2.3和WordPress2.5版本之间发生了变化。请看看2008年3月的评论和http://trac.wordpress.org/ticket/6196上的附件,查找对变化的解释,以及2.3和2.3的插件样本,显示了变化。

TinyMCE Upgrade to Version 3[ ]

TinyMCE 升级到3版本[ ]

The upcoming WordPress version 2.5 includes TinyMCE 3 which is a complete rewrite of the editor. There are many changes in the API and all WordPress plugins that add button(s) to it have to be updated. Good places to start are:

即将发行的2.5版本包括TinyMCE 3,这是编辑器的完全重写。API发生了许多变化,所有向API添加按钮的WordPress插件需要更新。下面是一些推荐开始操作的站点:


Of course adding a button that will insert some code at the cursor location is still quite easy. The "pagebreak" plugin can be used as an example.

当然,添加按钮,在指针的位置插入一些代码,仍然比较容易。"pagebreak"插件可以用在一个例子。

For loading the plugins there is a new filter $mce_external_plugins that takes an array 'name' => 'url' and inserts it in the zipped TinyMCE. It's best to use absolute url (with or without the host name), as using relative needs some settings in the init array to stay at the default values (that can be changed by a WordPress plugin), so it would be possible to break the loading of external plugins that use relative url. TinyMCE would still not load a plugin from another domain.

载入插件,有个新的 filter $mce_external_plugins,带有数组'name' => 'url'并且将其插入解压后的TinyMCE。最好使用绝对的url(有或者没有主机名),因为使用相对的url,在init数组中需要一些设置,保持默认参数值(可以由WordPress插件更改),因此有可能破坏使用相对的url的外部插件的载入。TinyMCE仍然不会从另一个域名中载入插件。

The gzip compressor has changed too. Now it gathers all parts of TinyMCE and outputs the zipped file all in one step. The action "mce_options" is still supported, but deprecated. The action "tinymce_before_init" is replaced by a filter "tiny_mce_before_init" that is applied to the array with all settings for TinyMCE. Also the zipped file is cached on disk to save some memory/server resources. This cache is invalidated by any change to the init array or by changing the ver=[number] arg when calling tiny_mce_config. The version is filtered by "tiny_mce_version" defined in /wp-includes/script-loader.php, so a plugin can change it.

Gzip压缩器也更改了。现在gzip收集了TinyMCE的所有部分,并且一次输出所有压缩文件。action "mce_options"仍然得到支持但是已取消。action "tinymce_before_init"由使用TinyMCE的所有设置应用到数组的filter "tiny_mce_before_init"所取代。同时,压缩的文件储存在磁盘上以节省一些内存/服务器资源。更改了init数组或者调用tiny_mce_config时,更改了ver=[number] arg,都会使得存储无效。版本由定义在/wp-includes/script-loader.php中的"tiny_mce_version"过滤,因此插件可以更改。

There are changes in loading language files too. The language codes are only ISO 639-1, which is just the first 2 letters from WordPress locale, like de, fr, es, etc. TinyMCE will load langs/[lang].js when a plugin is loaded and if the plugin has a popup, it will load langs/[lang]_dlg.js when the popup is opened.

载入语言文件也发生了变化。语言代码只是ISO 639-1,是WordPress本地化语言的前两个字母,如de, fr, es,等等。当载入插件而且插件有弹出窗口的时候,TinyMCE会载入langs/[lang].js,如果弹出窗口是打开的,TinyMCE会载入langs/[lang]_dlg.js。

The loading of the default language strings is different too. Now they all are defined in tinymce/langs/wp-langs.php, so they can be included in the main .pot file and translated to all languages available in WordPress. A plugin can use any of the strings there, check the tinyMCE.i18n js object when TinyMCE is loaded, to see how to reference them.

载入默认语言字符串也不同。现在,这些都定义在tinymce/langs/wp-langs.php,因此可以包含在主要的.pot文件而且翻译为WordPress中的所有语言。插件可以使用那里的任何字符串,载入TinyMCE的时候,检查tinyMCE.i18n js object,看看怎样reference them。

Database changes[ ]

数据库变化[ ]

Changes to database schema from Version 2.3 to 2.5.

将数据库结构从2.3版本更改为2.5版本。

  • Table: comments
  • 表格:评论
Changed comment_approved to varchar(20) NOT NULL default '1'

:将comment_approved更改为varchar(20) 不是零默认 '1'

Added KEY comment_approved_date_gmt (comment_approved,comment_date_gmt)
Added KEY comment_date_gmt (comment_date_gmt)

:添加comment_approved_date_gmt (comment_approved,comment_date_gmt)

已添加 KEY comment_date_gmt (comment_date_gmt)
  • Table: links
  • 表格:链接
Changed link_visible to varchar(20) NOT NULL default 'Y'

:将link_visible更改为varchar(20)不是零默认'Y'

  • Table: options
  • 表格:选项
Changed autoload to varchar(20) NOT NULL default 'yes'

:将autoload 更改为varchar(20)不是零默认'是的'

  • Table: posts
  • 表格:文章
Changed post_status to varchar(20) NOT NULL default 'publish'
post_status更改为varchar(20)不是零默认'发表'
Changed comment_status to varchar(20) NOT NULL default 'open'

:将comment_status更改为varchar(20)不是零默认'打开'

Changed ping_status to varchar(20) NOT NULL default 'open'

:将ping_status更改为varchar(20)不是零默认'打开'

  • Table: term_relationships
  • 表格:term_relationships
Added term_order int(11) NOT NULL default 0

:已添加term_order int(11)不是零默认0