Module Tracy Debugger

[adrian]

Thanks for the penflip suggestion. I am hesitant to host the docs somewhere else though.

I am actually tempted to just use the README.md file and make use of a Table of Contents to make it easier to navigate. In some ways this is better than the pagination options in the wiki and in some ways worse.

I am also looking at the possibility of using Github pages, but that means a "docs" subfolder (which would be included in module installs), or a separate "pages" repo. Doesn't seem like there is anything really ideal, although maybe having offline docs with a module would be an advantage despite the larger download. Maybe the PW modules interface could actually read and display the contents of the docs folder? That could actually be really cool - offline docs available directly from within PW. Anyone interested in supporting a request for this from Ryan? Or maybe it could be built initially as a module. Of course it would only be useful if module authors were to get on board, so it might take some time before it was actually useful.

 

Thanks @bernhard and @szabesz for the donation button push. There are so many people here who do lots for the PW community, I never wanted to put pressure on anyone for donations. Also not sure how effective it will really be. If the plan is to do less client work and more PW modules, then I think you need a more robust/reliable source of income that might come from a killer paid module, or a module with a free and pro version. Obviously getting way OT here though.

 

[szabesz]

I'm not a fan of docs as part of modules. Maybe its just me but I like to keep the codebase as light as possible. Also, we've been asking for "changelog" support in ProcessWire so it is hard to see why docs support would get priority but one never knows  

11 minutes ago, adrian said:

I am hesitant to host the docs somewhere else though.

I understand this but if that tool can export in a format which makes it possible to migrate the whole stuff – just in case – then why not give it a try? I'm not pushing penflip.com as I have only read its homepage, I just like tools which are designed for a specific need. As long as they work well, of course...

[bernhard]

21 minutes ago, adrian said:

I never wanted to put pressure on anyone for donations

i think most of us can handle this pressure of course it will not pay back the time invested but it's nice to have the possibility to say thank you. but of course if someone wants to invest more time on a module making it commercial is totally fine. i'm also thinking about that topic...

regarding the docs i would love to see some kind of standardisation here. maybe someone knows a good solution already.

[adrian]

30 minutes ago, szabesz said:

I'm not a fan of docs as part of modules. Maybe its just me but I like to keep the codebase as light as possible.

Well if there is no support by PW for reading and displaying the content in the /docs folder, it can easily be excluded from downloads using .gitattributes in the repo:

docs export-ignore

will ensure it is not downloaded when you install the module.

This way I could have a dedicated docs pages for Tracy hosted on Github Pages and you guys could submit PRs to help (which would be hugely appreciated). I'd love to see lots of screenshots and examples - this could work out really nicely I think. To that end, I have set up a new docs page at: https://adrianbj.github.io/TracyDebugger/

I have checked and the docs folder is correctly excluded from the download, so I think we should be good to go to start working on these docs. I have set the theme to the default "Cayman" for now, but may change as I learn more about Github Pages.

I'll set up a basic structure and then hope to see some pull requests from you guys. Does that look / sound ok?

[szabesz]

9 minutes ago, adrian said:

Does that look / sound ok?

Yes it does

[bernhard]

@adrian what about using readthedocs? https://docs.readthedocs.io/en/latest/getting_started.html

[Robin S]

Hi @adrian,

What do you think about adding a way to label dumps in the console, similar to what is possible with barDump?

So you could do:

d($foo, 'Foo');
d($bar, 'Bar');

This would help to identify which dump is which.

[adrian]

Hey @Robin S - how's this?

The only thing I am concerned about is the lack of delineation between "2" and the untitled "3", but the Dumps panel with bd() calls has the same problem which is a Tracy core thing anyway. I think this is probably ok - if you feel the need to title dumps, then you'll probably title them all.

The other frustration (which also affects the Dumps panel), is the need for specifying a title if you need to adjust the maxDepth or maxLength setting because of the order of the function arguments. I have thought about maybe checking if the second argument is an array, then assume it's the maxDepth/maxLength etc options, and not intended to be the title. This approach always feels hacky to me though - any thoughts?

[adrian]

Or maybe this is a little nicer?

This looks more like the output of the Dumps panel - there really is no point to that blue background in the entire results div.

[Robin S]

1 hour ago, adrian said:

Or maybe this is a little nicer?

Maybe remove the space between the label and the dump output?

1 hour ago, adrian said:

I have thought about maybe checking if the second argument is an array, then assume it's the maxDepth/maxLength etc options, and not intended to be the title. This approach always feels hacky to me though - any thoughts?

Ryan does that sort of thing all through the core so I figure it's not too hacky. 

[adrian]

@Robin S - I've been playing a little more with this. I decided to do the check to see if the second parameter is an array or not. It still feels hacky, but I do like not having to add a title when I just want to adjust maxDepth/maxLength, so I think it's worth it.

I also tried removing the space between the label and the dump output (which I just got your reply about right now ) and I think that works nicely.

What do you think - does this look ready to go?

BTW, I have also made both these changes to the Dumps panel.

[adrian]

@Robin S - I have committed a new version with these changes - let me know if you see anything amiss.

Cheers!

[Robin S]

29 minutes ago, adrian said:

It still feels hacky, but I do like not having to add a title when I just want to adjust maxDepth/maxLength, so I think it's worth it.

Could you just pass null as the title argument in that case? Or is that just as much hassle?

38 minutes ago, adrian said:

What do you think - does this look ready to go?

Looks great to me.

[adrian]

28 minutes ago, Robin S said:

Could you just pass null as the title argument in that case? Or is that just as much hassle?

