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

[Gaarai]

Hey Jacob. We met at WordCamp back in April. This is the Chris that 
chatted with you about wanting to develop some coding standards for plugins.

You bring up a good point, and it reinforces my point about the lack of 
consistency. First off, there is no way that the deprecated.php file can 
ever be a comprehensive source of what is or is not deprecated. 
Secondly, while the commenting has been improving greatly, I don't think 
any type of commenting format could ever adequately identify the nuances 
that occur with some types of deprecation.

Consider the ongoing debate about the API change with the 
load_plugin_textdomain() attributes. No amount of entries into the 
deprecated.php file or exhaustive commenting could distinguish between 
the old function call with two parameters and the envisioned replacement 
function call with two parameters.

I guess my point is that there may not be a solution to this problem. I 
would rather have a lack of such a "debugging" system than a system that 
only caught the obvious problems while missing the obscure ones entirely.

I suppose that there is a possible solution that isn't as elegant but 
could be implemented right now. Plugins that contain a readme.txt file 
and have an appropriately-formatted "Tested up to" entry could be 
checked for version compatibility. Thus, if a WordPress upgrade were 
available (which the code for that already exists), the plugins listing 
could show whether or not specific plugins are to be considered ready 
for the upgrade to the latest WordPress version. Just an idea to throw 
into the hat.

- Gaarai

Jacob Santos wrote:
> Gaarai,
>
> There is this problem called phpDocumentor. Luckily, Peter Westwood 
> has blessed us with his public installation: 
> http://sandbox.ftwr.co.uk/doc/ Hopefully, one of these days this will 
> find itself on wordpress.org. Peter did suggest a better domain for 
> it, so who knows (but Peter).
>
> There is also the source, which has deprecated functions as marked, 
> and wp-includes/deprecated.php, which holds obsolete functions and 
> globals.
>
> Jacob Santos
>
> Gaarai wrote:
>> I think that we are missing something very important here. The Codex 
>> is consistently outdated on what is or is not deprecated, and often 
>> is an unreliable source of accurate and current API information.
>>
>> What mechanism could possibly keep track of the status of all 
>> function calls and valid parameters when the Codex doesn't even 
>> contain that data?
>>
>> 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.
>>
>> - Chris
>>
>> Stephen Rider wrote:
>>>
>>> On Jul 28, 2008, at 5:01 PM, Otto wrote:
>>>
>>>> On Mon, Jul 28, 2008 at 4:32 PM, Stephen Rider
>>>>> I think we need a narrow column in the plugins screen that can 
>>>>> display
>>>>> icons, and the icons either have a mouseover "tiptext" and/or are 
>>>>> clickabel
>>>>> to pop up a message window.  This could cover both this caution 
>>>>> message, and
>>>>> the "not checked for updates" message (and whatever else comes up 
>>>>> down the
>>>>> road.)  (Or maybe put said icons in the "version" cell?  Better 
>>>>> than a whole new
>>>>> column....)
>>>>
>>>> I'd put it in front of the plugin name.
>>>>
>>>> However, given the separation of plugins in 2.6 and 2.7-bleeding, I'd
>>>> prefer to simply create a new section at the top of the page: "Plugins
>>>> that need attention."
>>>>
>>>> Move plugins that need updates, plugins not checked, plugins found to
>>>> use deprecated functions, etc, all up there.
>>>
>>> FAR to intrusive.  There should be a notice, but they shouldn't 
>>> radically alter the plugin organization.  These are relatively minor 
>>> cautions, not major RED ALERTs.
>>>
>>> On Jul 28, 2008, at 6:42 PM, Adam Hunter wrote:
>>>
>>>> create a mechanism ( using the same concept that updates the 
>>>> plugins ) to check them against a depreciated function list before 
>>>> updating wordpress to a new version?
>>>
>>>
>>> Interesting idea, but probably a bit much.  What we could do, RE the 
>>> idea above, is to have different levels of warning --
>>>
>>> 1) This plugin contains outdated (deprecated) code.
>>> 2) This plugin contains obsolete (called functions are gone!) code.
>>>
>>> I was almost going to suggest auto-deactivation, but I don't think 
>>> we should go that far, as the outdated code might be part of minor 
>>> functionality and we shouldn't DEMAND that the user can't try to use 
>>> the plugin.
>>>
>>> What we're really doing is telling them where to look first if 
>>> there's a problem.
>>>
>>> Stephen
>>>
>> _______________________________________________
>> wp-hackers mailing list
>> wp-hackers at lists.automattic.com
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>