adrian

If my memory serves, it was because it ruined the flow of the thread. In a lot of cases we are not looking for a single "best answer", but rather it's a discussion of different approaches. That said, it obviously works pretty well on StackOverflow so I think it's something to consider again, but I don't know which boards should use it and which shouldn't and I think that was part of the problem with the attempted implementation at the time.

You might find what you need in this post: https://processwire.com/talk/topic/19024-selector-arrays-with-page-reference-fields-with-and-not-or/

Thanks for doing that test. Now the problem is that I am not really sure what to do. You do have the option to change what tabs are output: so I guess if you're coming across this a lot and don't want to (or can't increase) the PHP memory limit, then perhaps the best option is to drop back to one tab. Would you mind confirming that works for me?

Would you mind checking what is the last old version of Tracy that doesn't have an issue with that hook in your setup? If there has been some change, I'd love to help sort it out. Perhaps it's when I introduced the debugInfo / Iterator / Full Object tabs in the dumped results? This is the commit where this was first introduced: https://github.com/adrianbj/TracyDebugger/commit/104a9457ec1eae78b46d139a631f798b2a042bf0

Hi @Zeka - I think is probably just a result of trying to bd() lots of complex PW objects. Try replacing the bd call with bd($e->object->title) and see if that helps. Or maybe you could use bd($e, [1]) as a shortcut to reduce the maxDepth of the dump. The main thing is I don't think it's a problem with Tracy but rather just how much content is being dumped. How many bd() calls are being made in this hook in your setup?

Inline with my last comment, I am thinking about adding an alert (with orange icon) when there are new properties/methods available after you upgrade to a new version of PW. Haven't decided on the exact interface yet, but if you like the idea and have any thoughts, feel free to suggest, but probably a simple note at the top of the panel detailing those new options and also highlighting in the tables. Probably with an option to "acknowledge" that you've seen the options to remove the notice. Something like that anyways.

Me too!

Thanks @ryan - excited to see it. Regarding the new "numParents" method/property, you are missing the @property in the Page.php doc comment.

I can confirm that today's updates have fixed the Profields Table field error I was getting. Not sure about the PHP <7 errors though as I am on 7.

Brand new numParents() method from the latest PW dev showing up in the API Explorer ?

Tracy's settings contain an InputfieldEmail field so I expect that is where the conflict is. You need to add a condition to your hook to make sure it's only affecting ProcessPageEdit rather than ProcessModule and others. Sorry, gotta run so now time for an example, but hopefully that will get you going.

Lots of improvements to the API Explorer have been committed and as far as I can tell it should now include all methods and properties for all PW objects and classes. It's now definitely ready for primetime although I am sure I'll think of other improvements to add ? Honestly I am learning about lots of methods/properties I didn't know about! Hopefully you guys will find it the best first stop for api docs.

And everything works as expected when Tracy is uninstalled? Can you save config settings for other modules? Any chance you could try an older version of Tracy - I wonder if I recently did something that makes it require a new version of PW?

Agreed - I honestly didn't pay much attention because it said "coming soon" and I was happy to see PW included along with Wordpress and Joomla.

Sorry for the trouble - what version of Tracy, PHP, and PW are you running?

Themes for PW: https://prothemes.studio/

Do you have PW's debug mode on? If not it suppresses PHP errors. Alternatively, TracyDebugger will in most cases display these errors even with debug mode off.

Another question for you all - in addition to the core objects and classes, would you find it useful to also see these for core and site module classes as well? Maybe optional?

New version of the API Explorer. 1) It now shows all core classes (rather than the previous select list), but it excludes those classes with matching API variables avoid duplicate content. 2) By default, methods inherited from Wire, WireArray, or WireData are no longer shown which dramatically decreases the size of the panel and makes it much easier to find what you are looking for. However if you want to see all methods, then you can check the new "Include inherited methods" config setting. I would really appreciate some feedback on this new version. I am thinking about maybe showing inherited methods for the core classes, but not for the API variables (objects), but I'd really like to get thoughts from you guys on what you think will be most useful - I think it's a challenge to balance usefulness and clarity. Thanks!

Recently introduced, unintentional bug ? I have just committed a fix, although no version number bump just yet because I am working on other changes.

I think this is something that @tpr needs to take care of in AOS, but if someone know better, please correct me. I actually think I am OK with the horizontal scroll in this case. I'd rather be able to read it all and I don't want to go with line break either. If others think this is annoying, please let me know and I'll reconsider. Over the last few years I have come to really dislike forced new window/tab links unless there is a chance of data loss which I guess in this situation is possible if you're editing a page at the time, so I have introduced a config option under the Misc section to let you guys decide. This is the same as the option for the PW Info panel. I have also added it to the Captain Hook panel as well. So guys can choose what you prefer. I have added this to the latest version - also added to the Captain Hook panel as well. Sorry, I don't get what you are talking about It's a link to automatically insert that code into the Console panel so you can easily dump it to get the value. Maybe it will make more sense when it's done ?

New version just committed which revises the output for object properties - now runtime properties are more accurately collected and the description is displayed (rather than the value). I think this is more inline with what this panel is about. I think if you want values you can get them easily via the Console panel - I am actually thinking about a link from the property to open the Console panel with the $object->property wrapped in a d() call, eg: d($page->createdUser); to make it even quicker/easier. Any thoughts on whether you'd use this? Please keep the feedback coming.

That is currently expected - same as with the Captain Hook panel. It's because of the way I am showing all because actually triggering the toggle on each element is too slow. I'll keep it in mind to improve if I can though. Not sure about the paths/urls stuff - do you think those are things that need Ryan's attention?

I agree that would be nice - perhaps in a future version and maybe using @tpr's FilterBox Utility - for now, the best option is browsing and Toggle All and then CTRL+F to use your browser find in page functionality. The first version of the API Explorer is now available and includes some config settings for determining what is shown in the tables for each object/class's method. The default is to show the "description" column and not to have the full doc comment block toggleable. This results in much smaller sizes for these panels and of course if you have your code editor links configured properly you can always click the line number to go to the method and read the doc comment that way. Also, since the previews posted yesterday, the API Explorer now also includes Core Classes (as well as API variables) so you have access to things like wireArray and Pageimage methods. It also now displays all properties for each object/class which is especially useful for $page Please take this for a spin and give me your feedback. I will most certainly be tweaking it myself lots over the next few days, but I'd still love your inout to guide my decisions.

@jmartsch - what about this module from @netcarver - http://modules.processwire.com/modules/admin-restrict-page-tree/