Jump to content

Repeatable Fields


ryan

Recommended Posts

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

Link to comment
Share on other sites

:D :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 :D

Link to comment
Share on other sites

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...

Link to comment
Share on other sites

  • 1 month later...

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)?

  • Like 1
Link to comment
Share on other sites

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. 

  • Like 2
Link to comment
Share on other sites

  • 2 weeks later...

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

Link to comment
Share on other sites

  • 2 months later...

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.

Link to comment
Share on other sites

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. :) 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 1 year later...

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 by LostKobrakai
Added code block
Link to comment
Share on other sites

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);
Link to comment
Share on other sites

  • 3 weeks later...

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 1 month later...

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?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • 1 month later...

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? :)

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...