Module Tracy Debugger

[flydev]

No more issue on Windows.

what I need is the username of the ID returned by the "fileowner" function

check my last comment/edit.

thanks for the update sir.

[pwired]

Hi Adrian, thanks for releasing version 0.80 

I installed version 0.80; error message is gone and immediately the Tracy Toolbar showed up.

[matjazp]

Hi everyone,

The latest version fixes the error on Windows, although I have had to remove the "Owner" details if that function isn't available. Thanks for the suggestion Kongondo, but I think it is more complicated than using "getenv". That allows you to get the current running user - what I need is the username of the ID returned by the "fileowner" function. It also seems that perhaps "fileowner" doesn't even work as expected on Windows: " - http://www.w3schools.com/php/func_filesystem_fileowner.asp

I don't have a Windows dev environment to test, so if there is someone out there who wants to test this and submit a working PR, I'll happily include it.

Please let me know if anyone has any problems with the latest version.

I'm on windows + IIS. "Apache is running as user: nt authority\iusr" is correct (I would change Apache with Web server). About permissions: I tested with /site/config.php. The owner of the file is iusr user and has read only access. No one else has access so I don't know what to say about "0666 Readable by more than just the owner." Exists, Readable and Writeable columns seems to be correct.

[adrian]

Thanks for the feedback @matjazp,

I am definitely still tweaking this stuff, but I do think that statement is correct because 0666 means that all users can read and write . If you read Ryan's recommendations for config.php (https://processwire.com/docs/security/file-permissions/#securing-your-site-config.php-file) he states that it should only be readable by the apache user, and no others. Ideally it should actually be 0400 or 0440 so that it isn't even writeable by apache, but that may not always be convenient.

I will add that I am not sure I expect to ever has these status/notes comments perfect, but I would like them to be a useful flag for obvious problems. I definitely want as much feedback on this as possible, so thanks. 

[matjazp]

Well, now I tested with install.php. I made the owner of the file iusr and iusr is the only one with read permissions, no one else. 

Install File /install.php ✓ ✓   0666 Failure Should be deleted for security.

Yes, install.php should be deleted for security, file exist, is readable, not writeable, but 0666? 

[adrian]

Well, now I tested with install.php. I made the owner of the file iusr and iusr is the only one with read permissions, no one else. 

Install File /install.php ✓ ✓   0666 Failure Should be deleted for security.

Yes, install.php should be deleted for security, file exist, is readable, not writeable, but 0666? 

Sorry, are you saying that it is reporting that install.php is set to 666, but that is not actually the case? What permissions is listed when you:

ls -al install.php

[matjazp]

There is no ls command on windows. There is icacls that shows:

C:\inetpub\wwwroot>icacls install.php
install.php: Access denied.
Successfully processed 0 files; Failed processing 1 files

Access is denied because I (my login account) don't have access to the file. The only user with access to the file is the user under which web server is running. On linux that would be 400 and file is owned by user apache. 

If I change the ownership to my account and run icacls again:

C:\inetpub\wwwroot>icacls install.php
install.php NT AUTHORITY\IUSR:(RX)

Successfully processed 1 files; Failed processing 0 files

It shows that iusr user has read+execute access.

I wouldn't bother too much with windows permissions, they are more complicated than on linux, and maybe wouldn't even show permission, status and notes columns? Many php functions don't give reliable results on windows (I think that chmod does nothing on windows, but haven't tested...). There are also differences with rename/move operations etc. 

[adrian]

Thanks for the feedback @matjazp - sorry, I spaced on "ls" not being available. I forgot that permissions are not the same on Windows - it's been a while for me

As you say, maybe I shouldn't bother showing them. I also wonder how much it really matters - presumably 99% of Windows use cases are dev environments - is anyone actually hosting a live site on a Windows server these days? Anyone else with any Windows input on this?

New version just posted has a new "Output Mode" indicator/panel - as a reminder of what Tracy mode you are in. If you are in DETECT mode, it will report the actual mode that Tracy determined is appropriate based on your IP Address.

I also added a phpinfo() output to a new section on the Diagnostics panel - maybe this is too much? I don't really want to make the config settings anymore complicated - ie I don't really want to add the ability to determine what sections are included in a multi-section panel, but I would like everyone's feedback on this. Should the phpinfo section be removed, or maybe should it be its own panel - maybe one that you typically leave disabled, but enable if you need to take a quick look? Any thoughts?

[matjazp]

As you say, maybe I shouldn't bother showing them. I also wonder how much it really matters - presumably 99% of Windows use cases are dev environments - is anyone actually hosting a live site on a Windows server these days? Anyone else with any Windows input on this?

As I said, I would not show permission, status and notes columns since they show wrong info on windows. Exist/readable/writeable columns are ok. I can't test what statuses are displayed on linux box, but flaging read/orange/green is also not trivial. If you want to be able to upgrade PW version using ProcessWireUpgrade Module, /wire has to be writeable and if that user wanted to do then it should be marked green (or orange), not red (I don't make /wire writeable in production). If you want to upgrade site modules, than /site/modules has to be writeable etc. I would limit phpinfo() just for admins. 

