[wp-hackers] WP Roadmap Project

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
>     developers.
>   * 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
>> use
>> of them?
>>
>> As for includes/requires, PHP has you covered -- no core editing required:
>> http://www.php.net/manual/en/function.get-included-files.php
>>
>> 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
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>

-- 
Viper007Bond | http://www.viper007bond.com/ | http://www.finalgear.com/