Robin S

Looks like internally $sanitizer->date() is relying on strtotime() to check that the date is valid, and this function for some reason returns a timestamp for '2017/02/31' rather than 'false'. It should perhaps be changed to checkdate() which correctly identifies that date as invalid. In the meantime you could add an extra validation: function validate_date($value) { $parsed = date_parse($value); return checkdate($parsed['month'], $parsed['day'], $parsed['year']); }

I think you can do this with core PW fields, and enhance it with some custom JS if you want. Here's what I'm thinking... You have your Place pages in their own branch of the tree. The Place template has a repeater field "Offers" where all the possible offers for that Place are defined. Then you have a repeater field "Places" on your Partner template. You add two Page Reference fields to the repeater: 1. "Place", which is a single select field limited to the Place template. 2. "Choose offers" which is a multiple AsmSelect field using a "Custom PHP code" hook. The hook will return the value of the "Offers" repeater field (which will be a PageArray) for the place that is selected in the "Place" field. Now this hook is a bit trickier than normal because your Page Reference fields are inside a repeater and so you don't want $page to be the page being edited, but rather the repeater page that contains your fields. So in the hook you need to get the inputfield name and extract the ID integer portion of it and use that to get the $page object. I can explain more about this if you decide to go down this road. So this approach should work but it will require editors to save the page after choosing a place in the "Place" select, before they can choose offers for that place. If you wanted to enhance it a bit more you could have the "Choose offers" field allow all offers pages (limit using the Offers repeater template rather than a custom PHP hook) and then use some custom JS in admin to empty the inputfield options on load and on change of the "Place" select it gets the offers for that place via AJAX and populates the "Choose offers" options.

Issue has been opened on GitHub: https://github.com/processwire/processwire-issues/issues/183

It is only option D that forces the modal dialog editor. Option C allows inline editing - you just have to place edit tags around the individual fields in your repeater rather than around the whole repeater foreach(). For example: <?php foreach($page->my_repeater as $item): ?> <h3><edit <?= $item->id ?>.title><?= $item->title ?></edit></h3> <?php endforeach; ?> You're right that there does seem to be some sort of permissions issue for non-superusers, but rather than change access for the admin template (which non-superusers shouldn't have access to) I suggest you give edit access to your repeater template (select the "Show system templates" option to see repeater templates).

Did you check the front-end editing documentation when investigating your problem? It specifically advises against using option B for Repeaters:

@Juergen, you can create inputfield dependencies based on any arbitrary PHP/API code using the Custom Inputfield Dependencies module, but these are only evaluated when Page Edit is loaded/saved so it may not suit your needs.

@Macrura, I have released a new module PageTable Extra Actions that provides this feature.

PageTableExtraActions A module for ProcessWire CMS/CMF. Allows PageTable items to be published/unpublished and hidden/unhidden directly from the inputfield. Usage Install the PageTableExtraActions module. Use the icons in the "Actions" column of a PageTable field to publish/unpublish or hide/unhide an item. https://modules.processwire.com/modules/page-table-extra-actions/ https://github.com/Toutouwai/PageTableExtraActions/

Not sure - nowhere in the code you posted do you show where $pageArray is defined. What this error means is that $pageArray is a string and not an actual PageArray. Use Tracy to dump $pageArray and find out what is going on with it.

Sounds like you have found a solution that works - nice one. If I understand correctly, your options that may be selected in the Page Reference field are organised into categories according to the hierarchy in the page tree. So for example the hierarchy might be: - colour - red - green - blue - size - small - medium - large But don't you end up with a situation where an editor can ignore your custom button and use PageListSelectMultiple to select the page 'colour' or 'size' instead of one of the actual option pages? To make a more straightforward and foolproof UI you could create a custom inputfield module for the Page Reference field that organises the checkboxes the same as you are doing in the modal front-end page. It's not as difficult as you might think because as you found it's only the value of the hidden input that matters when it comes to submitting the form.

Sure, losing functionality is not good. Elsewhere I proposed a separate button for the cases where you want to add multiple templates. However, in terms of the total amount of convenience for the total number of users, I think the times you want to add fields and other settings immediately after adding a new template much outnumbers the times you want to add multiple empty templates and then end up back at Setup > Templates.

