adrian

Introducing the new "User Bar" If enabled (currently off by default), this bar is displayed for users that don't have Debug bar permissions (typically all non-superusers) Currently it has three features: Admin, Edit Page. Page Versions The first two are simply links from the front-end to the root of the admin panel, and a link to edit the current page in the admin panel. These are quite similar to horst's ALIF module, but I was thinking if you are using Tracy anyway, then why not have it provide these buttons for other users who have editing permissions. Now for the first of the unique features: Page Versions. This is a simplified version of the Template Path panel that is available from the Debug Bar. It is also similar to the User Dev Template option, but this one allows the user to try multiple options that you provide. Remember you can always have the alternate template files load different js/css etc files as well, so you can provide a very different version of a page for your users to test. To make it more friendly for your clients/editors, the labels in the list are formatted to look like page names, rather than filenames. The user simply selects an option and the page instantly refreshes showing the page using the alternate version. Even if you have the Page Versions option selected in the config settings, it won't appear on the User Bar unless you have alternately named template files matching this pattern: "home-tracy-alternate-one.php" etc. The key things are the name of the template, plus "-tracy-", plus whatever you want to appear in the list of options, like "alternate-one", plus .php Users must also have the "tracy-page-versions" permission assigned to their role. My next goal for the User Bar is the Feedback / Tickets / Review functionality that was discussed earlier. I know this is starting to take this module beyond just a debugging tool, but I think it's nice to have all this stuff accessible from the same place, so that when you as the developer look for a user submitted support ticket, it will be part of the Tracy Debug Bar. Of course I am also planning a central admin interface for managing all tickets in one place, but I still think it makes sense to be able to submit them from the page in question and also view them from the page as well. It certainly needs some styling improvements etc, but is functional already. I will probably make it possible to define custom styling/positioning in the config settings. Please test carefully before enabling this new User Bar on a live site! Maybe it's time this module gets renamed as the "Tracy Developer Toolbox"

Ok, I still can't reproduce here - from reading about that object it should only be an object if output formatting is off. Anyway, I have committed a new version which should prevent the error - the PW Info panel might not display the contents of that object as an array how I'd like, but it should hopefully work for you for now until I can reproduce and format properly. Please let me know if it fixes the error for you.

Please try enabling the Dumps Recorder panel - the dump is probably being lost due to a page redirect or something. If you still don't get anything returned, can you please try: bd($outValue); at line 311 - just before the if(is_array) line. Thanks for your help with this.

@Juergen - would you mind adding: bd($val); to the line before 315 - ie just inside the foreach and let me know what is returned.

@Juergen - I might also need some more info on the content of the troublesome pages. I am not really a ML user, but I have it installed and have a field which is set to ML and I have content in both languages, but am not seeing an error. Can you figure out what is specific to those pages?

Thanks for the report - what version of Tracy are you running? Just want to be sure that reported line number is pointing to what I think it is. If it is easier, you could just post the contents of 315 of ProcesswireInfoPanel.inc

Sorry, did you read my updated post - you replied too quickly

Did you restart apache after running apt-get? What about the php5-gd package? Nevermind you are running PHP7. I thought GD was included with php these days by default. Any chance PHP was manually compiled, rather than installed via aptitude? What does this return? php -i | grep -i --color gd

I don't think this is an option - I think you need to format yourself with something like PHP's date()

@szabesz - thank you for the offer of putting together a flow chart. It might prove useful, but I am honestly wondering whether the fact that we are even discussing the need for a flowchart means that I have failed - if something is complicated enough that we need a flowchart, I get the feeling it needs be to simplified. Thanks for your thoughts on this - maybe I should at least remove the "show the debugbar to everyone when Detect determines localhost" behavior - that seems to be a confusion.

Actually in response to Macrura's question I want to clarify some things - Tracy active vs the debug bar visible vs Production/Development are all different things. Once installed, Tracy is always active. Even unchecking "Enabled" loads some files - these files handle your bd(), d(), fl(), l(), da() calls so that non Tracy users / guests won't get undefined function errors in case you have some of those calls in your live code. In Production mode Tracy is fully loaded to handle all errors, but it doesn't display those errors or the debug bar - it logs the errors and can email you of an error (if you have the settings configured with your email address and "Allow Logging in Production Mode" checked. In Development mode (either set or determined from Detect mode), errors and the debug bar are displayed (although the debug bar can be hidden from front/backend based on those checkboxes). It can be all a bit confusing which is why I am contemplating removing the Detect mode option and maybe even making the "Output Mode" panel one of the defaults when Tracy is installed. If anyone has any thoughts on improved behavior, I am all ears!

A little confused here, although I think you might be seeing what @Zeka noted above: https://processwire.com/talk/topic/12208-tracy-debugger/?do=findComment&comment=127543 If you are in DETECT mode and on local host then the debug bar is active for everyone, even guest users. Is that what you are seeing? If it is, please see my response here: https://processwire.com/talk/topic/12208-tracy-debugger/?do=findComment&comment=127589 If not, then it might be something I need to investigate in which case it would be great to have some more details.

