adrian

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