Jump to content
adrian

Tracy Debugger

Recommended Posts

Hey @szabesz - a modules refresh and/or Tracy settings save will fix that. I converted one of the settings from a string to an array. I probably should have handled it better, but that's all you need to do.

  • Like 1

Share this post


Link to post
Share on other sites

Thanx for the help! Module refresh did not help but saving settings did.

 

  • Like 1

Share this post


Link to post
Share on other sites

Good day everybody!

When I think about TracyDebugger, I always think about the invaluable functionality of this must-have module. But yesterday I had a new impression about TracyDebugger - its super appealing design (in places). I was installing Tracy on a new site and was astonished by the new look of a "Donate" button in the module config. It is super simple and probably even a standard PayPal button, but it's placement and a color contrast just struck me.

I could not resist, clicked the button and made a $10000 donation. This is by far less than the value this module gives me, so wanted to give something back (and the magic button did its job, of course). But must be something with PayPal in Russia that it only let $5 of my donation pass though 😀.

So I suggest everybody go look at this button in the TracyConfig to learn some useful marketing tricks. And if you happen to be somewhere outside Russia please click on it and try to make a more than $5 donation to check, if the same limits apply in your country. So we can report to PayPal or something)))

  • Like 4

Share this post


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

only let $5 of my donation pass though

I can tell you how to transfer me the $9995 you could not get rid of, just PM me 😄

  • Like 2
  • Haha 1

Share this post


Link to post
Share on other sites

Hi everyone,

Just released v4.18 this morning which comes with the new Tracy core v2.6

I have managed to retain PHP 5.4.4+ support for now. If you are running PHP 7.1+ you will get the new Tracy core, otherwise you'll be using the old 2.5 branch. I decided not to ditch < 7.1 just yet because Debian stable still ships with 7.0.

Here's the list of changes:

1) New multiple AJAX debug bars

This allows you to see more than one consecutive AJAX call. There is a new module setting that controls the number of AJAX bars (default 3). Adjust this if you need, but keep in mind that you don't want lots of bars stacking up as you navigate around the PW admin where opening menu items / pages are all AJAX calls.

This new feature also means that the AJAX dumps panel no longer needs to store consecutive dumps, but if you still want that, then the Dumps Recorder panel will do that.

image.png.2360bdc05da937d7546ad872a808162b.png

 

2) BarDump (bd) and barDumpBig (bdb) calls now use LIVE

This feature was always not quite right in the Tracy core, but it has been rebuilt and is now the default for these calls. This makes the dumping of large / multiple objects 10x faster. It also means that we can probably increase the default maxDepth setting and increase the value for the barDumpBig even further. I haven't made these changes yet, but I am going to start testing here and see how it goes.

This means that there is no longer a need for the barDumpLive (bdl) method, so this has been removed.

3) Lots of other minor/rare bug fixes and improvements

Nothing worth mentioning specifically, but definitely worth having 🙂

There will likely be more improvements to these new core features coming pretty soon, so I'll make sure we stay up to date with those also.

Let me know if you notice any problems.

Cheers!

 

  • Like 7
  • Thanks 2

Share this post


Link to post
Share on other sites

Several more Tracy core updates just committed that improve live dump performance among other things.

I have also changed the default editor protocol handler from Sublime Text to VSCode - I feel like this will be a more useful default as it seems VSCode is gaining lots of users around here.

 

  • Like 2
  • Thanks 1

Share this post


Link to post
Share on other sites
5 hours ago, adrian said:

have also changed the default editor protocol handler from Sublime Text to VSCode - I feel like this will be a more useful default as it seems VSCode is gaining lots of users around here.

Hooray! Any tip how to set this up for a linux box? Ta!

Share this post


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

I'll have a look, cheers!

Btw, for some reason I still thought Tracy does not support debugging in a modal?! I only noticed the setting yesterday when we were trying to help @JoshoB with the asmSelect problem! How this could have helped me recently, with VPS (lots of modal interaction)! I feel foolish 🙃. Thanks for Tracy again, @adrian!

 

  • Like 1

Share this post