parent!=7

Tweaked, although I still like the "Toggle All" out on its own. I have also cleaned up the time/size values at the bottom of all panels - very simple now with no superfluous text.

Is this better? That's how it looks in the latest version.

@tpr - columns for the panel selector does sound like a decent idea. The Tracy core CSS is a bit of a pain - I already have to make one core hack because of the way they have things set up. I am actually using all: initial in one place already, but not everywhere. Maybe I'll revisit using it more. That's always been my thought too, but when I see what you have done with AOS I second guess that decision

Thanks for your thoughts as usual. I keep for forgetting about your screen real estate limitations. My laptop is 1680 x 1050 and my last one was actually 1920 x 1080 (from 2003) so I forget that people have smaller resolution to work with. I thought I took care of this recently - are you still seeing this problem? There are lots of things that I need to override but it takes time to come across them all. Please let me know whenever you find a CSS attribute that I have missed. What would the logical groupings be? I just made them in alphabetical order which I thought would be simplest. I agree that the admin settings could be improved. I'll admit I don't have @tpr's flare for that though

Have you looked at BatchChildEditor: You can move the interface to anywhere you want - either part of the Children tab, the Content tab, or even its own tab. You can predefine field pairings for the CSV columns to PW fields, etc. In Update mode it will update existing PW pages. You can also choose from Add and Replace modes depending on your needs. Maybe it might be helpful?

I decided to add a dedicated "Tracy Toggler" panel. Well it's actually just a button - you can see it second from the end: and when it's disabled, this is all you see at the bottom right of your site: I left the "Disable Tracy" button in the Panel Selector because I figured some users may prefer that approach - it's your choice.

Ok, the latest version has a new disable/enable option. I added the Disable button to the bottom of the Panel Selector because I think most of you have that enabled all the time. Please let me know if that won't work for some of you and I can rethink @szabesz's suggestion for adding it to the System Info panel. I would have done that straight away, but that is a Tracy core panel, so I would have to add with JS. The main problem is that panels are lazy rendered, so the DOM for panels is not available until the first time they are loaded. Still do-able, but requires a little more effort. The Enabler button is simply a red bug icon (like the one I am using for Tracy in the site modules list). It appears at the bottom right of the page when you have disabled Tracy. It only appears on frontend and backend if the debug bar is enabled for those locations. Note that this disabler doesn't actually uncheck the "Enable Tracy Debugger" checkbox in the settings - it's just disabled with a cookie. I am happy to revisit this approach, but my reasoning was that I'd rather the settings checkbox had a little more power, so that if it's unchecked there, the enable icon won't actually appear at the bottom right of your site. Anyway, hope this helpful and don't be shy if you think I have messed it up by doing it this way

Ok, I'll see what I can do. Obviously a disable link like AOS has would only be available when you're in the admin, but if the only problem you are having is module updating, then that is probably ok. I had actually been thinking about a "Disable Once" button available from the debug bar that would prevent Tracy from being loaded on the next page load, but I don't think this would handle your situation anyway because module updating involves a few page loads. One thing though - if you are getting warnings from PW core files - have you reported these as issues on Github? Sorry, what is the "main panel" you are referring to? Do you mean the debug bar, or the panel selector panel? Do you have any specific ideas for how best to provide a disable feature? You have noticed something that I have been considering changing. It was meant as a feature, but I wonder if it's more of a confusion. Basically the logic is that if you are in DETECT mode and Tracy also determines that you are on a localhost, then it will display the debug bar regardless of whether you are logged in or not. If you switch to DEVELOPMENT or PRODUCTION mode, it will behave the same as a live server. I was trying to make it easy to have the debug bar available to test things when not logged in, but now that Tracy has the User Switcher panel, we don't really need this, because we can use the User Switcher to change to a non-superuser (or even logout) and still have access to the debug bar for the length of the user switcher session. Do you (or anyone else) have any thoughts on the best scenario here?

I am not sure what you're trying to do with that. $event->arguments[0]->id returns the ID of the user page. You don't want to override the $page object ever. Given that we are talking about a user, the convention is often to use $u. $u = wire('users')->get($event->arguments[0]->id); but that is basically what I showed you up above.

Follow the instructions in this post to move the Name to the Content tab Then hide the Settings tab altogether using this module (http://modules.processwire.com/modules/restrict-tab-view/)

Hi @biber - I think your problem might be similar to this: https://github.com/justonestep/processwire-imageextra/issues/9 Can you cleanup the db table for the images field: "field_images" (or similar) by removing the extra language fields? Looks like the problem should be fixed in the dev branch of that module, but you still might have to cleanup manually at this point.

The PW namespace is ProcessWire, not Processwire