adrian

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.

Just checked with your new FEEL and it's working great here. Just a side note, you have a: Notice: Undefined offset: 0 in /Users/ajones/Sites/pwtest/site/modules/FrontEndEditLightbox/FrontEndEditLightbox.module on line 203 Let me know if it's working at your end now too.

Thanks for the link to the new repo - you should update the first post of the support thread as well Not sure exactly what you are saying here - do you need it in init() or not? Sounds like if you do, then I need mine to change. Regardless I just committed a new version just before your message came through - the editable hook is now in init() so I think it should work just fine with FEEL. I will try your new version now, but I think it should work perfectly now.

Just to clarify, those screenshots are from the front-end - just the standard PW template. I am linking directly to the min.js version of FEEL on your Github account - you'll see that in my code when your at a bigger screen I didn't try using the optional helper function that you mention on Github, but I think that is probably why you are having an issue. Is your _funct.php file being included from _init.php ? If it is, then that is the problem since AdminRestrictBranch is being called from ready(), not init() which is after your FEEL check for $page->editable(). I can probably change it to init() though which should solve your problem. I'll take a look and make sure everything works as expected and then commit a new version.

You'll need to load up the ProcessChangelog.css file to make it styled correctly (or style yourself), but this does the trick otherwise: $changelog = $modules->get("ProcessChangelog"); echo $changelog->execute();

Weird - I feel like there must be something on your end confounding things. Take a look at these screenshots. These are based on this code: if($page->editable()) { echo 'editable'; } else { echo 'not editable'; } in the template code. Both Branch One and Branch Two are on the same template. The user is restricted to the Branch One branch using the module. Any other modules that might be interfering? What version of PW? PS If you think it might be an autoload issue, try a log statement from the module to confirm, or load the module manually in the template? PPS I just tried FEEL (which looks great btw) and the edit link shows up: using: if($page->editable()) { echo 'editable <script src="https://raw.githubusercontent.com/rolandtoth/FEEL/master/FEEL.min.js"></script> <a href="'.$page->editUrl.'" class="feel feel-inline">Edit</a> '; } else { echo 'not editable'; }

@tpr - I just discovered something that was probably impacting the interaction of this module with FEEL - I had it set to autoload only in the admin. I just committed a new version that also autoloads on the front-end. Of course you will need to refresh modules (I think that is enough) or uninstall/reinstall to get the autoload to change. However, I am not sure if this fixes what you were seeing or not. I am actually using FREDI (I need to try FEEL) on the site I just deployed to this to and the problem was actually the opposite to what I think you were seeing. My restricted user was getting the FREDI edit link because the $page->editable() was returning true, because this module was not being loaded to restrict it and return false. Anyway, hopefully when you read this you can let me know more and I can fix any issue you might still be having.

PHP version is the issue. If the server is < 5.5 you will need to set $session->get("uploaded_documents") to a variable first, then call empty on that variable. $uploaded_documents = $session->get("uploaded_documents"); if(empty($uploaded_documents)) { Read more about the 5.5 change here: http://php.net/manual/en/function.empty.php

If I understand correctly, I don't think I am seeing that issue here, so I am probably not understanding. Here is a screenshot of my restricted branch - you can see that the EDIT action button is available: Sorry - what am I missing? Can you send me a screenshot showing editable not being available in the restricted branch? Thanks for your help testing!

Sorry about that - I actually already added those screenshots (between you reading and then posting). It actually works the other way - it limits the users to see just the restricted branch. Take a look at the new screenshots and let me know if it makes sense. If you want something like you described, my unpublished AdminPageHider works for that except for child page counting issues.

I just turned this into a configurable module: https://github.com/adrianbj/AdminRestrictBranch Support Thread: https://processwire.com/talk/topic/11499-admin-restrict-branch/ @tpr - I'd love your feedback in particular on this, but hopefully others will find it useful too.

This module lets you restrict users to a certain branch of the page tree - it can limit editing permissions, as well as the page list view to this branch. http://modules.processwire.com/modules/admin-restrict-branch/ https://github.com/adrianbj/AdminRestrictBranch Restricted View Non-restricted View Note that this module does not add permissions (unlike how PageEditPerUser and PageEditPerRole work), so the user must have template level permissions to edit the pages in the restricted branch. What this does allow though is giving all users/roles editing access for the home template and allowing that to inherit all the way through the page tree and let this module restrict to specific branches. As you can see from the screenshots you can specify how to determine the branch to restrict the user to - either via a matched role name, or via a dedicated page select field on the user's profile. The match role name works like this - if you have a series of branches called: Branch One, Branch Two, etc, users with a role named: branch-one will only have access to Branch One. You can also decide whether to restrict page tree viewing as well and editing privileges (default) or just editing privileges. The Branch Exclusions option is important for things like external PageTable parent branches etc. Main module config settings User specific branch setting on user profile page This module came out of my personal needs as well as this discussion: https://processwire.com/talk/topic/11428-project-design-main-shop-hundreds-of-affiliates/ As always, feedback is very welcome.

Very nice looking site! Another responsive issue, or maybe a feature - just before it breaks from two items per row to one, the cart icon is no longer sticky - it is sticky on larger screens and on phone sized screens, but it looks like around small tablet size it is just up top. Does that make sense? Let me know if you need a screenshot.

Just updated the code above to fix a tree doubling bug when "open" is set and the page matches the branch parent. Also removed a PHP warning.

Right - sorry I understand - I didn't realize that there would only be one user/editor per branch. In my case there will be several per branch which is why the role approach makes sense to me, but in your situation, that makes perfect sense

I guess I am not understanding how selecting a "home_branch" for each user is easier than giving them a role. I am also using the role to control editing permissions for some pagetable templates as well, so in my case I think it is the logical approach, but obviously the home_branch field could work equally well or better with different requirements.

Just been playing around with limiting branch visibility and have something that seems to be working quite well - please test carefully for your needs though - I already had one false start with this! This lets a user only see a branch with the top parent "name" equal to the name of their role. For example if you give the users of each affiliate a role like: affiliate-1 this will match the name of the Affiliate 1 parent page (of course: affiliate-1) and that will be the only branch of the tree that will be visible. Providing a GET id variable limits the listed page tree to just the branch with that parent. Using this hook forces it to that all the time. As I said, I am not yet sure how safe/stable this is, but so far I like the results, although I am not sure about overriding $_GET['id'] like this. There is likely a better way! if(!wire('user')->isSuperuser() && !isset($_GET['id'])) { $this->addHookBefore('ProcessPageList::execute', null, 'setTreeRoot'); function setTreeRoot() { foreach(wire('user')->roles as $role){ $p = wire('pages')->get("has_parent!=admin, name={$role->name}"); if($p->id) { $pid = $p->id; break; } } $_GET['id'] = $pid; if(isset($_GET['open']) && $_GET['open'] == $pid) wire('input')->get->open = null; } } I am currently using this along with a modified version of the PageEditPerUser module which now works to also match the user's role to the parent page. So far so good, but I am expecting there is something I have overlooked - will keep things updated here.