adrian

Ok, here is a really quick and dirty demo. Obviously the links need to look nicer and the selected one needs to be highlighted, but hopefully you get the idea. Any thoughts before I clean it up?

Morning ? Thanks for the thoughtful discussion @szabesz and @bernhard - I think I like Bernhard's idea of a toggle, although I think it belongs below the title, just before the dumped objects. I think I'll go with debugInfo and Full Object as the labels for the toggle though - I'd rather this was more explicit and helps to educate new developers about what they are actually seeing. I tried blending the debugInfo version into the main object and it works but it gets added to the data property, so you have to dig down to find it and it gives an incorrect impression of how the object is actually constructed. This would certainly be the simplest approach, but I'll take a look at implementing the toggle idea - I think if that works it will be the cleanest and most useful.

If you go with the dynamic roles module, please read this critical issue: https://github.com/ryancramerdesign/DynamicRoles/issues/14 You can apply the fix I have there, or perhaps use @matjazp's fork.

What do you guys think about this approach. As you can see I have automatically combined the debugInfo and the full object versions into an array. I have also added an automatic title if one isn't specified. I was thinking about making this all work for PW's $page, $template, $field, etc objects. The one concern I have is that at first glance this looks like $page returns an array, so I wonder if it might be better simple, like this where the first dump is debugInfo, and the second one is the full page object, but they both are obviously a PW $page object. Not sure - what do you guys think? I am pretty keen to have both version output automatically, but I want it to be obvious what's what.

Busy morning ? Firstly, a huge thank you to Steve (@netcarver) for his epic rework of the Diagnostics panel - take a look at the diff https://github.com/adrianbj/TracyDebugger/pull/24/commits/8604a683ef408b4106f7b7237b3eae6c24de315a - he's put in a huge amount of time on this. I have merged his changes and bumped up Tracy's version to 4.11.0 - it deserves a major point bump for this ? If you haven't used this panel much in the past, you really should take another look and give it a thorough go - it's really useful for new and experienced devs alike! I also also added @tpr's blue for the icon color. Not sure about the inverted scheme just yet - any strong thoughts on it? I do think that the background color of the bar (the light version) could be made to look a little less dirty though. BTW, as a reference, take a look at the default Tracy bar: https://nette.github.io/tracy/tracy-debug-bar.html - be sure to check out the panels as well - we have @tpr to thank for our version looking considerably better than that ? Regarding the automatic dumping of both full object and debugInfo versions, it could be as simple as this - just one version, and then the other. Perhaps some visual indicator so you know it's from one call or something. Any ideas/thoughts? @szabesz - you mentioned wanting the page ID shown without having to open the object - I don't think is any simple approach to do that, especially given that not all dumped objects are pages. Of course you can do: d($page, $page->id) but that's only useful if you are dumping multiple pages at once so you know which one is which. If you have any more specific thoughts on how to implement what you are looking, let me know. Regarding the memory limit error - not sure what can be can about that - I guess Tracy can't handle that error because the error broke Tracy ? Seriously though there is just so much output when you have all panels toggled on that it's not surprising that these come up occasionally - I haven't seen one, but I up the PHP memory limit on my dev machine to 128M. Hopefully I answered everyone's questions, and please don't forget to test the new Diagnostics panel and give @netcarver your feedback.

I like both actually - the first option really does look a lot nicer than the grey which is pretty awful now that I see the difference ? The second one is nice but you're right, it will be problematic for the orange and red icons. Anyone have any thoughts? Not sure yet - I don't think I can hook into debugInfo though - I'll see what I can do about this sometime soon.

I am getting a little annoyed with the debugInfo output myself actually - there are lots of holes in it's output - there is a bit of a discussion about it here: https://github.com/processwire/processwire-issues/issues/575 but it would be a lot of work for Ryan to go through all of PW and set this up properly. Of course there is a config setting to make the default behavior show the full PW object, but there are times when the debugInfo output is better/easier. I mentioned above somewhere that I was thinking about having an option to dump both versions automatically with any dump/bardump call - best of both worlds. What do you think about this as an alternative? Not saying I don't like the verbose idea - I just want to make sure we don't end up with more options than we need. It might also be confusing if you already have debugInfo off by default in the config settings. I don't know - anyone else have any thoughts?

Thanks! Also, just an FYI that your bdb and db 999 has been changed to 9999 in that version.

