Leaderboard

This module enables you to limit edit access (by role) to any field in the page editor. This essentially provides field level access control on top of the existing access control system. It removes access to fields within a template, which is something that the built-in access control does not currently do in ProcessWire. This gives you a nice and simple granular control of fields. For instance, you might have two users (with different roles) that have access to edit a page, but only one of them could edit a particular field you had limited access to. Another example might be if you (the superuser) wanted to keep a notes field that only you would see in the page editor. But those are just simple examples, and the possibilities are quite broad. I've been wanting to find a way to provide field-level access for awhile, so this module has been on my mind for a bit. But what motivated me to finish it was a need that came up earlier today by Raymond Geerts in this thread where he needed the ability to limit access to fields on the page's settings tab... this module would do that quite nicely. http://modules.processwire.com/modules/page-edit-field-permission/ https://github.com/ryancramerdesign/PageEditFieldPermission How it works This module hooks in to modify the behavior of Page::editable, which is used throughout ProcessWire, but most notably by Page Edit. This module looks for permissions in the system that follow the name format of page-edit-[field] where [field] is the name of an existing field in the system. When it finds such a permission during a Page::editable call, it checks to see if the roles from the current user have this permission assigned. If they do not, then permission to the relevant field is refused, thereby preventing edit access to the field. This module also hooks into the Page Edit process and simply removes fields that the user doesn't have access to edit, before the form is rendered or processed. How to use it Once the module is installed, you get a set of checkboxes on the module configuration screen. Check the boxes next to each field that you would like it to create permissions for. (Alternatively, you can create the permissions yourself, so this is just a shortcut). You should only create permissions for fields that you intend to limit access to. Once your new page-edit-[field] permissions are created, any non-superuser roles that previously had access to edit those fields will no longer have access to edit them. To give them access, you must edit a role and check the box for the relevant permission.

It's certainly possible, you just have to create a page in the root for each of those, and the article as children of them home -articles (template articles) --article 1 (template article) --article 2 (template article) --article 3 (template article) --... -music (template music) --song 1 (template song) --song 2 (template song) --song 3 (template song) --... -video (template videos) --video 1 (template video) --video 2 (template video) --video 3 (template video) --... -... Then, in each template do this, adapting with the relevant info for each one foreach($page->children as $c){ echo $c->title; } for the feeds you can use the RSS Feed Generator module http://modules.proce...les/markup-rss/ and use it like this: create a page for each feed with it's own template, then do for each one $rss = $modules->get("MarkupRSS"); $rss->title = "Articles"; $rss->description = "All the articles"; $items = $pages->find("/articles/")->children; $rss->render($items); Do the same for the others. Read the module instructions for some configuration options.

Firstly I am loving the CMS, so glad that I found it. I have worked with and tinkered with many and literally non have excited me except this one. I only started playing yesterday and I have a few questions I'd appreciate some advice on: tokens/sanitization/html fields For some of my fields I would like to be able to use tokens for example "It's in the [highlight]Game[/highlight]". Failing this I would like to create simple single line fields which accept some html tags like span/em/strong. Also in the stock installation I don't see a field that allows html - just a "Text" field. Thanks!

If u set advanced mode u can set an option on the template system or advanced tab to move name to content.

I see what you mean, I was forgetting about the status settings. Also, I do the same thing with page 'name', but admittedly have never had a problem with a client changing it when they weren't supposed to. But this is all easy to overcome with a module. I think this will accomplish what you want to do. I've also tested this to confirm, so it should work out of the box. As it is now, it'll deny access to editing of name, parent, template, status for everyone except superuser. But I put in variables at the top where you can add additional templates or roles that should fall-back to the default permission checks as if the module wasn't here. One thing I want to note is that PageEdit doesn't perform a permission check before displaying the status checkboxes. However, it does perform a check before saving them. So the user may see them, but they won't be able to change them (which is probably just as good). Code is pasted below, but I'm also attaching the file if you prefer to download it instead: CustomPagePermissions.module class CustomPagePermissions extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'Custom Page Permissions', 'version' => 1, 'summary' => 'Starter/example module to enable customization to page field permissions.', 'singular' => true, 'autoload' => true, ); } // names of fields that you want to deny access to protected $denyFields = array('name', 'status', 'template', 'parent'); // optionally specify names of templates that will be excluded from these permission checks protected $skipTemplates = array(); // optionally specify names of user roles that will be excluded from these permission checks protected $skipRoles = array('superuser'); // attach the hook public function init() { $this->addHookAfter('Page::editable', $this, 'hookPageEditable'); } // perform the editable() check public function hookPageEditable($event) { // if editable() already denied access, then don't continue if(!$event->return) return; // if user has one of the 'skip' roles identified above, then skip permission check foreach($this->skipRoles as $name) if($this->user->hasRole($name)) return; $page = $event->object; $fieldName = $event->arguments(0); // if page template is one you want to skip, then we'll return if(in_array($page->template->name, $this->skipTemplates)) return; // if fieldName is one of those listed, we'll deny access if(in_array($fieldName, $this->denyFields)) $event->return = false; } }

You should also be able to do this: $biology_students = $pages->find("template=student, subject=/subjects/biology/, sort=title");

The current dev branch is meant to be 2.3. I'm planning to add a little more to do it, but will be final before the years end. I do think its safe to use the dev branch if you keep an eye on it. I am currently using the dev branch in all my projects. The only reason I'm not bringing the changes over to master individually is because there are a couple bigger ones in there (database session support and change to blowfish for password hashing). I think those need to accompany a version number for safety. But I could definitely use help testing the dev branch since it will become 2.3 very soon.

Actually there is. http://modules.processwire.com/categories/textformatter/

I think you could check the "last modified date" of the file itself with php: foreach ($file_pages as $file_page) { int modified = filemtime($file_page->filename); echo "last modified" . date('d-m-Y', modified); } Not testet and assuming that ->filename returns the path + the filename itself

I logged in and saved the page, it's back now.

Usually sanitizing is done through textformatters: edit field => details tab => textformatters. I think there is HTML entity encoder on headline field, you can remove it if you want to. Other way is to sanitize when outputting and third way would be using some kind of autoload module (but I think there is little reason for that because of textformatters).

Ryan: that makes sense.. and thanks for the example. Hooking right after ProcessController::execute did the trick in this case

he re.u go reno bird

Thanks Steve! That's very kind of you. What you may not know is that I've been raising my beer glass to all of you this whole time. Here's the rest of my profile photo