adrian

Not exactly a changelog, but I have been thinking about adding a "What's New" section at the top of the API Explorer panel in Tracy. It would simply list any new methods or properties in the current version compared to the old version. Firstly, would you guys find this useful? Secondly, the catch with implementation is that Ryan doesn't seem to be using @since tags anymore - not sure if this is a recent oversight, or an intentional omission (https://github.com/processwire/processwire-issues/issues/759). If he gets back to me and starts implementing them again, I think that would be the simplest approach. Otherwise I'll need to cache the API explorer results and compare the current to the cached version (on PW upgrades). This isn't a big deal and I guess has the added advantage of showing all changes since your last upgrade (not the last actual version) so if you skip over a few versions, this will be more complete. So what do you think - would you guys make use of this? Can you see viewing the API Explorer panel after each upgrade to see what's new?

@celfred - sorry, looks like I forgot to commit that new 4.15.5 version - please try updating now - this new version should prevent the error.

@celfred - I just committed a new version that won't error even if there are old settings with panels that no longer exist, so please try updating and let me know how you go.

Oh now I see what's going on - the Template Editor panel hasn't existed in forever ? Your module settings must be configured to try to load it still. An uninstall/reinstall should remove those settings though. Maybe you had used the Panel Selector and "Sticky" selected the template editor? Could you please delete the "tracyPanelsSticky" cookie from your browser and let me know if that works.

@celfred - does that file actually exist? How are you upgrading / installing Tracy ? It's always safest through Setup > Modules > New or the PW Upgrades module. Also, if it's uninstalled and you're getting that error, then you probably need to do a Modules > Refresh

Thanks for letting me know about this - I didn't test the PR that went into 1.0.1 - it seemed like such a simple regex change ? Anyway, regex is now fixed and I have also removed the ancient and broken CURL code for grabbing the Youtube video title and replaced it with wireHttp()

Sorry about that - fixed in the latest version.

Great! Thanks, not sure when that happened - probably newly broken in UiKit theme. Should be fixed now.

A couple of updates to the new RequestLogger panel. You can now define which types of request methods are logged: GET, POST, PUT, DELETE, PATCH. By default, all are checked, but I think in most cases unchecking GET is probably helpful as it will prevent page views from being logged. You can now use this panel on non-ProcessWire pages, so if you use a php script like payment_confirmation.php in the root of your site, so long as it bootstraps PW (include ./index.php), it will let you log and retrieve request data. The only catch is that you need to trigger the logging manually by adding: $page->logRequests(); to the script file. Visit the page and enable logging (as with any normal PW page) and you're good to go. The only weird thing at the moment with this is that the logged url will be /http404/ but otherwise it works as expected. Let me know if you make use of this approach and if you find any issues. BTW, I still need to add docs for the Request Logger, API Explorer, and Adminer panels to https://adrianbj.github.io/TracyDebugger/ - I've been slack on this. Anyone out there like doing documentation and would like to help ?

Actually, an even better option is probably to use $filePage as this will automatically choose the field from the repeater if the image is uploaded to a repeater image field or the main $page if the image is uploaded to an image field on the main page. Does that make sense?

Turns out it already works ? Just use $repeaterPage instead of $page. Let me know if it works ok for you.

Does this help? https://stackoverflow.com/questions/33758126/how-to-store-xml-obj-in-php-session-variable It might be related to the need to serialize the xml before storing. Is $xml->customer_id definitely a string?

In fact I misspoke in my previous post. I've been using the new version but on a different local site Does this mean you are seeing the "open in window" icon on the new version? It should look like this: Just the Maximize/Restore icon and the close icon. The open in window icon should be hid by this rule: https://github.com/adrianbj/TracyDebugger/blob/077b5c26aea42de451dcd94d97ae186d3bbf8529/styles.css#L830-L833

New version of Tracy includes 4.7.0

That's ancient (10 months old) - you are missing out on so much ? but that explains why the icon is not hidden. There are lots of new options for making the Console panel larger - you can maximize the panel, but you can also fullscreen mode the editor/results panes. You can also "rollup" any Tracy panels by double-clicking on their title bar - nice to get it out of the way quickly. I'll see about restoring the "window" option, but no promises - it's been painful!