Link to post
Share on other sites
30 minutes ago, kongondo said:

Btw, for some reason I still thought Tracy does not support debugging in a modal?

Sorry, perhaps those should not be disabled by default - generally I find it a bit obtrusive having the debug bar on in a modal and in general we are talking about the PW admin for these, so usually you don't need to debug them. Occasionally I enable them for a particular need.

  • Like 2

Share this post


Link to post
Share on other sites

Adrian, I can't maximize the console panel, I see this error in Chrome console:

Uncaught ReferenceError: tracyPanel is not defined
    at tracyResizePanel (?_tracy_bar=js&v=2.6.1&XDEBUG_SESSION_STOP=1:1130)
    at HTMLAnchorElement.onclick (?id=1015&s=1&c=1:1744)

Not sure when this started...

 

 

  • Like 1

Share this post


Link to post
Share on other sites
2 hours ago, matjazp said:

Adrian, I can't maximize the console panel, I see this error in Chrome console:

Thanks for the report - looks like the new Tracy core is forcing strict rules in JS which is affecting some sloppiness in my code. I have fixed this one, but I think we'll need to lookout for issues like this.

 

  • Like 1

Share this post


Link to post
Share on other sites

Hi,

I think this is a newbie question but I am trying to use Tracy Debugger to debug code on the a field in the Template context but gives me the error:

- "Fatal error: Uncaught Error: Call to undefined function ProcessWire\barDump()"

I tried to use:

TD::barDump('test');

and

$TD = $this->modules->get('TracyDebugger');
$TD::barDump('test');

but also gives an error.

How can I call the barDump() on a field in the template context ?

Many thanks

Share this post


Link to post
Share on other sites

Hi @bluellyr - in general you should use the shortcut methods: bd(), d(), l(), fl(), etc but if for some reason you don't want to, try: \TD::barDump('test');

The reason you need the backslash is because your template files have the ProcessWire namespace so you need to get to the global namespace to access the TD class.

Share this post


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

Hi @bluellyr - in general you should use the shortcut methods: bd(), d(), l(), fl(), etc but if for some reason you don't want to, try: \TD::barDump('test');

The reason you need the backslash is because your template files have the ProcessWire namespace so you need to get to the global namespace to access the TD class.

 

Hi,

even using: \TD::barDump('test'); or  bd(), d(), l(), fl(), when trying to debug a field on the template context I always get the following error, in this case I was trying to use \TD::barDump('test');

I think that is because the module Tracy Debugger is not loaded when editing a field on the template context, can this be the case?

Thank you

Screenshot 2019-03-05 at 13.30.43.png

Share this post


Link to post
Share on other sites

Sorry @bluellyr - my apologies - I didn't initially realize what you meant by "template context". Using Tracy to debug the PW core is hit and miss. It loads before all site modules, but for the core and core modules it often isn't available depending on exactly what you are trying to debug. Unfortunately there isn't anything I can do about this. Typically for this, using $log->save('testing', json_encode($page)); or something like that is your best bet.

  • Like 1

Share this post


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

Sorry @bluellyr - my apologies - I didn't initially realize what you meant by "template context". Using Tracy to debug the PW core is hit and miss. It loads before all site modules, but for the core and core modules it often isn't available depending on exactly what you are trying to debug. Unfortunately there isn't anything I can do about this. Typically for this, using $log->save('testing', json_encode($page)); or something like that is your best bet.

Thank you, for the explanation and for the alternative.

All the best

  • Like 1

Share this post


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

Using Tracy to debug the PW core is hit and miss. It loads before all site modules, but for the core and core modules it often isn't available depending on exactly what you are trying to debug.

It often happens to me too. I know Ryan made some adjustments in the core so that Tracy is loaded earlier (if I remember correctly), but is there really nothing that could be done in that regard? Could we have some sort of bd() function always available? Independent of the modules load order? Something that we put in init.php, even index.php? Yes, I do use $log methods, but Tracy is very handsome and good looking 🙂 

  • Like 1

Share this post


Link to post
Share on other sites
16 minutes ago, matjazp said:

