During the development of WordPress 3.0 we have made a number of changes under the hood which will be of interest to the developers and users of themes. Some of these changes are about making themes easier to develop and some of them are about making it easier to support the override of parts of themes.
1) get_template_part – [13146], #12371
The first change which should make it easier for extensible flexible theme development is the introduction of get_template_part() which has been introduced as a generic way of modularising themes a step beyond the basic footer/body/header files. This new function makes it very easy for a theme to reuse blocks of code implementing theme areas such as the WordPress loop in a way which makes it easy for a child theme to override the implementation in a context sensitive way.
This function is really easy to use – You create a file within your theme containing the code you want to re-use and then you pull it in as follows:
get_template_part( 'loop', 'author' ); // Pull in the loop for the author archives
This will look for the files loop-author.php and loop.php searching first in the current themes folder before looking in the parent themes folder (if one if defined). The new TwentyTen theme in WordPress 3.0 uses this for every call to it’s loop.php to make it easy to override in a single instance from a child theme.
2) Deprecating overly minimal themes [14365], #12425
The next change is to deprecate the support for overly minimal themes. Prior to WordPress 3.0 any theme which was using the relevant template tag but missing any of the following template files – header.php, footer.php, sidebar.php, comments.php, comments-popup.php – would effectively behave as if it has a parent theme defined as ‘default’ using the relevant files from the old default theme.
Now that we are moving to a new default theme we didn’t want to have to support this very old behaviour indefinitely or make it such that the files from the TwentyTen theme were used as they have a different visual layout and would like change peoples existing sites.
Going forward a WordPress theme using the relevant template tags is expected to contain all these files itself, or have them provided by a parent theme, and the theme compatibility files included in WordPress 3.0 will be removed in a future version.
If you are using a theme which is affected by this change then you just need to make sure that you have the default theme installed – it will not be in new installs but will be preserved on upgrades. Then add the following to the comment at the top of the style.css of your theme to make it such that the default theme is used as its parent theme:
Template: default
More information on the process of indicating a parent theme in a child themes style.css is available in the codex.
westi on wordpress 
So once again we will be left with a mass of themes, some of which have cost hundreds of dollars, which are useless thanks to sundry changes in the software.
Isn’t it about time to work out a solution to theme destruction, rather than upgrading and causing countless of otherwise satisfied users the myriad problems of finding a new theme for their weblog instead of a theme they have used and are more than happy with?
Neither of these changes make any themes useless.
The first one makes theming easier in the long run and is an opt-in change.
The second change is fully backwards compatible – we don’t want to break these themes which is why we aren’t forcing them to use the new “default” theme as this hidden parent but instead supporting them for now and letting people know they need to update there theme in the long run.
If a theme is missing one or more of: header.php, footer.php, sidebar.php, comments.php, comments-popup.php, then copying that file from kubrick into the theme folder would fix the problem wouldn’t it?
That is another way of fixing up the theme yes.
Great idea about get_template_part()! Before that we’d need to put strategic codes inside functions and call them from do_action(), so that child themes could remove_action() and add their custom code. Now we can just split our code in multiple files and reuse them, and when a child theme wanna custom that code they just implement their own file!
Now, regarding the 2nd feature I didn’t understand it. Can parent themes set kubrick or 2010 as their parent, and then we have 3 themes in a grandparent – parent – child structure?
An active theme can only have one parent and there is no support for grandparents.
These change only affects themes which were relying on the fact that WordPress used the default theme as a de-facto parent in some cases.
This still works but it is deprecated.
I was already looking forward to a number of WordPress 3 changes, and get_template_part is another. As someone who is more developer than designer, modular is always better to me.
I don’t buy it. Every major upgrade of any software package always disrupts themes (templates). I don’t see the advantage of WP3 at all. The best release was 2.3 and I refuse to use any next. WP Inc behaves like Microsoft: more gimmicks and less productivity. Go figure!
If you are really still running 2.3 then I hope you have ported all the security fixes we have made since then to your site – otherwise you are an open invitation to hackers.
If you have particular ideas around improving productivity or WordPress in general then please share them in the Ideas Forum – http://wordpress.org/extend/ideas/
exactly, you don’t have to “buy it” since wordpress is free, how is that anything like ms? I see plenty of advantages in using WP3 and I’ve only been using it for a day.
Hi Peter,
for a better understanding:
so if i don’t use for example comments_popup_link() or comments_popup_script(); there is also in the future no need to have comments-popup.php?
Also for Themes that would like to send to http://wordpress.org/extend/themes/?
Greetings
Yes Perun. A theme only needs the comments-popup.php file if it uses the popup comments method.