New version just committed contains all the icon color changes. Mostly it's just consolidating the default color to grey and changing a few instances of when orange (WARN) vs red (ALERT) is used. Let me know if you find anything I have missed or any inconsistencies.

@Guy Verville - I just updated the module with a more reliable fix - the other one would probably have worked on almost all sites, but there was a possibility for an issue. Please let me know if you have any problems with the new version.

Works great now - thanks!

Ok, I have been looking at the admin live search results and it seems that if the user doesn't have edit rights (either in general, or because of ARB), then the result link goes to view the page on the frontend, rather than edit in the backend. I think I find it a bit strange that the results don't have links to both when appropriate. But anyway, I don't think there are actually any issues with ARB and the new PW admin search, but I wouldn't mind a few others to investigate to make sure I haven't missed anything.

Hey @Robin S - could you please take a look at this? I am seeing it if I try to edit a page that I don't have permission to edit. I am using AdminRestrictBranch, but I expect it might happen regardless of this. Let me know if you need any help reproducing. Thanks!

I have pushed a fix for this, but I have discovered that Ryan's recent changes to the admin live search functionality has broken restricting of search results. I am working on this now, but could be a bit painful.

Thanks - I see the problem - it's to do with the way ARB blocks pages when viewed in Lister and because the Users page in PW uses Lister, it is causing the problem. I should have a fix shortly.

Glad I stumbled across this post - ARB should not get involved with displaying users - is there anything special I need to do to reproduce?

Just the default icons to give you guys an idea, but how's this looking? Still not sure if Debug Mode icon on should be orange or red? Perhaps I should check if on local dev or live server and go with grey for the former and red for the latter where it really is important!

Honestly I am starting to feel like this is something that should be solved by the PW core - I don't really feel like messing around with hacky solutions for this. @iank - would you be willing to submit an issue to the PW github account? I am honestly not sure if this should be an issue or a request, but I feel like it's strange that normal fields allow for an easy fallback, but module settings don't, so maybe it's an issue?

Sounds good - I don't think you need to go creating them - probably just need to spend some time looking around for better free ones, but whatever you think would be great. I think regardless of how you go about creating or finding them we should wait till you have them all ready before committing any changes.

Also, if there are any icon geeks out there, I'd love some help to revamp the icons on the debug bar - many of them are very ugly ? Any takers?

I just wanted to clarify that the grey/green/orange/red color scheme is already in place and has been since the beginning of the module. As per my mockup above I am more than happy to make all the icons that don't need this scheme grey instead of PW pink or PHP purple, or blue (the System Info icon). Hopefully we're all good with that change. I think this approach of grey instead of green to indicate no attention needed will be fine - I can't currently see any reason not to make this change. I think there will always be some difficulties in determining what should be orange and what should be red, although I do think that if we get rid of green altogether it will actually be simpler, for example I always felt a bit weird about debug mode set to on resulting in red. I think a new grey / orange only combo is probably much nicer. Orange being a warning that you need to be aware of the fact that it's on and this is a security concern on a live site. No problem at all - as with most things, Tracy has evolved and wasn't really planned from the beginning, so more than happy to revisit this stuff now and I really appreciate everyone's input.

Hi @iank - sorry, I have no idea how ProCache will handle this - I have never used it. Regarding dealing with fallback if empty - I think the only way to logically do this and also consider @tpr's point about allowing for an intentional blank value is maybe to only fallback when a field is required. I think that will work fine for this module. What do you both think?

Doesn't say much, but #3 on a list of the 6 best alternatives to Drumlapress: https://www.geckoandfly.com/27533/wordpress-drupal-joomla-alternatives/

Hi everyone - @netcarver has mentioned to me that he's not a fan of some of the ambiguity of the icon colors in the debug bar - mostly the blue for the System Info icon and the PW pink color used by the PW Info and Captain Hook panels, and the purple used by the PHP Info panel. I have quickly mocked up a version where these are all grey: He wanted me to poll you guys to get some input on this change and also any other changes you might like to see. In general the idea with icon colors is: grey - no significance green - everything ok - no attention needed orange - warning or attention to a new entry/item of interest red - warning, fail, or something else that you should be aware of So please post your thoughts - what do you think can be done to make it look cleaner and also more meaningful/useful? Thanks!

Typically the simple solution for this would be to drag the Tracy debug bar out of the way - this will work so long as you don't have the "Fixed Position" option checked in the config settings.