adrian

Just an FYI - in the Console panel you can now do mixed HTML/PHP without needing to add a php closing tag first. <p>Welcome to the <?=$page->name?> page!</p> File-based snippets (Snippet Runner) can be plain html, plain php, or mixed html/php, but they must have an opening php tag as per normal PHP requirements. The Console panel does not require an opening PHP tag (although having one will still work). You can use mixed html/php as per the example above, but for a pure HTML file you will need an initial ?> before the HTML to make it work, eg: ?> <p>Welcome to this page</p> Plain html in the Console seems like a pretty uncommon use case, so hopefully this gives us the most flexibility without too much weirdness.

Sorry about that - I am not seeing that, but I see where it's coming from. Please try 4.6.5 and let me know. PS Don't forget to enable the new Request Info panel which now contains most of the info from the old version of the PW Info panel

I've just made a few more tweaks so that now you can have mixed html and php in your snippet file. For example this: <p>Welcome to the <?=$page->name?> page!</p> will return: This might come in handy for testing snippets of template code if you use a direct output approach, or markup regions, or anything else where you are embedding php into HTML tags. The only downside is that now pure PHP snippet files must start with a php open tag. I think this is a quite acceptable compromise as I couldn't imagine writing code in my editor without it. You can also do this with the Console Panel, but you have to start the snippet with ?> to close the automatically added PHP tag, eg: ?> <p>Welcome to the <?=$page->name?> page!</p> This is because the Console Panel always adds an opening PHP tag if it doesn't find one - I think this is best here because it's nice to not have to manually add when doing a quick code test. Anyone have any thoughts on these new abilities - does anything seem illogical?

@Robin S - please try the latest version which supports declared namespaces in both Snippet Runner and Console panels.

Yeah, it is certainly up there Glad it's working well for you. The focusing of the Run button was initially to help with helping target the eventListener for the keyboard shortcut, but I found what I think it a better way without having conflicts if both the Console and Snippet Runner panels are open at once. Even after figuring this out, I decided to keep the focus of the Run button as a visual reminder that loading != running. Let me look into this - should be a pretty simple fix.

Ok, they are now a list of icons with labels by default with an option to turn off the labels in the module settings. Hope that helps! Of course if you are upgrading you will need to check the option.

Hi @Robin S - I have fixed both those bugs you reported - thanks for that. As far as using a File field - actions can use any PW code, so this is certainly possible. You could make use of a FieldtypeFile field using the same approach that Ryan uses in his ImportPagesCSV module, or you could use a Markup field and add a "manual" <input type="file" /> field - whatever you prefer really. I don't think the main code in AdminActions needs any adjustments to support these, but let me know if there is anything I can do.

