Module Tracy Debugger

[Mike Rockett]

Seems that the 'blue screen' template can't really be overriden without completely overriding the $blueScreen static with our own class. :-(

Edit: nope, can't override it that way either - $blueScreen is private.

Edit: This issue has reference to the topic.

Edited October 8, 2017 by Mike Rockett

[adrian]

44 minutes ago, Mike Rockett said:

Seems that the 'blue screen' template can't really be overriden without completely overriding the $blueScreen static with our own class. :-(

Ah yes, sorry it is a little more complicated because it's hard to inject styles into bluescreen because a fatal error/exception means that PW isn't loaded, so I don't have easy control over that. 

I have found an approach (hack) that might be ok. Insert the following code here: https://github.com/adrianbj/TracyDebugger/blob/6f4ffa444e9f464b5b44a3de82ba8cc3a6b51a17/TracyDebugger.module#L825

        Debugger::getBlueScreen()->addPanel(function ($e) { // catched exception
            return [
                'tab' => 'ProcessWire',
                'panel' => '
                    <style>
                        #tracy-bs-error {
                            background: #cccccc;
                        }
                        #tracy-bs h1 {
                            color: black;
                            font-size: 12pt;
                            text-shadow: none;
                        }
                    </style>',
            ];
        });

 

Anything you add to the styles here will be loaded for the bluescreen page. The only catch is that it results in a new empty panel on the bluescreen called "ProcessWire". Maybe if we could come up with some actual useful content for this panel, it wouldn't feel like such a hack. Any ideas for something useful there?

 

PS - obviously I don't want grey background / black text

[Mike Rockett]

@adrian - Thanks, didn't think of doing it like that. Though, being a 'clean coder', I still feel it's hacky, even if we were to occupy the panel... I find it really weak (for lack of a better word) of Nette to now allow changes to the design.

I saw in a pull request that you mentioned making changes to the source (and that you didn't want to do it, but let's skip that part for a second). I wonder if we shouldn't use our own Bluescreen class and simply make the $bluescreen service public. Tracy releases don't seem to be all that frequent, and so changing this when you update shouldn't be a hassle. The service class could then be changed to use our own templates, which would be based on the existing ones (copy-paste-modify). For me, this seems far less hacky in terms of the output. In such a class, we could make the adjustments required (and add the PW logo in there somewhere).

On another note, I see that the index.php exception handler appends the stack to the error message itself. So, when a new WireException is thrown, that red bar (or whatever colour we change it to) extends out. I'm wondering if there's a way to inspect each exception message and pass the stack into a panel, leaving only the original message in the top bar. Thoughts?

[tpr]

How about modifying the core bluescreen and make a PR to Tracy core? At first the best would be to make design mockups and ask both parties (PW &Nette) for approval.

[Mike Rockett]

Just now, tpr said:

How about modifying the core bluescreen and make a PR to Tracy core? At first the best would be to make design mockups and ask both parties (PW &Nette) for approval.

Something about the way in which Nette operates tells me that they wouldn't accept the PR, especially due to a comment in that issue I linked to about it being non-relevant.

<rant>In that thread, it is said that "Tracy has quite polished appearance", and I beg to differ. Apparently, it's also not supposed to look colourful. Red is a colour. And for some people, like myself, red is just far too vivid. Wish they'd learn something from the likes of filp/whoops.</rant>

[abdus]

2 minutes ago, Mike Rockett said:

Wish they'd learn something from the likes of filp/whoops.

+1

I really like whoops's color scheme and layout but I guess Tracy is packed with more indispensable features.

[Mike Rockett]

3 minutes ago, abdus said:

... Tracy is packed with more indispensable features.

Absolutely - and that's what makes Tracy great. I'm not a huge fan of Whoops’ sidebar style (when the left gets too long, the scrollbar breaks the dark colours between the two panes). I do prefer the Tracy layout in general. It's just a matter of making it more clean and modern.

[tpr]

I still think that a nice looking img preview could convince those Czechs Anyway, in case that attempt would fail you could start hacking.

[Mike Rockett]

3 minutes ago, tpr said:

I still think that a nice looking img preview could convince those Czechs Anyway, in case that attempt would fail you could start hacking.

