Jump to content
adrian

Tracy Debugger

Recommended Posts

2 minutes ago, adrian said:

This isn't about permissions in the sense you are talking about. It's just for these page permissions:

Of course, again! Sorry, am half asleep! Custom permissions are mainly used with custom modules 🙂

  • Like 1

Share this post


Link to post
Share on other sites

@kongondo - just wanted to check to make sure the new "current user" row at the top of the table helps with your initial concern?

Share this post


Link to post
Share on other sites

Ya, I initially thought it would show all the permissions.

As for the colors: maybe a light green background with a dark green check mark and light red/pink background with a dark red "X" ?

Share this post


Link to post
Share on other sites
1 minute ago, adrian said:

@kongondo - just wanted to check to make sure the new "current user" row at the top of the table helps with your initial concern?

It does, thanks!

  • Like 1

Share this post


Link to post
Share on other sites
27 minutes ago, adrian said:

image.png.472dea523fdfa82e7c9263932cc13e0e.png

Better imho! I think it could even be grey instead of orange. I'll play around with it one day, but atm I'm busy with other stuff and don't need to care about permissions a lot 😄 Maybe @tpr comes up with a good suggestion...

 

13 minutes ago, adrian said:
19 minutes ago, kongondo said:

So no custom permissions then?

This isn't about permissions in the sense you are talking about. It's just for these page permissions:

https://github.com/processwire/processwire/blob/341342dc5b1c58012ae7cb26cffe2c57cd915552/wire/core/Page.php#L88-L107

Maybe it needs to be reimagined, but that was my initial goal for this. What does everyone think?

Oh. I also thought it would list all available permissions. 

 

31 minutes ago, adrian said:

I'll need to think about this some more - I feel like we are starting to get into the territory of this module: http://modules.processwire.com/modules/process-access-overview/ which is not really the goal here, or at least it wasn't.

Didn't know about that one. You are absolutely right. Anyhow, it was just an idea. Personally I don't have a need at all for such a panel, but I'm quite sure it can be very handy to have one day...

  • Like 1

Share this post


Link to post
Share on other sites
8 minutes ago, gmclelland said:

As for the colors: maybe a light green background with a dark green check mark and light red/pink background with a dark red "X" ?

I strongly vote against using the red color at all. IMHO having "no access" colored red is wrong, if you want the role not to have access! So it would be indicating a problem where everything is actually fine.

  • Like 1

Share this post


Link to post
Share on other sites
7 minutes ago, bernhard said:
17 minutes ago, gmclelland said:

 

I strongly vote against using the red color at all. IMHO having "no access" colored red is wrong, if you want the role not to have access! So it would be indicating a problem where everything is actually fine.

I think this is a good point. Maybe it really is just cross vs tick and no background colors at all?

 

11 minutes ago, bernhard said:

Oh. I also thought it would list all available permissions. 

This panel is just page permissions for the currently viewed / edited page. I don't want to get into a roles/permissions matrix. I think this is why it probably does belong as a section in the RequestInfo panel. It's not meant to be a big "all knowing" overview of permissions and roles.

Share this post


Link to post
Share on other sites
2 minutes ago, adrian said:

Maybe it really is just cross vs tick and no background colors at all?

I think it's good to have some color. What about the colors of the console - active = white, inactive = light blue:

mWqULxX.png

3 minutes ago, adrian said:

This panel is just page permissions for the currently viewed / edited page. I don't want to get into a roles/permissions matrix. I think this is why it probably does belong as a section in the RequestInfo panel. It's not meant to be a big "all knowing" overview of permissions and roles.

Understand. Thx 🙂 

  • Like 1

Share this post


Link to post
Share on other sites

Ok, I have added this functionality to the RequestInfo panel like I suggested. This keeps things simple and always available. I got rid of all the background coloring - it's really not needed and I prefer the striped rows for clarity of info for each row. 

Current user is on the first row (and bolded to stand out) so if you're using the User Switcher panel you can quickly get all the details for that current user.

I have a few other things in the works, but will commit this shortly.

image.thumb.png.78ef5ca7cde0fc018c53bfd155181633.png

  • Like 2

Share this post


Link to post
Share on other sites

I liked the previous colored version where it was more obvious who can or cannot do what. I would perhaps try making the X icons 50% transparent or so to separate things better (or remove entirely?).

Another idea is that on clicking on the table would toggle the icons visibility, so eg it would load with no X icons but on click they would appear and the check icons would disappear. Or perhaps just use hover for inverting the icons' visibility so no need to use js?