Not sure if this is the cause of the problem, but this line... if($options['useMarkerSettings'] && (count($pageArray) == 1 || !$lat)) { ...does not ensure that $pageArray exists. The if() condition is passed if $options['useMarkerSettings'] and !$lat, regardless of what $pageArray is.

Another approach would be to do a redirect in your template file: $session->redirect('http://www.webshop.com' . $page->url);

I get the feeling this feature is rarely used. I'd like to see it dropped in favour of not being booted back to Setup > Templates after creating a new template, and then having to reopen the settings for the template you just created to add a label, fields, etc. I find that much more a hindrance than I would not being able to create multiple empty templates.

FYI, you can add multiple templates in one go via the admin interface:

Selectors are your friend. $my_special_pages = $pages->find("parent=/, name=foo|bar|baz"); // or match by template, or anything else $my_other_pages = $pages->find("parent=/, id!=$my_special_pages"); // now build your menus from these PageArrays

I suggest you structure your pages based on how the front-end URLs should be (e.g. mydomain.com/page/subpage/) rather than how you happen to be styling your menus.

Yes, that would get tedious with PageListSelectMultiple. But can't you substitute a different inputfield? You say you are using checkboxes in your modal page: checkboxes are an inputfield option for Page Reference fields, so can't you just use checkboxes directly in your Page Reference field?

No problem.

You need to initialise/reset the $selected variable in each iteration of the loop. Otherwise two things will happen: 1. If the first child of /sectors/ is not in the whitelist array you will get an undefined variable notice. 2. After one child name is found in the whitelist array and $selected is defined as ' selected ' then all subsequent iterations will output ' selected ', regardless of if that input is in the whitelist array or not. This is the problem you are getting now. So it should be something like: foreach($pages->get("/sectors/")->children() as $sec) { $selected = ''; if(is_array($input->whitelist->cb_sectors) && in_array($sec->name, $input->whitelist->cb_sectors)) $selected = ' selected '; // echo, etc... }

Sounds like a useful thing to have. In terms of UI I imagine something like the action buttons in Page List, where publish/unpublish/hide/unhide buttons appear when hovering the title link in the table. Will investigate how this could be added. Not sure if it's something that belongs in LimitPageTable, or should be a separate module, or perhaps added to AdminOnSteroids. Will have a think.

I had a need to do this and there were some requests in the Table forum so... LimitTable A module for ProcessWire CMS/CMF. Allows limits and restrictions to be placed on selected Profields Table fields. For any Table field you can limit the number of rows that may be added and also prevent the use of drag-sorting and the trashing of rows. If a limit has been defined then there is an option to show all (empty) rows up to that limit. This module does not support paginated Table fields. Usage Install the LimitTable module. The module configuration screen should be self-explanatory. You can add rows in the module config as needed using the "Add another row" button. Please note that limits and restrictions are applied with CSS/JS so should not be considered tamper-proof. Module config: The effect of the above config in Page Edit. The empty rows up to the limit are shown because "Show all rows" is checked. https://github.com/Toutouwai/LimitTable https://processwire.com/modules/limit-table/

v0.0.3 released. You can now select multiple roles to be affected by the limit/restrictions, including the superuser role and "all roles".

v0.0.9 released. You can now select multiple roles to be affected by the limit/restrictions, including the superuser role and "all roles". @NikNak, I had a change of thinking on this issue and can now see that there are situations when it is useful for the module to affect superusers, mostly to serve as a reminder and prevent accidental changes. In any case a superuser can access the module config and so change any restrictions that are affecting them when needed.

If a whitelist value is null then it simply means you have not set anything to it at the time you are checking it. Going back to the earlier code example, you must set an array to the whitelist... $san_array = array(); foreach($input->get->st as $st) { $san = $sanitizer->selectorValue($st); $san_array[] = $san; $selector .= "projectStatus=$san, "; } $input->whitelist('st', $san_array); ...before you can use the array in $input->whitelist('st') to determine which checkboxes should be selected. The code above will appear in your search results template, and it must execute before (i.e. above) your code for generating the search inputs. Of course if you are showing your search inputs on other templates besides the search results template then $input->whitelist('st') will be null, but in those cases you don't want any of the inputs to be pre-selected anyway.