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

[Stephen Rider]

On Jul 29, 2008, at 7:51 AM, Jacob Santos wrote:

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

Depending on plugin authors to fill in the max compatibility info is  
circular reasoning.  If they're not checking it out and getting rid of  
obsolete function calls, they sure as heck aren't going to fill in the  
compatibility info either.  "When it breaks, it needs updating."

About the only way I can think of that this could be automated is if,  
upon update, WordPress read the source files of plugins and looked  
(via grep) for function calls, and then compared what it found to a  
list of deprecated functions.

Kind of brute force, but the _deprecated_function and _deprecated_file  
functions can only find the functions when they're called.

Okay, second idea:

Maybe a debug system could hook into _deprecated_function etc. and  
simply record hits.  (I think there is a do_action within each of  
those, so it could be done that way with a plugin right now.)

The limitation is that it would only find them as they are called, and  
thus couldn't possibly flag bad plugins preemptively.  To find the  
outdated code without running it, you need to read the files....

Is there a hook for when WordPress notices that it's been updated?   
(Not just when database needs to change, but when THIS run is a higher  
version of WP than the PREVIOUS run?)

Stephen

-- 
Stephen Rider
<http://striderweb.com/>