[wp-testers] 2.3 Beta 1 changes semantics of get_the_title

[Peter Westwood]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Travis Snoozy wrote:
> On Sun, 02 Sep 2007 10:35:04 -0700, Jennifer Hodgdon
> <yahgrp at poplarware.com> wrote:
> 
>> Travis Snoozy wrote:
>>
>>>   The get_the_title function is now filtered, whereas in the past
>>> (through all the versions back to 2.0; I haven't checked earlier)
>>> it was not. 
>> See  http://trac.wordpress.org/ticket/4477  for discussion of why
>> this was done.
> 
> Thanks for the pointer.
> 
> I understand why it was done -- the issue is that it breaks everything
> that depended on the old behavior (i.e., getting an _unfiltered_
> title, and processing it as needed), and there is no API for getting the
> title that doesn't ride right on top of the database (get_post/global
> $post/etc., which break if there's a schema change).
> 
> [SpecificRant]
> 
> So, the issue I have specifically is that this will at least break my
> plugin insofar as trying to escape post titles that have already been
> escaped, and consequently printing out rubbish. It's fixable, but rather
> obnoxious (especially in terms of forwards/backwards compatibility).
> 
> It may also break how other parts of WordPress interacts with my plugin.
> There's a "Title Prefix" option which (as the name would suggest) adds
> a prefix to the title of certain posts. This is accomplished using a
> filter. get_the_title was previously immune to this change in name, and
> now it is not -- I have no idea what the consequences will be, and the
> feature (which was rather handy, IMHO) may now be untenable, because
> having the prefixed name show up -everywhere- is likely to be too
> cluttered, compared to having it show up in just the places that
> filtered before.
>

get_the_title is a template tag - therefore it's output should be
filtered - plain and simple.

It is design for use in templates and if plugins want to affect what is
output then they can filter it on the the_title filter

The problem at the moment IMHO is the reuse of the filter name.  Each
filter should only be used in one place - this enables a plugin to be
very specific about what it is filtering.

At present we have the_title used in 7 places:

./wp-includes/comment.php:      $post_title = apply_filters('the_title',
$post->post_title);
./wp-includes/classes.php:              $output .= $indent . '<li
class="' . $css_class . '"><a href="' . get_page_link($page->ID) . '"
title="' . att
ribute_escape(apply_filters('the_title', $page->post_title)) . '">' .
apply_filters('the_title', $page->post_title) . '</a>';
./wp-includes/deprecated.php:           $string .=
apply_filters('the_title', $post->post_title, $post);
./wp-includes/deprecated.php:           $string .=
apply_filters('the_title', $post->post_title, $nextpost);
./wp-includes/link-template.php:        $title =
apply_filters('the_title', $post->post_title, $post);
./wp-includes/link-template.php:        $title =
apply_filters('the_title', $post->post_title, $post);
./wp-includes/general-template.php:
        $text = strip_tags(apply_filters('the_title', $arc_title));

Really we should split these out.

> [GeneralRant]
> 
> Where's the insulated, reliable, public API? The one that's _not_
> subject to change? Clearly the database is subject to change (see the
> recent post2cat stuff), and now the APIs are too? How the heck is
> anyone supposed to program on top of this mess if it keeps changing out
> from under their feet*?
>

If you want to filter something then the api is a filter.
If you want raw info then something like the $post returned from
get_post is the api.

> The correct (albeit ugly) solution is to introduce either a new
> function call entirely (get_the_filtered_title), or add a defaulting
> parameter to the current call (get_the_title($pid, $filter=false)), or
> both (with a latter being a shortcut to the former, but defaulting to
> true for the filter instead). Yes, it adds bloat. Yes, it's not pretty.
> That's why -public APIs need to be designed and documented
> thoroughly- -- so that implementers know exactly how the function
> should behave, testers know exactly how to verify the correct
> operation of the function, and (ultimately) programmers know how they
> can rely on the thing to work (and know if they're relying on a bug
> vs. intended behavior).
> 

This is not the correct solution.  If there is a bug it should be fixed
plain and simple - keeping a function working in the incorrect way helps
no one.

Cheers

westi
- --
Peter Westwood
http://blog.ftwr.co.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG2xlIVPRdzag0AcURAgkzAJ4m4N6Zqe4DimCG9s3tWm+mqmbhaQCgzR7W
3tNyvzKQivfcWn+L2154HMw=
=VkCY
-----END PGP SIGNATURE-----