Robin S

PageListTrash Allows non-superusers to trash pages directly from Page List (if they have page-delete permission for that page). Not much to say really - the module adds a "Trash" option to the extra actions for pages in Page List. It looks and works just like the Trash action available to superusers. https://github.com/Toutouwai/PageListTrash/ Up to you whether you think non-superusers should be trusted with simpler trashing. For most cases I like the default behaviour where editors have to jump through some more hoops - I want them to think carefully about what they are doing. But if an editor needs to trash several pages then this module might reduce frustration. @tpr, by now you can probably predict what I'm going to say... ...something to merge into AdminOnSteroids?

The thing that can potentially allow Table to scale up to a very large number of rows is the ability to paginate the rows, both in output and in the admin interface. Pagination is not enabled by default but is an option. You could probably have 150 rows in an AJAX-loading repeater without a technical issue, but for both Table and Repeater you could have a bit of a usability issue with that number of rows. Imagine dragging a row from bottom to top for instance. And I don't know if that's even possible with a paginated Table interface (how do you drag from the last page to the first?). But these problems seem like they just go with the territory of what you are needing to do and the number of items you need to support. If you think you will work on more PW projects I'd say it's definitely worth purchasing ProFields. It's fantastic value for money, just for Table and Repeater Matrix alone.

Yes, that's what it boils down to basically. There are several reasons for this depending on the fieldtype to be edited, but in the case of a repeater PW has no idea what you are doing in terms of displaying your repeater output on the frontend - it gives you total flexibility there. So PW cannot really provide an inline frontend interface for drag-sorting repeater items for instance, because there is no guarantee you are even presenting all of your repeater subfields contiguously inside a single containing div. So I think you'll need to resign yourself to modal editing unless you are up for some serious custom frontend interface work. I'm curious to see the existing interface your client is using - it sounds quite fancy. Maybe you could post a video? (LICEcap is useful) Repeaters scale to a medium level fine so long as you use the AJAX-loading setting. I haven't tried Table with frontend editing but I think any fieldtype becomes editable via a modal.

I'm a bit confused about exactly what you want to do, but it sounds like the default frontend edit behaviour (where non-superusers edit a repeater field via a modal) is exactly what you need. When your editor goes to edit anything in the repeater on the frontend they get a modal where they can edit any of the fields within a repeater item, add new repeater items, delete them, drag them, etc. In your template file you surround the entire repeater foreach() with edit tags (editing method C or D) - have you tried this yet?

I haven't followed this discussion closely so sorry if I'm missing the point here, but I believe you can override the append/prepend files directly when you render a page with $page->render(). echo $p->render( ['prependFile' => null, 'appendFile' => null] );

@joshuag, I think I have fixed the uninstallation issue. I found a few other issues in the module code too - I will PM you with the details.

