adrian

Just so you know - you should probably use: $config->adminRootPageID because it is possible for it not to be 2.

Hi everyone, A few commits today to improve a few things. You can now choose the branch of the Tracy core from the modules config settings. It defaults to the master (dev) version if you have PHP 5.4.4+, but now if you have having the slow rendering of the debugger bar (mentioned by @tpr above), you can easily choose to load the stable branch instead. Hopefully the Tracy folks will fix this and if they do, I'll likely remove this setting in the future. There is now better panel resizing and scrolling of internal content - this is especially handy with large panels when you have the dev console open on the bottom. Probably still not perfect, but should be much better. Actually I think the Tracy core needs some work to make this even better. Performance Panel now has internal scrolling - this was absent before. Enhancements to the Debug Mode panel, including linking of the API variables to the new PW 3.x API Reference docs.

@Robin S, Sorry for the delay on this - partly no time, and partly not sure what to do. That bug you noted at the end there is new since I added checks to prevent extra images being added to an image field with MaxFiles not set to '0'. I am actually thinking that the easiest and best solution is to simply require that the image field that is selected for this module has a maxFiles set to '0'. My reasoning is that there are three scenarios where you might end up with more than one image in the field. 1. You allow users to manually upload other images to that field 2. You are using a textarea field where they can enter multiple video links 3. You have chose "All Available" for the thumbnails to be grabbed There are also combinations of the above. I don't see a simple, logical way to make this work without the potential for losing images if I continue to allow a single image field and overwrite existing images. I have gone ahead and made these changes - hopefully it won't impact your (or anyone else's) use cases. Please let me know if you have any problems with this new version.

Sorry for the delay - got distracted by other things. Please check out the latest version - as I mentioned, you can now match a user to the homepage so they'll have access to the entire tree.

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.