adrian

I do believe this is on the todo list for repeaters, along with the ability to name each one (which is pretty important if they are initially collapsed).

Why don't you try adding them to children like: $children->add($this->pages->get(1088));

You can use insertBefore, eg: $newField = $fields->get("your_new_field"); $t = $templates->get("your_template_name"); $existingField = $t->fields->get("sitemap_ignore_END"); $fg = $t->fieldgroup; $fg->insertBefore($newField, $existingField); $fg->save();

Any module that is a textformatter needs to be applied to each of the required fields via the Text Formatters dropdown on the Details tab of the field's config.

Sorry, I am on a bit of a roll - I really do love this module I don't really understand the "Select the inputfields where the extra fields should be attached." option in the config settings. It lists all the different inputfield types, but the module only works with image field types. I actually tried to see if it works with InputfieldFile, but it didn't even work there. Am I missing something about this setting? I think a more useful setting would be to control which image fields (the actual fields, not field types) that imageextra is attached to. At the moment the "Image Extra Fields" fieldset is added to the Input tab of all image fields, which I expect most developers don't need - they probably only want them for certain image fields. Does that make sense and sound like a good idea? Thanks again

I don't know what to say about the issue with removing extra fields - I am continuing to get that error on different PW installs. But now I have another issue for you. With ImageExtra installed and Maximum Files Allowed set to "1" when I go to upload a second image, the editor actually shows both images. After save, the first one disappears, but without ImageExtra, the second one instantly overwrites the first one. This has been confusing for our users - they think a second image has been uploaded rather than overwriting the first one. I hope you can reproduce at your end. I wonder if it's a simple matter of incorporating some of the new code in: https://github.com/ryancramerdesign/ProcessWire/blob/980ce4f0be2054dfbad4a7b334d35bdca42da7da/wire/modules/Inputfield/InputfieldFile/InputfieldFile.module#L438 into your module at: https://github.com/justonestep/processwire-imageextra/blob/master/ImageExtra.module#L540 Thanks!

