Robin S

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!

Just some explanation because it is interesting... This isn't something that is specific to Repeaters - it applies to any selector used on a PageArray/WireArray (a Repeater field returns a PageArray). When you do $some_pagearray->find() this is different to a $pages->find() - the method name is the same but they are actually totally different methods. See find() method in the PageFinder class vs the WireArray class. When using $pages->find() the method refers back to the fieldtype for each queried field and the fieldtypes can do some special preparation to the queried value. In the case of a Datetime field the value is passed through strtotime() if it is a string. So this allows "today" to be converted to a timestamp. But when using $some_pagearray->find() this process does not happen, so the queried value must be a timestamp. Another gotcha to watch out for is using the page status as a string in a selector. With $pages->find() you can do something like "status!=hidden" but this won't work with a selector in $some_pagearray->find(). I think it would be nice if things like this did work with PageArrays - there is an open request for it.

Most of the hookable methods in the Pages class have $page as their first argument. So you get $page in your hook like so: $page = $event->arguments(0);

Users are pages so you have all the hookable methods in the Pages class too ('added', 'publishReady', etc). So you make the code in the hook conditional on the page template being 'user'.

Whoops, somehow overwrote my original post. I recall striking this problem too. The code below works for me on a front-end AsmSelect inside a FormBuilder form - should be the same on the backend. In this case I am adding/removing items from the AsmSelect when a grid square on a map is clicked. // Add hectare to AsmSelect $map.on('click', '.sponsorable:not(".selected")', function() { var hectare = $(this).data('hectare'); $('#Inputfield_hectares_to_sponsor').children('option[value="' + hectare + '"]').prop('selected', true).end().change(); }); // Remove hectare from AsmSelect $map.on('click', '.sponsorable.selected', function() { var hectare = $(this).data('hectare'); $('#Inputfield_hectares_to_sponsor').children('option[value="' + hectare + '"]').prop('selected', false).end().change(); });

I think we need something like UserVoice for PW feature requests, so Ryan and other core developers can gauge the level of support for individual requests and prioritise accordingly. It would actually be good to have the same for PW issues, so we can get an indication of which issues are particularly problematic to the largest number of users.

Related modules... PageEditPerUser - it's not explained in the module description but there is a option to allow access to descendant pages of a page where edit access has been given. AdminRestrictBranch Edit: just realised you are talking about the front-end and not back-end. Sorry, disregard.

In a current project I am using a Repeater field to build a kind of pseudo-table, where each Repeater item is a row. Some of the rows are headers, and some have buttons that toggle corresponding checkbox fields in a hidden FormBuilder form. The problem was that when the Repeater items were collapsed I couldn't see which rows were headers and which contained buttons. I tried including the fields in the Repeater labels but it still didn't provide enough visual difference to be quickly recognisable. So I investigated how classes could be added to selected Repeater items in admin depending on the value of fields within the Repeater items. This is what I ended up with... In /site/ready.php // Add classes to selected service row Repeater items $this->addHookAfter('InputfieldFieldset::render', function(HookEvent $event) { /* @var $fieldset InputfieldFieldset */ $fieldset = $event->object; $attr = $fieldset->wrapAttr(); // Fieldsets in a Repeater inputfield have a data-page attribute if(isset($attr['data-page'])) { // Get the Repeater item $p = $this->pages((int) $attr['data-page']); // Check field values and add classes accordingly // If item is a header if($p->row_type && $p->row_type->id == 2) { $fieldset->addClass('header-row'); } // If item has a checkbox button if($p->fb_field) { $fieldset->addClass('has-checkbox'); } } }); In admin-custom.css (via AdminCustomFiles) /* Special repeater rows */ .Inputfield_service_rows .header-row > label { background:#29a5aa !important; } .Inputfield_service_rows .has-checkbox > label .InputfieldRepeaterItemLabel:before { font-family:'FontAwesome'; color:#73cc31; content:"\f058"; display:inline-block; margin-right:6px; } Result

Not sure if it could cause the issue, but in your copyParent() function you could try find() instead of findMany() - no need for findMany() when you have a limit of 50. Also, the selector you posted looks a bit off: $tx = wire('pages')->findMany("template=transaction-earn, start=$start, limit=$limit, sort=transactiondate, [tagreference=$tag, merchantreference=$merchant]"); What is going on with the section in the square brackets at the end? Looks a bit like a subselector but you are not matching it against a field.

Hi @joshuag, unfortunately this update does not resolve the problem I am having with uninstallation. When I do the following steps... Remove the existing module files Add the updated module files Do a modules "Refresh" Clear compiled files ...I still get the PHP timeout when I try and uninstall, regardless of which sub-module I try and uninstall from. Sometimes timeouts like this are caused by a circular reference in the code. I'm wondering about the fact that each sub-module installs and uninstalls all the others. That seems non-standard to me: normally where there are multiple sub-modules there is one "main" module file that installs/uninstalls the others. The other modules only require the main module but do not install/uninstall them. See FieldtypeRepeater for example. Could there be some circularity where FieldtypeRecurme tries to uninstall ProcessRecurme, which tries to uninstall FieldtypeRecurme, which tries to... and so on?

There is the Page Reference with Date Field module that might be useful for this sort of thing. I've never used it and the module page doesn't indicate that it is compatible with PW3. But the real problem with using Page Reference fields for likes or any purpose that could potentially use thousands of pages is that there is no pagination or limiting possible when getting the field value. So it's not just a matter of dealing with the inputfield in Page Edit but also the impact on memory when getting the value via the API. There's an open request about this but no sign of activity.

@joshuag, you say in the email: I think it would be good if you do bump the version number each time you make a release even if it is for bug fixes. Otherwise it isn't clear from the PW modules listing whether that installation has been updated to the latest version, so it's harder to keep track if you have multiple sites running Recurme. Also, it will be easier for you in terms of support if you can ask what the installed version number is and know from that what release of Recurme the user has installed.

I'm not seeing any jumping problem with scrolling/dragging/swiping in Chrome on Windows or in Safari on iPad. But from an interface design point of view I think there is a bit of an issue in that there is nothing to indicate that there are multiple items in the work section and that the user should should scoll/drag/swipe to see more.