Jump to content

Tracy Debugger

adrian

By adrian,
in Tracy Debugger

 Share

Recommended Posts

adrian Hero Member

adrian

Posted
  • Author
Posted

Hi Adrian, i tried both master and dev, and also tried disabling all panels, but the error persists either way;

That is confusing that the errors persists with all panels disabled - is there any chance that you set a "sticky" set of panels that is overriding the settings in the module config? Closing your browser should clear the session cookie.

Link to comment
Share on other sites
lpa Sr. Member

lpa

Posted
Posted (edited)

Have you seen this before? I just upgraded to the latest version both PW (3.0.18) and TracyDebugger (1.5.6)

post-442-0-25480400-1463239137_thumb.png

Edit:

I found this later:

Error: DiagnosticsPanel
exception 'RuntimeException' with message 'SplFileInfo::getPerms(): stat failed for /Library/WebServer/Documents/XXX/YYYY/ZZZ' in /Library/WebServer/Documents/pw3/site/assets/cache/FileCompiler/site/modules/TracyDebugger/DiagnosticsPanel.inc:286
Stack trace:
#0 /Library/WebServer/Documents/pw3/site/assets/cache/FileCompiler/site/modules/TracyDebugger/DiagnosticsPanel.inc(286): SplFileInfo->getPerms()
#1 /Library/WebServer/Documents/pw3/site/assets/cache/FileCompiler/site/modules/TracyDebugger/DiagnosticsPanel.inc(349): DiagnosticsPanel->incorrectPermissionFiles()
#2 /Library/WebServer/Documents/pw3/site/assets/cache/FileCompiler/site/modules/TracyDebugger/tracy-stable/src/Tracy/Bar.php(73): DiagnosticsPanel->getPanel()
#3 /Library/WebServer/Documents/pw3/site/assets/cache/FileCompiler/site/modules/TracyDebugger/tracy-stable/src/Tracy/Debugger.php(221): Tracy\Bar->render()
#4 [internal function]: Tracy\Debugger::shutdownHandler()
#5 {main}
 
This is quite odd, because the RuntimeException is happening outside my pw-root which is /Library/WebServer/Documents/pw3/ not /Library/WebServer/Documents/XXX/.
 
2nd edit:
 
those files are either symbolic links pointing to non-existing files or "failed to open dir: Permission denied" errors. But still I don't know why tracy is reading the files outside PW root?
Edited by lpa
Link to comment
Share on other sites
Macrura Hero Member

Macrura

Posted
Posted

That is confusing that the errors persists with all panels disabled - is there any chance that you set a "sticky" set of panels that is overriding the settings in the module config? Closing your browser should clear the session cookie.

OK- sorry about this, i did as you recommended and was able to get rid of the error by disabling the ProcessWire Info panel; So yes, something about that panel and not sure if it related to the lines which are referenced in the error which all pertain to track changes.

  • Like 1
Link to comment
Share on other sites
adrian Hero Member

adrian

Posted
  • Author
Posted

Have you seen this before? I just upgraded to the latest version both PW (3.0.18) and TracyDebugger (1.5.6)

attachicon.giftracy.png

Edit:

I found this later:

Error: DiagnosticsPanel
exception 'RuntimeException' with message 'SplFileInfo::getPerms(): stat failed for /Library/WebServer/Documents/XXX/YYYY/ZZZ' in /Library/WebServer/Documents/pw3/site/assets/cache/FileCompiler/site/modules/TracyDebugger/DiagnosticsPanel.inc:286
Stack trace:
#0 /Library/WebServer/Documents/pw3/site/assets/cache/FileCompiler/site/modules/TracyDebugger/DiagnosticsPanel.inc(286): SplFileInfo->getPerms()
#1 /Library/WebServer/Documents/pw3/site/assets/cache/FileCompiler/site/modules/TracyDebugger/DiagnosticsPanel.inc(349): DiagnosticsPanel->incorrectPermissionFiles()
#2 /Library/WebServer/Documents/pw3/site/assets/cache/FileCompiler/site/modules/TracyDebugger/tracy-stable/src/Tracy/Bar.php(73): DiagnosticsPanel->getPanel()
#3 /Library/WebServer/Documents/pw3/site/assets/cache/FileCompiler/site/modules/TracyDebugger/tracy-stable/src/Tracy/Debugger.php(221): Tracy\Bar->render()
#4 [internal function]: Tracy\Debugger::shutdownHandler()
#5 {main}
 
This is quite odd, because the RuntimeException is happening outside my pw-root which is /Library/WebServer/Documents/pw3/ not /Library/WebServer/Documents/XXX/.
 
2nd edit:
 
those files are either symbolic links pointing to non-existing files or "failed to open dir: Permission denied" errors. But still I don't know why tracy is reading the files outside PW root?

I have just pushed a fix for this - sorry about that!