It often happens to me too. I know Ryan made some adjustments in the core so that Tracy is loaded earlier (if I remember correctly), but is there really nothing that could be done in that regard? Could we have some sort of bd() function always available? Independent of the modules load order? Something that we put in init.php, even index.php? Yes, I do use $log methods, but Tracy is very handsome and good looking 🙂 

The changes Ryan made were to ensure that Tracy is always the first "site" module loaded. This means you can always debug other site modules. Getting Tracy to load earlier is problematic. init.php won't help - it already loads on init. 

I would like to be able to load Tracy earlier, but I don't see Ryan being keen on doing what is required to make that happen. You have got me thinking though about figuring out how we might be able to at least get bd() working earlier - this wouldn't include all of Tracy's other error capturing / reporting abilities, but I think it would still be helpful. 

I'll have a think about it.

  • Like 1

Share this post


Link to post
Share on other sites

@bluellyr, your screenshot shows a modal. Make sure you do not have the Tracy debug bar disabled for modals in the module config:

2019-03-06_092156.png.51b016961f3e7402a20b1f568d2ddfc2.png

@adrian, I wonder if it would be better to not have Tracy disabled for modals by default, and people can disable it if they are finding the debug bar annoying. And perhaps spell it out that no debug bar = errors if you try and use a dump method.

  • Like 2

Share this post


Link to post
Share on other sites

@Robin S - actually, I think you might be correct in this case. That was my initial thought, but some recent changes I made to Tracy should have actually prevented that error, so it threw me off. So I think it might be a combination of an older version of Tracy and the disabled in modal option.

I agree that the defaults should be for Tracy to be on in all those modals/panels/iframes - I have made this change in the latest version.

  • Like 3

Share this post


Link to post
Share on other sites

@bluellyr - could please let me know what version of Tracy you are running? Those errors should not have appeared on recent versions even with the modals disabled.

Share this post


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

@bluellyr - could please let me know what version of Tracy you are running? Those errors should not have appeared on recent versions even with the modals disabled.

Hi, I am using the Tracy Debugger 4.17.18.