You can filter like this: foreach($page->fields->find("type=FieldtypeImage") as $f){ or you can create a new field array with: $myFields = new FieldsArray(); foreach(xxxx as $f){ $myFields->add($f); }

Just to add to this thread - I needed the check to run during init() and the best option I could think of was: if( wire("process") != 'ProcessPageView' ) { //in the admin } Can anyone think of any situation where this would fail? Perhaps some modules may run ProcessPageView in the admin? Maybe Nico's check for the admin path in the URL is a better option. Anyone have any more recent thoughts on this?

The latest version of PW has built-in hide/unhide and pub/unpub action buttons, so I don't actually think there is a need for this module anymore.

It's working fine here - are you saying it never returns any results from image descriptions, or are there inconsistent results returned?

As far as I know it's been around for a long time - certainly since 2.3

Thanks teppo - I do think it makes sense to keep this module a little more focused on single branch functionality. I haven't actually used UserGroups yet so didn't realize it could do that - thanks for the heads up. @BernardB - if you try out Dynamic Roles, please be aware of this bug: https://github.com/ryancramerdesign/DynamicRoles/issues/14 - I assume I am not the only one that is being affected by this - I provide a simple fix in that first post that you can implement.

I just added a couple of new options to this module that allow for automatic protection of unpublished and hidden pages and their children. I am finding the unpublished protection very handy as I can set the parent of a branch to unpublished while it is being developed. With this option enabled, I can send the link to this page direct to clients and they will be presented with the custom login form so they login and then immediately view the page - no need to go via the backend admin panel (just like the normal way this module works), and they won't get the 404 page if they attempt to visit when logged out. Because children can also be protected there is no worry about someone guessing the URL to subpages, the entire branch is protected based on the publication status of the parent. Once the branch is ready to be published, simply publish and it will be live and the protection is removed - no need to give clients access to the control of this module on the settings tab and explain how they work. Hope you all find it useful!

As far as I know, the only option is to do it with the buildFormContent hook. Have a look here: https://github.com/adrianbj/BatchChildEditor/blob/master/BatchChildEditor.module#L371 See the commented code of the old way I did this using the BuildForm hook and then the new way by creating a new InputfieldFieldsetTabOpen with buildFormContent. Hope that helps.

@BernhardB - just thinking about this a little - what method for matching users to the parents of multiple branches would you want? I think that likely the only option that would work would be the 'Specified Branch Parent' option. I guess you could assign multiple roles with names that match branch parent names, or perhaps the custom php code option could match branch parent names with partial name matching or something, but these two are sounding a bit more convoluted. Would you mind having a think about how'd like to see this matching work. I am a little worried about overcomplicating this module, but I think the Specified Branch Parent might be an OK option - what would best fit into your workflow / requirements?

Well if that is acceptable in some cases then I could probably make it possible to limit edit access to more than one branch - would just need to disable the visibility restriction to that use case. I'll take a look sometime in the next couple of days to see what I can do.

Have you checked (logged in with a test user of that role) that the user can actually create a child page under Categorie? If they can, then you know it's a problem with the Page field config, but if not, then it's a template level permission problem.

Try this: $matches = $pages->find("title|body|sidebar|thumb_one.description|thumb_two.description|thumb_three.description|thumb_four.description|gallery_img.description%=$q, limit=50");

I had a feeling that questions was going to come up It would be very easy to make it restrict the editing rights for more than one branch. But it's not so easy to restrict the page list view to multiple branches. This is where you get into issues with incorrect child page counts and subsequent pagination issues. Have a read of this Github issue: https://github.com/ryancramerdesign/ProcessWire/issues/302 and some of the forum posts it links to. As I mentioned above, AdminPageHider () and some of my gists I link to in that thread might be useful, but the child count is still a problem unless you make numChildren() hookable, which it isn't. I had a fairly unique need for creating this module - one that @tpr also has (). It works great if you have very compartmentalized branches (potentially subsites) in your page tree that are specific to individual users, or teams of clients.

@tpr - I tried to reproduce here, but couldn't trigger it, but probably some combo of levels/page names that you have that I am missing. I applied your fix and committed so hopefully that will take care of it as you suggested. Thanks for all your help testing!

Glad it's working so well for you - that's what I like to hear I looked for a new version of FEEL, but it doesn't look like those recent changes have been committed yet, correct? I could maybe change the hook back to ready(), but I don't think it really hurts to have it in init() - the main thing is that apparently you can't check whether the user is a superuser in init(), so that check is added to the method called by the hook - not a big deal.

Maybe we should continue this conversation over on that Github issue - we are getting way off track with what AdminRestrictBranch actually does - it's purpose is actually fairly simple in scope and it turns out quite easy to implement. It's way simpler to restrict a user to view and edit one branch than it is to deal with all the child count and pagination issues of removing selected pages/branches.

Just to clarify - not sure if you are talking about "listable" here - I don't think it suffers from those issues - at least not in my experience with it in BCE. This is how I used it: https://github.com/adrianbj/BatchChildEditor/blob/master/BatchChildEditor.module#L201

Hey teppo - I am actually using "listable" in BatchChildEditor for hiding the children of a specific page - it actually seems to work very well for that scenario. It's more complicated when trying to hide the specific page itself, which is why I haven't used it in AdminPageHider yet. Making numChildren hookable would solve that, but I PM'd with Ryan about this and because it is called so often he doesn't think it is a good idea performance-wise. I may revisit the child count issue in AdminPageHider at some point to see if there is an alternate solution - I tried once but I was trying to reduce the numChildren incrementally, but it seems it is only possible to set it to zero - I asked Ryan, but haven't heard back yet - if it worked, this could be a solution. To be honest when I have used AdminPageHider I haven't worried too much about the incorrect child count - for me it has only ever been on Home and even though it stands out to me, I doubt most site editors would even notice It only becomes a real issue if pagination is involved, but I find that rarely happens at the level of pages directly under Home and that is usually the level I am hiding anyways, so it's not an issue. This new module is suiting my needs very well for one of my current projects as separate clients are responsible for certain branches of the sites - so much easier to restrict viewing and editing rights by parent than messing around with other solutions. Obviously not always appropriate though.

Lots of iterative changes made throughout the day to fix some bugs, allow front-end editing branch restriction (to work with FREDI and FEEL - thanks to @tpr for his help in figuring these out) and some other improvements. I am now running this on a live site - so far so good but I'll leave the Alpha warning for a little longer. Be sure to grab the latest version and let me know how it works for you.