Codex

Interested in functions, hooks, classes, or methods? Check out the new WordPress Code Reference!

Difference between revisions of "Migrating Plugins and Themes"

(Migrating from 2.3 to 2.5: add Database changes)
 
(13 intermediate revisions by 7 users not shown)
Line 1: Line 1:
  +
{{Languages|
  +
{{en|Migrating Plugins and Themes}}
  +
{{ja|プラグインとテーマの移行}}
  +
{{th|Migrating Plugins and Themes}}
  +
{{zh-cn|迁移插件和主题}}
  +
{{zh-tw|遷移外掛與佈景主題}}
  +
}}
  +
 
==Introduction==
 
==Introduction==
   
When you upgrade WordPress from one major version to another, such as from 2.1 to 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.
+
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.
 
This article has some hints on how to upgrade plugins and themes from one version to another, below. There is also a special article on [[Migrating Plugins and Themes to 2.1]], which covers changes between WordPress 2.0 and WordPress 2.1, as well as a much older article, [[Upgrade 1.2 to 1.5]], which covers how to convert a really old Theme to the current theming system.
 
 
==Migrating from 2.1 to 2.2==
 
 
The main change of importance to Plugins and Themes in [[Version 2.2]] was the introduction of WordPress Widgets as part of the core of WordPress. (Widgets are small pieces of WordPress output, such as category lists, archive lists, and search forms, which you can put into the sidebar(s) of your blog.)
 
 
If you want to use Widgets in a Theme that was developed prior to WordPress 2.2, you can find out how to update your theme in [http://automattic.com/code/widgets/themes/ this article on Widgetizing Themes].
 
 
If you want some output that your Plugin generates to be displayed in a sidebar Widget, you can find out how in [http://automattic.com/code/widgets/plugins/ this article on Widgetizing Plugins], and you may also find the [http://automattic.com/code/widgets/api/ Widgets API] article useful.
 
 
==Migrating from 2.2 to 2.3==
 
 
===Categories and Tags===
 
The main change of importance to Plugins and Themes in [[Version 2.3]] was the introduction of tagging as a core WordPress functionality.
 
 
If you want to add tags to your theme (e.g. to display the tags used on a post, or put a tag cloud into your sidebar), you will be interested in new [[Template_Tags/the_tags|the_tags]] and [[Template_Tags/wp_tag_cloud|wp_tag_cloud]] template tag functions.
 
 
There were also quite a few new tag-related functions for use in plugins introduced in WordPress 2.3.
 
 
Also, as a side effect of introducing tags to WordPress, the underlying database table structure, in regards to storage of categories, was changed considerably. So, any plugins that ran queries using the category-related tables in the WordPress database will likely be broken; the queries will have to be completely rewritten. Plugins and Themes that used WordPress functions to access categories should be OK.
 
 
===Canonical URLs===
 
Another change in 2.3 that affects some plugins is the introduction of "canonical" URLs. The canonical URL system basically rewrites all URLs used in WordPress into "canonical" form, so that there is only one URL that points to a given display, and other URLs that could also point to that display are redirected to the "canonical" URL. Most plugins will not be affected by this change, but a plugin that adds suffixes to URLs could find that some of the URLs it generates are broken. Notably, a URL with a page number in it, such as example.com/page/2/ (to access the second page of older posts) ''must'' have the page section at the end of the URL. Prior versions of WordPress would have allowed example.com/page/2/suffix/ to work, but in WordPress 2.3, the URL must be generated as example.com/suffix/page/2 in order to function correctly.
 
 
Note that if you use a non-standard url/permalink structure that is necessary for the functioning of your site, the "canonical url" functionality can be turned off by adding the following to a plugin file or the functions.php file in your template folder:
 
remove_filter('template_redirect', 'redirect_canonical');
 
WordPress 2.5 will make a further filter available for choosing which canonical redirects are denied rather than forcing them to be all on or all off.
 
 
==Migrating from 2.3 to 2.5==
 
 
(Note: There was no WordPress version 2.4 - it was skipped.)
 
 
There is one major new functionality addition in [[Version 2.5]] for Themes (Avatars), and several changes that affect plugins (the rest of the sections below).
 
 
===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 [http://gravatar.com Gravatar]; plugins can override this.
 
 
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 <tt>comments.php</tt> file, to support this new functionality (see the Default and Classic themes in WordPress 2.5 for examples):
 
<pre>
 
<?php if(function_exists('get_avatar')){
 
echo get_avatar($comment, '50');
 
} ?>
 
</pre>
 
The first input to the <tt>get_avatar</tt> 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.
 
 
===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 [[Adding Administration Menus]], but some may need to adjust.
 
 
===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 [[Plugin API|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 <tt>[[add_meta_box]]</tt> 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 <tt>wp-admin/includes/template.php</tt>).
 
 
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 <tt>add_meta_box</tt> has been defined. For example:
 
<pre>
 
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
 
}
 
</pre>
 
 
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.
 
 
===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:
 
<pre>
 
global $my_plugin_variable;
 
$my_plugin_variable = 3;
 
 
function my_plugin_activation_function() {
 
global $my_plugin_variable;
 
 
// rest of activation function
 
}
 
</pre>
 
 
===Hook Changed: restrict_manage_posts===
 
 
The behavior of the <tt>restrict_manage_posts</tt> 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.
 
 
===TinyMCE Upgrade to Version 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:
 
* http://wiki.moxiecode.com/index.php/TinyMCE:Create_plugin/3.x
 
* http://wiki.moxiecode.com/index.php/TinyMCE:API
 
* http://codex.wordpress.org/TinyMCE_Custom_Buttons
 
 
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.
 
 
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.
 
 
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.
 
 
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.
 
 
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.
 
 
===Database changes===
 
 
Changes to database schema from Version 2.3 to 2.5.
 
 
*Table: comments
 
:Changed ''comment_approved'' to varchar(20) NOT NULL default '1'
 
:Added KEY ''comment_approved_date_gmt'' (comment_approved,comment_date_gmt)
 
:Added KEY ''comment_date_gmt'' (comment_date_gmt)
 
 
*Table: links
 
:Changed ''link_visible'' to varchar(20) NOT NULL default 'Y'
 
 
*Table: options
 
:Changed ''autoload'' to varchar(20) NOT NULL default 'yes'
 
 
*Table: posts
 
:Changed ''post_status'' to varchar(20) NOT NULL default 'publish'
 
:Changed ''comment_status'' to varchar(20) NOT NULL default 'open'
 
:Changed ''ping_status'' to varchar(20) NOT NULL default 'open'
 
   
  +
This article is a list of other Codex articles that cover how to upgrade your plugins and themes from one WordPress version to the next.
*Table: term_relationships
 
  +
* [[Upgrade 1.2 to 1.5]] - Covers how to convert a really old Theme to the current theming system.
:Added ''term_order'' int(11) NOT NULL default 0
 
  +
* [[Migrating Plugins and Themes to 2.1]] - Covers changes between WordPress 2.0 and WordPress 2.1
  +
* [[Migrating Plugins and Themes to 2.2]] - Covers changes between WordPress 2.1 and WordPress 2.2
  +
* [[Migrating Plugins and Themes to 2.3]] - Covers changes between WordPress 2.2 and WordPress 2.3
  +
* [[Migrating Plugins and Themes to 2.5]] - Covers changes between WordPress 2.3 and WordPress 2.5
  +
* [[Migrating Plugins and Themes to 2.6]] - Covers changes between WordPress 2.5 and WordPress 2.6
  +
* [[Migrating Plugins and Themes to 2.7]] - Covers changes between WordPress 2.6 and WordPress 2.7
  +
* [[Migrating Multiple Blogs into WordPress 3.0 Multisite]] - Covers changes between WordPress blogs into WordPress 3.0 Multisite
  +
* [[Migrating Plugins and Themes to 3.1]] - Covers changes between WordPress 3.0 and WordPress 3.1
   
 
----
 
----

Latest revision as of 16:39, 27 July 2011

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.

This article is a list of other Codex articles that cover how to upgrade your plugins and themes from one WordPress version to the next.