[wp-hackers] "Outdated plugin" notice (was: load_plugin_textdomain() )

[Jacob Santos]

Xavier Borderie wrote:
> 2008/7/29 Jacob Santos <wordpress at santosj.name>:
>   
>> It should be pointed out that users already have the power to check whether
>> or not plugins and themes use deprecated code with WordPress 2.5+. All they
>> have to do is add
>> define('WP_DEBUG', true);
>>     
>
> Indeed, but to me this is akin to a power-user tool, and as you say
> yourself, displaying PHP notices remains quite unfriendly, and limited
> in its usefulness.  For lambda users, that would mean help requests
> like "I added WP-DEBUG, but it broke WordPress/my favorite plugin even
> further."
>   

My point was that you could make it look prettier or someone else. Just 
because the default is to throw a notice to the viewer doesn't mean that 
it could save the location of the problem and then output where the user 
can see it in a nicer format. No one has yet made a debug plugin, and I 
suppose I'm just waiting for someone else to make one, so that I don't 
have to. However, I wanted to do it a little bit differently, and the 
ticket that would allow me to do that hasn't been finished nor committed.

>
> 2008/7/29 Andy Staines <andy at yellowswordfish.com>:
>   
>> Please remember also that some of us support older versions of WP as well as
>> the latest. With each successive version that means more version checks,
>> branching, selectable includes..... some of which might trigger your red
>> light and give the end user an erroneous warning.
>>     
>
> So the best way would be to force plugin-devs to manually fill the
> "Requires WordPress Version: X.X or higher" and "Compatible up to:
> X.X" fields on  wp.org/extend/plugins? And maybe add a backend check
> to make sure it really fits in this versions, and if not send a
> warning to the plugin-dev to proofread his code and revalidate his
> stated supported versions?
>   

I think it would be great to have a front end with the plugins/themes 
extend where a trusted member can confirm the tested up to. That would 
be wicked sweet. I'm unsure how it would work.
>
> 2008/7/29 Gaarai <gaarai at gaarai.com>:
>   
>> If we can fix this problem either programmatically or procedurally, then we
>> can start talking about automated checks for deprecated code. Until such a
>> time, I feel that such checks will be nothing more than a pipe dream.
>>     
>
> WordPress' phpDocumentation is getting really precise thanks to
> Jacob's work, and deprecated functions do feature the @deprecated tag,
> with even a pointer to the replacing method. It would be even better
> if that tag included a "since version X.X", but by combining this
> information with the @since tag, a pretty solid compatibility table
> could already be extracted automatically from each /branched versions
> in SVN, and a table generated with each major version clearly
> indicated. Add to that a check that raises a flag if a new version
> doesn't support a function that the previous one did, and you got the
> @removed-like information filled-up. No need to rely on the
> possibly-outdated Codex.
> (yes, I know, @removed doesn't exist for obvious reason :) )

I should explain that. I had wanted to put when the function was 
deprecated, but that information wasn't readily available at the time. 
Also, it was agreed way back in like Fall of last year or something that 
it should just point to the function that replaces it. Not the best way, 
but was accepted way. It would be better if the @deprecated since X.X.X 
with @see function_name() instead. Might not make sense seeing it in the 
phpDocumentor site.

You could check the replacement function @since information to see when 
the function came to. This might not mean the same as when it was 
deprecated, but it should get you close.

Jacob Santos