Module Tracy Debugger

[tpr]

I see the issue, thanks. Your fix was working because position: inline-block is invalid, so I removed it entirely ?

styles.css

[adrian]

Just now, tpr said:

I see the issue, thanks. Your fix was working because position: inline-block is invalid, so I removed it entirely ?

styles.css

Oops ?

Your latest version still didn't work because of position:absolute but the attached version seems fine:

 

styles.css

[tpr]

There's no position: absolute in the one I added lastly ? Anyway, I have added two additional minor things in that file, here are the full blocks involved:

ul.dumpTabs+span {
    margin-right: 1px;
    margin-top: -25px;
    user-select: none;
}

ul.dumpTabs+span a {
    display: inline-block;
    padding: 4px 6px 3px 6px;
    font-size: 12px !important;
}

(margin-right instead right, and a padding adjustment)

[adrian]

39 minutes ago, tpr said:

There's no position: absolute in the one I added lastly ?

Sorry, I did grab it but did a diff and I guess I somehow copied the wrong one across to my testing site - apologies for the confusion!

Anyway, thanks for those other changes. I think everything looks great now, so I have committed and modules directory is updated.

Thanks again for your effort on this!

[adrian]

@szabesz - just wanted to let you know that I have implemented more of your ID and count idea to the dumps output. Notice the tooltip titles (and link address below) on the edit links to various PW objects and then in the last one you can see the number of items in the PageArray (which also works with any WireArray, including images, repeater items, etc). Note that the tooltip titles also show you the name of the object which I think is also a nice preview rather than having to open the dumped object.

 

[szabesz]

Excellente! We cannot thank you for all the hard work you share with us.
Where is the donate button, btw? ? 

[Zeka]

@adrian, @tpr Thanks for updates to the module. The new color scheme looks clean and new style of objects info inside the Dump panel also really great edition.

[adrian]

Thanks @szabesz and @Zeka for the kudos - much appreciated!

I just added a new optional "Iterator" tab to the dumps output which return the output of PW's getIterator() method which in the case of page objects returns the values of all properties and fields for the page. For other objects, what is return varies somewhat, but in some cases it is more useful than the debugInfo result which is still lacking for many objects. Here is just one example - the debugInfo output for Permissions is basically useless, but the Iterator output contains useful info.

Sure, you could manually dump the object with ->getIterator() added to it, but this makes it that much easier when you are looking for different bits of info and you're not sure which option will provide the exactly what you need in the easiest format to find it.

An interesting side-effect of the Iterator tab is that the Full Object now also contains values for all the fields when dumping a page object because the getIterator() call queries all those fields and they are now joined to the page object.

 

I have made this optional, so you will need to go to this setting to enable it:

[Robin S]

Thanks for all the recent updates @adrian (and @tpr too).

Is the "Use debugInfo() magic method" option redundant now? With this option unchecked I still see a populated Debug Info tab in the dumps panel.

Also, do you think it would be possible to include a setting for which dump tab is active (or leftmost) by default, for those of us who most often want the Full Object and the Debug Info only once in a while? 

[Robin S]

A little issue...

Tracy Debugger v4.10.24 (working)

Tracy Debugger v4.11.10

[adrian]

14 hours ago, Robin S said:

Is the "Use debugInfo() magic method" option redundant now? With this option unchecked I still see a populated Debug Info tab in the dumps panel.

It's not completely redundant - it still determines how dumps in the RequestInfo panel's Field List & Values sections are output. It also defines the default dump for the dump/barDump output for cases where the separate tabs may not kick in - not sure if there actually are any situations where this will happen. It now also controls the output of field values in the Iterator tab. Also with the new option (described below) to choose what tabs you want, if you choose none, then this setting will be relevant to how the one version of the dump is handled.

14 hours ago, Robin S said:

Also, do you think it would be possible to include a setting for which dump tab is active (or leftmost) by default, for those of us who most often want the Full Object and the Debug Info only once in a while? 

Good idea - done:

 

11 hours ago, Robin S said:

A little issue...

Thanks for reporting this undefined variable error - it's fixed now and hopefully there shouldn't be any other cases like this, but please let me know if you come across anything else.

 

 

[adrian]

Oh and I also made the dump in the additional tabs open (not collapsed) by default.

