adrian

Done! Makes sense - let me take a better look at that existing panel. Unfortunately most of the existing Tracy plugin panels require the entire Nette framework, so it is unlikely I will be able to use that one directly. I initially started with someone else's ToDo panel, but even after I had stripped out all the requirements for other Nette components, I still didn't like the way it was parsing out comments, so I ended up writing a new one from scratch I guess I am not totally sure how this would help. At the moment by default, it only scans files inside /site/templates. With that new checkbox, you can now expand this to include /site/modules, but I doubt many will want to add this option. I am think most will want to scan all of /site/templates, but simply exclude some parent folder like /site/templates/scripts/libraries/ where they would add all third party js libraries. Can you explain what folders you might want to exclude that a regex could help with - that would help me better understand how to implement. I am not totally sure on this either - you'll notice when you have Tracy enabled in the backend, there is an additional bar that shows up when the admin makes ajax calls (like for getting menu subitems), so theoretically I could have an "email" panel also show on the ajax bar - currently I disable all of the custom panel (except performance) from appearing on the ajax panel, but I can make an exception for an email one. I am guessing this shouldn't be too hard - just need to hook into wireMail. Perhaps you guys ( @tpr and @bernhard ) could come up with a list of required features?

I guess I am a little confused about the purpose - the https://github.com/nextras/mail-panel seems to capture outgoing messages sent from the server, but https://mailcatcher.me/ seems to display messages sent to a particular email address in a web interface. What functionality are you actually looking for? Maybe if I know more I'll have a better idea about whether I think it should be in Tracy or not.

Don't apologize - feedback is what I need Yeah, good point about modules - I think it makes sense to have the option to scan the modules directory too - I don't recommend this for most users as it can slow things down a bit, but the latest version now includes a config settings checkbox to allow this if you want. I also fixed the error if you empty the ignore dir list as well as improving some other elements of comment parsing.

