[wp-hackers] "Outdated plugin" notice
(was: load_plugin_textdomain() )
wp-hackers at striderweb.com
Tue Jul 29 21:30:19 GMT 2008
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?)
More information about the wp-hackers