adrian

Ok, some more updates. @tpr and @bernhard - hopefully I have taken care of your suggestions with this latest version. Now if the Dumps Recorder panel is enabled, the built-in dumps panel is not triggered which should make things simpler. Once you disable the Dumps Recorder, it automatically clears recorded dumps. They are also cleared when you logout. This behavior has also been added to the Mail and Event Interceptor panels. Other updates improve detection of template constants and functions in the Template Resources panel and adding editor links to the included files section. Any thoughts on these improvements? Do they come close to what you were looking for regarding keeping the Dumps Recorder manageable?

Two major changes this morning! 1. The "Variables" panel is now called "Template Resources" and contains: variables, constants, user defined functions, and included files. 2. The Console panel now also has access to any functions defined in any included files. In this example I am calling the renderNav() function from the _funct.php file.

Hi @bernhard, @tpr and @szabesz - thanks for the feedback. I am not sure I understand the point to auto-clear. Surely if you activate the Dumps Recorder panel then that means you want to keep them. Otherwise disable it and rely on the built-in dumps panel that comes from the Tracy core. You could even enabled the Dumps Recorder panel using the Once option. As I think about this, maybe what should happen is if the panel is not enabled, then it should clear its results then? Would that make sense so you don't need to clear before disabling? Maybe that's what you meant in the first place? Yeah, there are potentially a lot of DOM elements in a dump of a PW object - add several of those together and it can get very large. I guess I didn't want to assume when it was time to remove old items, hence the manual clear button. But if you guys feel strongly about a max number of items, or a max size in bytes for the output before older items get truncated, I can add that. Sure - done locally - will commit later. This would be easier if this request (https://forum.nette.org/en/26456-ability-to-disable-panels-in-debug-bar-and-the-bluescreen) had been considered. I could have disabled the core dumps panel if the Recorder version was enabled. Maybe I can still unregister the panel somehow - I'll take a look. The other possibility of course is to not send bd() calls to the Dumps Recorder, but instead have a separate recordedDump() / rd() method and we use that instead - maybe that is easier, or maybe it is more confusing? Any thoughts?

