adrian

I've had no issues with the PW core and PHP 7.1. It should be noted that 7.2 does result in this warning though: https://github.com/processwire/processwire-issues/issues/408 - it's only a warning though, so not a deal breaker. There will be many modules that also fall victim to this, so I would recommend that module authors upgrade to 7.2 as soon as possible to get these dealt with.

The other option is: http://modules.processwire.com/modules/dynamic-description-notes/

@rafaoski - that second load looks good, although of course the Captain Hook results are now cached, but the others have sped up also. I won't worry about anything for now.

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 - I have committed a new version with these changes - let me know if you see anything amiss. Cheers!

@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.

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.

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?

Hey @bernhard - when using Laragon do you see the slow panel load times that are shown in the screenshots above? In particular 9 secs for an uncached Captain Hook seems crazy slow. For me it's about 1 to 1.5 seconds. And then once cached, it's 15ms.

Thanks for checking into that so thoroughly. I don't remember why I had "nowrap" in there, but it certainly doesn't seem to be needed. Maybe it was needed in one of the older layouts I had. Anyway, I have removed it and it will appear in the next version. Thanks again! PS - there are some very long times for some of those panels - is that your local dev setup, or a shared server? Sorry, we are getting so OT here.

Thanks for the follow up and explanation about Easy Screenshot messing with the debug bar layout. One final question for you - it looks like there is a layout issue on the panel selector - the time for the Captain hook panel has moved down one row and all the others have followed. Does this always happen? I have never seen that before - it would be good to fix if I could figure out why it's happening for you.

Glad you got this sorted @Juergen - just wanted to note for everyone else (which you obviously also found) that you were looking for the Inputfield, rather than Fieldtype hooks:

Hi @rafaoski - I think maybe I didn't explain myself properly. I was wondering why it looks like: and not: Sorry, what privacy policy and what error are you referring to? If you are having z-index issues, please take a look at the "Staring Z-Index for Panels" setting in the Tracy config settings. That is the best way of taking care of those issues if you are having any. By default the Tracy core sets panels to 20000, but I found this put panels over the top of PW submenus in the admin which was annoying, so I changed the default setting to 100 but made it configurable if you are having issues on the frontend of your site.

HI @rafaoski - nice looking site profile - thanks for sharing and for including Tracy! I am curious about the layout of Tracy's debug bar though - is that an intentional change you have made, or is it a side-effect of some site CSS? If the latter, I'd love to know what it causing it so I can properly override it so others don't also experience it.

It's mostly a legacy thing, but also functions as a fallback if the other themes aren't loaded for some reason. That said, I am not sure if the css file from that directory is needed if another theme is working as expected.

In a rush, but take a look at this post: https://processwire.com/talk/topic/6435-cant-figure-out-how-to-create-a-repeater-through-the-api/?do=findComment&comment=62987 Can't remember why I say that the docs are wrong, but for some reason I save the new item before adding any subfields - maybe something to that for some reason?

Seems to me that you should take over this project and the modules directory should point to your fork. Is it time to PM @David Karich and get the ball rolling

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?

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.

Hey @szabesz - I really need to start the docs again from scratch. I have butchered that blog post so badly with new additions and most of the screenshots are really old. I'd really like to start a Github wiki for docs - @tpr has inspired me with the amazing job he has done on the docs for his modules using the wiki. The problem of course is time. I am already spending way too much time on module development and support and not enough time on paid client work - not meant to be an excuse, just a reality. And there are lots of others here putting in just as much time! I'd love to dedicate more time to PW module development, but of course that would mean paid modules - what to do ? Maybe the Tracy docs could be a team effort - anyone interested? The problem is that there is no easy way to enable PRs on Gitbub wikis, although this might work: http://www.growingwiththeweb.com/2016/07/enabling-pull-requests-on-github-wikis.html Any thoughts?

Sometimes the best approach to debugging when you're not getting anywhere is to just exclude large chunks of code to narrow things down. It's process of elimination which may not seem elegant, but sometimes it's actually pretty quick. Actually, leaving off the closing ?> is recommended, unless of course you have HTML after the php.

Just a quick update - I went to use the Email Batcher for the first time with a complex HTML template and realized that ACF and Purifier were getting in the way, so these are now disabled so now you can build complex email templates and preview them right in the CKEditor body field.

It works both ways. Is it the missing closing " after username in your example, or is that just a typo here in the forum?

I am running out of ideas without testing on your server. I would still recommend installing Tracy first though - I am getting 130+ PHP notices and warnings from your code. Admittedly some are likely because my user template doesn't have all the fields yours does, but I am sure you will find you're still getting lots. Once those are fixed, it will be easier for someone to help debug the real problem.

Well I would seriously suggest turning on debug mode at a minimum - there are probably errors not being reported that are causing the problem.