adrian

I'm honestly not sure how I feel about this, but that's another story :) The feature that you're asking for probably belongs in the Tracy core, so it might be best to request it over here: https://github.com/nette/tracy/issues That said, I have hacked together something (fairly quickly, but definitely not 5 minutes). Try the attached - currently only works for direct loading of frontend pages - ie it doesn't work in the admin or via AJAX. The errors panel gets recolored if the only errors in it are deprecations. Sorry, I don't have anymore time to spend on this at the moment, especially given that I think it belongs in the Tracy core. TracyDebugger.module.php

@2hoch11 - please try the latest commit - it should work now even if there is no CkEditor field on the template.

I just tested and it's working fine here. Can you take a look at the browser dev console to see if there are any JS errors?

@2hoch11 - is this what you're looking for? https://github.com/adrianbj/processwire-fieldtype-assisted-url

Hi @d'Hinnisdaël - I wonder if you'd be willing to support loading a tab directly from the hash in the URL please? Thanks for considering.

Give the latest version a go. There was one other place that needed the isLocal check removed.

@bernhard - I'm with @teppo - it works for me - that bd() call you added correctly returns the path set via: $config->tracy = [ 'localRootPath' => '/path/to' ]; so I think there is something else that must be awry at your end. As he asked, are other settings defined that way working as expected?

In that case, can't you simply append to (or replace) $config->tracy in this local config file? If that works for you, I think all I need to do is to remove the isLocal() check that currently prevents this working unless on a live server. Does that sound correct?

Sorry, I must admit I read in a rush this morning and assumed your example was an option, but just noticed you're saying that it's not an option. I have always worked solo (although that is about to change), so I will defer to you both to let me know how you'd like this set up - I am happy to implement whatever you suggest on this.

Maybe we need a way for all of Tracy's setting (via the $config->tracy option) to be user specific? Would it makes sense to have something like: $config->tracy = [ 41 => [ 'outputMode' => 'development', 'guestForceDevelopmentLocal' => true, 'forceIsLocal' => true, 'localRootPath' => '/xxxx/path/to/' ], 1276 => [ 'outputMode' => 'development', 'localRootPath' => '/yyyy/path/to/' ] ]; where the top level keys are the user IDs? Although of course that doesn't work if you're not logged in. How do you suggest we handle that? I separate config file outside the root of the site so it's not part of the version control of the repo?

HI @bernhard and @teppo - The local root path was designed as a way to override the path to the remote server so that you could open the file locally even though you clicked from a remote server. I am certainly happy to add user specific paths for these if it helps. Let me know what you think the best approach would be. Can we go with: userid: path pairs on separates lines in a textarea? What about covering @teppo's point about when you're not logged in?

It's not nonsense, but SVGs don't need to have width / height attributes. It's perfectly acceptable for these to be missing, but it can result in some display issues depending on how they are output. I don't think PW should automatically add these (at least without it being optional), but on some sites I do this via a hook because I do want to ensure those attributes are set. If they're not set, I get them from the viewbox and add them - similarly to the way @snck is showing above.

Hi @snck - nice work. I really do think this should be incorporated into the core, although I am a bit confused by the calculation method you have for getting the width / height. I feel like the width and height should be take directly from [2] and [3]. Even if the min_x or min_y aren't set to 0, surely that doesn't change the width of the canvas area that the illustration is on which is what we want the width / height of. Do you agree, or am I missing something? We need to get Ryan's attention on this - maybe a Github issue?

Interesting that it didn't work straight away. If you find similar issues again, please let me know - maybe I've overlooked something?

Ok, please give the latest version a go. It should be much better in that you now get notification of new entries no matter when they happen relative to when you reload the page - they might even happen in another process. Thanks for prompting me to revisit this.

It's a bit hacky - it looks for an entry within the last 5 seconds and color orange if there is one. I figured this was probably OK for manual reloads. It turns the icon red if the last entry (within those 5 seconds) is an error. I'll take a look at improving this - should be quite easy now that I am caching the results in a wirCache because I'll be able to tell if there is a new entry or not. This wasn't really possible until I introduced the caching.

Thanks for taking a look @d'Hinnisdaël - I decided to go with a "template" panel type and build a custom chart, mostly because there was something amiss with using a time series with the way the module is configured and it was easier this way.

I am not a regular ChartJS user so not sure of any breaking changes, although pointing the module's CDN link to the latest version does result in a JS error coming from the module's DashboardPanelChart.js file. I haven't looked into to see what fix is required though.

Hi @d'Hinnisdaël - just wondering if you've had any thoughts about changing the charting library, or at least updating to v3 of ChartJS. The old 2.x branch has lots of limitations with the time axis type. Thanks!

Does this relatively new feature help? https://processwire.com/blog/posts/pw-3.0.177/

Hi @Mike Rockett - I know you're not around much these days, but I just had this exception: Obviously that's a weird request for mysite.com/? but it would still be nice if this was handled better. Not sure if you want to change the request_uri field to utf8mb4 so it can store these, or if you want to sanitize it somehow? Let me know if you need more details. Thanks.

@gmclelland - it looks like the option to parse an array was only made available since PHP 7.2 - "This function now also accepts an array as string. Formerly, only strings have been supported." This is something I actually introduced back in December (I guess you haven't updated since then). Anyway, I've moved that call earlier onto the main string (before I break it into an array) which I think should have the same affect without breaking in older PHP versions. Can you please try the latest version and let me know?

Thanks @kater - should be fixed in the latest version.

@Pete - in case it helps, I had to do something with processing incoming emails recently and given the abandones status of the flourish library, I went with pure PHP. $inbox = imap_open('{imap.gmail.com:993/imap/ssl/novalidate-cert}', 'me@gmail.com', 'password'); $msgnos = imap_search($inbox, 'UNSEEN'); if($msgnos) { foreach($msgnos as $msgno) { imap_setflag_full($inbox, $msgno, "\\Seen \\Flagged", ST_UID); $header = imap_headerinfo($inbox, $msgno); $bodyText = imap_fetchbody($inbox, $msgno, 1.2); if(!strlen($bodyText) > 0) { $bodyText = imap_fetchbody($inbox, $msgno, 1); } $timestamp = strtotime($header->date); $toObj = $header->to[0]; $fromObj = $header->from[0]; $to = $toObj->mailbox.'@'.$toObj->host; $from = $fromObj->mailbox.'@'.$fromObj->host; $u = $users->get('email='.$from); if($u->id) { // process contents $bodyText here } } } I had this all ready to use and then decided to actually switch to using Mailgun's incoming callback feature - if you have access to it, I think it's much nicer because they will ping your site via a webhook callback, rather than you needing to regularly ping your email via imap.