The Console Panel now also has access to any template variables that you might have defined yourself. The screenshot shows dumping of two custom defined variables via the console (I have included the content of the variables panel so you can see where they are coming from). This should make testing code snippets in the context of the template of a specific page much easier. The one caveat is that currently (hopefully I'll find a way around this) to access to these variables requires including the template file a second time. In most situations this probably won't be a problem, but if the page using the PW API to add/modify/delete any content or similar, then it will be processed twice. So, for the moment, this functionality requires checking the "Allow access to template variables" checkbox - otherwise you'll get an "Undefined variable" error. Hope you all find this useful!

Good news - the Variables panel now works without the file compiler - which also means you can use it with PW 2.x as well!

On another note - I am seeing more issues with PW's SessionHandlerDB module - it seems to affect the loading of the AJAX bar when using vanilla JS. Without it everything works great. I'll be putting together a troubleshooting section on the support blog post sometime soon will all the issues like this.

I think the problem is that you need to foreach all the instruments, not just the ones in the user's instrument field. Probably something like this: foreach ($pages->get("/instruments/")->children() as $instr){ $person = $users->find('instrument='.$instr);

Ok, the new Dumps Recorder Panel is now available. If you have this panel enabled, all dumps sent via bd() calls will automatically be stored and displayed in this panel until you click the "Clear Dumps" button. Keep in mind that dumps of PW objects can be very large, so it pays to keep this cleaned up very regularly. In case you didn't follow the discussion above, this panel is great for when there are more than one AJAX call which would replace the core dumps panel content with the last call meaning you may completely miss the dump you are interested in. It will also be handy if there are multiple redirects going one. It may also be useful when you want to compare the values of dumping the same variable/object from different pages. I am sure there are use use cases as well. I hope you'll find it a useful addition. @tpr - I tested the situation you described with a repeater and the bd() from your AOS module and this new panel works great for recording these calls. I updated your test install so you can see it in action there. Let me know if anyone has any problems/suggestions for this.

$person = $users->find("instrument=$instr"); or: $person = $users->find('instrument='.$instr); Variables won't be parsed inside single quotes!

Try the develop branch of this module - it looks like it has been fixed there: https://github.com/justonestep/processwire-imageextra/blob/develop/ImageExtra.module#L108

Thanks for the test example - I added an "exit" after your bd() call and that keeps the dumps panel active, so without investigating too much, I am guessing that there is a second ajax action that is clearing the dumps panel. So I think this is related to this: https://github.com/nette/tracy/issues/199 The Tracy guys might come up with a rework to make this possible, but in the meantime, I think I'll proceed with the idea of a "Persistent Dumps" panel as it has other/different benefits as well.

Any chance you could set this up on that test site you gave me access to? I think there might be some redirect going on in the repeater somewhere. The barDump content in the Tracy core only exists until the page is reloaded. If I can test your setup and confirm that would be helpful. I am also wondering if it might be useful for me to create a new panel that is a combination of expandable/collapsible nature of content that is sent via bd() and the persistence of content sent to the Tracy log files via l() - I think this "Persistent Dumps" panel could be very useful as I have come across similar situations myself where the data sent to bd() is lost due to a page reload, so I end up using l(), but this doesn't allow nice dumping of objects/arrays. This panel would have a "Clear Items" button so it's easy to reset when you have reviewed everything you've sent. Any thoughts on this idea? Or maybe this Tracy Issue would also deal with the problem: https://github.com/nette/tracy/issues/199 - it's not quite the same problem though, or maybe in your repeater case, it actually is the problem - more than one ajax call, rather than a redirect?

Something like this was fixed some time ago: https://github.com/ryancramerdesign/ProcessWire/issues/1416 Does the field actually exist in the db? If not, does creating it manually fix things?

Ok, I think these should be fixed - the problem was not just limited to the Mail panel. I have made a significant change to handle ajax requests in the backend - before they weren't detected as coming from the backend - I am relying on $_SERVER['HTTP_REFERER'] which isn't awesome, so please let me know if anyone notices any problems. The fix for the incorrect URL when clearing emails (and other things) now also uses $_SERVER['HTTP_REFERER']. Thanks @tpr for the server access - very helpful!

In this what you mean?

Done! Access to that PW install would be helpful - thanks!

Thanks @gingebaker - I have applied your curly brace fixes. Please let me know if you have any further troubles.

Hi @Barido - thanks for reporting. Sorry for the delay - I was on vacation. Can you please test the latest version and let me know if that fixes things for you?

Just for reference, here is the origins of that module:

Yeah, sorry about the frequency of updates But in all seriousness you might want to take a look at: https://github.com/adrianbj/ProcessModuleToolkit It's not officially released because there are some outstanding issues I haven't managed to get back to, but one thing it does (it has lots of features), is that it adds a "Batch Upgrade Modules" button to Ryan's Upgrades module. This makes upgrading multiple modules super quick with one click. It also makes installing modules with your preferred config settings really easy. Lots of great options. I guess I really need some more interest from you guys to get the motivation to finish it off.

Have you tried fixing the cause of that warning: https://github.com/USSliberty/Processwire-site-indexer/blob/master/Indexer.module#L186 It would be good to know if that warning is gone whether everything works as expected without debug mode on.

Try this: $publi = $pages->find("template=publication, author.name=".$page->name);

I just added a new Metadata section to the Mail panel, as well as linking the attachments so you can easily check them. Note that the Metadata section has currently only been tested with @horst's WireMailSmtp module. Please let me know if you have any problems/requests for use with wireMail's default use of PHP's mail() function, or @teppo's SwiftMailer module.

@fuzendesign - looks like your issue has already been reported: https://github.com/ryancramerdesign/ProcessWire/issues/1965

You can do a $modules->isInstalled("ModuleClassName") check in the template file and do your own error / notification handling.