Regarding the @Robin S remark about the having the "Tracy debug bar disabled for modals", I had the Tracy Debug disable for modals, can this be the cause of the error?

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By Robin S
      A community member raised a question and I thought a new sanitizer method for the purpose would be useful, hence...
      Sanitizer Transliterate
      Adds a transliterate method to $sanitizer that performs character replacements as defined in the module config. The default character replacements are based on the defaults from InputfieldPageName, but with uppercase characters included too.
      Usage
      Install the Sanitizer Transliterate module.
      Customise the character replacements in the module config as needed.
      Use the sanitizer on strings like so:
      $transliterated_string = $sanitizer->transliterate($string);
       
      https://github.com/Toutouwai/SanitizerTransliterate
      https://modules.processwire.com/modules/sanitizer-transliterate/
       
    • 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 to 2.10, add Product: Facebook Login, on Facebook Login -> Settings, set Client OAuth Login: Yes, set Web OAuth Login: Yes, set Enforce HTTPS: Yes, add "http://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.


    • By thomasaull
      I created a little helper module to trigger a CI pipeline when your website has been changed. It's quite simple and works like this: As soon as you save a page the module sets a Boolean via a pages save after hook. Once a day via LazyCron the module checks if the Boolean is set and sends a POST Request to a configurable Webhook URL.
      Some ideas to extend this:
      make request type configurable (GET, POST) make the module trigger at a specified time (probably only possible with a server cronjob) trigger manually Anything else? If there's interest, I might put in some more functionality. Let me know what you're interested in. Until then, maybe it is useful for a couple of people 🙂
      Github Repo: https://github.com/thomasaull/CiTrigger
    • By Robin S
      I created this module a while ago and never got around to publicising it, but it has been outed in the latest PW Weekly so here goes the support thread...
      Unique Image Variations
      Ensures that all ImageSizer options and focus settings affect image variation filenames.

      Background
      When using methods that produce image variations such as Pageimage::size(), ProcessWire includes some of the ImageSizer settings (height, width, cropping location, etc) in the variation filename. This is useful so that if you change these settings in your size() call a new variation is generated and you see this variation on the front-end.
      However, ProcessWire does not include several of the other ImageSizer settings in the variation filename:
      upscaling cropping, when set to false or a blank string interlace sharpening quality hidpi quality focus (whether any saved focus area for an image should affect cropping) focus data (the top/left/zoom data for the focus area) This means that if you change any of these settings, either in $config->imageSizerOptions or in an $options array passed to a method like size(), and you already have variations at the requested size/crop, then ProcessWire will not create new variations and will continue to serve the old variations. In other words you won't see the effect of your changed ImageSizer options on the front-end until you delete the old variations.
      Features
      The Unique Image Variations module ensures that any changes to ImageSizer options and any changes to the focus area made in Page Edit are reflected in the variation filename, so new variations will always be generated and displayed on the front-end.
      Installation
      Install the Unique Image Variations module.
      In the module config, set the ImageSizer options that you want to include in image variation filenames.
      Warnings
      Installing the module (and keeping one or more of the options selected in the module config) will cause all existing image variations to be regenerated the next time they are requested. If you have an existing website with a large number of images you may not want the performance impact of that. The module is perhaps best suited to new sites where image variations have not yet been generated.
      Similarly, if you change the module config settings on an existing site then all image variations will be regenerated the next time they are requested.
      If you think you might want to change an ImageSizer option in the future (I'm thinking here primarily of options such as interlace that are typically set in $config->imageSizerOptions) and would not want that change to cause existing image variations to be regenerated then best to not include that option in the module config after you first install the module.
       
      https://github.com/Toutouwai/UniqueImageVariations
      https://modules.processwire.com/modules/unique-image-variations/
    • By Sebi
      I've created a small module which lets you define a timestamp after which a page should be accessible. In addition you can define a timestamp when the release should end and the page should not be accessable any more.
      ProcessWire-Module: http://modules.processwire.com/modules/page-access-releasetime/
      Github: https://github.com/Sebiworld/PageAccessReleasetime
      Usage
      PageAccessReleasetime can be installed like every other module in ProcessWire. Check the following guide for detailed information: How-To Install or Uninstall Modules
      After that, you will find checkboxes for activating the releasetime-fields at the settings-tab of each page. You don't need to add the fields to your templates manually.
      Check e.g. the checkbox "Activate Releasetime from?" and fill in a date in the future. The page will not be accessable for your users until the given date is reached.
      If you have $config->pagefileSecure = true, the module will protect files of unreleased pages as well.
      How it works
      This module hooks into Page::viewable to prevent users to access unreleased pages:
      public function hookPageViewable($event) { $page = $event->object; $viewable = $event->return; if($viewable){ // If the page would be viewable, additionally check Releasetime and User-Permission $viewable = $this->canUserSee($page); } $event->return = $viewable; } To prevent access to the files of unreleased pages, we hook into Page::isPublic and ProcessPageView::sendFile.
      public function hookPageIsPublic($e) { $page = $e->object; if($e->return && $this->isReleaseTimeSet($page)) { $e->return = false; } } The site/assets/files/ directory of pages, which isPublic() returns false, will get a '-' as prefix. This indicates ProcessWire (with activated $config->pagefileSecure) to check the file's permissions via PHP before delivering it to the client.
      The check wether a not-public file should be accessable happens in ProcessPageView::sendFile. We throw an 404 Exception if the current user must not see the file.
      public function hookProcessPageViewSendFile($e) { $page = $e->arguments[0]; if(!$this->canUserSee($page)) { throw new Wire404Exception('File not found'); } } Additionally we hook into ProcessPageEdit::buildForm to add the PageAccessReleasetime fields to each page and move them to the settings tab.
      Limitations
      In the current version, releasetime-protected pages will appear in wire('pages')->find() queries. If you want to display a list of pages, where pages could be releasetime-protected, you should double-check with $page->viewable() wether the page can be accessed. $page->viewable() returns false, if the page is not released yet.
      If you have an idea how unreleased pages can be filtered out of ProcessWire selector queries, feel free to write an issue, comment or make a pull request!
×
×
  • Create New...