adrian

Yeah, I am not actually sure which I prefer at the moment - I think it depends on the complexity and also how well Ryan implemented __debugInfo() for the object type in question.

@Robin S - I'll have to get back to you on that when I get a minute to look into it. Totally OT, I just wanted to mention this issue to you guys because it cost me some time today. Now that Tracy by default uses __debugInfo() for d() an bd() calls, I was getting empty responses for d($input->get), post, cookies etc. I have posted an issue for Ryan: https://github.com/processwire/processwire-issues/issues/575 - please feel free to +1 it! but in the meantime, you will need to set debugInfo to false or turn of __debugInfo() completely in the config settings.

Hi @Robin S - sorry for the slow response on this. Honestly I didn't really get very far attempting to load Tracy early. I thought it was ok initially, but as that thread showed, there were lots of issues I didn't initially see. I think it needs some significant investigation. I just don't have the time for that at the moment, but if you find a solution, I am very happy to implement any conditionals in Tracy to make it possible.

Thanks for pointing this out - I'd forgotten about that issue. Unfortunately I have a lot of code and a lot of Page Reference fields that rely on single page / null so I am hesitant to change at this point in the project. I am testing your other solution though and so far so good

Hi all - I have started a new 3.0 branch which has some more breaking changes. This new version moves the country code into it's own "data_country" database field and stores a raw version of the number in the default "data" field. The reason for this is to make it possible to do a: $pages->find("phone=13727654876") Before you could only find by component parts, like: $pages->find("phone.country=1, phone.are_code=372, phone.number=7654876") My need for this was to find a user by their full raw/unformatted phone number as returned by the Twilio sms service's POST response. I'll keep the changes in this branch for a while, but I would encourage new installs to try this version. Let me know how it goes.

Thanks - I have referenced your idea in the Github issue - will see what Ryan says. Cheers for the help!

It's a little more complicated than that - need to make sure that $processedPages is defined outside the method so it' not reset on each recursive call. I know Ryan will have his approach to this so I'm not going to bother refining right now, but if anyone is interested, here is the new issue: https://github.com/processwire/processwire-issues/issues/572

@BitPoet - You're a legend! I had dumped everything I could think of, including your suggestion, but this comment: triggered something in my tired brain It's because one of the other page fields points back to the initial user. I didn't think about the recursion happening from another field. The question of course now is how to prevent it happening. I feel like this is a PW bug because I think it's valid to tag a user from one as a "subscriber" and yet still tag the original as a "tester" for that user. I feel like that foreach loop in resetTrackChanges() needs to keep track of page ids that have already been processed. What do you think about this for a solution to propose to Ryan: public function resetTrackChanges($trackChanges = true) { parent::resetTrackChanges($trackChanges); $processedPages = new PageArray(); foreach($this->data as $key => $value) { $processedPages->add($value); if(is_object($value) && $value instanceof Wire && $value !== $this && !$processedPages->has($value)) $value->resetTrackChanges($trackChanges); } return $this; } PS I probably need to check that $value is an instance of Page before trying to add it

Yes of course - I forgot that the Trash action isn't normally available to non-superusers - thanks for the reminder.

No chance as far as I can tell. I have debugged the values of $this and $value and the only thing I can ascertain is that the recursion only happens with there is a selected value for the page field (this is probably to be expected), but they never match. This is the result from being on the user with ID 1122 which has the selected subscribed user as 1100. if($key == 'subscriber' && $value !== '') { bd($this .':'. $value); continue; } 1122:1100 1100: 1122:1100 1122:1100 1100: 1122:1100 1122:1100 If I don't "continue" in that conditional, then I get the following - note the extra occurrences of the 1100 page which as I mentioned is the page the is selected from the page I'm currently on. Note that on page 1100 the subscriber field is hidden and nothing is selected. 1122:1100 1100: 1122:1100 1100: 1122:1100 1100: 1122:1100 1100: 1122:1100 1100: 1122:1100 1100: 1122:1100 1100: 1122:1100 etc etc etc Thanks if you have anymore ideas!

Of course the core now has the "trash" page list action, but AOS also has a great "delete" action implementation with an inline confirmation step.

Hey guys, I have battling with this for way too many hours now and wondering if someone might have any clue what's going on, cause my brain is no longer working I have a very customized user template with several page reference fields that allow selection of other users. The selectors for these page fields prevent selecting the current user so it's not the same as what @BitPoet reported and fixed, but it's certainly related. Of the the page reference fields I have, it's only one that causes the trouble, but I can't see any difference between it and the others. Here's the export of the tester (which is fine) and the subscriber (which results in the recursion). At the moment the only way I seem to be able to prevent recursion is to add a: if($key == 'subscriber') continue; to the foreach loop in the resetTrackChanges() method. There has to be something I am missing, but right now I have no idea what Suggestions greatly appreciated!

@Robin S - I'll see what comes of those discussions over on the tracy github account, but if they don't implement an option to fix position, I will add one to the config settings that uses your css - thanks!

@Robin S - I'd be careful of "fixed" - I had recently changed the Tracy because of this: https://github.com/nette/tracy/pull/291 Otherwise looks good - I'll try it out later.

If anyone has strong feelings about bar / panel position, what's remembered between page loads etc, now would be a good time to chime in: https://github.com/nette/tracy/issues/289 https://github.com/nette/tracy/issues/295 https://github.com/nette/tracy/issues/294