My thinking on this is that if you dump lots of items, you don't want the default tab to be open by default because it could make for too much scrolling, but for the additional tabs, if you click on them then it's obvious you want to see the content so you shouldn't need to click again to expand the dump. 

Let me know if you guys don't like this behavior and if you have a preferred approach.

See how below I can quickly scroll through to the dump I am looking for (because the default Debug Info tab content is collapsed), but when I switch to the Iterator or Full Object tabs, these are not collapsed.

[Robin S]

5 hours ago, adrian said:

Oh and I also made the dump in the additional tabs open (not collapsed) by default.

I like this, but I think when you switch back to the first tab the dump should be expanded. Because in clicking the tab you are saying "show me this tab content", and if you are actually wanting to just reduce the height of the dump container you would click to collapse the dump on the current tab.

Maybe a simplified way of handling this would be that clicking any tab a) shows that tab's content and b) toggles the collapsed state of the dump. So dumps in all tabs would be loaded collapsed by default, but clicking a tab also toggles open a collapsed dump so has the same effect as this latest update. It would also allow for an alternative way to collapse the dump on the current tab (i.e. clicking the active tab collapses/opens that dump depending on its current state).

[adrian]

1 hour ago, Robin S said:

I like this, but I think when you switch back to the first tab the dump should be expanded. Because in clicking the tab you are saying "show me this tab content", and if you are actually wanting to just reduce the height of the dump container you would click to collapse the dump on the current tab.

Maybe a simplified way of handling this would be that clicking any tab a) shows that tab's content and b) toggles the collapsed state of the dump. So dumps in all tabs would be loaded collapsed by default, but clicking a tab also toggles open a collapsed dump so has the same effect as this latest update. It would also allow for an alternative way to collapse the dump on the current tab (i.e. clicking the active tab collapses/opens that dump depending on its current state).

I knew that request was coming ?

I have added all this to the latest version, including the click again on the tab to collapse.

Please test and let me know if the behavior is what you are looking for.

[Robin S]

9 minutes ago, adrian said:

Please test and let me know if the behavior is what you are looking for.

Very nice, thanks!

[Robin S]

Hi @adrian,

What do you think about adding a "Expand/Collapse All" button for dumps? This button would expand/collapse all nested elements within a dump would be useful in situations where you are dumping a massive nested object and you want to use the browser's find tool to look for a specific string of text.

[tpr]

Actually it would be pretty easy, just add .tracy-collapsed { display: block; }. You can even do it without Js by adding a hidden checkbox somewhere above all containers and use something like this:

input:checked ~ [selector for an element in the same level] .tracy-collapsed {
    display: block;
}

Plus you can wrap the input in a label and format that it as an icon.

Update: wrapping the input in a label won't work (the CSS sibling combinator "~" cannot target the desired element), but adding a "for" and an "id" to the label and the input is OK. However, in this case the CSS solution is not applicable because once all nodes are expanded you can't manually collapse individual nodes.

[adrian]

The most recent version includes @Robin S's suggestion for "Expand/Collapse All" functionality. Both Robin and @tpr have helped significantly with testing of this feature - thank you both.

Also new in this version is the ability to override any module config settings using:

$config->tracy = array()

You can read more about this and why it was introduced here: 

 

[adrian]

More enhancements to help support @Ivan Gretsky's needs. These settings (via config.php/config-dev.php or the module config settings):

$config->tracy = array(
    'enabled' => true,
    'guestForceDevelopmentLocal' => true,
    'frontendPanels' => array('mailInterceptor','processwireInfo','requestInfo','processwireLogs','tracyLogs','debugMode','console','panelSelector'),
    'backendPanels' => array('mailInterceptor','processwireInfo','requestInfo','processwireLogs','tracyLogs','debugMode','console','panelSelector'),
    'nonToggleablePanels' => array('mailInterceptor', 'tracyToggler'),
    'panelSelectorTracyTogglerButton' => false
);

results in the following:

1) Tracy is enabled
2) Tracy is in development mode (ie debug bar on) even when logged out on localhost / dev machine
3) Mail Interceptor is enabled and can't be toggled off (notice that the checkbox is greyed out)
4) Tracy Toggler panel is disabled and can't be toggled off (notice that the checkbox is greyed out)
5) Tracy Disable/Enable (toggler) button in the Panel Selector is removed

 

[bernhard]

Hey @adrian

