1

So I have a php application with lots of different files, the code is a bit of a mess.

What I want to do is install the application on my server, use it briefly, try to cover all functionality clicking here and there, and then get a log somehow that says 'these php files were used' or 'these functions were accessed'.

I don't care about function arguments, time needed, how many times each thing was called etc etc.

I just want to see if there are functions or at least whole files that are never called - so they are dead.

I know that 1) it could be possibly done by editing each file and writing something out when it is called or included 2) there may be static tools that try to follow all code paths etc.

I'm not interested in the above - i need just something, probably a php module/debugger I'm not sure, that logs which files are requested/included/run by php. If specific functions can be traced too, even better. But even just files would be awesome.

frustrated_george
  • 109
  • 1
  • 11
  • 1
    A little `grep` can go a long way. Specifically, it can find `require` and `include`, all statically compiled function calls, and all defined functions. With a little data massaging you can get on top of the problem without running any code. – Jon Dec 05 '11 at 17:43
  • @Jon The problem with this approach is that I'll find files that are included or required in parts of the code that are never actually accessed by the application. The code base has old and new files - some of the functions or files are not called from anywhere while using the application - that is the main problem. Grep will not help! – frustrated_george Dec 05 '11 at 17:46
  • That's great! As soon as you find some dead code, you can delete it and start over. You can then find some *more* dead code, until all you are left with is only code that is actually useful. – Jon Dec 05 '11 at 17:48

3 Answers3

5

Sound like you are looking for debugger like xdebug, specially this feature and this function trace

ajreal
  • 46,720
  • 11
  • 89
  • 119
  • http://meta.stackexchange.com/questions/8231/are-answers-that-just-contain-links-elsewhere-really-good-answers – Gordon Jul 24 '13 at 08:28
1

This is just to get a list of files that are in use. A debugger would be required to do a profiling of your project. Also reference this answer to a similar question.

The list of included files will be saved to a text file.

In your php.ini, set up auto_prepend_file to point to a file that contains the following.

<?php

function shutdown_file_output()
{
    file_put_contents( 'included_files.txt', implode( PHP_EOL, get_included_files() );
}

register_shutdown_function('shutdown_file_output');
Community
  • 1
  • 1
Tim G
  • 1,812
  • 12
  • 25
  • This is very intersting, thank you Tim G. I didn't know about the auto_prepend functionality, cool :) My only problem with this is: Will it also log when files are accessed without include? E.g. while browsing, I make access script1.php, script2.php or more. Of course I can see what I access - most times. Other times scripts may be accessed using ajax without me noticing – frustrated_george Dec 05 '11 at 18:37
  • The script originally called is considered an "included file," so it will be listed together with the files referenced by include() and family – Tim G Dec 05 '11 at 18:55
0

PHP's debug_backtrace() function can be used to get a full trace of a script's execution, including called functions and arguments. If you place a call to this function at the end of your script and log the output to a file or files then that should accomplish what you're looking for.

wrren
  • 1,281
  • 9
  • 11
  • I've used debug_backtrace for other purposes and it does what I've said, why? – wrren Dec 05 '11 at 17:52
  • 1
    Because it's a fine tool -- for other purposes. – Jon Dec 05 '11 at 17:53
  • 1
    That's not particularly helpful, if you think that it's unsuitable as a method for doing what was asked then please say why. – wrren Dec 05 '11 at 17:57
  • 1
    There are so many reasons. I 'd start with "you don't *know* where the deepest part of the script is for each possible call chain" -- and for this to work you need to do this at the deepest nesting level, not the "end of the script". – Jon Dec 05 '11 at 18:03