OK- sorry about this, i did as you recommended and was able to get rid of the error by disabling the ProcessWire Info panel; So yes, something about that panel and not sure if it related to the lines which are referenced in the error which all pertain to track changes.

Glad that it's now working without the PW Info panel. I definitely need to make some optimizations there - I will try to take a look at this on Monday. It would be great to be able to replicate exactly what you have going on there, so I will probably come back with some more detailed questions for you. I am actually wondering about the PW Info panel in general and trying to figure out what elements of it you guys are finding most useful and whether some parts should be split into another panel so that those bits that are slow (due to loading large table fields for example) can be in a panel that you only load as needed using the "Once" option in the Selector Panel.

  • Like 1
Link to comment
Share on other sites
Macrura Hero Member

Macrura

Posted
Posted

Thanks, what is strange is as i mentioned these appear to be completely random in terms of why they exhibit this error; it may be nothing directly due to TD; some of these that exhibit the error have much less data/info on the page than other siblings which don't crash; i've been trying to figure out if there is some deep error somewhere in the code that could be causing it, will keep tracking it down..

  • Like 1
Link to comment
Share on other sites
adrian Hero Member

adrian

Posted
  • Author
Posted

Those of you who noticed very slow rendering of the Debugger bar, but noticed significant improvements when you switched to the stable version of the Tracy core - were you all running xdebug? I noticed that it speeds things up significantly (almost as fast as the stable branch) if you disable xdebug.

If that is the case for you it might be helpful if you could contribute any ideas to this issue: https://github.com/nette/tracy/issues/157#issuecomment-219547179 and either confirm that disabling xdebug helps, or it doesn't and any other info you have that you think might help to solve it.

Thanks!

Ignore this - see my next post.

Link to comment
Share on other sites
adrian Hero Member

adrian

Posted
  • Author
Posted

You can ignore my last post - @dg decided to go with the approach of sending all debugger bar requests with: XDEBUG_SESSION_STOP=1 which seems to solve the issue for me.

So for those of you who manually switched to the stable branch, I would suggest updating to the latest version of this module and switching back to master. I will be removing the old stable option (or swapping them when the master is released as 2.4 stable).

Please let me know if things are running fast again with the new version and master branch - thanks!

  • Like 2
Link to comment
Share on other sites
tpr Hero Member

tpr

Posted
Posted

Just tested with latest Tracy and it seems everything works fine here, no slowdowns and the bar appears even using the Master option (http & https). I wasn't using xdebug btw.

Thanks!

  • Like 1
Link to comment
Share on other sites
adrian Hero Member

adrian

Posted
  • Author
Posted

I have just added a new config setting: Local Root Path which you can use to modify the editor links from a production server to a your local dev files - I think this is a really handy improvement. If you have the remote server mapped as a local drive, you could even point to that if you'd prefer.

It also includes a bunch of Tracy core updates, including support for AJAX errors on the bluescreen, but you guys can read more about the changes here (https://github.com/nette/tracy/commits/master) if you want.

  • Like 3
Link to comment
Share on other sites
adrian Hero Member

adrian

Posted
  • Author
Posted

Another really cool (at least I think so  :) ) panel.

Template Path allows you to temporarily change the template file of the page.

post-985-0-96503600-1463778562_thumb.png

By default, it adds "-dev" suffix to the filename, eg. home-dev.php, but you can change this on-the-fly to whatever suffix you want, allowing you to easily test different versions. Like the selector panel, you can make the change "Once", or "Sticky" for the session.

Sticking with the "alert" approach to icon colors, if the template icon is green, then it is loading the default template file. If it is red, then it is loading your temporary template file.

Hopefully you'll all find this very useful when debugging live sites - no excuses now to ever make changes to a live file without testing first  :)

Please let me know if you have any suggestions for enhancing this feature - we all work differently, so there might be some cool approach that I could support that I haven't yet thought of.

  • Like 4
Link to comment
Share on other sites
tpr Hero Member

tpr

Posted
Posted

Interesting feature, will try it next time.

I think the once-sticky-reset control is not very understandable, at least for me. Maybe adding a pushed state to the sticky button would clear things a bit (when it's active). And perhaps adding different colors to once-sticky buttons would also help. Reset could go to the far right and be shown as a text link.

I can do a design mockup if you think tho is a good idea. But it may be that I shoot in the dark as I have never used these kind of panels.

Link to comment
Share on other sites
adrian Hero Member

adrian

Posted
  • Author
Posted

Hey @tpr - thanks for your thoughts on this. Perhaps the styling of those buttons could be improved to make it more obvious what is selected. In the PanelSelector Panel I add an icon next to each panel to indicate it is is loaded "Once" which I think works, but perhaps it could be improved by having a selected/pushed state added to it.

Anyone else have any thoughts on this?

A design mockup sounds like it could be helpful, but please don't go to too much trouble - I think I understand what you are wanting. 

Link to comment
Share on other sites
szabesz Hero Member

szabesz

Posted
Posted
Anyone else have any thoughts on this?

The UI of the two panels should match as much as possible, otherwise I'm quite happy with anything that works with the fewest clicks possible, and provides ways to easily see in which states the settings are ;)

Oh, and many thanks for the new panel! Now I just need to train my memory not to forget about all the goodies your wonderful module offers :)

  • Like 1