if(!$pages->get("name={$item_id}")->id) { // create new page } Although you probably want to add other limiters to the selector, like a parent page or template.

@Macrura - just to follow up, I have committed that change - now when you save the module config settings in the backend, the list of panels is reset to the permanent list in those config settings - ie, the Sticky list of panels is Reset. Hope that helps to avoid confusion / problems for others also.

That's not the behavior - sticky changes to the panels are stored in a session cookie. Maybe that is confusing, but it was designed to be a way to have panels display temporarily, but for more than one page reload. Maybe what I need to do is have saving the module config settings clear that session cookie (same as clicking "reset" in the selector panel on the frontend) - that seems like a logical solution to me - I'll implement that now. No problem - let me know if there are any changes that would help with your use case.

From my experience, @Robin S's solution is definitely the way to go!

Sorry it is proving slow for some (maybe all of you guys). Wish I was seeing the problems here so I could debug. Does anyone have a live server that is running slow that they'd be willing to give me access to so I can take a look? I'd really like to get this sorted out so no-one feels the need to have an on/off toggle. Are any of you running xdebug? Does disabling it completely make a difference?

I was hoping that was the issue - it certainly loads very quickly for me here. If you ever do find some time to investigate where the problem might be, I'd appreciate it.

Thanks everyone for the feedback / issue reports the last couple of days. @tpr - I have taken care of the ToDo panel incorrectly reporting # type comments in js files. However I would still recommend that if you want to use the ToDo panel (which I find really useful :)), you should put any external js libraries in a separate master "libraries" (or similar) folder, like /site/templates/scripts/libraries/ and then add this to the directories to be excluded so that the panel doesn't have to scan all those files that aren't your code. @bernhard - am I correct in assuming you are running the SessionHandlerDB module? I see a significant slowdown with Tracy and that module. I really don't know how to deal with that at the moment other than suggesting you uninstall it on your dev environment. You can always install it on the live site for the advantages it provides, but because Tracy has a LOT of data stored in sessions, this becomes a problem when using that module. Could you please try uninstalling to confirm that things also speed up for you. For me on my current test PW install with that module uninstalled, enabling Tracy takes the page load from 800 to 925ms, which I think isn't bad at all. @Macrura - now that you have excluded those directories, I'd love to hear if you find the ToDo panel useful - it has definitely made me start using the 'todo', 'fixme', 'pending', 'xxx', 'hack', 'bug' tags in my code more often now that I have a simple way to keep track of them on a page/template basis when viewing the site. Keep the feedback coming everyone!

Glad you had success by that combination. I think it is important if you have the ToDo panel enabled to exclude any external js/css libraries by putting them in a separate parent folder. Just to clarify - you say ToDo wasn't enabled in the settings but was showing on the bar - did you fix by clicking "Reset" on the Panel Selector? If so, then it must have been enabled via the "Sticky" option at some point. I have been thinking about adding this - sounds like a good idea. I am sorry to hear that it is slowing down page loading for you though. Can you narrow it down to a specific panel (look at generation times in the Panel Selector Panel). Also, did you by chance change the Max Nesting Depth setting in the config from the default of 3? I am in discussion with Ryan about this - there is some recursion going on that definitely slows things down for me if I make it larger than 3.

Nevermind - I am an idiot - I was including jQuery via CDN Now I see what you guys are talking about - investigating a solution now! EDIT: Turns out it's the hash(#) character in some regexes in jquery. Because I am using PHP's token_get_all to find comments, it is also finding these, because PHP allows for # comments. There is the word "pending" in the jquery code on the same line after a # which is why the entire line is being returned. I don't have an idea for a quick fix at the moment, so this might have to wait till tomorrow. Anyone have any bright ideas?

Thanks - I have made those changes here - will commit later. I am not seeing the issue here, but it sounds like @bernhard is getting it also. I don't really understand why though. There is nothing between those /*! */ that should trigger a match - no: todo, bug, pending, etc. Even if there was a match, why would it show the entire contents of the minimized file since the contents are outside those comment delimiters. I am testing with that exact version of jquery. Do you have any ideas why the entire file contents are being matched for you guys and not me?

Hi @Macrura and @bernhard - I think the errors you are seeing are likely due to scanning of binary files. I have added config options for setting directories to be completely ignored and also a list of file extensions to be scanned. The ToDo panel is now using a whitelist vs blacklist approach to the file extensions to be scanned. I have set up what I think are reasonable defaults: Hopefully this should take care of all the errors you are seeing - please let me know how it goes for you. Also, if anyone has any suggestions for changes to the defaults, please let me know.

Does this mean you don't even have it enabled? This is what it looks like: Note the 5/17 icon in the debug bar. I can't see any problem with that ascii art in your template files. I am guessing it might be from some external JS libraries or something else in a site/templates/scripts subfolder. The ToDo panel is not loaded by default when TracyDebugger is installed - it has to been added via the module config settings, or the Panel Selector. Could you maybe try excluding any scripts subfolders like bernhard did and see if that fixes things. Of course you could also just disable the ToDo panel, but I would really appreciate a little help in diagnosing if you don't mind. If excluding one of the folders works, it would be great to know the contents of those files - is there anything non UTF-8 in there?

Hey @Macrura - sorry about that - what version of Tracy did you upgrade from? It sounds like perhaps you are having a similar issue to @bernhardhere: https://processwire.com/talk/topic/12208-tracy-debugger/?do=findComment&comment=123622 I can't think of any changes in recent versions that would cause this, but if it is just recent, could you figure out exactly which commit started the errors? Also, to help me diagnose this it would be awesome if you guys could provide one of the files that the ToDo panel is scanning that is triggering this. Looks like I probably just need to encode all file content as UTF-8 before scanning for //todos etc, but having a test file to work with would be great. Thanks.

I am not so sure about that and it certainly wasn't my intention. ALIF has additional features that make it a worthwhile tool, like: screen dimensions session destroy OPCacheStatus viewer Also for those not using Tracy because they prefer a different PHP debugger, the user switcher in ALIF will still be indispensable.

The latest version adds a new User Switcher panel that lets you instantly switch to any user (or logout) and then easily switch back to your superuser account. It is fairly similar in functionality to the user switcher in @horst's excellent ALIF module, but has the advantage of making the Tracy debug bar available when switched to any user and even when logged out, which can be very useful for debugging. Obviously there are some security concerns when setting up functionality that can log into other accounts without needing a password. There are several things this panel does to make this safe(r), but the key thing to remember is that setting Tracy to Production mode keeps you safe! It is completely disabled unless Tracy is specifically set to Development mode. Detect mode won't work and even the "Superuser Force Development Mode" option won't enable it so you can be sure your live sites are safe unless you specifically enable Development Mode for a debugging session. You need to be a superuser to have access to the panel until a session is started, so even when Development mode is enabled, other users still won't be able to use it. It only works for the duration of user switcher session (max 60 minutes) and only a superuser can start a session. Starting the session makes use of PW's CSRF protection. The switcher session has a unique ID and expiry time which is stored in the database and must match the ID in the user's session. Once the session has expired, it is no longer possible to switch users. You can manually end the session, or if you forget it will expire automatically based on the session length you set. As usual, icon colors are meaningful telling you what type of user is currently logged in: Green: superuser Orange: non-superuser Red: guest / logged out Please let me know how you go with this new panel - hopefully it will be a significant timesaver when checking/debugging your site from other user roles. Also, if you think of any improvements that could make this more secure, or useful, please let me know. I would definitely appreciate an extra set of eyes (or two) to take a look! This new version also has the following changes: It removes the need for the separate helper process module for executing the Console Panel code - it will be uninstalled during the upgrade. I have removed the "Debug Statements" tool in the config settings - I think this is superfluous now that you can easily add debug statements to template files dynamically using the Template Editor Panel. If anyone really wants this back, let me know. There is also significant cleanup of other sections of code, so please let me know if you notice any issues from these changes. Have a great weekend!

Hi @bernhard - glad to hear that Tracy is first on your list I am happy to make that ignore list configurable, but I would also like to know what errors you were getting due to those invalid characters. Maybe that also needs some attention? I am also wondering if perhaps it should be the other way around - maybe it should only process the root of site/templates plus the root level of the scripts and styles subfolders. In other words it would not scan any other site/templates subfolders and also no subfolders with scripts and styles. I would of course make this configurable also as I expect some people change "styles" to "css and "scripts" to "js". I don't want to end up with too many config options, but sometime soon I need to make it easy to export Tracy settings from one install and import into other installs.

A really great article from @M.O.Z.G highlighting his migration from WP to PW. It talks about structuring and retrieving data, multi-language output, creating your own module, and debugging using Tracy. Thanks for a great writeup - really nice work! http://mozg-studio.org/blog/migration2pw/ I have to include this quote from the article

Nice - love the Textile reference I blame you and your forebears for this crazy language!

Your English is just fine I was just taking a dig at you for not clicking "Like". English is such a weird language and please note that those definitions of "taking a dig" that I linked to sound a lot stronger than how most people think of it when using that phrase. Ribbing is probably closer to what I was doing.

This is already implemented - the icon is red when you are viewing code that is different from that in the original template file. Glad you dig it - pity you don't like it Btw, the Template Path panel also allows this functionality without adding $user== conditionals - if you haven't checked it out, you should experiment with it also - whether you use it or this new panel depends on how attached you are to your editor, whether you have access to it, or if you want to save the hassle of setting up a "-dev" version of the file and pushing to the server, etc. Probably in most cases I would use this new Template Editor panel for debugging and the Template Path panel for adding/testing new functionality.

New Template Editor panel just added! This is an alternative to the Template Path panel (which I still think is a great option) if you need to edit a live site, which of course you never do The difference with this compared to Nico's Template File Editor (http://modules.processwire.com/modules/template-editor/) is that it allows you to test changes without affecting other users currently viewing the site. Note that there are three buttons: Test: This will reload the page using the code in the editor - no changes are made to the template file or the code served to all other users of the site. Push Live: This will save the editor code to the template file, making this a live and permanent change. Reset: This will reload the page (and the code in the editor) with the code from the saved template file. Possible use scenarios Use this panel similarly to your dev console for tweaking CSS/HTML - it still requires a page reload, but there are likely less clicks than your normal workflow. Use it to tweak a live site if you're away from your computer and need a quick way to fix something, but want the ability to test first without breaking something temporarily due to a simple syntax error mistake or more serious code mistake. Use it to add debug statements: fl(), bd(), d() etc to your template code without ever touching the actual template files. This is a first version of this panel - I am looking for feedback and feature/behavior suggestions. At the moment this only lets you edit the template file for the currently viewed page. I am considering adding a dropdown where you can load other files (included files, JS, CSS files etc), but want to see what you guys think.

Typically the file compiler in PW3 takes care of making modules without namespaces work in 3.x, however I have had a couple of situations where I have had to conditionally check if a class exists and if not, prefix it with \ProcessWire\