adrian

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\

I personally haven't noticed this and hope it's not happening - the Version Switching panel in Tracy relies on these renamed folders/files being left after the upgrade. Maybe going back to old versions is not that critical for the average user, but as a module developer, it is super convenient to be able to instantly switch between versions, including the 2.x and 3.x branch. And honestly I think it can be useful for others too for helping to report core PW bugs - it makes for a very quick way to revert to previous versions to see if the problem exists there also.

Hey Marty, Unfortunately I never got around to finishing it - I just took a quick look at what I have and I think that rather than being a dedicated module, it might be better to convert it to an Action for ListerPro. I know that will obviously mean that you'll need a ListerPro license, but leveraging LP's ability to perform actions on just matched pages and its built-in batching will make for a more powerful and performant tool.

https://github.com/ryancramerdesign/ProcessWire/blob/7e8c7c6836282b6b64de81263f5aaa8112fd51ae/site-beginner/templates/_head.php#L21

Thanks @tpr - I have decided to remove that setMaxAllowedPacket method in the latest version - it's most likely not going to work for a standard SQL user on most shared hosts anyway. So, the message for everyone out there is if the debug bar isn't working and you have the PW core SessionHandlerDB module installed, you have three options: Uninstall SessionHandlerDB Increase your SQL max_allowed_packet setting (in your my.ini or my.cnf file, or via SET GLOBAL max_allowed_packet) - http://stackoverflow.com/a/5688506/1524576 Use the "Legacy" option for the Tracy core setting in the module config (not really recommended as you'll be missing out on core updates)

Hi and welcome to PW. That CNN URL is not a valid feed - it needs to return an XML document, but that one is just a directory of actual feeds - choose one from the list and it should work fine. What was the other URL you tried before switching to the CNN one?

Thanks to @netcarver - http://pwgeeks.spreadshirt.co.uk/

Hi @tpr - sorry about that - is that working version the last one that works for you? Everything is fine here, so it's hard for me to track this down without more info. Would you mind doing a little debugging - I am honestly not even sure where to start for this one. Can you please at least post a screenshot of the error so I can see the file and line number that is generating the error? Thanks!

Hi everyone! Thanks to a tip from Ryan, I now have the latest version of the Tracy core working properly when the core SessionHandlerDB module is installed. This means that I have been able to consolidate the number of packaged versions down to two: Legacy and Master. Now the only reason not to use Master is if you are running PHP < 5.4.4 I will keep the Master version updated with changes to core after testing to make sure there are no issues. The module now automatically adjusts your MySQL max_allowed_packet setting so that it is large enough to handle storing the Tracy debug bar data when you have SessionHandlerDB installed. Ryan has changed the "data" field in the "sessions" database table from text to mediumtext and says he'll be adding this to the upgrade routine shortly, but if you have problems with the Master version, please make this change yourself. Please let me know if you have any problems with the new Master version.

Thanks Wanze - very good point! When I wrote that module I initially had things set up quite differently such that it required rendering the template file directly. More recent changes mean that it no longer needs to do that. Rendering the page directly (like you noted) works fine here, so I will make that change to the module anyway and hopefully it will solve the problem with TEF. PS New version with this change just committed.