Page Reference Input fieldtype: Checkboxes - more advanced options

[cst989]

Currently the option to list all pages as checkboxes is very basic:

I would really like (please inform me if something like this already exists), something which

• Has check all/none controls
• Indents child items/highlights parent items
• Pagination/load more for long lists
• An option to check all children of a parent item

I know there are other more comprehensive systems, but they are focused on expand/reveal controls, re-ordering etc.

The use of this would be if you're creating a page, and you want to determine which other page the content appears on.

Edit: I'd also happily take suggestions on better ways to do that!

 

Edit: A better way to word this would be: the Page List Select Multiple input type, but with checkboxes for each item, plus secondary checkboxes on parent pages for selecting all child items. Currently when you pick any option from the list in Page List Select Multiple, it's added to a separate list and the list collapses, meaning you need to re-expand everything just to pick the next page in the list.

[dragan]

I'm not sure, but maybe you could use selectize: https://processwire.com/talk/topic/13549-selectizejs-modules-family/

 

Also, there's an option in the Admin On Steroids module to check/uncheck all radio buttons, if I'm not mistaken. Not sure if it works with checkboxes.

As for intending: Inspect the checkboxes and see if there's any CSS classes you could use in a custom admin CSS.

[adrian]

22 minutes ago, cst989 said:

Has check all/none controls

Not quite the same, but you can currently select the first item and if you hold down shift while clicking the last, all will be selected.

[cst989]

Yeah there's various practical ways I could do this to make it easy for myself, but as a user friendly option for a third party, I'd need something a little more robust. 

[bernhard]

you could do something like this:

<input type="checkbox" id="checkall">
<script>
$('#checkall').on('click', function() {
  $('#yourfield').find('input[type=checkbox]').prop('checked', true);
});
</script>

i don't think there is a need to "bloat" processwire with features when you get simple and taylormade solutions on google or the forum within some hours  

edit: i know the feeling of looking for plugins and solutions by the CMS for almost any feature you want. but the main feature of processwire is that it so so easy to adopt to your needs that you do not need all those ... plugins  

[Robin S]

On 15/11/2017 at 6:28 AM, cst989 said:

Indents child items/highlights parent items

The selectable pages for a Page Reference field can come from anywhere in the tree - this could be hugely nested and several levels of parents may not be included in the selectable pages. So I don't think it would be possible to reliably and accurately display the tree structure for a list of checkboxes.

On 15/11/2017 at 6:28 AM, cst989 said:

Pagination/load more for long lists

Pagination is not supported in any type of Page Reference inputfield or in the value that is returned by a Page Reference field. It would be fantastic if it was, because the current state of affairs limits the extent to which Page Reference fields can scale up. It's one of the big limiting factors for PW in my opinion. There is an open GitHub request that you could add support to if you like.

The way you are using the Page Reference field is not typical I think so perhaps not likely to become supported in the core. More typical would be to use a Page Reference field on the website pages to select a call-to-action page. You could possibly add Connect Page Fields to have the relationship work both ways and get an overview from the call-to-action page. Note also that you can use a custom label format for your inputfield to include the name of the parent page(s) if you want to get a sense of how nested the selectable pages are. 

Using a hook to set the label would give you greater control.

Lastly, it's not outside the realm of possibility to create your own custom inputfield, using InputfieldCheckboxes as a starting point.

[elabx]

Just to elaborate a bit more on @bernhard's suggestion, you could hook into the Inputfield::render method and draw some other stuff you need right there inside the inputfield (for the check all/none functionality). I think a good example is in HelperFieldLinks code. Here is also an example on how you could add also the necessary Javascript.

@Robin S Pagination in Page Table would be awesome. 

[bernhard]

hm.. ok i get the point  when we are talking about the pagefield in general i agree that it can be limited at some point.

i connected it to my datatables module to get a filterable, paginated list of selectable options:

but in this case i'm only browsing many pages... i've never had the need to reference a lot of pages in a pagefield. can you give me some examples when you needed this @Robin S ?

[Robin S]

1 hour ago, bernhard said:

i've never had the need to reference a lot of pages in a pagefield

An example would be if you want to use a Page Reference field to store "likes", where each user that has liked a page is added to the field. For a large site with thousands of users this becomes a problem.

There would be plenty of other examples for sites with very large numbers of pages. Pages (in the broad sense of being some grouped data) are of course central to the PW philosophy. And Page Reference fields are the primary way to make connections between pages. So it's important that this be able to scale up for PW to be seen as a credible candidate for large projects.

[bernhard]

mhm, interesting  ok, thousands of likes in one pagefield would not be possible. but what about a solution like this in such cases?

should'nt it be possible to handle thousands of likes that way? it would be easy to store likes (or any other datatype) via the api and it would be easy to retrieve them. it would also be possible to show them in a paginated way with a runtime markup field and a lister (i guess). or (one day) maybe even with my datatables module (if anyone wants to join me on this project it would be appreciated)...

dont get me wrong. i don't want to disagree about this, but i don't really get an idea of how a page reference with thousands of pages could look like. we also have the profields table that creates a database table with desired columns. only the interface for editing lacks support for large data.

maybe the problem is just to have a proper way of presenting a large amount of pages inside the page editor (inside a field)? maybe my datatables would fill that gap? i'm using it all around in my projects, so i think there is a need for it. and i think it would be a great addition to processwire. do you agree or are you talking about something different?

[Robin S]

8 hours ago, bernhard said:

i don't really get an idea of how a page reference with thousands of pages could look like

8 hours ago, bernhard said:

we also have the profields table that creates a database table with desired columns. only the interface for editing lacks support for large data

The inputfield could be approached a similar way to Profields Table, which does support large amounts of data through limiting and pagination. It was the introduction of pagination within Table that prompted my GitHub request. 

But although an inputfield solution is important it is the API side that is of greater importance. Currently you cannot do anything with the value of a Page Reference field without loading all the pages into memory. So if you have a Page Reference field with 2000 items and you do...

$item = $page->my_page_reference->first();

...or...

$item = $page->my_page_reference->findOne("name=foo");

...then boom, you have 2000 pages loaded to memory. It's not like $pages->find() or $page->children() where you can be selective or limit what is loaded.

Compare with $page->children(): parent-child is one kind of basic relationship between pages. Page Reference is the other kind of basic relationship between pages. Both of these relationships should be able to scale up, but currently only parent-child does.

This discussion probably warrants it's own topic. 

[cst989]

Thanks everyone for your input, you've definitely given me some other ideas on how I could approach my particular need for now. Especially happy to discover Connect Page Fields!