Major new version just released. There are quite a lot of changes and it fact it jumped two major point versions because I added two new panels. Here are the highlights! 1) New Snippets Runner panel - as discussed in the last few posts, this is similar to the Console panel, but all snippets are stored in the filesystem. By default they are stored in /site/templates/TracyDebugger/snippets/, but you can change that to /site/asets/TracyDebugger/snippets/ if you prefer. Running a loaded snippet grabs the latest version each time, so simply save in your code editor, switch to your browser and trigger Run. It has access to all PW variables and can reference the currently edited page etc, just like the Console panel. 2) New Request Info panel - this panel contains most of the info from the ProcessWire Info panel, but also adds the following: Server request (this is a dump of all items from $_SERVER Input GET, POST, & Cookies (these used to be in the Debug Mode panel, but I think this panel is more appropriate for them) PLEASE NOTE: This panel is set to be loaded by default when Tracy is installed, but if you are upgrading an existing Tracy install, you will need to manually add this to be loaded in the config settings. 3) Revised ProcessWire Info panel - this is now much simpler and now contains: API variables (with links to PW docs for each) Core classes (with links to PW docs for each) Config data (dump of $config var) Versions List (an easily copyable list of server and PW core and module versions) Admin Links (including Login, Logout, and Documentation Links 4) Revised Debug Mode panel - several elements moved to Request Info and ProcessWire Info panels. Most of these sections could justifiably belong on the Request Info panel, but I think you are less likely to use most of these on a regular basis - they are more technical than the sections in the Request Info panel. 5) Request Info and Debug Mode panels now load in Redirect and AJAX bars I limit the panels that show up on the Redirect and AJAX bars to ones that will have different content. For example, there is no point loading PHP Info, Captain Hook, etc for these additional bars. Part of my reason for splitting up the ProcessWire Info panel into the new Request Info panel is because there is no point having admin links etc being populated to the additional bars. So you'll see that the ProcessWire Info panel is not loaded for the additional bars, but the Request Info and Debug Mode panels are. Now you can see the details of each page request (whether it's a redirect or AJAX, or ordinary). The panel on the left is after a POST form submission on a regular PW page and the one on the right is an AJAX call to a non-PW PHP script which is why there is no "Page Info" section. In this case, you can see the details of the request via the "Server Request" section which shows: It also shows the GET and POST data for the request, and the edit link will open that /data/testajax.php file in your code editor. 6) Lots of other tweaks There are lots of other tweaks, but the one that might cause a few weird issues is the way the debug bar and panel styles are loaded. The Tracy core now makes this easier, but I have noticed some instances where the styles are not being applied. I think it always comes down to browser caching, but if you find that a hard reload doesn't fix things, please let me know and I'll investigate further. Feedback There are lots of changes in this version, so please let me know if you have any suggestions - did I mess with something that you loved, but now hate, or do you just have ideas for how something could be done better? Please let me know!

Why not use a variable defined in the module class, eg: protected $clearPassword and populated via: $this->clearPassword in the hook's function. This will be available throughout the module's functions. This is what I did in my EmailNewUser that I linked to above.

I am sure it will! The challenge will be if someone asks you to work on a project with something else

Generally I agree with @Robin S's comments to you about inheritance of roles - that should usually take care of things without the need to edit template's access settings. It sounds like in your case inheriting everything from the home page template down will do what you want. However, just in case you do ever need to make lots of change to multiple templates, this can help - it's from the AdminActions module.

I have done this with an after hook on Password:setPass and you just need to grab $event->arguments[0]; https://github.com/adrianbj/EmailNewUser/blob/324e33730efc7e0431216a95c35ad8b8e27a013a/EmailNewUser.module#L56

Hi @adrianromega - thanks for the kind words and also for reporting this. Please test the latest version and let me know if that works ok for you. I also fixed a bug with the "Backed Up Settings" section on the config settings page for this module - where you can get the settings for all modules.

And thank you guys for all the feedback - seriously, it makes it much easier - often the decisions on the best way to do something can take longer than the coding

Ok, I am going to provide two options (/site/assets/TracyDebugger/snippets/ and /site/templates/TracyDebugger/snippets/) - you can choose whichever you want from the config settings. I definitely see the version control issue, but semantically "assets" seems more appropriate, so you guys can decide what suits you better I like having the parent "TracyDebugger" rather than your suggested "TracySnippets" in case we end up with a need for another Tracy folder in the future - this way they are nested, rather that having them on the same level which I think will be cleaner. Hope that's ok with everyone

Of course, wasn't thinking about the renaming with dot character prefix. This does of course mean that your snippets will end up in that archived version so you'd have to copy across with each upgrade. I was literally just writing this when your reply came through. This is safe from the files being run directly from the browser and we have a history of this approach with several other modules using this location. Done!

I think it depends on how you update modules. Manual overwrite of files would depend on whether you merge or replace when copying. I think if you use the PW Upgrade module it will replace /site/modules/TracyDebugger/ completely so the snippets directory would be lost / replaced with an empty one. I haven't tested this, but I think that's what happens. Either way, I think there are too many chances it will be lost. What do others think?

Sorry if I am not quite getting this - are you suggesting then that I should force snippets for the Snippet Runner panel to be stored in /site/modules/TracyeDebugger/snippets/ ? Surely they will be overwritten when upgrading Tracy? Outside of document root is obviously safe, but if I allow full flexibility it will be up to you guys to add rules to the .htaccess to block direct access to these snippet files so they can't be run directly from the browser. That's why I'd prefer /site/templates/ or perhaps /site/assets/TracyDebugger/ as a base path. Anymore flexibility than that and I think we are asking for trouble.

