Repeatable Fields

[wishbone]

ok, I found that in the admin page section. Sorting in my case, kongondo, works! Repeater items names are a bunch of ciffres, which you have to find out first which is which and then move.

For clients not practicable...

or, Soma, did you mean another place where to dragndrop the items?

I'd just like to sort repeater items as you can do with images...

However, for some reason, the order is not being respected when outputting the repeaters

could be caused by some caching... it worked for me, as stated

[Soma]

I dont understand what you dont get. You can sort the item with drag and drop on a page. See the picture above in this thread. See the icon on each item on the left?

[wishbone]

:D hahaha omg - found it!

I searched on the right, I tried the bar, the name - as with images... but you have to touch the little arrows to the left ;-)

sry

[kongondo]

:D hahaha omg - found it!

I searched on the right, I tried the bar, the name - as with images... but you have to touch the little arrows to the left ;-)

sry

Yes, we are going round in circles here  I said this in my post above, about sorting repeater items on a page by page basis

[wishbone]

thank you, but page by page doesn't really hit the point... I still don't know what is a "page by page basis" ;-)

could be sensible to make the move function consistent across items; should be the same with repeaater items and with images...

[MrEd]

We'll be adding more configurability to repeaters in the next version or so, including an option to have them collapsed by default (the repeater items themselves), ability to control labels of repeater items, and automatic sorting. 

Hello, I am new with PW, but I am looking for this functionality. Is it in 2.3 already, or is this quote about 2.4? Maybe there is something done already with the labels (use patch or other way)?

[Martijn Geerts]

@MrED, nope

Welcome to PW.

[ryan]

Hello, I am new with PW, but I am looking for this functionality. Is it in 2.3 already, or is this quote about 2.4? Maybe there is something done already with the labels (use patch or other way)?

Not yet, but it's good to hear the request come up again. When the same request comes up more than once, it gets bumped up the priority list. I will plan to look at this in more detail soon. 

[maba]

Ryan, future "automatic sorting" means the we will be able to sort children pages also for repeater.subfield in page list (admin)?

I have a movie template with a scheduling repeater that contains day_time field.

I would sort movies by the first day_time in page list..

Thanks

[maba]

sort children pages also for repeater.subfield in page list (admin)?

Fixed with a hook for now as suggested in other posts.

[DV-JF]

Now my question. Would it be any way possible to have to be able define multiple "block" templates (with different fields each) for the repeater field? Then when adding a new item, it would ask for the block template to select first. Pretty much the same as it is now, just with variable templates. I can imagine it would require something complete different concept/codewise.

It's just what I kinda "expected" from (the) repeatable page element, so I don't have to use child pages anymore. It can be very handy to be able to define "blocks" that can be chosen from, to build a page. TItle, Video, Text-Image, Linklist, Text. Do you see a good way to add such "variable blocks" feature to PW through a module, much similar like this one?

I would like to come back to this question: Is it possible to use a repeater field the way Soma described it or is there a way to create such functionality?

Many greets.

[ryan]

The term "repeater" in our context means repeating the same type. What's being described above is essentially ProcessWire's pages system, and repeaters aren't meant to replace creation of page structures or groups of different pages. If there were a repeater type field that did that, there would have to be a different name for it.  

[MadeMyDay]

Dreaming of a field type called "flexField". Wet dreaming going on here

[DV-JF]

What's being described above is essentially ProcessWire's pages system, and repeaters aren't meant to replace creation of page structures or groups of different pages.

Hey Ryan, I agree with you.

Processwires page system would match perfectly, the only problem for the editors I see is, that the whole content witch is displayed on one page at the frontend site, would be fragmented into many child-pages without having the opportunity to edit and manage it on one single site.

Many greets, DV-JF alias Jens.

[Asterix]

When outputting a repeater field, how do I access the current rows index number?

ie:

