When developing a plugin, is there a way to automatically determine the minimum version of WordPress that’s required to run it? I want to make sure that the Requires header is accurate, but manually checking every time I call a new core function is tedious and error-prone.
I’m thinking a script could figure it out easily enough:
- Scan all the files in a plugin.
- Parse out all the class instantiations and function calls based on the
new foo( [...] ),foo::bar( [...] ),bar( [...] ),call_user_func( [...] ), etc syntax. - Parse the WP source to determine when each of those classes/functions were added to WordPress, using the
@sincephpDoc tag. - Generate a report listing each class/function and the version it was added, along with the earliest version of WordPress that includes all of the classes/functions.
I’ve looked around but couldn’t find anything like it, and don’t have the time to write it myself. Does anyone know of an existing solution?
I found a solution as an automated service over at http://wpseek.com/pluginfilecheck/
It’s does exactly, what was asked for including the generation of list of used functions and giving a suggestion for the Plugin-Header comments.
Well, this is more of a starting point, but there is this nice list of WP functions and the versions they were added/removed here. Unfortunately, it only goes up to WP 3.0.1, but if you’re shooting for 3.0 as a baseline it will at least help – if it’s not in the list, it was added later. You might want to email Ozh and ask him to update the list, and if one of us gets the gumption someone can make a plugin to check (like a reverse deprecation checker).
ETA: Per @mrwweb – Adam Brown’s Hook List! Current to 3.3 and goes waaaaay back to 1.2.1, which no one in their right mind would be running anymore (release date Oct. 6, 2004).
I think the answer does lie in the deprecated notices – you should be developing with WP_DEBUG true – whether you display or log them is your call, but WP will notify you if you use a deprecated function.
It would be possible to parse @since as you say, but tools can only take you so far – familiarity with the codebase and manual checking may be the way to go.