adrian

Hey @tpr - just looking at this in more detail now. I hadn't thought of triggering this client-side, but I think it might make sense - is your thought that it's probably the easiest way to prevent a clear from being called during a PHP redirect or AJAX call? This way it has to be due to a page change or reload? I think that makes sense, but a couple of problems I have noticed: It actually only works reliably for me using beforeunload - I think Chrome doesn't accept unload It uses jQuery, but I want to make Tracy vanilla js only because we can't be sure that jQuery is loaded on the frontend Nice work of figuring out the need to init the panel if it wasn't ever opened, but I think I have a much easier solution all around which is as simple as: window.onbeforeunload = function() { document.cookie = "tracyClearDumpItems=true;expires=0;path=/"; }; Setting that cookie is actually the key part of the clearDumps() function - with that set, the dumps are removed from the session variable. There is no need to call the entire clearDumps() function because we don't need to remove the dump content from the DOM of the panel instantly - we can rely on the PHP code to do it on the next page load. Does that make sense to you?

I should have also pointed you to this post which explains more about how to use implode, including using it with <li>

I don't see anything wrong with your videos foreach, but look at the Cast line from your OP, you can't simply output $page->cast assuming "cast" is a page field. There are multiple ways, but perhaps the easiest for the way you have your code structured would be: $page->cast->implode('<br />', 'title');

A multiselect will return an array, so most likely you will want to foreach through it - something like this: foreach($page->pagefieldname as $p) { echo $p->title . '<br />'; } There are lots of other ways to grab the data so tell us more about your needs and we can help further.

Thanks for the report @szabesz - can you please check if the latest version fixes both of those for you?

Interesting idea for sure. The thing is that I am not sure that I would always want it to auto-clear. There are times when I want to compare the results of one dump with another (perhaps after a code change), or even on a different page. It could be a configurable option though - on the module settings page, or maybe a checkbox on the panel so you can easily uncheck when needed. What do you think? I think the idea is great, just not sure how easy the implementation is. I can't find Ryan's notes about the module disable feature he added, but he only made it available when in advanced mode because he mentioned there can be some big side-effects in the case of some modules. I guess I could also limit to advanced mode and add the same caveat. Here is the text from the source code where the disable module checkbox is added (https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/modules/Process/ProcessModule/ProcessModule.module#L1280): "Be careful, checking this box can break the module or your site. Use for temporary testing only."

Thanks for the confirmation @tpr. Minor update just committed adds the filename and line number of defined functions, and links to open to that spot in your code editor. Should be a nice addition when you don't remember where a function is defined.

Not directly answering your questions, but when it comes to getting page creation with complex fields happening on the frontend I actually really like this module: https://github.com/teppokoivula/AdminBar - this is an updated version of the one created by apeisa which works in more recent versions of PW. I like to use this as a starting point and add some custom styling and tweaking to suit the site look and its needs. You can limit it to just the pages you want (in your case the blog). I am honestly not sure why it's not more popular, but maybe it's just me who likes it PS - maybe it is overkill or maybe not appropriate for your project, so as @Robin S says, it's definitely possible to get CKEditor working on the front-end.

Hi @rolisx and welcome to the forums. foreach ($pages->get('/shows/')->children("show_date<=".time().", sort=show_date') as $show) { and then another one where the show_date is greater than the current time()

You might also find this option useful:

Not sure if this really belongs here, but interesting to see that: http://www.burgerking.it/ is running on PW and yet several other of their regional sites, eg: http://burgerking.ca/ are running Drupal. Sites looks very similar visually.

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!