Link to comment
Share on other sites
tpr Hero Member

tpr

Posted
Posted

I played with pixels and here is the concept. What bugged me the most were the green tick icons, they were too loud imho. Szabesz was right that they were confusing because the checkboxes are very similar (both meaning "checked"). Now I replaced them with an asterisk. Maybe this is not the best solution, but I think such signal is enough.

"Once" orange icons went to the left, it's easier to overview them if they are under each other. My first idea was to put them to the far right, but then one couldn't see which panel they belong.

The template file changer works great, though I use a template engine so I have to change the view file name inside home-dev.php. But I guess there is no general fix for this and I can live with it.

Here are mainly design mods, to make more obvious where is what. I'm not entirely happy with the Once-Sticky buttons, but such differentiaton should make clear which one is active.

There's also an error: if I check Toggle All, I get this:

post-3156-0-02144500-1463835188_thumb.pn

exception 'ErrorException' with message 'file_get_contents(http://...domain.com/?tracyValidating=1): failed to open stream: HTTP request failed! HTTP/1.1 401 Authorization Required
' in /....../public_html/...sitename.../site/assets/cache/FileCompiler/site/modules/TracyDebugger/ValidatorPanel.inc:34

post-3156-0-01377600-1463834081_thumb.pn

post-3156-0-58101400-1463834218_thumb.pn

  • Like 4
Link to comment
Share on other sites
adrian Hero Member

adrian

Posted
  • Author
Posted
The PW Upgrade module shows an upgrade for Tracy Debugger (from version 1.6.6 to 1.6.7)

Sorry about that Charles - I reverted a commit from last night that turned out to be a bit buggy, but I forgot to revert the version number in the modules directory. I have just recommitted a fixed version with that new version number, so hopefully your update should now work.

The new version uses a <select> for choosing from available alternate template files. I think this makes it easier. It now also remembers different dev versions for different templates. Obviously you need to create the file in the templates directory first before it will be available from the select dropdown. You can now also reset just this template, or all templates on the site.

post-985-0-70512200-1463849617_thumb.png

@tpr - thanks for those great mockups - I haven't had time to incorporate your ideas yet, but will do hopefully shortly. The error you are getting is specifically with the validation panel - I am not completely sure why file_get_contents is giving that authorization required error. I am using wireHttp first and falling back to file_get_contents. I will look into this soon also, but in the meantime, disabling the Validator will gets things going for you.

The latest version also includes some core Tracy updates which introduced lazy rendering of panel contents - this should speed up initial rendering of the debugger bar significantly.

  • Like 2
Link to comment
Share on other sites
tpr Hero Member

tpr

Posted
Posted

Sorry to bother again, but even with disabled httpasswd the validator panel says Validation Errors, and its content is 

Sorry, but there was a problem accessing the validation server at https://html5.validator.nu/

But when I manually visit html5.validator.nu and paste the URL of the site, it says everything is fine (valid).

Commenting out this line fixed this, valid/invalid messages appeared fine. Maybe this line is required only for the non-html5 validator?

Link to comment
Share on other sites
adrian Hero Member

adrian

Posted
  • Author
Posted

No problem at all - sorry it's causing you problems :)

The line you point to is to clean up the returned results for display - the results start with <ol> for both the standard and html5 validators so I am not sure why, but I have committed a new version which has a much cleaner approach to extracting the contents of the <ol> - hopefully this will mean that $this->result won't end up blank for you, which is what must be happening to cause that error which is triggered here: https://github.com/adrianbj/TracyDebugger/blob/master/ValidatorPanel.inc#L510

Please let me know if the new version helps.

Link to comment
Share on other sites
tpr Hero Member

tpr

Posted
Posted

Partly yes - it says Validated but the panel contains too much info - or is this normal?

post-3156-0-73015600-1463863408_thumb.jp

It seems that the two validators have different markups or perhaps the html5 validator page markup was changed.

The green bordered line is a "p" tag with "success" class.

Maybe I see this because I'm the only one here writing valid markup? :)

  • Like 1
Link to comment
Share on other sites
adrian Hero Member

adrian

Posted
  • Author
Posted

@tpr - some of that was intentional, but some was a result of the last change.

The latest version now cleans this up better and should look like this:

post-985-0-95844000-1463870068_thumb.png

or:

post-985-0-92574200-1463870148_thumb.png

Please confirm that it looks the same for you now too - thanks!

  • Like 3
Link to comment
Share on other sites
  • adrian pinned and locked this topic
  • adrian unpinned and pinned this topic
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...