adrian

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

@MarkE - just be aware that hook doesn't prevent a user getting access to the pages via Pages > Find and also via the Live Search in the menu bar. There are some hooks in the Admin Restrict Branch module that will help you with that though.

Thanks for confirming that I am not senile just yet ? This is what I am using, where 1145 is the parent of the "user_types" page reference field. Not terribly elegant, but it seems to work ok. I'd love to see a better solution though.

Hey guys - I am feeling like a PW noob asking this one. Maybe it's a slack of sleep getting this current project out the door, but I am trying to do something that I feel should be easy, but doesn't seem to be. I have users with various possible user types. This user_types field is on the user template and is also on the "message" template, so trying to match up users with messages that are appropriate for them based on the user type they are and the message tagged for their type. It's easy to get messages that match one of the user's types: $pages->find("message=template, user_types={$user->user_types}") but because users and messages can both be tagged with more than one type, I don't see any easy way to force an exact match of the user_types between the user and messages. Separating the user_types out into an AND selector like: user_types=type1, user_types=type2 isn't enough either because that doesn't enforce those types that aren't selected, so you also need to add like so: user_types=type1, user_types=type2, user_types!=type3 That last one does what I want, but I feel like the page reference field getMatchQuery() method should support exact matching without having to spell it out like this. Is there a syntax I have forgotten that does this?

You need to give it a template, name, title:

The "Copy Content to Other Field" action in Admin Actions could do this, although currently it does it for all pages of the selected template, but wouldn't be difficult to modify to add an additional page selector:

Can you show the code from the entire page? Is it maybe a PHP short tags issue, or a character encoding issue? Do you have PW debug mode on? Does that code work in the Tracy Debugger console panel? Just trying to isolate it.