foreach($pageresult->repeaterField as $repeater) {
  if ($repeater->subfield) {
    $repeater->index() ) /* obviously this doesnt work
  }
}

I'm looking for something that can give me 1 for the first repeater entry, 2 for the second etc. I can pop in a integer and just increment it every line but thought perhaps there is a handy feature in the API (that I can't seem to see)

Also, how would I lookup a specific row?

Edited August 25, 2015 by LostKobrakai
Added code block

[LostKobrakai]

By default lists of pages / repeaters are saved in the object like this: [ page.id => page obj, page.id => page.obj ] so there's no api way to directly get an incremental key. But there's the getValues() function, that returns an array while scraping all the keys, so the pages get automatically keyed by incremental numbering. Keep in mind that both indexes below are zero-based and therefore do not start at 1. 

foreach($pageresult->repeaterField->getValues() as $key => $repeater) {
  if ($repeater->subfield) {
    // Do something with $key
  }
}

// To lookup repeaters
$pageresult->repeaterField->eq($n);

[Spica]

I am using

count($page->buildings)

at for a frontendpage and for an adminpage, and do get different values. At the adminpage the unpublished repeaterfields are included. So same code gives an pagearray of 2 and of 5 counts for frontendpage and adminpage.

This shows no effect:

count($page->buildings->not(Page::statusUnpublished))

How to deal best with that?

Edit:

Now found this thread with a solution – count($page->buildings->filter("status=1")). But theres no explanation found for that behaviour.

[bora]

I am using

count($page->buildings)

at for a frontendpage and for an adminpage, and do get different values. At the adminpage the unpublished repeaterfields are included. So same code gives an pagearray of 2 and of 5 counts for frontendpage and adminpage.

This shows no effect:

count($page->buildings->not(Page::statusUnpublished))

How to deal best with that?

Edit:

Now found this thread with a solution – count($page->buildings->filter("status=1")). But theres no explanation found for that behaviour.

I'm not sure if makes a difference in behaviour but you may also use it like $page->buildings->filter("status=1")->count()  . As it is object's own method it might be more reliable.

[nikosch]

The term "repeater" in our context means repeating the same type. What's being described above is essentially ProcessWire's pages system, and repeaters aren't meant to replace creation of page structures or groups of different pages. If there were a repeater type field that did that, there would have to be a different name for it.

Processwires page system would match perfectly, the only problem for the editors I see is, that the whole content witch is displayed on one page at the frontend site, would be fragmented into many child-pages without having the opportunity to edit and manage it on one single site.

Exactly. I came to Processwire from Redaxo and I miss nothing - except the easy module approach for page content authoring. Module stacking has its downsides without a question e.g. you can't group slices with group elements oder classes. But it is a nice way to edit page content (and to force the editors not to "draw" page content). Especially in times of fluid grid layouts and closed Wysiwyg editors, that never meet the wishes of advances authors.

So here's my suggestion: Create a (another ) Page(Collection) Fieldtype, which stores nothing but Page references (so you can reuse content-parts of other pages as well). To adress the point of  DV-JF  the only differences to "normal" Page InputFieldtypes were: They would render with a short, stacked preview of each linked page (the page title or something, maybe the template name) AND on Click they open the linked page as overlay editor.

Nice to haves (and probably easy to do): Stacked view is sortable and has icons to remove the links (not the pages).

How about that?

[nikosch]

Recently I found the ProFields PageTable Type in the dev version, which adresses a lot of my ideas. Basically it needs only a (dynamic rendered?) dummy field in the table, that represents a preview of the page in the background. Howsoever its much more useful than a repeater

[MadeMyDay]

Look for pageTableExtended.

[nikosch]

I will. Thank you, MadeMyDay

[daniel.s]

Is it possible to put ProFields: Table in a repeater field?

[adrian]

Is it possible to put ProFields: Table in a repeater field?

It seems to work just fine, but isn't officially supported, so your mileage my vary depending on your setup.

[daniel.s]

It seems to work just fine, but isn't officially supported, so your mileage my vary depending on your setup.

Great! I'm building a system for menus for a restaurant website and don't know the how the customer wants the sub-categories for the menus (Starters, Main, Desserts). My thought was to let the repeater take care of the sub-categories and the table stand for the individual dishes. Is this a valid way of doing this?