[adrian]

22 minutes ago, Mike Rockett said:

I saw in a pull request that you mentioned making changes to the source (and that you didn't want to do it, but let's skip that part for a second).

Are you referring to this PR: https://github.com/nette/tracy/pull/241 ? If that approach ends up being part of the core, I think it will make things a lot harder for me to override and also to add in styles for things like the Console Panel which uses styles from ACEeditor. As it is, I already tweak one line in the Tracy core which I mention in that PR thread. What didn't I want to do?

 

17 minutes ago, Mike Rockett said:

In that thread, it is said that "Tracy has quite polished appearance"

Yeah, but the lead dev David also says "To allow to create skins for Tracy is not a bad idea.": https://github.com/nette/tracy/issues/27#issuecomment-39398635

 

17 minutes ago, Mike Rockett said:

Wish they'd learn something from the likes of filp/whoops.

I agree that looks much nicer, although I am not as concerned with the look of the bluescreen as I am with the debugbar and panels because I don't need to look at it that often - unless I am having a bad day

21 minutes ago, tpr said:

How about modifying the core bluescreen and make a PR to Tracy core? At first the best would be to make design mockups and ask both parties (PW &Nette) for approval.

I like this idea, although I think we might have better/quicker success with asking for making it skinnable - he has already expressed interest, and it should be hard to provide a way to load an alternate CSS file for the bluescreen. 

[Mike Rockett]

14 minutes ago, adrian said:

Are you referring to this PR:

Actually, the one just before that (240). Was pointing in the direction of you not wanting to make updates to Tracy itself every time you updated. ;-)

14 minutes ago, adrian said:

Yeah, but the lead dev David also says ...

Also true - wasn't aware he was lead on the project. So I think maybe we should approach them then...

[Mike Rockett]

Have been working a new stylesheet, and noticed a small bug. The debug bar renders by default with rounded corners and a drop shadow. When you hover over it, the rounded corners disappear, along with the drop shadow, and the panel titles reduce their size... At first I thought this was my doing, but it seems to happen with the default stylesheet too...

[adrian]

2 minutes ago, Mike Rockett said:

The debug bar renders by default with rounded corners and a drop shadow.

Are you talking about the default styles from the Tracy core, as seen here: https://nette.github.io/tracy/tracy-exception.html or in the PW module? I get rid of those in our version here: https://github.com/adrianbj/TracyDebugger/blob/6f4ffa444e9f464b5b44a3de82ba8cc3a6b51a17/styles.css#L8-L9

[Mike Rockett]

12 minutes ago, adrian said:

Are you talking about the default styles from the Tracy core, as seen here: https://nette.github.io/tracy/tracy-exception.html or in the PW module? I get rid of those in our version here: https://github.com/adrianbj/TracyDebugger/blob/6f4ffa444e9f464b5b44a3de82ba8cc3a6b51a17/styles.css#L8-L9

Your styles override when a panel is loaded. Here's a vid: pw_tracy_style_glitch.mp4

[Mike Rockett]

Anyways, the stylesheet attached below is an improvement over the default. It uses system native fonts, a darker header, and full-width panels:

bluescreen.css

[adrian]

2 minutes ago, Mike Rockett said:

Your styles override when a panel is loaded. Here's a vid: pw_tracy_style_glitch.mp4

Thanks for the vid - that's only an issue when the bluescreen is showing - it looks fine on a normal page load. The issue is that because PW doesn't init(), I can't get my CSS file to load normally. Currently I am checking to see if it's loaded when you hover to open a panel and if not, it loads the CSS dynamically. I'll look for another option if I can find one.

10 minutes ago, Mike Rockett said:

Anyways, the stylesheet attached below is an improvement over the default. It uses system native fonts, a darker header, and full-width panels:

Thanks for the new stylesheet - I'll see what I can do about getting it integrated somehow.

[Mike Rockett]

6 minutes ago, adrian said:

Thanks for the vid - that's only an issue when the bluescreen is showing - it looks fine on a normal page load. The issue is that because PW doesn't init(), I can't get my CSS file to load normally.

I see, makes sense indeed. Pity it's so difficult to style things with Tracy...

6 minutes ago, adrian said:

I'll see what I can do about getting it integrated somehow.

Hoping we can all work on it and maybe submit a PR to Nette. Integrating it will be messy, I'm sure...

bluescreen.css

bluescreen.stylus

Edited October 8, 2017 by Mike Rockett
Added source (Stylus) and unminified CSS

[adrian]

14 hours ago, Robin S said:

I for one would love that, if it's not too much work to add (hopefully much of it could come from what you've already developed for console).

Hi @Robin S - here's a screencap of my first version of SnippetRunner. It looks and works quite similarly to the Console panel, except that it loads snippets from files in a configurable folder and of course the code itself isn't shown. I kept the "Processing" and "Completed!" notifications, as well as the results pane in case the snippet returns any output.

If case it's not obvious, clicking "Run" executes the latest version of the snippet from disk, so no need to reload anything here after saving changes in your code editor. Also, the code in your snippets has access to $page when viewing a page on the frontend, or editing a page on the backend. It also has access to $field, $template, & $module when appropriate: see #2 here: https://processwire.com/talk/topic/12208-tracy-debugger/?do=findComment&comment=152466 

Please let me know if you have any suggestions before I put the final touches on it.

[szabesz]

2 hours ago, adrian said:

Thanks for the new stylesheet - I'll see what I can do about getting it integrated somehow.

Whatever changes you guys make to the styles please do not use big whitespaces or at least let me and others preferring small whitespaces pick it as an option to keep it "crammed". Some whitespace is always a must, however Tracy is not about stylish design but a handy tool which should provide the most information in the smallest screen area possible. I like the current styles a lot, btw.

[Robin S]

3 hours ago, adrian said:

here's a screencap of my first version of SnippetRunner

It looks fantastic, thanks! Could the shortcut keys for Run and Clear work here like they do in Console?

[adrian]

5 hours ago, Robin S said:

It looks fantastic, thanks! Could the shortcut keys for Run and Clear work here like they do in Console?

Good to hear! I hope to have the shortcut keys working - it's a little different because with the Console panel they work when the editor is focused which we don't have in this case. I can probably add the eventListener on "document", but I would like to check that the Snippet Runner panel is open as well - will see what I can do.

A question for you - do you think it's ok to have the path to snippets be relative to /site/templates/ so you would just enter something like "snippets" in the config setting which would scan /site/templates/snippets/ for files? Or maybe it doesn't need to be configurable and it's just in that folder, or do you think it should be configurable by full path, or maybe relative to document root? Any thoughts?

[Robin S]

14 minutes ago, adrian said:

A question for you - do you think it's ok to have the path to snippets be relative to /site/templates/ so you would just enter something like "snippets" in the config setting which would scan /site/templates/snippets/ for files? Or maybe it doesn't need to be configurable and it's just in that folder, or do you think it should be configurable by full path, or maybe relative to document root? Any thoughts?

Any of those options would be fine with me - personally I don't mind if it's not configurable and is just /site/templates/snippets/, but I suppose some might already be using a "snippets" folder for something like partials in which case they might want a configurable option.

[szabesz]

2 hours ago, adrian said:

configurable by full path, or maybe relative to document root?

Both please  Could you make the code recognize which one it is?

[adrian]

8 hours ago, szabesz said:

Both please  Could you make the code recognize which one it is?

I am curious where you are thinking of storing snippet files? I would like to limit storing of snippets to folders that PW's .htaccess file blocks direct access to. /site/templates/ is one of these, but /site/ is not. It could be very dangerous to store snippets directly in /site/

[bernhard]

i prefer to have a dedicated folder for code snippets inside the modules' folder ( /site/modules/mymodule/snippets ). it's simple to implement, it's simple to work with and it's simple to communicate!

think of the difference that ready.php made to hooks. any newbe can easily add hooks to the system by some help in the forum "just put this into the /site/ready.php file..."

a configurable option is nice to have but needs more config for the dev (applying the correct settings to the module compared to just placing a file in the right folder) and also for communication in the forum ( place the file wherever you like, set the correct path in the module, with or without trailing slash, relative to xy... ). but i had this discussion with @kongondo regarding his runtime markup field and "lost" (using my own render method), so maybe i'm alone with that opinion...