How about removing the -able endings in the column headers to make it more compact? You can add the original text as a title attribute to keep them too. 

  • Like 2

Share this post


Link to post
Share on other sites
1 minute ago, tpr said:

I liked the previous colored version where it was more obvious who can or cannot do what. I would perhaps try making the X icons 50% transparent or so to separate things better (or remove entirely?).

Another idea is that on clicking on the table would toggle the icons visibility, so eg it would load with no X icons but on click they would appear and the check icons would disappear. Or perhaps just use hover for inverting the icons' visibility so no need to use js?

You know you've just signed up to add your magic to this don't you 🙂 

PM on the way if you are actually interested in giving it a go.

Share this post


Link to post
Share on other sites

Ok but let me know which version you (including others) would prefer, if any.

Share this post


Link to post
Share on other sites
12 minutes ago, tpr said:

Ok but let me know which version you (including others) would prefer, if any.

Honestly I don't know. I am actually pretty happy with the clean and simple I have now. I don't actually see using this for trying to get an overview of who can do what, but rather as a way to check that a certain user or role can do what I want them to be able to do. Given this, I actually think the striped rows is the most important visual distinction - find the role you're interested in and follow it across.

But you're right, let's see what others think before we do anything. I might actually just commit things shortly and those interested can test and can provide better feedback.

Share this post


Link to post
Share on other sites

I vote for striped rows, no red, no green, just set the X to invisible or light grey.

Checkmark means access, empty cell means no access. No warning colour but still easy to distinguish (better than without any colouring).

@adrian why don't you create a temporary branch for such updates? We could then play around and give feedback or prs. Why sending zip files around?

Share this post


Link to post
Share on other sites
21 minutes ago, bernhard said:

Checkmark means access, empty cell means no access. No warning colour but still easy to distinguish (better than without any colouring).

Yeah, I actually think that is probably cleanest - thanks!

image.png.b63a3cf93f0d6289ba01699041eb4979.png

22 minutes ago, bernhard said:

why don't you create a temporary branch for such updates? We could then play around and give feedback or prs. Why sending zip files around?

Maybe I should - I have on occasion, but maybe I should more often!

  • Thanks 1

Share this post


Link to post
Share on other sites
3 hours ago, tpr said:

How about removing the -able endings in the column headers to make it more compact? You can add the original text as a title attribute to keep them too.

@adrian I added this line to my previous post by editing it so you may have missed it. I think the shorter column headers would be just as informative as the longer.

Share this post


Link to post
Share on other sites
8 minutes ago, tpr said:

How about removing the -able endings in the column headers to make it more compact? You can add the original text as a title attribute to keep them too.

Sure - don't think I'll bother with the title attribute here though - it should be obvious enough. I also changed the order so the more important/relevant ones are on the left, although I am not really sure where "list" belongs ?

image.png.22522999f1daeb4c5b77af7925a0a81d.png

  • Like 3

Share this post


Link to post
Share on other sites
22 hours ago, adrian said:
On 10/2/2018 at 9:15 PM, bernhard said:

Are you talking about a link to the docs or about shortcut links to the settings page of the template where the admin can adjust those permissions? The latter would be great! Maybe there could also be a section where it shows which template setting is responsible, eg:



path             | template     | active
-----------------|--------------|--------------------------------
/                | home         | yes
/foo             | basic-page   | yes
/foo/bar         | whatsoever   | no (inherited from basic-page)

The template strings could be linked to the access tab of the template settings.

I'll need to think about this some more - I feel like we are starting to get into the territory of this module: http://modules.processwire.com/modules/process-access-overview/ which is not really the goal here, or at least it wasn't. I'll let you guys chime back in on what you think would actually be most useful.

@LostKobrakai might not want to take his module any further, he also writes:

Quote

...I haven't used it in a while. But I haven't added the 3.0 flag for a purpose, because the module was build before the ability to assign additional permissions on a per template level was added. I'm not sure if the module does take those into account properly.

Also, your Tracy Debugger module is an all-in-one Swiss Army Knife module to support development in general, so this feature would also be welcome.

Edited by szabesz
typo
  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, adrian said:

although I am not really sure where "list" belongs ?

Thanks, I think it's fine now (means I'm outta ideas :))

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, adrian said:
2 hours ago, bernhard said:

Checkmark means access, empty cell means no access. No warning colour but still easy to distinguish (better than without any colouring).

Yeah, I actually think that is probably cleanest - thanks!

image.png.b63a3cf93f0d6289ba01699041eb4979.png

awesome! thx 🙂 

5 minutes ago, szabesz said:

@LostKobrakai might not want to take his module any further, ha also writes:

Quote

...I haven't used it in a while. But I haven't added the 3.0 flag for a purpose, because the module was build before the ability to assign additional permissions on a per template level was added. I'm not sure if the module does take those into account properly.

Also, your Tracy Debugger module is an all-in-one Swiss Army Knife module to support development in general, so this feature would also be welcome.

While I agree that it would be welcome I have to say that I haven't had a need for this module yet and will probably not have in the near future. I agree that it makes sense to integrate some modules into tracy, but I don't think it's a good idea to leave adrian alone with that effort. Even though he seems to be similar to ryan from a productivity point of view (do those two ever sleep? 😮😄 ).

I've done a little contribution once (field code) and it was not that hard. But maybe @adrian you could write up a little tutorial to show us how we can contribute to tracy. How everything plays together, what helpers are there, what css classes you use in general (or how we can inspect all that). Something like a quickstart of tracy extension building. Maybe this could make tracy more of a teamwork than an (absolutely awesome) one-man-show?

Maybe tracy could even be built a little differently to support 3rd party modules. Just like you did recently with the admin actions module (https://processwire.com/talk/topic/14921-admin-actions/?do=findComment&comment=173496). I'm not requesting this, I'm just thinking out loud here.

 

2 hours ago, adrian said:
2 hours ago, bernhard said:

why don't you create a temporary branch for such updates? We could then play around and give feedback or prs. Why sending zip files around?

Maybe I should - I have on occasion, but maybe I should more often!

It would then also make sense to streamline the way of collaboration and have a standard workflow centralized on git.

  • Like 1

Share this post


Link to post
Share on other sites
20 hours ago, bernhard said:

I strongly vote against using the red color at all. IMHO having "no access" colored red is wrong, if you want the role not to have access! So it would be indicating a problem where everything is actually fine

My vote would be not to colour the cells at all, or use a really light difference between the two because, as Bernhard already pointed out, there is no correct answer here - sometimes you want a role to have a permission - in which case the "tick" mark is correct - and sometimes you don't, in which case the "cross" is correct.

@adrian there is a "Note" colour from the diagnostics panel that might work as a possibility here.

Edited to add: just read the updates on empty cells for no-access. Even better!

  • Like 1

Share this post


Link to post
Share on other sites
10 hours ago, bernhard said:

But maybe @adrian you could write up a little tutorial to show us how we can contribute to tracy. How everything plays together, what helpers are there, what css classes you use in general (or how we can inspect all that). Something like a quickstart of tracy extension building. Maybe this could make tracy more of a teamwork than an (absolutely awesome) one-man-show?

I'd love some help 🙂

If people have ideas for other panels that would be brilliant. It's really very simple to get a panel working and what you do with it is up to you.

Maybe I'll add this to the docs site (https://adrianbj.github.io/TracyDebugger/#/) at some point, or maybe someone could do that for me, but here are the really quick basics.

  • Create a new file under the panels subdirectory named to match the name of your new panel, eg: MyNewPanel.php
  • In that file have a class MyNewPanel that extends BasePanel, eg:
class MyNewPanel extends BasePanel {
  • Add getTab() method
    • optional isAdditionalBar() method to check if the current call to the panel is from an AJAX or Redirect debug bar. Some panels are not relevant for these bars, so you can check that and return if you wish.
    • timer() method to check how long it takes to generate this panel.
    • return a span with title tag (for mouseover of the panel icon in the debug bar) with the SVG for the icon and a label. It's up to you to assign the SVG to that $this->icon variable.
    public function getTab() {
        if(\TracyDebugger::isAdditionalBar()) {
            return;
        }

        \Tracy\Debugger::timer('myNew');

        return '
        <span title="My Panel">
            ' . $this->icon . (\TracyDebugger::getDataValue('showPanelLabels') ? ' My Panel' : '') . '
        </span>';

    }
  • Add getPanel() method
    • if this panel does work with additional bars, then check for this and add the name of the bar in parentheses in the <h1> title
    • output should all be contained in a tracy-inner div
    • use generatePanelFooter to create the ms/kb values in the footer of the panel. The last parameter (optional) is for a hash link to the docs website
    • return - parent::loadResources() actually currently returns nothing but it's in the BasePanel class and may be used again at some point, so should be included in the return. The minify() method is not mandatory but I use it in some panels with a lot of embedded JS / HTML. Note that it's very rudimentary and currently is broken by inline comments in $out so be careful.
public function getPanel() {

    $isAdditionalBar = \TracyDebugger::isAdditionalBar();
    $out = '
    <h1>
        <a title="My New">
                ' . $this->icon . ' My New
        </a>' . ($isAdditionalBar ? ' ('.$isAdditionalBar.')' : '') . '
    </h1>

    $out = '<div class="tracy-inner">';
    $out .= 'whatever you want output in the panel';
    $out .= \TracyDebugger::generatePanelFooter('myNew', \Tracy\Debugger::timer('myNew'), strlen($out), 'myNew');
    $out .= '</div>';
    return parent::loadResources() . \TracyDebugger::minify($out);
}

 

You have access to these color constants from the main \TracyDebugger class:

    const COLOR_LIGHTGREY = '#999999';
    const COLOR_GREEN = '#009900';
    const COLOR_NORMAL = '#354B60';
    const COLOR_WARN = '#ff8309';
    const COLOR_ALERT = '#cd1818';

 

You can access module config settings with: 

\TracyDebugger::getDataValue('settingName');

Once the panel is built, you can add it to Tracy here:

https://github.com/adrianbj/TracyDebugger/blob/dd617b8ca8f450b8891ecacaef2b3949698fc126/TracyDebugger.module#L139-L169

That's a very rough first draft of what needs to happen. 

I think the best place to start is probably the MethodsInfoPanel.php file because it's so simple.

This process has reminded me of just how messy some things are 🙂

 

  • Like 3

Share this post


Link to post
Share on other sites
11 minutes ago, adrian said:

SORRY - rest coming soon!!!

Cat bite? 😱😜😁

  • Like 1

Share this post


Link to post
Share on other sites
23 minutes ago, bernhard said:

Cat bite? 😱😜😁

Haha - no, errant keyboard shortcut saved the post 🙂

It's been "completed" now, although it really needs some work and should be moved to the docs site as I mentioned.

  • Like 1

Share this post


Link to post
Share on other sites
11 hours ago, szabesz said:

Also, your Tracy Debugger module is an all-in-one Swiss Army Knife module to support development in general, so this feature would also be welcome.

I would certainly welcome this functionality in Tracy, but I am not super excited on building this at the moment, but if you're feeling motivated, I am sure with the code from LK's module and the quick guide I just put together you should have a decent starting point. Of course it will need to be updated to support the new access functionality that Ryan added fairly recently.

  • Like 2

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By MoritzLost
      This is a new module that provides a simple solution to clearing all your cache layers at once, and an extensible interface to perform various cache-related actions.
      The simple motivation behind this module was that I was tired of manually clearing caches in several places after deploying a change on a live site. The basic purpose of this module is a simple Clear all caches link in the Setup menu which clears out all caches, no matter where they hide. You can customize what exactly the module does through it's configuration menu:
      Expire or delete all cache entries in the database, or selectively clear caches by namespace ($cache API) Clear the the template render cache. Clear out specific folders inside your site's cache directory (/site/assets/cache) Refresh version strings for static assets to bust client-side browser caches (this requires some setup, see the full documentation for details). This is the basic function of the module. However, you can also add different cache management action through the API and execute them through the module's interface. For this advanced usage, the module provides:
      An interface to see all available cache actions and execute them. A system log and logging output on the module page to see verify what the module is doing. A CacheControlTools class with utility functions to clear out different caches. An API to add cache actions, execute them programmatically and even modify the default action. Permission management, allowing you granular control over which user roles can execute which actions. The complete documentation can be found in the module's README.
      Beta release
      Note that I consider this a Beta release. Since the module is relatively aggressive in deleting some caches, I would advise you to install in on a test environment before using it on a live site.
      Let me know if you're getting any errors, have trouble using the module or if you have suggestions for improvement!
      In particular, can someone let me know if this module causes any problems with the ProCache module? I don't own or use it, so I can't check. As far as I can tell, ProCache uses a folder inside the cache directory to cache static pages, so my module should be able to clear the ProCache site cache as well, I'd appreciate it if someone can test that for me.
      Future plans
      If there is some interest in this, I plan to expand this to a more general cache management solution. I particular, I would like to add additional cache actions. Some ideas that came to mind:
      Warming up the template render cache for publicly accessible pages. Removing all active user sessions. Let me know if you have more suggestions!
      Links
      https://github.com/MoritzLost/ProcessCacheControl ProcessCacheControl in the Module directory

    • By joshua
      This module is (yet another) way for implementing a cookie management solution.
      Of course there are several other possibilities:
      - https://processwire.com/talk/topic/22920-klaro-cookie-consent-manager/
      - https://github.com/webmanufaktur/CookieManagementBanner
      - https://github.com/johannesdachsel/cookiemonster
      - https://www.oiljs.org/
      - ... and so on ...
      In this module you can configure which kind of cookie categories you want to manage:

      You can also enable the support for respecting the Do-Not-Track (DNT) header to don't annoy users, who already decided for all their browsing experience.
      Currently there are four possible cookie groups:
      - Necessary (always enabled)
      - Statistics
      - Marketing
      - External Media
      All groups can be renamed, so feel free to use other cookie group names. I just haven't found a way to implement a "repeater like" field as configurable module field ...
      When you want to load specific scripts ( like Google Analytics, Google Maps, ...) only after the user's content to this specific category of cookies, just use the following script syntax:
      <script type="optin" data-type="text/javascript" data-category="statistics" data-src="/path/to/your/statistic/script.js"></script> <script type="optin" data-type="text/javascript" data-category="marketing" data-src="/path/to/your/mareketing/script.js"></script> <script type="optin" data-type="text/javascript" data-category="external_media" data-src="/path/to/your/external-media/script.js"></script> <script type="optin" data-type="text/javascript" data-category="marketing">console.log("Inline scripts are also working!");</script> The type has to be "optin" to get recognized by PrivacyWire, the data-attributes are giving hints, how the script shall be loaded, if the data-category is within the cookie consents of the user. These scripts are loaded asynchronously after the user made the decision.
      If you want to give the users the possibility to change their consent, you can use the following Textformatter:
      [[privacywire-choose-cookies]] It's planned to add also other Textformatters to opt-out of specific cookie groups or delete the whole consent cookie.
      You can also add a custom link to output the banner again with a link / button with following class:
      <a href="#" class="privacywire-show-options">Show Cookie Options</a> <button class="privacywire-show-options">Show Cookie Options</button> This module is still in development, but we already use it on several production websites.
      You find it here: https://github.com/blaueQuelle/privacywire/tree/master
      Download: https://github.com/blaueQuelle/privacywire/archive/master.zip
      I would love to hear your feedback 🙂
      Edit: Updated URLs to master tree of git repo
       
    • By David Karich
      Admin Page Tree Multiple Sorting
      ClassName: ProcessPageListMultipleSorting
      Extend the ordinary sort of children of a template in the admin page tree with multiple properties. For each template, you can define your own rule. Write each template (template-name) in a row, followed by a colon and then the additional field names for sorting.
      Example: All children of the template "blog" to be sorted in descending order according to the date of creation, then descending by modification date, and then by title. Type:
      blog: -created, -modified, title  Installation
      Copy the files for this module to /site/modules/ProcessPageListMultipleSorting/ In admin: Modules > Check for new modules. Install Module "Admin Page Tree Multible Sorting". Alternative in ProcessWire 2.4+
      Login to ProcessWire backend and go to Modules Click tab "New" and enter Module Class Name: "ProcessPageListMultipleSorting" Click "Download and Install"   Compatibility   I have currently tested the module only under PW 2.6+, but think that it works on older versions too. Maybe someone can give a feedback.     Download   PW-Repo: http://modules.processwire.com/modules/process-page-list-multiple-sorting/ GitHub: https://github.com/FlipZoomMedia/Processwire-ProcessPageListMultipleSorting     I hope someone can use the module. Have fun and best regards, David
    • By dimitrios
      Hello,
      this module can publish content of a Processwire page on a Facebook page, triggered by saving the Processwire page.
      To set it up, configure the module with a Facebook app ID, secret and a Page ID. Following is additional configuration on Facebook for developers:
      Minimum Required Facebook App configuration:
      on Settings -> Basics, provide the App Domains, provide the Site URL, on Settings -> Advanced, set the API version (has been tested up to v3.3), add Product: Facebook Login, on Facebook Login -> Settings, set Client OAuth Login: Yes, set Web OAuth Login: Yes, set Enforce HTTPS: Yes, add "https://www.example.com/processwire/page/" to field Valid OAuth Redirect URIs. This module is configurable as follows:
      Templates: posts can take place only for pages with the defined templates. On/Off switch: specify a checkbox field that will not allow the post if checked. Specify a message and/or an image for the post.
      Usage
      edit the desired PW page and save; it will post right after the initial Facebook log in and permission granting. After that, an access token is kept.
       
      Download
      PW module directory: http://modules.processwire.com/modules/auto-fb-post/ Github: https://github.com/kastrind/AutoFbPost   Note: Facebook SDK for PHP is utilized.


×
×
  • Create New...