adrian

I know you need to check a constant or variable, but if you enter things directly, you don't need the namespace. I guess it's to do with quoting FieldtypeEmail when assigning to a variable or const that causes the problem.

Sorry @tpr - I actually even left the \ProcessWire\ in the version I posted above - d'oh. I did try without and wasn't getting an undefined wire error so assumed it was ok.

Interesting - it works like this here:

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.

@NorbertH - thanks for the screenshot - nothing out of the ordinary there. There is no need to deactivate the RequestInfo panel, just uncheck the "Field List & Values" option from its settings: That will reduce the size and time of that panel considerably. The API Explorer and Captain Hook panels are naturally going to be large in size, but the time should be significantly lower the next time you load it because the content gets cached - for me it's 79ms. Hope that helps a little.

Yeah, I kinda agree with you - it's a bit annoying at times - I have gotten used to the keyboard shortcuts to increase/decrease as needed. Not sure how easy it would be to do what you want because I make use of the splitjs library (https://github.com/nathancahill/split) for that stuff and it's a percentage based setup and not sure how I would go about overriding that at the moment - it's certainly on my mind though.

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/