I am curious where you are thinking of storing snippet files? I would like to limit storing of snippets to folders that PW's .htaccess file blocks direct access to. /site/templates/ is one of these, but /site/ is not. It could be very dangerous to store snippets directly in /site/

Good to hear! I hope to have the shortcut keys working - it's a little different because with the Console panel they work when the editor is focused which we don't have in this case. I can probably add the eventListener on "document", but I would like to check that the Snippet Runner panel is open as well - will see what I can do. A question for you - do you think it's ok to have the path to snippets be relative to /site/templates/ so you would just enter something like "snippets" in the config setting which would scan /site/templates/snippets/ for files? Or maybe it doesn't need to be configurable and it's just in that folder, or do you think it should be configurable by full path, or maybe relative to document root? Any thoughts?

Hi @Robin S - here's a screencap of my first version of SnippetRunner. It looks and works quite similarly to the Console panel, except that it loads snippets from files in a configurable folder and of course the code itself isn't shown. I kept the "Processing" and "Completed!" notifications, as well as the results pane in case the snippet returns any output. If case it's not obvious, clicking "Run" executes the latest version of the snippet from disk, so no need to reload anything here after saving changes in your code editor. Also, the code in your snippets has access to $page when viewing a page on the frontend, or editing a page on the backend. It also has access to $field, $template, & $module when appropriate: see #2 here: https://processwire.com/talk/topic/12208-tracy-debugger/?do=findComment&comment=152466 Please let me know if you have any suggestions before I put the final touches on it.

Thanks for the vid - that's only an issue when the bluescreen is showing - it looks fine on a normal page load. The issue is that because PW doesn't init(), I can't get my CSS file to load normally. Currently I am checking to see if it's loaded when you hover to open a panel and if not, it loads the CSS dynamically. I'll look for another option if I can find one. Thanks for the new stylesheet - I'll see what I can do about getting it integrated somehow.

Are you talking about the default styles from the Tracy core, as seen here: https://nette.github.io/tracy/tracy-exception.html or in the PW module? I get rid of those in our version here: https://github.com/adrianbj/TracyDebugger/blob/6f4ffa444e9f464b5b44a3de82ba8cc3a6b51a17/styles.css#L8-L9

Are you referring to this PR: https://github.com/nette/tracy/pull/241 ? If that approach ends up being part of the core, I think it will make things a lot harder for me to override and also to add in styles for things like the Console Panel which uses styles from ACEeditor. As it is, I already tweak one line in the Tracy core which I mention in that PR thread. What didn't I want to do? Yeah, but the lead dev David also says "To allow to create skins for Tracy is not a bad idea.": https://github.com/nette/tracy/issues/27#issuecomment-39398635 I agree that looks much nicer, although I am not as concerned with the look of the bluescreen as I am with the debugbar and panels because I don't need to look at it that often - unless I am having a bad day I like this idea, although I think we might have better/quicker success with asking for making it skinnable - he has already expressed interest, and it should be hard to provide a way to load an alternate CSS file for the bluescreen.

Ah yes, sorry it is a little more complicated because it's hard to inject styles into bluescreen because a fatal error/exception means that PW isn't loaded, so I don't have easy control over that. I have found an approach (hack) that might be ok. Insert the following code here: https://github.com/adrianbj/TracyDebugger/blob/6f4ffa444e9f464b5b44a3de82ba8cc3a6b51a17/TracyDebugger.module#L825 Debugger::getBlueScreen()->addPanel(function ($e) { // catched exception return [ 'tab' => 'ProcessWire', 'panel' => ' <style> #tracy-bs-error { background: #cccccc; } #tracy-bs h1 { color: black; font-size: 12pt; text-shadow: none; } </style>', ]; }); Anything you add to the styles here will be loaded for the bluescreen page. The only catch is that it results in a new empty panel on the bluescreen called "ProcessWire". Maybe if we could come up with some actual useful content for this panel, it wouldn't feel like such a hack. Any ideas for something useful there? PS - obviously I don't want grey background / black text