[wp-hackers] WP Roadmap Project
viper at viper007bond.com
Thu Oct 30 21:22:26 GMT 2008
For the record, I'm not trying to say your work is unjustified or anything
like that -- docs are always awesome. I just think code 24/7 and like
debating different methods of accomplishing tasks via PHP. That's all.
Keep up the awesome work. :)
On Thu, Oct 30, 2008 at 6:32 AM, Chris <gaarai at gaarai.com> wrote:
> Once again Viper, you have great information. Thus one of the many reasons
> why I always read messages you send on the list.
> I suppose I haven't made a very good case for what I'm working on right
> now; you're right about that. I'll see if I can't justify what I'm doing.
> If you want to see the very rough front-end that I've put together, you can
> find it at (http://new.gaarai.com/roadmap/). I've only generated a few
> page views on 2.6.3 as of now, I'm not displaying any backtrace information,
> some of the stored data needs a lot of clean up, and the presentation leaves
> a lot to be desired, but it should give you a taste of what I'm going for.
> Also, some of the line numbers are going to be slightly off. I'm getting
> that fixed up currently.
> Currently, I intend to offer the following with WP Roadmap:
> * A full list of all page includes (include, require, etc) combined
> with other relevant function calls in their order of execution.
> * Provide detailed information at each roadmap entry. This
> information includes the source file containing the call, the line
> number, the arguments passed to the function, and a full backtrace
> on each call.
> * Be able to select an entry in the roadmap to pull up the full
> source-code listing that automatically scrolls down to the
> specific line of code and highlights it. This would be invaluable
> to quickly figure out how the WP core coding team did it.
> * Provide this information on any WordPress version with a large
> selection of specific page views. The execution stack changes from
> version to version and page view to page view. Providing
> information about the specific differences of the execution stack
> can quickly provide needed information on why a certain hook
> doesn't work properly on a specific page view or version.
> * All the core customizations are done via a script and not by hand.
> I also intend to write a script that can automate all the page
> views. This means that I will be able to install a newly-released
> version, add the roadmap code, and traverse all the page views to
> generate the data moments after the new version is released. In
> other words, this would be a very reliable source of information
> about any potential changes in new releases.
> Here are some other ideas of what I would like to create if I can and have
> time to:
> * A backtrace source view. This would be similar to the source view
> mentioned before except that it would pull out complete functions
> from the source of each backtrace step in order to give a quick
> code view from start to finish for specific points of execution.
> Each point along the backtrace execution path will be highlighted
> for quickly tracking the calls.
> * I mentioned before that I would like to create a generated tree
> image of the calls. I think producing a number of different
> quick-reference cards from this data could be beneficial for many
> * A version compare ability. This would allow you to quickly see the
> differences of the execution stacks between two versions. Out of
> all the ideas that I have, I think that this will be the most
> difficult to implement. Anyone have experience with generating
> difference sets?
> I know that not all of this information will be useful or relevant to every
> programmer. I do think that all the information will have value to someone
> however. One of my frustrations with the documentation that currently exists
> is that it is typically either inaccurate or insufficient for my specific
> needs. This results in me going to the command line and doing a series of
> grep queries to find what files I need to look through and then wading
> through a sea of code. If I could have a tool that would give me quick
> access to detailed information from the surface level down to the deep
> internals, I wouldn't have to spend so much time searching through code.
> I wouldn't be able to generate a reliable execution stack, backtraces, or
> version-specific and page-specific data without modifying the core or by
> using a plugin. I'm not sure if I've provided sufficient reason for you to
> think that this tool should exist. I know that I will find this tool very
> valuable, and as such, I'm sure that others will find value in it as well.
> - Chris Jean
> Viper007Bond wrote:
>> I'm pretty sure there aren't any hooks before plugins are loaded. As you
>> said, what would be the point of having them there if nothing could make
>> of them?
>> As for includes/requires, PHP has you covered -- no core editing required:
>> You still haven't offered a valid reason of why this couldn't just be a
>> couple line plugin. :P
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
Viper007Bond | http://www.viper007bond.com/ | http://www.finalgear.com/
More information about the wp-hackers