I'm hosting 3 live sites on Windows server for more than a year, 2 more to come. No problems so far.

[pwired]

presumably 99% of Windows use cases are dev environments / the phpinfo section any thoughts?

Yes I'm only developing on windows and host on linux. I like the new phpinfo section, it's not in the way and it saves me

oploading my own php scripts.

[horst]

@adrian: I have a running PW 3 now, and played a little with Tracy. Really, really useful. Thank's for that, (also to @tpr!)

Regarding the configuration and features: Personally, I would like to only have those features visible / enabled, I currently need. phpinfo is definetly not one of them. I think when I use 1000 times the debugger, I would need 2 times the phpinfo.

What's about a single and simple ASM in the configscreen, that lets the user enable / disable features?

I have done it that way with ALIF, I don't think it is to much confusing or overwhelming. It would need one ASM in the configscreen and one additional line in your render method: https://github.com/horst-n/AdminLinksInFrontend/blob/master/AdminLinksInFrontend.module#L1437

Anyway, with or without configurable features, it's a very useful module, especially for remote debugging (on live servers) !!

[adrian]

As I said, I would not show permission, status and notes columns since they show wrong info on windows. Exist/readable/writeable columns are ok. I can't test what statuses are displayed on linux box, but flaging read/orange/green is also not trivial. If you want to be able to upgrade PW version using ProcessWireUpgrade Module, /wire has to be writeable and if that user wanted to do then it should be marked green (or orange), not red (I don't make /wire writeable in production). If you want to upgrade site modules, than /site/modules has to be writeable etc. I would limit phpinfo() just for admins. 

I'm hosting 3 live sites on Windows server for more than a year, 2 more to come. No problems so far.

Thanks - I'll revisit these shortly. As you say, even on Linux it is still not trivial getting the status flagging correct, but I guess I will need to disable on Windows and tweak regarding /wire - I forgot about it needing to be writable when using the upgrade module.

 

@adrian: I have a running PW 3 now, and played a little with Tracy. Really, really useful. Thank's for that, (also to @tpr!)

Regarding the configuration and features: Personally, I would like to only have those features visible / enabled, I currently need. phpinfo is definetly not one of them. I think when I use 1000 times the debugger, I would need 2 times the phpinfo.

What's about a single and simple ASM in the configscreen, that lets the user enable / disable features?

I have done it that way with ALIF, I don't think it is to much confusing or overwhelming. It would need one ASM in the configscreen and one additional line in your render method: https://github.com/horst-n/AdminLinksInFrontend/blob/master/AdminLinksInFrontend.module#L1437

Anyway, with or without configurable features, it's a very useful module, especially for remote debugging (on live servers) !!

Thanks for the feedback horst - really appreciated.

I have split PHPInfo into its own panel so it can be easily disabled in the config settings. BTW I do already have an ASM field handling the display of each panel - I just didn't want to get into the various sections in each panel. I am not actually convinced about the ASM choice over a simple checkbox. It's nice having the ability to order panels, but it's harder to quickly see which ones aren't selected. As users upgrade they won't necessarily know there are new panels.

The latest version also includes some CSS tweaks to the panels - I think they are a little friendlier now.

I am contemplating adding more panels:

1. Available upgrades: core and site modules
2. Data from Google Analytics - like realtime visitors and other timely stuff
3. MySQL info - number of current connections and other available info
4. Custom links panel - lets you define links and link text - maybe direct link to analytics for the site, or whatever really.
5. Custom panel - you can output anything you want here - it would have full access to wire(). This would be kinda like a permanent barDump() panel with the output defined from the config settings. Or it could be a set of instructions, or a direct link to edit a specific page in the admin, or whatever.

Some of these are probably overkill - just brainstorming! Any thoughts on these, or do you have ideas for others?

I am also considering having separate permissions for each panel so that if you allow non-superusers access, you could hide all the debugging/error reporting stuff and just display some of these custom panels to site editors.

Does anyone think this would be useful, or should all authorized users be able to see everything?

[cstevensjr]

  

BTW I do already have an ASM field handling the display of each panel - I just didn't want to get into the various sections in each panel. I am not actually convinced about the ASM choice over a simple checkbox. It's nice having the ability to order panels, but it's harder to quickly see which ones aren't selected.

I ask that you please somehow keep the ability to order the panels.

[adrian]

No problem - I can stick with the ASM option - I just wasn't sure whether anyone was using the ordering option - now I know you are, it's only a small inconvenience to allow that ability.

[kongondo]

Hey Adrian. This is looking more awesome by the day. I have to agree with the boys though...It can feel a little overwhelming viewing the configurations' GUI. I agree that something simpler would work better. I would go with ASM as well, or some collapsed fieldsets to hide stuff if possible.

As for contemplating adding these two panels:

1. Available upgrades: core and site modules
2. Data from Google Analytics - like realtime visitors and other timely stuff

...IMHO, I think these two are overkill. One, they are a 'digression' from the 'debugger' ball park, which is the core aim of this module. Secondly, we already have other modules that take care of those needs....to some extent. My suggestion is to only stick to tools/features that aid in debugging. Thanks!