I've had some headache today because of outputformatting and the tracy console. I have several saved and saveready hooks active that populate fields, do aggregations and so on. Everything seemed to work well, but when I updated all pages through the tracy console (basicalle a foreach loop with $p->save() to trigger the hooks) things started to get weird.

I found out that it must be an outputformatting issue. In the hooks and modules OF is always FALSE but using the console OF seems to be TRUE. Is this indented? When I add $pages->of(false) on top of my console code everything works as expected. I ended up with hundreds of pages having status corrupted (131073).

Wouldn't it be better to set OF to FALSE by default?

[adrian]

5 hours ago, bernhard said:

Hey @adrian

I've had some headache today because of outputformatting and the tracy console. I have several saved and saveready hooks active that populate fields, do aggregations and so on. Everything seemed to work well, but when I updated all pages through the tracy console (basicalle a foreach loop with $p->save() to trigger the hooks) things started to get weird.

I found out that it must be an outputformatting issue. In the hooks and modules OF is always FALSE but using the console OF seems to be TRUE. Is this indented? When I add $pages->of(false) on top of my console code everything works as expected. I ended up with hundreds of pages having status corrupted (131073).

Wouldn't it be better to set OF to FALSE by default?

Hey Bernhard - sorry for the hassles - hope you didn't do any long term damage to anything!

As for whether this should be on or off, I am not really sure to be honest. Perhaps it should be "ON" if you're using the Console panel on the frontend and "OFF" if you're using it in the backend/admin.

I don't explicitly set it on, but that is how it works by default.

The problem with it being off is if you simply want to get the value of a field, it will return the raw, unformatted value:

instead of:

So, I guess we could take several different approaches:

1) Always ON
2) Always OFF
3) ON in frontend and OFF in backend/admin
4) Configurable as ON or OFF for both
5) Configurable separately for frontend and backend

Any thoughts? 

What does everyone else think?

 

[bernhard]

16 minutes ago, adrian said:

Hey Bernhard - sorry for the hassles - hope you didn't do any long term damage to anything!

No worries ? No - working on a dev environment so it is/was no problem.

I get your points. Don't know what would be the best approach. Maybe tracy should not be responsible for that at all and I should adopt my code to make sure OF is always false? But on the other side the docs say that OF is always false in module context, so I'm not sure what is the best approach? Would be happy to hear your thoughts.

Personally I use the console a lot for testing hooks etc. and I've come over several occasions with weird results where it made a difference if I saved the page manually or via the tracy console $page->save(). I guess that where all OF issues...

Hm... First I wanted to vote for OF=false by default, but I see that in the frontend it makes sense to have it ON to get the same results as in template context. But I don't think it is a good idea to have different settings in frontend and backend. I guess that would lead to unexpected/unwanted bugs even more than now. I think there should be one standard that is equal everywhere.

Maybe two little radiobuttons on top of the console would be the best option? That would ad least remind us of thinking about it and make it easy to change?

Edit: The state of the radio would need to be saved somehow. Not sure how to treat that best? Maybe the easiest and best option would be a simple hint on top of the console that adds "$pages->of(false)" to the code when we click on it. That way it would not change the settings for all other open consoles and it would make sure that this one code has the correct setting.

Or maybe the best would be just to remember it myself? ? What do others think?

[adrian]

I do want to hear from a few others, but I actually think that #3 (off in backend and on in frontend) makes most sense to me because that matches how PW itself works. I think perhaps a simple OF icon with either a red or green background somewhere on the console panel is probably a good idea as a reminder, but I don't think there should be a toggle - I think if you need to adjust the status, it should be added to the Console code.

[Robin S]

4 hours ago, adrian said:

I do want to hear from a few others

My vote goes for the status quo - no need to change output formatting or have an indicator IMO.

I think the best thing is to get into the habit of always turning output formatting off before setting any value to a page (I tend to do it individually for the page I'm changing rather than for all pages). I think it's simplest to follow that rule everywhere - frontend, backend, in a module, etc. It's just a single line of code, and if output formatting is already off for any reason then it doesn't do any harm to explicitly set it off to be sure.

If Tracy was to get involved in output formatting I think it would add confusion, particularly for new users who are still getting to grips with output formatting.

[adrian]

I just committed a new version with several tweaks and fixes for the old, unloved Template Resources panel. It now better detects variables, constants, and functions that are only used once and therefore redundant code. The panel icon is now also colored to warn you that there are redundant things that you could remove.