Interesting because I actually purposely made this not obvious by hiding the icon that triggers the new window mode. Are you using SHIFT+Click to trigger this or is the icon not hidden for you? The reason I "disabled" this functionality is that it was a bit painful to get layout to work properly in this mode. And actually, the Console panel is completely broken for me at the moment in this mode at the moment. Are you running a much older version?

Weird - I just tested upgrading Tracy with the PW Upgrades module and it deleted the old .module versions automatically. I have no idea why it wouldn't have worked the same for you. Thanks for the Adminer update note.

I was worried that might happen. @bernhard added .php to the TracyDebugger.module file so that intellisense in vscode could work its magic. I thought I might starting adding the php extension to all my modules files because .module really is a silly extension in my mind. You'll be able to solve the issue my deleting the .module version. Same goes for ProcessTracyAdminer.module. I am curious what method you used to upgrade. I would have thought that the PW Upgrades module would handle this and a git update approach should also work. Updating via modules > add new should also work. Did you just unzip and copy?

Hey @Tom. - I am not sure your exact goal here - not sure if the session storage is for production use, or just while developing/testing, but @bernhard and I just put this together: https://processwire.com/talk/topic/12208-tracy-debugger/?do=findComment&comment=176842 - which came about while he was working with foxycart and since you are as well, I just thought it might be worth mentioning ?

Well it took several hours of discussions with @bernhard and lots of back and forwards on the best way to do things, but we've finally committed the "WebHooks" panel he posted about above. It's now called the Request Logger panel because in reality it is logging requests to a page on your site - who knows whether it's really a "webhook" request or something else. Instructions 1) In the PW admin, edit the page you want to log incoming requests for. 2) Open the Request Logger panel. 3) Click the "Enable logging on this page" button. 4) Send a request to that page. This may be something like a confirmation of payment webhook call from Paypal etc. 5) Reload the edit page in the PW admin to see the logged request. The reason we say to edit the page, rather than visit it on the frontend is because visiting the page would result in a logged request. Note that you can easily test incoming requests using the Postman app (https://www.getpostman.com/). You can choose POST or GET and under "Body" you'll want to specify Raw / JSON You'll notice the json supplied in the Postman Body is what shows up in the Request Logger panel under "input" and "inputParsed". This is all well and good, but here's where the magic really comes in ? There is a new getRequestData() method added to $page so you can get the logged data in your code. You can get logged requests by: ID (shown in the title of the logged entry in the Request Logger panel) ALL requests (an array of all logged requests for the page) The last logged request by passing "true" The current live request This allows you to have access to the data sent by the webhook without constantly having to trigger it each time - ie no need to continually make test payments over and over as you refine and debug the your scripts that consume/parse this data! You can even make use of $page->getRequestData() in your final live code if you want - this does not rely on Tracy being enabled - it just has to be installed. So you could potentially execute one request and then use the "true" option while testing, and then when you're ready to go live, you can remove the "true" so it returns the live request. There is a config setting to determine whether this method returns an array or an object. Please take it for a test drive and let us know what you think! @bernhard - did I miss anything worth mentioning?

I am sure support could be added for this. Any chance you feel like having a go at implementing it? Sorry I am juggling lots of different commitments right now, but I'll take a look when I can if you don't get to it first ?

I use curly braces, like this: {$page->title}-[Y_m_d_H_i_s]

You should be able to specify any PHP date() format you want - if you want to replace those dashes with underscores you can. I think that should take care of the conflict with the "-n" suffix check.

Does this help: https://processwire.com/blog/posts/processwire-3.0.107-core-updates/#page-gt-references

Sorry about the issue with the unknown module error. I'll fix that in the next commit. Keep in mind that if you don't want it to appear under the Setup menu, you just need to make Admin > Setup > Adminer hidden. That way you could still use the Adminer panel from the Tracy debug bar. Does that help? Also, I know it's obvious, but only superusers will see the Setup > Adminer option.