sgt.blikey

It would be helpful to have a bit more flexibility on this field type. What about, instead of any extension, an option for no extension? Use case: storing configuration files in a knowledgebase system. It is a little inconvenient to be required to rename a file or add an extension in order to upload, and once more when downloading. I appreciate it isn't a major headache to have to do that, but it all goes towards usability.

You're right, the hidden version of the field is not populated. The field is populated only after changing its visibility to something other than hidden, and then editing/saving a page. Thanks for clearing that up.

No, I'm not sure of this actually. I've been changing the visibility setting from hidden to something else, e.g. closed. Subsequently, when viewing the page, the field is populated, but I haven't tested whether the value is correct-ish so I do not know whether the field is populated when the page is created or when the attribute is changed from hidden to closed.

Oh, I forgot about that field. That is what I need, but I'm curious about the above.

How do you determine whether the field has been populated? If the field is hidden, where do you view the content of the field? I mean, if a field is hidden and auto-populated, how can you see its value?

Howdy, What am I misunderstanding? I have a date time field and have specified that children of template 'home' should be (reverse) ordered by that field the field should default to todays date input and output formats I have added the field to the template 'basic-page'. When, under field settings > input > visibility, I have set it to 'Closed' the field is populated when a new page is created and the page is ordered correctly under Home. When, under field settings > input > visibility, I have set it to 'Hidden (not shown in the editor)' the field is populated when a new page is created but the page is ordered incorrectly under Home and subsequent reloads of the page tree do not resolve the issue. Changing the option for the field back to 'Closed' doesn't reorder the pages under Home according to the rule. Why is that happening? Nic

Oh, they're in there are they? Okay so I should have: $ grep -R page-edit-created * Thanks for pointing me in the right direction. For pedantry's sake I've gone with: if(!wire('permissions')->has('page-edit-created')) { $permission = wire('permissions')->add('page-edit-created'); $permission->title = 'Edit only pages user has created'; $permission->save(); }

@adrian thanks. I wonder where the names/titles are coming from when populating the form/table in the function beginning here. https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/modules/Process/ProcessPermission/ProcessPermission.module#L37 protected function getOptionalPermissionsForm() Does this line suggest they exist as pages? https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/modules/Process/ProcessPermission/ProcessPermission.module#L51 $optionalPermissions = $this->wire('permissions')->getOptionalPermissions();

I would like to check for and enable the predefined system permission 'page-edit-created'. I am currently working in a 3.0.27 installation. When the permission is enabled in the admin, it has a title, 'Edit only pages user has created'. I am using the following code (in the context of a module): if(!wire('permissions')->has('page-edit-created')) { wire('permissions')->add('page-edit-created'); } This creates the permission, but leaves the title blank. Deleting this api created version via the admin restores the title, that is it seems to restore the default version of the permission. Is there an alternative to add, e.g. enable, that enables the permission as defined by the system? Am I checking for its presence correctly? Thanks!

Surprising myself, I have figured out how to hook into Page::addable. class MemberBranchAddable extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'Member Branch Addable', 'version' => 3, 'summary' => 'Grant addable access to users on their member page', 'singular' => true, 'autoload' => true, ); } /** * Attach hook to Page::addable * */ public function init() { $this->addHookAfter("Page::addable", $this, 'addable'); } /** * Page::addable hook * * Add children permission is granted based on edit. * If they have edit access, then they can also add children, * but only apply this if the $page->template = 'member' * */ public function addable(HookEvent $event) { $page = $event->object; // If page template is $singular continue // That $singular should come from the // configuration if ($page->template->name == 'member') { // If page is editable and generally can have children, then allow addable if ($page->editable() && !$page->template->noChildren) { $event->return = true; } else { $event->return = false; } } } Which takes care of: And removes the requirement to manually edit wire/modules/PagePermissions.module

An additional specification. MemberGalleries (an index page)Gallery A Gallery B Journals (an index page)Journal 1 Journal 2 Allow, for each member page, one and only one page of template 'gallery-index' and one and only one page of template 'journal-index'. For the Member page, if there exists a child page of template 'gallery-index' and a child page of template 'journal-index' then do not offer 'new' in the page tree options for page Member. Otherwise offer the 'new' option and when the Member has advanced to /page/add/ if there exists a child page of template gallery-index, offer journal-index; and if there exists a child page of template journal-index, offer gallery-index. An extension of the Family > Can this template be used for new pages? Yes/No/One (no more allowed)/One per parent (no more allowed)

As far as I can see it isn't possible to achieve this with the built-in permissions. You'll have to modify the source files. I don't know which files you need to change, but someone might chip in. Given the following tree... Home -- Un-editable Index Page 1 ---- Editable Child Page A ---- Editable Child Page B -- Un-editable Index Page 2 ---- Editable Child Page C You will have to add clauses to the appropriate files that allow for a user with a role.. To move/sort Child Page A/B underneath Index Page 1 To move Child Page A/B to be a child of Index Page 2 etc. You might reasonably expect that the page-edit attribute applies only to the page content, but I don't think it does.

@Olli I am doing the same (with the code from post above #6) I get my child pages $posts = $page->children; I loop through the posts: foreach($posts as $p){ $pbody = $p->wordLimiter("body", 100); echo($pbody); } & this produces the desired output.

That's weird, I was looking at this site about a year ago. What a metamorphosis.

Note. I think inserting images from within CKEditor is being managed by ProcessPageImageSelect.module, which is using ProcessPageList.module to build a list of pages to select an image from, which I think is using haspermission("view") to construct a tree. Something like this: https://processwire.com/talk/topic/6315-processpagelist-to-hide-some-pages/?hl=processpagelist