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

[Xavier Borderie]

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


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?
That would therefore require a backend compatibility table for each
and every plugin (and theme!) API functions.
>From there on, the notitication process launched by WP could check not
only against each plugin's version, but also against WordPress version
itself. Users thus know if the widget can work with their version even
before they click the Enable button :)
I have no idea what would be the code implication of such a feature on
Extend, I'm just thinking out loud, sorry if it's too loud :).


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


Also, I agree with what Stephen Rider wrote.

-- 
Xavier Borderie