adrian

Thanks - I actually just committed one more change and did a version bump and updated modules directory.

And I think the key thing is that on a remote server you can still use the user switcher to change to a non-superuser and it will work - it's just that I don't want actual non-superuser users that might have the tracy-debugger permission from using it. I think that last version I just committed should be ok for this scenario. I am double checking here now, but could you confirm at your end also please?

Actually, thinking about non-superusers - not quite sure what I want to do here. Using the user switcher to switch to a non-superuser I think is OK for the console etc, but I don't actually think they should be available to non-superusers unless you're on local dev. Are you ok with that?

Hey @Robin S - sorry about - I went through a few different iterations of things and looks like I messed up a couple of things on the last version. I just made a quick fix (no version bump) that fixes it for local guest users, but I think I need to do a bit more to get non-superusers working. Feel free to test the recent commit, but hopefully will have a complete fix shortly.

It would be good to know what part/panel of Tracy is causing the slowdown - I am thinking it's probably the Field List & Values section of the RequestInfo panel - I find on complex sites I tend to disable this and it can help significantly.

@Tom. - it seems to work fine for me also. The one thing I did notice was that if I use your exact condition, it returns 'Low Stock' even though I don't have an "inventory" field at all. Not sure if a "less than" condition should return true if the field doesn't exist or there should be an error.

Glad you got it sorted. Just thought I'd mention that in addition to the procedural wireRender() file, we also have $files->render() https://processwire.com/api/ref/wire-file-tools/render/

You're all good - it won't affect the PHP / PW timezone. You can test stuff like this yourself - you can see that even though it's outputting the current time in Berlin in the first dump, the default timezone is still America/Los_Angeles

Hey @bernhard - sorry about that - it didn't work as you expected. Please try the latest version which lets the Console panel work as a guest when you use the "logout" option via the User Switcher and also it now works on localhost when using the "Force guest users into DEVELOPMENT mode on localhost" which should take care of @Robin S's request above. Hopefully the next version will include the new Tracy core features along with some other tweaks - just need to find some time ?

I've made those changes for you. I guess you couldn't edit because you didn't set an author when you first submitted the module. The interface is pretty clunky at the moment. Hopefully Ryan will improve it with the revamp.

For those interested - looks like the Tracy core will be getting multiple AJAX bars in v3: https://github.com/nette/tracy/pull/336#event-2144817375 This will be great for many reasons and will also let me remove my additive approach to dumps in the AJAX bar because consecutive requests will show the dumps on separate bars, rather than overwriting the last one which is how the core currently works.

Just another update to the Tracy core - apparently LIVE dumps now work more reliably and are now the default when calling barDump(), so it looks like we'll be able to ditch our custom bdl() method and probably even our bdb() and db() and integrate the LIVE option into standard d() and bd() calls. As you can tell, I am excited about the new version ?

@Robin S - I haven't ignored your request - it will be in the next version. Speaking of the next version, I have been looking at the poll from @teppo's PW Weekly and wondering what you guys would think about Tracy dropping support for PHP < 7.1 ? The new core Tracy 3.0-dev version requires PHP version 7.1 or newer and looking at the changes since the 2.5 version we are currently using, it won't be practical to support two versions of the core like I have done previously. So, the question is, can I make 7.1 a requirement for the new version? Not sure how to really get your feedback on this, but maybe a "like" means your OK with it, or a "sad" if you're not happy either sticking with the current version of this module (to maintain 5.x support), or otherwise don't want to lose 5.x support just yet. The new Tracy core comes with much faster rendering of dumped objects with a lot of depth, so we might be able to increase the default and big dump options significantly. There have also been improvements to live dumping that I still need to experiment with, but both sound very useful to have so I would like to upgrade. Thanks for your thoughts.

Thanks @Robin S for the idea, but I am not sure that it can really help me in this case. It's mostly an issue of my dev/staging vs production both being on the same server. My script which can be run via http and also via cron needs to have the domain hardcoded because there is no way to get the domain via cron. I need to send a webhook endpoint for my site to twilio, so it needs to be either "dev" or no subdomain, but versioning the script between the two environments isn't simple. I have a workaround and I don't expect PW to have a solution for this - it's just that I think the current behavior is confusing.

Good catch - I've unpinned it. That said, there are still lots of modules that aren't tagged as v3 compatibly that probably are, but if the authors haven't mad the change by now, they probably never will ?

Try adding check_access=0 to the selector.

Hey @kongondo - these changes seem to work well and prevent any unnecessary re-rendering of the output. In the fieldtype, I change these three methods to return true. public function ___sleepValue(Page $page, Field $field, $value) { //return $this->renderMarkup($page, $field); return true; } public function getLoadQuery(Field $field, DatabaseQuerySelect $query) { // prevent loading from DB return $query; } public function ___loadPageField(Page $page, Field $field) { // generate value at runtime rather than loading from DB //return $this->renderMarkup($page, $field); return true; } And in the inputfield I replace the ___render() method with the following which returns the wakeup value without re-rendering. public function ___render() { //if code field is empty return early if(!$this->runtimeFields) return; //so that $page and $pages are locally scoped to the eval $process = $this->wire('process'); if($process && ($process->className() == 'ProcessPageEdit' || $process->className() == 'ProcessUser')) { $page = $process->getPage(); return $page->{$this->name}; } else { return; } } Let me know if you have any questions / comments about this approach. Thanks again for an invaluable module!

I think you mean @Robin S ?

Not sure if it gets exactly what you want, but I think @Robin S's Breadcrumb Dropdowns are the best thing ever ? http://modules.processwire.com/modules/breadcrumb-dropdowns/

$page->getUnformatted('body')

The only thing to add to LK's comments is that it's nice to have everything in the one place - I have my public repos on Github, so having the private ones there also is nice. That said, I like the OS nature of Gitlab and the unlimited collaborators, so it really depends on your needs and maybe these are project specific?

Yep d() for dumping to the current output (either the console results or the template file where you call it from), or bd() for bardump which dumps to a dedicated Dumps panel on the Tracy debug bar.

Nice! Interesting you figured out using count for an exact match. In the same multi-parameter selector mentioned in the linked post, I use count to find messages with either all the age categories checked, or alternatively, it has at least the user's age category checked. This is used because the user's age is not a mandatory field to be completed so if we don't know their age, we need the message to be for all ages, but if we do know their age, then it must match the ages tagged in the message. $selector[] = 'ages=(ages.count='.$pages->count('template=age'), ages=(ages='.$user->age.')'; Anyway, obviously getting away from the purpose of the thread, but it's another example of how using a count can be helpful for queries.

Sensational, Brilliant, Fabulous ? Now this is something we definitely need in the core - I can't believe someone hasn't realized that we can't already do this. I think we need to nominate Robin as PW support guru of the year!

It's a Wordpress thread, but it's a great explanation so I thought it was worth linking to: https://wordpress.org/support/topic/why-is-it-an-error-to-have-a-closing-tag-in-functions-php/#post-10430549