adrian

Thanks @gebeer - I forgot about that. I have pushed a new version that uses wireRenderFile instead. It definitely wasn't available in older versions of PW.

Just in case you don't know, you can do this directly via the API: https://processwire.com/blog/posts/multi-instance-pw3/

@szabesz - this isn't the count of a PageArray that you were looking for, but it does return the ID of each page and is linked to the edit interface for the page. Is this at all useful? I think this is simple and clean enough not to be too messy

Ok @bernhard - here's a try a tabs. I think this works ok and looks ok, although I am sure someone out there will want to tweak the look of it - looking at you @tpr ? - and happy for your thoughts! Is everyone happy enough with this so I can finish it up and commit?

I tend to use wireHttp. Here's a recent example: https://github.com/adrianbj/CookieManagementBanner/blob/a8e66127bdcbd80e10ac797ad5cbb143644c7857/CookieManagementBanner.module#L38-L39 $http = new WireHttp(); $userLocation = $http->getJSON('https://extreme-ip-lookup.com/json/'.$this->get_user_ip_addr());

I don't disagree with you, but I also don't want to pollute the dump output with lots of extra stuff. It could easily look quite messy with several object dumps, all of which have text / button links to the debugInfo and Full Object versions.

It's not really that simple though - a page object doesn't have count. In the case of count(), it is relevant to PageArray, PageFiles, PageImages objects, but also to field types with multiple values. Then there are template, field, module etc objects - what should be displayed for those?

I tried both. Here is left which is fine and does prevent the scrollbar jumping, I didn't like the way it affected left alignment compared to other dumps like the "test" one above, but maybe it's ok? I see where you're headed, and I like the idea but I am a little worried about going down a huge rabbit hole. Maybe if you can put together a list of PW objects and the data you think should be automatically displayed in this way, maybe we can come up with a solution. I am actually thinking that this might need to be another element that sits between the title (if defined) and the object dump. That's the plan - I haven't coded it yet so not sure - there could be some complications, but hopefully solvable.

Here's a screencast of the icon based switching in action. Is everyone happy with this approach? Any ideas for improvements? Back to @szabesz's idea of the page ID being shown - I have removed that from the recent screenshots/casts, but here it is again with the new icon toggles in place. What does everyone think about these automatic titles - useful, or unnecessary - I am not sure.

An interesting read: https://dba.stackexchange.com/questions/75091/why-are-simple-selects-on-innodb-100x-slower-than-on-myisam

I've been using Licecap on MacOS as well - seems to work pretty well, but honestly haven't investigated what else is out there.

Playing with this idea where the toggles are icons floated to the right of dumps that have both debugInfo and regular object versions. Notice that the currently selected version of the dump results in the highlighted icon color. I think I need some help figuring out the most useful / cleanest looking option for this. Any ideas?

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!