Just something I was trying out recently that might be useful to someone... With the following hook added to /site/ready.php you can adjust the CKEditor toolbar that a particular role gets for a particular field. Use the name of your CKEditor field in the hook condition. $this->addHookBefore('Field(name=my_ckeditor_field)::getInputfield', function(HookEvent $event) { $field = $event->object; // Define toolbar for a particular role if($this->user->hasRole('editor')) $field->toolbar = 'Format, Bold, Italic, -, NumberedList, BulletedList, Outdent, Indent'; }); Or what I find useful on some sites is adding extra toolbar buttons for superuser only that you don't trust editors to use. $this->addHookBefore('Field(name=my_ckeditor_field)::getInputfield', function(HookEvent $event) { $field = $event->object; // Add extra buttons for superuser only if($this->user->isSuperuser()) $field->toolbar .= ', Table, TextColor'; }); You could use the same technique to selectively define other CKEditor settings such as 'stylesSet', 'customOptions', 'extraPlugins', etc.

Superusers may edit individual repeater items inline (not in a modal) but non-superusers may not. There's an open issue regarding it (with a possible workaround you can use at your own risk) but based on Ryan's comment here I think he is not inclined to view this as a bug to be fixed.

No solid solution but just wanted to say that you're not alone - I get this from time to time too. Sometimes I can solve it by rebooting all my devices.

FYI, a while ago a wrote a little tutorial demonstrating how an array_chunk method can be added to WireArray:

Hi and welcome @dscONE! Yes, I do think the behaviour you have discovered is unexpected. Just to reiterate in a simplified way what I think you are saying.... The expected behaviour is that for any selector, the combined results of $pagearray->find($some_selector) and $pagearray->not($some_selector) should equal the entire PageArray. But this is not the case, as can be demonstrated with a PageArray containing three pages titled "red car", "blue car", "green truck"... $matches = $pagearray->find("title~=car"); // "red car", "blue car" $not_matches = $pagearray->not("title~=car"); // "green truck" // So far, so good $matches = $pagearray->find("title~=car, !title~=red"); // "blue car" $not_matches = $pagearray->not("title~=car, !title~=red"); // expected "red car", "green truck" but got unexpected empty PageArray Would you please report this issue over at the PW issues GitHub repo? https://github.com/processwire/processwire-issues/issues

I'm guessing he is talking about the profile edit interface (ProcessProfile). There are a couple of places where the module assumes/requires ProcessPageEdit.

Just be aware that, as with the similar change made to SelectizeImageTags, the module will now require a minimum of PW v3.0.61 - would be good to add that as a requirement in getModuleInfo().

That # symbol has bugged me too: https://github.com/processwire/processwire-issues/issues/284 When you look into the Repeater module code it seems very much like that symbol only exists to allow a Javascript fix to a problem that could be easily solved in the module PHP.

A post from Ryan where he shows how you can use MarkupPagerNav to paginate an image field: https://processwire.com/talk/topic/390-images-pagination/?do=findComment&comment=2928

Sorry for the late reply; I have been on holiday for a while. This module acts only on changes to a Page Reference field - this is deliberate for reasons of efficiency. If you already have some Page Reference values in place before you start using the module on those fields then you can get things set up with a one-off API operation: // Get all pages where page_field_a is not empty $pgs = $pages->find("page_field_a.count>0"); // Get derefAsPage property of page_field_b to distinguish multiple/single page fields $deref = $fields->get('page_field_b')->derefAsPage; foreach($pgs as $p) { // For this page, get the pages selected in page_field_a $selected_pages = $p->page_field_a; // Standardise $selected_pages to PageArray in case of "single" field if($selected_pages instanceof Page) $selected_pages = $selected_pages->and(); foreach($selected_pages as $selected_page) { // Add this page to page_field_b on the selected page $selected_page->of(false); if($deref) { $selected_page->page_field_b = $p; } else { $selected_page->page_field_b->add($p); } $selected_page->save(); } } You can do a similar operation for page_field_b -> page_field_a if needed. Once you set up the Page Reference field pair in the module config then the module will take care of all changes from that point onwards.

I haven't tested it much but it looks like you can hook Page::getMarkup() $wire->addHookAfter('Page::getMarkup', function(HookEvent $event) { $page = $event->object; if($page->template->name !== 'TEMPLATE(S)_USED_IN_YOUR_PAGE_FIELD') return; $out = $page->title; // add more stuff to $out using $page $event->return = $out; });

Right, gotcha. Actually, this module is not installable either despite the requires property being consistent with the module documentation. So I think it's an issue with ProcessModule and/or the Modules directory JSON generator and it should be reported to Ryan.

You can do this... $items = $pages->find('template=product-item, action=1, !outlet=[status=published]'); $group_items = $pages->find('template=product-item, action=1, outlet=[status=published]'); ...but I don't think unpublishing Group pages is a good strategy, because unpublished pages do not appear as an option in a Page Reference inputfield. So it means that in Page Edit you cannot distinguish between a product that has no Group selected, and a product that does have a Group selected but the Group has been unpublished. What I would probably do is create a new Page Reference field "group_status" with selectable pages "Active" and "Inactive", and set the "Active" page to be the default value. Add this to the Group template. Then in the Outlet field, include the group_status field in a custom format for "Label field" so you can see the status of each group in the Outlet inputfield. You can have both if you use the ConnectPageFields module.

PW creates thumbnails for files uploaded to an image field, so the file type needs to be something that the ImageSizer supports. Webp is not yet supported. If you just need the path then you can use a file field.

That does look strange, but I think it might be normal. It seems to apply to all modules: http://modules.processwire.com/export-json/oauth2-login/?apikey=pw300 And if the values are blank then I would expect it not to apply any restriction. I see that you have module info defined it two places - maybe that is the cause of the issue? https://github.com/outflux3/SelectizeImageTags/blob/d4160b20f40e05840b6cb5d947fb63b3a95aeb4c/SelectizeImageTags.info.php#L4-L20 https://github.com/outflux3/SelectizeImageTags/blob/d4160b20f40e05840b6cb5d947fb63b3a95aeb4c/SelectizeImageTags.module#L7-L22

I've never tried setting the module info conditionally like that (or the external info.php approach), but it looks like it should work. Tracy should help here to check the resulting $info array.

The issue won't be related to the upgrade method because the error message is different. So it must relate to the 'requires' property in the getModuleInfo() method. I note that above you say that JquerySelectize is not to be required. So you would want to remove that module from the 'requires' property if you haven't already, and perhaps check for it in the install/upgrade methods depending on the PW version.

This should do the job: $(window).load(function(){ var $repeater_wrap = $('#wrap_Inputfield_YOUR_REPEATER_FIELD_NAME'); if($repeater_wrap.length && !$repeater_wrap.find('.InputfieldRepeaterItem').not('.InputfieldRepeaterNewItem').length) { $repeater_wrap.find('.InputfieldRepeaterAddLink').trigger('click'); } }); It won't work for nested repeaters though - for that you'd have some more work to do, ensuring you get direct child elements of $repeater_wrap, and dealing with the fact that inputfields inside a repeater item have changed names. But it may not be such a good idea to open a new repeater item on page load. The issue is that you are actually creating a new repeater item when you do this, so that if the user saves without filling out the repeater fields you will end up with a blank item. And if any of the fields in the repeater are required the user will see error messages.

With a bit of hooking it is possible to both dynamically control the selectable pages for a PageAutocomplete inputfield, and dynamically set the parent/template of new pages created from the inputfield. I have only played around with this and haven't used it in production, so use it at your own risk. Dynamic selectable pages for PageAutocomplete The idea is that in the field settings you define a broad selector that includes all of the pages you might want to select. It could be something really broad such as "has_parent!=2". Then you modify the selector in a hook according to the page being edited. In /site/ready.php... $wire->addHookAfter('Field::getInputfield', function(HookEvent $event) { $field = $event->object; $inputfield = $event->return; // Only for this one Page Reference field if($field->name !== 'test_page_field') return; // Only for ProcessPageEdit if($this->process != 'ProcessPageEdit') return; $page = $this->process->getPage(); // Get findPagesSelector (or findPagesSelect if you used that) $selector = $inputfield->findPagesSelector; /* Now append to or overwrite $selector however you like, depending on $page maybe. You can even define some $allowed PageArray like with the "Custom PHP code" option that is possible with other Page inputfields, and then use it in the selector as "id=$allowed". But note that there is a 500 character limit enforced on selectors. */ // Set the modified selector back to the property you got it from $inputfield->findPagesSelector = $selector; }); Dynamic parent and/or template for pages created from the inputfield The idea is that in the field settings you do not define a parent or template for allowed pages, but then set these properties in a couple of hooks according to the page being edited. In /site/ready.php... $wire->addHookBefore('InputfieldPage::renderAddable', null, 'dynamicParentandTemplate'); $wire->addHookBefore('InputfieldPage::processInputAddPages', null, 'dynamicParentandTemplate'); function dynamicParentandTemplate(HookEvent $event) { $inputfield = $event->object; // Only for this one Page Reference field if($inputfield->hasField->name !== 'test_page_field') return; // Only for ProcessPageEdit if(wire()->process != 'ProcessPageEdit') return; $page = wire()->process->getPage(); // Now set $parent_id and $template_id dynamically depending on $page $parent_id = 1234; // demo value $template_id = 56; // demo value $inputfield->parent_id = $parent_id; $inputfield->template_id = $template_id; } Have fun!