adrian

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.

What an awesome writeup - great find kongondo!

Some more info on that error: The error is coming from PW itself because it looks like every DB field needs a value for the entry to be successfully saved. You should be able to replicate by removing one of the fields from the comma separated list of extra fields, or by simply uninstalling image extra and then trying to upload an image.

Another critical issue - when using an image extra field within a PageTable, the extra fields show up under the image and appear to be editable. You can make changes to the content of these fields, but of course they don't get saved when saving the main page which is very confusing for the user.

Thanks for the details. I have also been using Admin Page Hider ( since I built it ), and it is working well at my end. However I am tempted to make it optionally work in reverse so that all pages are hidden from all users unless the user's role is listed in the Admin Page Hider settings for that parent page - or something along those lines. Would make it much more efficient than having to hide all new branches as they are added. Any thoughts on this?

Hi @tpr - I am curious how you set this up - I have a similar situation and went with the Dynamic Roles module, but I am not super happy with this approach, so I'll probably end up with a custom hook to further limit access to specific page trees (given that each page tree shares the same templates). Anyway, I'd like to hear how you accomplished this, as I am sure would others.

Check out the latest version of PW - 2.7 just released. EDIT: Sorry, just read that you want it limited to specific pages. For this you might be better off with the dynamic roles module. I haven't checked if it can do exactly what you want, but worth a look: https://github.com/ryancramerdesign/DynamicRoles Be aware that it does have a critical bug right now that might or might not affect your use: https://github.com/ryancramerdesign/DynamicRoles/issues/14 Alternatively if none of these work as needed, you should be able to create a simple hook to check if the page matches you rules and prevent the title from being changed. No time for an example right now, but maybe someone else will chime in.

return $page->parent->parent->children();

Depending on your setup, you could probably make use of the "Custom PHP code to find selectable pages" option and reference the $page->parent or $page->parent->parent - hopefully you get the idea.

If my screenshot is what you want to achieve, then it's very easy. Here are the settings for the details tab of the field: And here is the page tree that is being referenced: