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

[Travis Snoozy]

On Sun, 02 Sep 2007 21:12:56 +0100, Peter Westwood
<peter.westwood at ftwr.co.uk> wrote:
<snip>
> get_the_title is a template tag - therefore it's output should be
> filtered - plain and simple.

Except that it wasn't, unless you did it yourself. Which, I'm sure,
someone somewhere did.

> 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

That's what it was _supposed_ to do. That and what it did do -- all the
way back to 1.5.2 (at least; possible further) -- is something
_completely different_. But since nobody documented what it was
_supposed_ to do, everyone invariably used it as-implemented.

> 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:

<snip>

> Really we should split these out.

As far as internals go, I agree with you. It's much cleaner. Filtration
done at a single point, with everyone using that one point, is
absolutely the way to go. Higher granularity (more filter chains to
pick from) has benefits too. But the argument I'm making is about a
public interface changing its semantics, not internal code needing to
be refactored. :)

> > [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.

You didn't answer the question, or if so, only in a tangential way. Are
you saying that get_post()/global $post will _always_ return a
forwards-compatible object? If so, I'll dig all the way back to 1.5.2 to
hold you to that.

> > 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).
<snip>

> 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.

If it's an internal/private function, I absolutely agree. If it's not,
then it helps every single person who wants to be compatible with
WordPress prior to 2.3. What it comes down to is that somebody isn't
doing proper API design & documentation. That means crap like this
happens, and the meaning of "get_the_title" changes between 2.2.x and
2.3 because QA & 3rd party devs had no metric to verify whether the
function was doing what it was supposed to. Nobody working on core
really has incentive to care, because all *their* code will get updated
to work in HEAD -- the problem just disappears for them from then on
out. However, any plugin or template that wants to work across <2.3
and >=2.3 now needs to wire in a brand-new compatibility function to do
the job of get_the_title, and that's BS. It's core's job to provide a
stable interface to program against, and changing semantics on a
function goes against that.

If it had been a minor "oops" for the first release the function was
introduced, I could see this as being an acceptable break. But the
function has behaved this way for at least 2.5 years, through at least
18 releases (possibly longer on both counts); just up and changing it
because it wasn't in line with what, in retrospect, it _should_ have
done, is no better than removing the old function and adding a new one
with a different name (except that by giving this new function the same
name, breaks are silent instead of loud).

-- 
Travis