adrian

So sorry @bernhard - I didn't read that bit of your question - my apologies! I have purposely prevented the Console, File Editor and Adminer panels and some others from working for non-superusers. Perhaps this could be made optional, but it seemed like a good default security setting. I can work on this later for you, but for now, just remove this line: https://github.com/adrianbj/TracyDebugger/blob/b225975afdad1c86ecb7ac7d4a724b46dcbcd0f0/TracyDebugger.module.php#L1444 and this conditional: https://github.com/adrianbj/TracyDebugger/blob/b225975afdad1c86ecb7ac7d4a724b46dcbcd0f0/includes/CodeProcessor.php#L20 I think those should get you going.

Can you remove the islocal check on this line: https://github.com/adrianbj/TracyDebugger/blob/b225975afdad1c86ecb7ac7d4a724b46dcbcd0f0/TracyDebugger.module.php#L2477 and if that works, then we know it's an issue with that check in your environment.

Typically Tracy reports on AJAX errors - if not in the AJAX debug bar, usually in the Tracy error logs. Sometimes they do seem to get through but usually they show up in the browser console's network > response tab

Or are you maybe using ngrok? Maybe that is affecting the detection of local via 127.0.0.1

Hey @bernhard - the "Force guest" setting should take care of that on localhost, but IIRC there are some dev environments that aren't correctly recognized as local - are you using one of these pre packages LAMP stacks? If that doesn't work, have you tried giving the "tracy-debugger" permission to the user role in question? Obviously you won't need to worry about the IP restriction in your dev environment.

You will also come up agains this: https://github.com/processwire/processwire-issues/issues/550 This will fix that issue: $this->addHookBefore('Pages::find', function(HookEvent $event) { $selector = $event->arguments(0); if(is_string($selector) && strpos($selector, 'template=user') !== false && strpos($selector, 'name|first_name|last_name%=') !== false) { $selector .= ', check_access=0'; } $event->arguments(0, $selector); }); PS - you might need to adjust the modified selector to suit your needs - re the first_name, last_name etc

You need to add "check_access=0" to the selector.

Hey @kongondo - I am back working on that project that makes heavy use of this field and I just replaced the: return $this->renderMarkup($page, $field); with: return true; for the sleep, wakeup, and loadPageField methods and it is bringing calls to the render method back to just one, which is really important because it contains some heavy querying. I am fine with this mod for my needs, but I wonder if you'd consider these as an option for when the module is only used in the admin. The render() method in the InputRuntimeMarkup file takes care of the actual rendering without all these duplicate calls to renderMarkup(). What do you think?

@bartelsmedia - thanks for the heads up. I think you can achieve your needs quite easily via the "Login Template" option. Hope that helps. @SwimToWin - sorry I let your post go by un-noticed. I am afraid I don't really have the need (and hence the time) to add a single passphrase option, but I am certainly open to a PR if you're willing. A tad OT, but I think PW needs to start fostering a culture of providing PRs more often than requests for features (both in 3rd party modules and in the core). This is absolutely not directed at you personally - I just feel like we need more contributors across the board because there are too few people being spread way too thin.

You may also need to grab the ->first() image from the images field, or add another nested foreach to loop through all images, eg: <?php echo "<h1>$page->title</h1><br>"; ?> <? foreach($page->we as $member): ?> <? foreach($member->images as $image): <img src="<?php echo $images->url; ?>" alt=""> <? endforeach;?> <?php echo $member->wemember; ?><br> <? endforeach;?>

Hey @Robin S - I agree with your analysis for sure, but I am not sure that returning the first item in that array is necessarily very helpful. I think I'd rather an error telling me that it can't determine the http root so I remember that I need to hardcode it myself. Perhaps if we could force it to return https then the first item in the array might be ok, but given that every site should now be https and not http, I think the current behavior is detrimental.

Hey guys, I haven't come across this before. I'm in a rush but didn't want to forget to ask / report this which seems weird to me. If you check the following via the http it returns the correct url $config->urls->httpRoot but if you do it via CLI then it returns the first entry in your $config->httpHosts array and gives http, rather than https. In my case I had the "dev" subdomain listed first which meant I was always getting http://dev.mydomain.com instead of https://mydomain.com Not sure if this is a bug or not, but definitely something to be aware of if you are using a service from a cronjob and you are using this to send a url for a webhook return or something along those lines.

@iNoize - that's a really old version of PW now - does upgrading help?

I think this might be the source of something that @GhostRider was experiencing - perhaps he can confirm whether uninstalling this module fixes the backup problem.

Hey Peter - you can customize in the settings exactly how you want - site wide, template wide and even by page IIRC. However, you might want to check out: https://github.com/wanze/SeoMaestro @Wanze looks to have done a beautiful job on this. @GhostRider - you might also want to check that new module out.

Awesome - glad you got it working and thanks for sharing the solution!

Hi @psy - no time for a detailed answer, but I expect the solution is similar to repeaters and so this should help: https://processwire.com/talk/topic/5397-assigning-fields-to-repeaters-with-the-api/?do=findComment&amp;comment=52123 Probably worth reading through the whole thread.

Lots of solutions for this from a simple API foreach, to the Batch Child Editor module or even this http://modules.processwire.com/modules/admin-actions-unordered-list-to-pages/ Everyone baulks at the everything is a page at first, but the benefits become apparent and it's actually very elegant and more importantly very flexible if you need to change things down the road. Not saying there isn't a place for what you have built - just say that there are multiple way to skin a cat ?

Glad you have it working, but maybe rather than changing the permissions, you should change the owner of the files to match the apache user ? https://processwire.com/docs/security/file-permissions/

I couldn't agree more - this was also my reaction with this latest version. I was thinking of mentioning this idea myself, but I love the fact that so far we've never really had any breaking changes in the evolution of PW. But unfortunately I agree that in v4 it's time to strip out lots of the experimental ideas that just haven't taken off. Think back to: $pages("template=basic-page") Has anyone here ever used that "variable as a method" approach for finding pages? I'd much rather spell it out with a get() or find() method. I know early on I was given some grief over all the shortcut methods in Tracy, but I think that's a different situation - those are temporary bits of code that don't stick around. For production stuff I like self documenting code over shortcuts that save a few keystrokes. I have no idea how it would be determined would would stay and what should be trimmed, but I think it's needed.

@DV-JF - take a read through: https://github.com/ryancramerdesign/LoginRegister/issues/2 I ended up going with a solution somewhat like this: https://github.com/ryancramerdesign/LoginRegister/issues/2#issuecomment-348031491 which is basically how I have handled this situation when I've built a register and login script previously. Unfortunately I wouldn't use this module again until it's had a lot of love - it's basically unusable at the moment.

Hey Peter, I think this isn't specifically an issue with this module but rather PW core login security settings. I just some googling on the Data Saver setting - I think the problem is that it affects the IP address of the user. I think perhaps if you disable PW's session fingerprinting the problem will also be solved.

Hope it's nothing too serious and you're on the mend.

Afraid I also agree with everyone here - too many options which I'll never remember - I'll be sticking with the traditional approach - verbosity FTW ? I feel like we are on a very slippery slope here and once you go down, you can't climb back out because you might break someone's code. I have always trusted Ryan's instincts about this stuff in the past (or he has at least convinced me in the end), but this time I am not so sure. I hate to come across as critical or unappreciative because I know that even in my own relatively simple modules I sometimes get caught up in going with too many options, so I do realize it's a tricky balance. I think this is a super important point!!!

Probably a permissions issue with the site/assets/files folder - check that the owner and perms match what you had in the staging setup.