adrian

I have just put together a solution that checks if the homepage is matched - now that will result in showing the entire page tree. That should take care of what you need without the need for adding roles to be excluded. I just need to test a little more - should have it committed shortly.

Are you using the custom PHP code option? If so, try "Entire Page Tree", rather than "No Access" and in your php conditional, you can return "/" for the role that should see the entire page tree, but "false" (without the quotes) for the other roles, so that they won't have any access. Does that suit your needs?

I am talking about site/init.php - that is definitely loaded in the admin. Maybe you are referring to your own manually included init.php that is in the templates folder?

Beware of putting $user->of(true); in init.php because it will also be loaded for the admin (as well as the frontend) which I expect will cause all sorts of problems.

Yup, just delete that field from the DB and it should be fine again.

Probably from the ImageExtra module When it is removed from a field, that module either needs to remove these fields as I suggested, or set them to NULL = Yes as suggested by @mn-martin in that issue thread I linked to above. Perhaps you could also leave a comment to back up my claims

Can you show us a screenshot of the field_portrait table structure from PHPMyAdmin or similar? Or at least list out the fields/columns in that table.

I wonder if you are using the ImageExtra fieldtype which is where the caption is coming from. Did you uncheck the caption option? Take a look at my Github issue: https://github.com/justonestep/processwire-imageextra/issues/9 that still needs fixing.

This seems like it might go back a very long time: https://processwire.com/talk/topic/1125-images-field-returning-array-even-when-max-files-set-to-1/ I feel like I have come across this before too and been in a hurry and just used ->first() rather than trying to debug it. A couple of things that work other than first() $user->of(true); echo $user->avatar->url; or this: $u = $users->get($user->id); echo $u->avatar->url; Both of these work. In a rush so not sure why - I don't see why the $user object seems to have outputformatting off by default - maybe this is intentional, but I don't recall.

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?