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:

  1. Scan all the files in a plugin.
  2. Parse out all the class instantiations and function calls based on the new foo( [...] ), foo::bar( [...] ), bar( [...] ), call_user_func( [...] ), etc syntax.
  3. Parse the WP source to determine when each of those classes/functions were added to WordPress, using the @since phpDoc tag.
  4. 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?

  • Have you seen this, wordpress.org/extend/plugins/log-deprecated-notices
    – Wyck
    Commented Apr 22, 2012 at 5:31
  • That'd be a good start, thanks for pointing it out :)
    – Ian Dunn
    Commented Apr 22, 2012 at 8:18
  • @IanDunn If you were able to find a solution to this, please do share it. :)
    – its_me
    Commented May 4, 2012 at 2:22
  • I haven't found a solution yet.
    – Ian Dunn
    Commented May 4, 2012 at 14:20
  • 2
    The more I think about this, the more it seems that WordPress should just build this and run it against all plugins in the repository so the version number is accurate for all plugins forever.
    – mrwweb
    Commented May 7, 2012 at 21:52

3 Answers 3


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.

  • That's pretty cool, thanks :) I think it'd be a lot more convenient if it were a WordPress plugin itself, rather than a web service, but it's better than nothing.
    – Ian Dunn
    Commented Apr 3, 2013 at 23:12
  • 2
    Unfortunately its also 'per file' - so no uploading of an entire plug-in. But still a very useful resource - great find! Commented Apr 14, 2013 at 22:23
  • 2
    That service now supports uploading a zip file, and it'll automatically scan all the files inside it :)
    – Ian Dunn
    Commented Nov 5, 2014 at 15:23
  • 2
    Is there any way to add this(de.wpseek.com/pluginfilecheck) or another alternate in static analysis of plugin during the build so that I don't need to go to the above site to check again n again and the build system will automatically generate a report along with other static analysis on every commit. Commented Jan 4, 2018 at 5:09

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

  • 2
    I would add Adam Brown's list of hooks by version (back to 1.2.1!) that would also be good to check against.
    – mrwweb
    Commented May 7, 2012 at 17:16
  • Thanks for the link to the Deprecation Checker plugin, that might provide some useful code to build on if I ever get time to write this.
    – Ian Dunn
    Commented May 8, 2012 at 18:24
  • That's a brilliant plugin, by WPSE user Brian Fegter.
    – SickHippie
    Commented May 8, 2012 at 20:09

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.

  • 1
    I think you answered the inverse of the question. The question wants to determine how far back support goes for the functions that are currently supported (e.g. a function your plugin uses was introduced in 3.1 so your plugin doesn't work in earlier versions, but that function doesn't throw an error or notice because it is supported now.)
    – mrwweb
    Commented May 7, 2012 at 16:23
  • You're right, serve me right for posting tired. Then what I'd suggest is manually checking it against the last major version and using that as an arbitrary starting point, because it's in everyone's best interests to encourage users to keep their WP up to date. Once a starting point has been established, commit messages are probably the best place to look in order to keep the Requires version updated, as any refactoring to avoid deprecated functions and methods should be noted there.
    – Chris Cox
    Commented May 7, 2012 at 16:54
  • Looking at wordpress.org/about/stats I'd say 3.2 is a nice version to shoot for, as any earlier versions are statistically insignificant.
    – Chris Cox
    Commented May 7, 2012 at 17:10
  • Thanks for the ideas Chris, but the main push here was to get an automated solution. You make a good point about versions older than 3.2 being statistically insignificant, though.
    – Ian Dunn
    Commented May 8, 2012 at 18:23
  • I'll make you a deal - let me know if you give up and write one, and I'll let you know if I get around to writing one. It's a good idea and would be a useful tool in anyone's toolbox.
    – Chris Cox
    Commented May 8, 2012 at 22:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.