adrian

Hey @tpr - sorry about that - please try the latest version.

Well I decided that it could be an issue is several scenarios, so I have added some new options. You can now return false from the custom php code option which will result in the user having no access to any pages in the tree. There is also a new config settings option for determining whether non-matching users see the entire page tree (current scenario and the new default) or they have no access. This setting works with all three matching options. Check it out and let me know what you think. I have also included the temp hack fix for the page doubling issue in PW 3.0.8+ (https://github.com/ryancramerdesign/ProcessWire/issues/1774). Hopefully this is something that Ryan will fix in the core shortly and I can remove the hack. The side-effect is that the new smarter page tree (that remembers what was open) doesn't work, but if you are using the functionality of this module, then likely the page tree that the user is seeing is quite simple anyway - I think a decent compromise for the moment.

Good point - I am not sure the best approach to take here. It is by design because for my initial use case the users without matches should have access to the entire page tree. It sounds like for your needs you'd want nothing listed at all in the page tree - is that right? Initially that sounds easy enough, but I am wondering if you'll still want certain users/roles to have full access and wondering how this should best be achieved. I don't think it's as simple as a config setting that asks what not matching users should see - everything vs nothing, because I expect you'll want some users to see everything and some to see nothing. I know that with your code you've taken care of this because only members are limited, but maybe for other situations this won't be as clear cut. I am also wondering if the "Role Name" method for matching also needs to consider this scenario - what should they see if there is no match? Before I go any further, do you have any thoughts on the best approach/logic? Maybe for the custom PHP code option I could check for a returned true/false - true would show the entire page tree, false would show nothing. That doesn't solve the Role Name issue or if the custom PHP code option doesn't have a conditional component, but it might be helpful in your scenario.

Yes that would be preferable.

Why don't you try it and see what happens

You could maybe hook into PageRender::renderPage ? Take a look at the ForcePasswordChange module: https://github.com/adrianbj/PasswordForceChange/blob/master/PasswordForceChange.module#L57 and the method that is called: https://github.com/adrianbj/PasswordForceChange/blob/master/PasswordForceChange.module#L87 Taking that approach you can prevent them from viewing the restricted pages even if they are logged in.

What's the missing 10% ? Did the field pairings work as expected? Is there anything I can do to make BCE work better for your needs?

There is a setting for the Forgot Password module that lets you set the from email address.

@sappel - maybe I am not getting exactly what you want, but something like this should do the trick. $products = $pages->get("/products/")->children(); foreach($products as $product) [ echo $product->sidebar; }

Because when you manually unzip a project from Github it has "-master" or "-dev" etc in the folder name. You don't want this in PW, so you either need to manually remove this, or install automatically from the zip itself. If you install manually and then run the Upgrade module, it is adding the version without the -master so you end up with two versions. Does that explain it?

The -master issue is probably just a result of you manually unzipping and FTP'ing the module folder. If you use the modules page to install, either via class name, github url, or from your hdd you won't see these. PS Glad you are now seeing 0.1.5!

The module includes the latest core version of Tracy with that commit you referenced, so not sure why manual updating would have helped. Also note that I make a couple of manual modifications to the core to make editor links reference the main template file, rather than the compiled version, so you will have problems there. Did you try the stable version - that should really speed things up - seems to me that the new src/Tracy/assets/Bar/loader.phtml approach used by master is the source of the slowdown. Any chance you can give me access to this server - I am baffled as to why the latest commit to the module stopped by debugger bar from working again. PS For reference, here is my Issue report to the Tracy core: https://github.com/nette/tracy/issues/157 - hopefully they'll be able to figure out the slowdown problem with the master (dev) version.

Any chance you can PM me with access to this server, or is it a local dev setup? Why do you have multiple copies of so many of your modules? You should delete all the -master versions. Also, when installing modules I would recommend the core method of installing by class name - it looks to me like you installed several modules manually and then used the upgrades modules to upgrade them - hence the extra copies. You must have a 0.1.4 version of PageProtector somewhere in your system.

@tpr - back to your slow loading issue - I don't think it is https related. I am getting TTFB for 3 scripts files at about 10s for all. This only happens for the master (dev) version of the Tracy core which is loaded automatically if you have php 5.4.4+. If I manually force the stable version to load, then it loads very quickly. Weird thing is that I have two PW installs on my local dev setup and one is fast with the master version and one is slow. So I need to investigate further but thought you'd like an update on that. Until I get it sorted properly (maybe needs a fix in the Tracy core), you can always force the stable version of Tracy here: https://github.com/adrianbj/TracyDebugger/blob/master/TracyDebugger.module#L102 - you'll want to change the two lines after that. Hope that helps in the meantime.

Back to the Tracy logs directory/files permission issue - I have just added a check that prevents the error and warns if the directory is not readable. Still don't know why it ended up that way for you guys, but at least now Tracy will still work and you'll get a message about why it can't show the Tracy log file entries.

Interesting that it's now working fine - it does suggest that there was initially an access permission problem - either "execute" on the tracy folder or "read" on the file. Any chance that might have happened when copying a site from one server to another? I wonder if I should add a check on the folder and chmod it to the default directory value for PW if it doesn't already match? I haven't tested on https yet - can you narrow it down to one particular panel, or does it cause the slowdown even if all custom panels are disabled?

Sure, although if you have lots of separate pages protected you might want to copy the module settings from the modules DB table so you can add them back in without having to re-create them all after the reinstall. Are you having issues with updating any other modules, or just this one?

Yeah sorry about that - I read your request in a hurry and saw "So not including any hashes" and extrapolated the "not" to the url segments etc.

$page->httpUrl

I am not sure what to suggest. Can you take a look in the .module file and make sure it says: "15" as the version number? If it does, then can you let me know if the new functionality is available despite the version number in the module config showing 14?

Thanks both of you - so it really does seem to be a permissions issue. Given @netcarver's report about the file permissions being correct, I was wondering if there was maybe an issue with the folder permissions - I was initially thinking it might be a lack of execute permission on the created "/site/assets/logs/tracy/" folder, rather than the log files themselves, but then I don't see how the file could be written in the first place unless the permissions have changed since the file was initially written. So I am actually not getting anywhere I do have a couple of tweaks coming (one which might fix the issue where @netcarver still had the problem even when the Tracy logs panel was disabled), but I don't think anything will fix this properly yet. What do you both have your $config->chmodDir set to? If you change this (increase permissions), delete the /logs/tracy folder and send something to the log again, does it work now?

Thanks for helping to debug. I wonder if this is the same issue that @tpr is having? I can replicate what I think is the same problem if the log file doesn't have read permission. Can you please check to see if it works with 0777 (just a temp change to debug)? I am using wireMkdir to create the tracy logs folder though so I feel like it should be correct. Also wondering if maybe there is some issue with the content of the log file - does it return with a simple text entry? If the permissions change doesn't fix things, any chance you could PM me a copy of the log file you deleted (if you still have backup of it) so I can test?

@tpr - those suggestion were kinda only relevant before I committed the update. @netcarver - looking forward to seeing those errors - thanks. I can't imagine that either of you guys are running less than php 5.4, but could you confirm that https://github.com/adrianbj/TracyDebugger/blob/master/TracyDebugger.module#L102 is validating to true and therefore including the master (dev) version of Tracy? While you are there I guess it would be good to see if instead the stable version works. Thanks again.

This sounds like a modules caching issue or maybe a FileCompiler caching issue? Can you try a Modules > Refresh? I'd be surprised if that doesn't work, but if not, maybe clear your FileCompiler cache as well?

I decided to update the Tracy core now anyway - please let me know if the latest version fixes it for you.