adrian

That make sense, but here's another scenario for you. What if the dev sets the maxFiles to 3 and the Which Images to All Available. And it is attached to a textarea field where they can enter multiple videos - what images get kept, and which ones get deleted when additional video links are added? Obviously it would be a silly combination to set up, but you never know. At least the way it is now if you want just one video per page you can use a text field (not textarea) and choose First Available. That way you'll only ever get one image - the only caveat is that you need to do $page->images->first(). If you want the manual upload override you can have a separate field, or you could tell the site editors to simply order the images field so that their manually uploaded one is in first position. Or, the template logic could look for the presence of an image without the "video-" prefix and use that if it exists? I am still not convinced I am right, so I would still like to hear from other users of this module! Thanks for your continued thoughts on this!

I think you are looking for getForPage(): https://github.com/ryancramerdesign/ProcessWire/blob/7e8c7c6836282b6b64de81263f5aaa8112fd51ae/wire/modules/Fieldtype/FieldtypeRepeater/RepeaterPage.php#L46

Hey Steve - thanks for your interest in this module and thanks for figuring out the issues with WireQueue - as you mention it will probably happen with others too so I need a way to exclude as necessary, or maybe it can be automatically dealt with - I'll take a look. The one main issue still remaining with this module is the slowdown when a template includes page fields - at the moment the module generates content for all fields from the templates of these page fields - this can take some time. I need to figure out a better way to do this. Connected to this is the delay from calling the http://loripsum.net API. Even though I make use of Faker locally for most things, the RTE fields still use http://loripsum.net because of their random text/image options. I would like to recreate this functionality directly with the Faker API as it would make it much quicker. Otherwise I think it is working well, although I would still like to add support for Profields etc.

Thanks - yeah, it is certainly doable, but the problem I see is that if the dev sets the max to 1 and doesn't prevent users from manually uploading an image, and this modules works like PW in that a single image is replaced if the max is one, then manually uploaded image will be lost. So it doesn't work for the scenario where you want the user to be able to override the default image from Youtube/Vimeo. I think it's better in that scenario to have a dedicated "manual override" image field - at least that is my current thinking. Is there anyone else there with any thoughts on this? I'd like to get a consensus before I go making anymore changes.

https://github.com/ryancramerdesign/ProcessWire/issues/1803 Will see what Ryan has to say.

Try looking at the Network tab (make sure it is open before you upload the image). You should end up with a line that has an error - that will be the PHP error that will give you the info to figure out what is wrong. The error you are seeing in the console is a syntax error because the ajax call is returning the real error. My initial guess would be file/folder permissions, but if you let us know the error, we should be able to figure things out.

Take a look at this post by soma: https://processwire.com/talk/topic/4530-how-to-get-a-list-of-all-pages-recursiv-without-admin-pages/?p=44508

Just added a new "Core Classes" section to the debug panel - so now you have really quick access to the new 3.x API ref docs for all the core classes.

You might find wireSendFile with the forceDownload option useful: https://github.com/ryancramerdesign/ProcessWire/blob/7e8c7c6836282b6b64de81263f5aaa8112fd51ae/wire/core/Functions.php#L521

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.