Yeah, you could pass null, but I do think it's just as much hassle, so went with the "hack". I know it's used in the PW core and l've seen it lots of other places and used it myself - it just feels dirty, but in this case, I don't think it will get out of hand and makes it much simpler to use. 

[Robin S]

8 minutes ago, adrian said:

I have committed a new version with these changes

Thanks for the speedy implementation!

[bernhard]

On 10.11.2017 at 2:08 PM, bernhard said:

@adrian what about using readthedocs? https://docs.readthedocs.io/en/latest/getting_started.html

@adrian just wanted to make sure you didn't miss my quick note

[adrian]

On 11/14/2017 at 6:01 AM, bernhard said:

@adrian just wanted to make sure you didn't miss my quick note

Sorry, @bernhard - yes I did see it. I haven't investigated fully yet. I am still not totally convinced of the right way to go - the Github Pages site is ready to go and can accept PRs, but @netcarver also has something cool up his sleeve:

 

Amongst its many features, makes the ReadMe file viewable from the Module settings within PW, so maybe that is actually a good place for docs after all?

So, not forgotten, just percolating. 

Thanks again for the suggestion!

[adrian]

Hi everyone,

Relatively major new version just released:

1) New run on init, ready, finished option in Console panel

I am not sure how popular this will be, but it lets you inject code from the Console panel into the PW process at init, ready, or finished. This lets you test hooks and other code that you would normally add to the init.php, ready.php, or finished.php files without having to edit files, and also without affecting anyone else viewing or working on the site.

This screenshot should give you the idea:

As you can see, I have added a hook to change the page title on saveReady. 

The way it currently works is that you:

• enter your code
• click Run to "register" the code for the next page request
• select "init", "ready", or "finished" as the place to have it injected
• In this example, you would then save the current page and the hook would be injected into init() and the page title will change

If you don't switch back to "off" when you are done testing, it will expire in 5 minutes.

The Console panel icon will also change to a red color to provide a visual indicator that you have an injection running on each page request.

Please give me feedback on this feature - if you guys are annoyed by having those options visible and you never plan on using this, I'll make it an option that can be turned off completely.

 

2) Make User Switcher available without setting to "DEVELOPMENT" mode

When I initially built the User Switcher I was a little paranoid about the possible security implications so went a little overboard by making it only available when hardcoded to DEVELOPMENT mode. But in reality this didn't make any difference and just made it more difficult to use, so now you'll find it easier to use - it's such a great feature! If you haven't used it, give it a go!

 

3) Options to hide debug bar from Form Builder iframe

Having the debug bar in a Form Builder iframe can be useful, but also a visual annoyance so now you can disable if you want.

 

4) Hide User Bar from Form Builder iframe

This is automatic as there is no reason for the User Bar to appear in a Form Builder iframe and it is confusing for users and ugly.

 

5) Restricted panels now works with "tracy-restricted-panels" role as well as permission (needed due to recent PW core change)

Due to a recent change in the PW core, it is no longer possible to edit the permissions for the superuser role, so I have now added support for assigning a "tracy-restricted-panels" role to a user. The "Restricted Panels" defined will then be applied to users with this role. The permission option will continue to work for other non-superusers.

 

6) ACE editor update

7) Other bug fixes / tweaks

[Robin S]

2 hours ago, adrian said:

3) Options to hide debug bar from Form Builder iframe

Having the debug bar in a Form Builder iframe can be useful, but also a visual annoyance so now you can disable if you want.

 

4) Hide User Bar from Form Builder iframe

This is automatic as there is no reason for the User Bar to appear in a Form Builder iframe and it is confusing for users and ugly.

Cool to have a dedicated option for these, but 3 and maybe 4 have been possible for a while now via the "No Debug Bar in Selected Templates" feature (the Form Builder iframe was what prompted my request for that feature ). 

[dotnetic]

@adrian These additions are great. I think the new console function is very useful. Thank you for all your efforts.

[adrian]

This is a minor change, but I am actually really excited by it

The Console panel now supports running just the selected code. 

I often find myself using the Console panel to test variations of code to see which is faster / more efficient. The time and memory usage is displayed after each request, but it's often a bit of a pain to keep commenting out some of the code, testing it, and then uncommenting that and commenting out the other, etc.

Now you can have multiple functional bits of code and just run one at a time.

You can see in these examples that I am selecting different chunks of code to be run and I can clearly see which one uses more time and memory.

[bernhard]

this is a fabulous idea!! 

[adrian]

Sorry for the quick follow up.

The latest version now supports non-contiguous and partial line selections, so now you can do this:

Note the partial line selections in this example:

 

[adrian]

Continuing on from yesterday's Console enhancements:

1) History stack now supports the state of text selection and the scroll position, so now much easier to run different versions without reselecting.

2) This selection and scroll position state is also recorded as you edit so it is also available if you reload your browser, etc so everything will be as you left it.

3) The editor window within the console should now always get focused when the panel itself is made visible (by hover or click). Previously this wasn't reliable. This makes running code much easier because the keyboard shortcuts for running will work without needing to click into the editor window to focus it.

Unrelated to the Console panel - I have made the "Show debug bar in backend" checked by default on module install. Of course you can always uncheck this, but I find the debug bar just as useful in the backend, especially the Request Info panel when editing a page, template, field, or module settings. So consider this an attempt to enlighten new users to the benefits of it in the backend because I am sure many never bother to enable it.

Please let me know if you find anything amiss with the new Console functionality.

[Macrura]

sorry for my confusion, but didn't the P icon used to have a link to edit the page being viewed? I used to use this all the time to get from front end to backend edit page - was that link moved somewhere - the appearance of that P panel seems to have changed a lot.