[adrian]

It can feel a little overwhelming viewing the configurations' GUI. I agree that something simpler would work better. I would go with ASM as well, or some collapsed fieldsets to hide stuff if possible.

Sorry, I think I might be on a different wavelength to you guys - I already have the ASM for selecting and sorting the panels to be displayed. What other settings do you think would benefit from an ASM options? I honestly don't see it being a useful interface (compared with checkboxes) unless you need to have them sortable, or if there are a LOT of options - such that there are just too many checkboxes. But I am definitely keen to hear which ones you think would be better as ASM.

I can definitely see that some collapsed fieldsets could be helpful to organize the settings into related sections - I'll have a think about this and figure out which settings belong together.

...IMHO, I think these two are overkill. One, they are a 'digression' from the 'debugger' ball park, which is the core aim of this module. Secondly, we already have other modules that take care of those needs....to some extent. My suggestion is to only stick to tools/features that aid in debugging.

I do have a habit of getting carried away with too many settings/options - thanks for reigning me in 

Thanks again for the feedback - we all work and debug differently so it's great to hear what you guys want for this - don't be shy!

[tpr]

Maybe creating a 1/4 and 3/4 columns in the admin, where the first would hold the asm select of the submodules, and the other their settings would make the page structure more logical.

I'm not sure the asm select can do showIf things, that would be the best. I guess this would satisfy those who needing a cleaner UI. Personally I'm fine with the current one though, it's an admin page after all.

[adrian]

Thanks for your thoughts @tpr - I am going to take a look at the settings in the next couple of days and clean them up a little.

In the meantime, the latest version has some enhancements to the PW Info Panel. In particular, the "Fields List" section has been extended to be "Fields List & Values".

It now additionally shows:

• some key Settings (at the moment just the maxFiles value, but might add some other key ones at some point)
• the type of value that is returned: object, string, integer, etc
• the value of the field - which is really nice for easily seeing what properties are available - see the phone_number in the screenshot for a useful example.

[szabesz]

+1 for checkboxes and easily discoverable options. I find that settings pages like this are not visited too often and I tend to forget what I should look for when I need to change settings. When I have only one loooong page I can at least use the browser's find feature to quickly look for what I am possibly after

I also like that the settings page is full of comments that are not hidden, because this way I am reminded to read them. (I often forget to read tooltips and similar UI help solutions since they are initially hidden, conceptually.)

All in all, I agree with tpr that it is an "admin page after all" and most importantly a page that is (should be) used by developers only.

[adrian]

+1 for checkboxes and easily discoverable options.

Yeah I agree - maybe I need to implement something like this (http://jsfiddle.net/PtskU/) as a new Inputfieldtype in PW. ASM's just don't always cut it.

[kongondo]

Sorry, I think I might be on a different wavelength to you guys - I already have the ASM for selecting and sorting the panels to be displayed. .

My bad. Would you believe I totally missed that! 

The 'problem/challenge' with ASM select (to organise the other settings in the backend GUI) is you won't be able to add notes, instructions, etc next to each option (not without a hook), so I see your point @adrian about it not being a better option compared to checkboxes.

I agree that this is an admin page so, @adrian, don't spend more time than you should on it . Having said that, a small confession (not a criticism in any way!!!), I get 'bothered' by grid/columns, that don't balance  ...In a single table/grid, I like all 'rows' to have the same number of columns if possible. In this case, I would have used collapsible fieldsets, with similar features grouped together under one fieldset, each single featere in its own row. Don't mind me, it's just me being weird. .   I spent too much time getting bothered by Menu Builder and Matrix settings not 'balancing'     

[pwired]

I think I found a typo that causes a server error 500 on the host, at least that is how it looks when reading the error message.

This is what I did:

a) I moved a dev site with tracy debugger enabled from my laptop to my host

b) Online the site would not open: We're sorry! The server encountered an internal error and was unable to complete

    your request. Please try again later. error 500

c) Then I disabled tracy debugger in the dev site on my laptop and moved again to my host

d) Now the site opened online

e) Online I went into the backend and enabled tracy debugger

f) Then this error came up and I have no longer backend access nor the site opens:

Parse Error: syntax error, unexpected '[' (line 42 of /home/www/mysite.com/site/modules/TracyDebugger/PerformancePanel/Register.php)

Edit: I looked at line 42 and to me everything looks normal there.

[LostKobrakai]

Is the server running php 5.4? This does suspiciously look like a 5.3 install, which doesn't support short array notation with [].

[pwired]

Is the server running php 5.4? This does suspiciously look like a 5.3 install, which doesn't support short array notation with [].

@LostKobrakai

You were right, the host had php 5.3 configured, but changing it to php 5.4 did not make the problem go straight away.

Maybe still some cache somewhere. I had to empty out config.php in the site folder, reload the pages, and put config.php

back. Maybe there is a better way for doing this but works for me. After that everything worked.

So in the end it was the old php 5.3 on the host like you said.

[adrian]

Sorry about that - I already adjusted one short array syntax issue with the Performance panel plugin. I'll take care of that one too - update coming shortly.