adrian

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

This is unfortunately a slightly different situation. Both however due to the change in the positioning of the bar's co-ordinates from bottom-right to top-left. I'll look for a fix shortly.

From what I can see, the value attribute is not populated by autocomplete in any browser. Keep in mind that val() and attr('value') are very different things. Hopefully Ryan will see this: https://github.com/processwire/processwire-issues/issues/537#issuecomment-383411262 and be happy to implement.

Taking a further look, I agree that wakeupValue is needed in case someone does use on the frontend, but I can't see a need for loadPageField() - so if it was limited to just wakeupValue then it would reduce processing of the code to just once.

Thanks for looking into this @Robin S - what actually caused @Torsten Baldes to make that recent change is this recent commit by Ryan: https://github.com/processwire/processwire/commit/ba21b28b4ec6cf4651a618561f8faa149497f7e4#diff-b49b5256779b14f5ffbe105307aa2be2 Everything in this module was working fine until that change in the PW core! Unfortunately I don't see Ryan removing that code because the change was to help fix a recently reported bug. Perhaps I can convince him to add an additional check though. What I have come up with that seems to work is to replace: https://github.com/processwire/processwire/blob/184059b5d66a6ed8c739594d6b51d8d11f17d62d/wire/modules/Inputfield/InputfieldPassword/InputfieldPassword.js#L175 if($(this).val().length < 1) return; with: if($(this).val().length < 1 || $(this).attr('value').length > 0) return; I am sure it's obvious, but what I am doing is checking the actual value attribute of the field at page load (rather than what is currently entered in the field). Now, if it's already populated (like Email New User does), it won't remove the password. This change means I can actually remove this hooked method entirely: https://github.com/adrianbj/EmailNewUser/blob/a93ea9d73ef523f1abd19135516edd80ac4ebf37/EmailNewUser.module#L63-L65 Would you mind checking at your end to see if everything works as expected. If it does, I'll see if I can get Ryan to make that change. @Torsten Baldes - could you please try this approach too please - I really need to revert your recent change ASAP as it's breaking things. Thanks!

Hey @Robin S - I just had a quick look and I can't actually see any issues with saving a user. Maybe I am doing doing the right thing, but can you please explain exactly what is required to reproduce?

Hey @kongondo - seems like it's all because of the ___wakeupValue and ___sleepValue methods. Is there any reason they can't just return true, rather than returning $this->renderMarkup($page, $field); ? Thanks!

No time to test well, but let me know how it goes. Note that you really want to pay attention to the note suggestion adding files, cache, logs, sessions etc to the ignored dirs. Even then it's still a little slow. What do you think of the attached version? TracyDebugger.zip

Hi @Robin S - sorry about that. I can try to take a look tomorrow, but maybe in the meantime @Torsten Baldes could also see if there is an alternative to that commit of his that fixed the password issue, but not have the side-effect of breaking user saving?

I think you need quotes to get accurate results. How about this one: https://nerdydata.com/search?query="%2Fsite%2Fassets%2Ffiles%2F" Although I don't think the total count is relevant, but definitely show some sites I haven't seen, especially of interest is: https://www.payrexx.com/

Didn't think about that. I use Soma's PageEditSoftLock for that. It also polls regularly, only in ProcessPageEdit, not all the time. Also, in general I just find the Notifications UI/UX really annoying and it's also frustratingly difficult to uninstall, but if others like it, then that's why we have options

Thanks @bernhard to the link to that live-form-validation script - that is a much nicer experience!

Hey @teppo - I haven't used this module in a long time, but I am playing around with v2.0 at the moment and I see that there is no repeater/repeatermatrix support at all. I understand the old/master version does have some repeater support though. Are you planning on support? Any possible timeframe? Thanks!

The entries in the Network tab aren't due to Tracy, but I was curious about the Tracy header which I don't believe should be there. Oh well, something for another time I guess.

The UiKit theme collapses notifications by default which is much nicer.

Hey @bernhard - thanks for this - I decided to give it a go in one of my current projects. I usually build from scratch using the PW form API, but thought it was time to give this a go given how good most Nette products are. So far really enjoying using it A few thoughts: 1) Any reason you are loading netteForms.js instead of netteForms.min.js ? 2) Any chance you'd consider making the RockFormsBranding div optional? It might be ok on some projects, but on others I really don't think I could have it displayed. Not trying to take credit away, but hopefully you understand. 3) I find the alert dialog really annoying and very 90's. I know it's part of Nette and not something you added (https://github.com/nette/forms/blob/849b672612b709227371f0e0c7d4ee9110206ddc/src/assets/netteForms.js#L304) but I would love to see it gone without hacking that file. I am tempted to make a request to David at Nette, or maybe you could if you agree? Or is there a way to disable this that I am not seeing? Thanks!

Hi @rick Those come from the Notifications module (PW core but not installed by default). Personally I really dislike that module and never use it. I don't see a reason to poll the server every 20 seconds for notifications. Tracy should not be loaded with those calls though - I exclude them here: https://github.com/adrianbj/TracyDebugger/blob/204db7e404312dc24e8ca39db445e7cfcc9ddd1a/TracyDebugger.module#L309 but I am wondering if maybe the if(isset($_SERVER['REQUEST_URI'])) { or one of the other conditions just above is not working as expected on your system. This doesn't prevent those annoying entries in the browser dev console, but it should prevent Tracy from being loaded on each request. The x-tracy-ajax header you are seeing makes me wonder if those checks aren't working for you. Could you please take a look and let me know what is happening in the block of code?