ProcessWire
ProcessWire copied to clipboard
ryancramerdesign
Feature Request: Max number of repeater items
Hi All,
There have been countless times where I have needed a repeater, but also needed to add a cap on the number of items in the repeater.
I would have thought this feature would've been in the core ages ago. I can't see, from a technical perspective, why this would be hard to implement, so there must be a reason I'm not aware of as to why it hasn't been already.
Could anybody clarify?
The reason I know is Ryan simply doesn't like to limit things prematurely. You can simply write in the description that only 10 (for example) items will be displayed and use $page->repeater->slice(0, 10) in the template. So your editor can for example switch out new repeaters and keep the old one after the initial 10.
The technical difficulty comes not with the limitation, but with how to handle changes in the limitation especially if you lower the limit. What should happen if you decide (after 10000 usages) that you only want 3 items instead of 5. Should they be deleted? Should they stay around and show even though you only expect 3 items? In 3.0 they might get hidden?
I see. I would've thought that it could warn you if you lower the limit, and the data would be truncated.
Also, I know there is a checkbox when editing a repeater that, when ticked, removes "old, unused" repeater items.
And I wouldn't say it's prematurely limiting things. Sometimes the design simple won't allow for more than say three or four repeater items. But you still want the ability to reorder the items, edit them etc, without having to create separate sets of fields for each item. It just makes for a tidier installation. Why allow the client to add more than the maximum number of items? Simple adding a warning is not always going to work. We have to let clients use the CMS that don't always know way they're doing. To make things easier we give them an account with the minimal permissions required to edit what they need to, so they can't break the installation somehow.
Regards, Caelan Stewart
On 25 Aug 2016, at 11:24, Benjamin Milde [email protected] wrote:
The reason I know is Ryan simply doesn't like to limit things prematurely. You can simply write in the description that only 10 (for example) items will be displayed and use $page->repeater->slice(0, 10) in the template. So your editor can for example switch out new repeaters and keep the old one after the initial 10.
The technical difficulty comes not with the limitation, but with how to handle changes in the limitation especially if you lower the limit. What should happen if you decide (after 10000 usages) that you only want 3 items instead of 5. Should they be deleted? Should they stay around and show even though you only expect 3 items? In 3.0 they might get hidden?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
Unless talking about one vs many, my opinion has always been that things like max quantities of repeater items should really be a front-end matter. Otherwise you've got the back-end configured with presentation assumptions about the front-end, and ProcessWire strives to maintain independence from this. After all, the front-end changes, quantity needs change, sites get redesigned, there are multiple views to the same data, etc. Perhaps just the first 3 repeater items are used in a summary page, and a larger quantity is used on a destination. Like LostKobrakai mentioned, I'm also not keen on adding features that can cause automated destruction of data when configuration changes. But the bigger matter really is about the best practice of keeping front-end presentation matters out of the back-end. If you know the front-end of the site cannot ever display more than 3 items in a specific spot, then always slice it to that quantity. That code will be in your front-end, right where the actual output need for limitation exists.
To be honest I don't have strong opinions on this, but in the past I have had to deal with users adding more items than are displayed on the front-end, and then asking me to "fix it". When I've told them that this limitation is explained in the description of said field, the answer is something along the lines of "sorry, didn't read that – it was possible to add more so..."
Sure, we can say that it was a user error, but the GUI would be more obvious if it was indeed possible to limit the ability to add more than X items. I'm mentioning this strictly from usability point of view, so feel free to disregard if it's not in line with other important design principles :)
I wonder how the limit is handled for file fields, where we can already set a max. number of items.
"sorry, didn't read that – it was possible to add more so..."
People don't read anything anymore! You have to force restrictions - listing and explaining never seems to work.
@teppokoivula, @adrianbj. I agree, you simply cannot rely on clients actually reading instructions. They don't, most of the time. I know, first hand.
@ryancramerdesign, OK. So instead of deleting the repeater items, if you impose the limit after the field has already been populated with more items than the limit would afford, then just warn the user when they save the page that the extra items won't be displayed in the front end. Perhaps the extra items could be automatically unpublished, and can't be re-published until other items are removed.
And, as @LostKobrakai mentioned, a limit can already be imposed on the file field. Why not just duplicate that behaviour for repeaters? They're pretty much the same thing as repeaters in an abstract sense.
So, what's the final word on this? Considering directly comparable functionality has already been implemented on other repeater-like fields. Would really like to see this.
Us, being developers, know exactly how to interact with ProcessWire. We're used to reading instructions, code comments and documentation, unlike a client.
If I just limit the number of items printed on the front-end, the client is going to try an add more items, not understanding that you can't just simply "stick another one in there", and expect it to work. It won't produce any errors, and the page will save successfully. So from the client's point of view, when they visit the page on the front-end of the site, the extra block they added in there should be there. And when it isn't, we're the ones who are getting calls from vexed/perplexed clients.
Yes, I can add in block capitals "MAXIMUM OF THREE ITEMS HERE". But it looks unprofessional, it's not the best practice method of imposing a limit, and I still wouldn't count on all clients actually reading it.
One client phoned up thinking the reason they couldn't access their bank's website is because we host the client's website.
Another client phoned up who'd accidentally deleted a page, and didn't even see the "Trash" page at the bottom of the page tree, and subsequently nor the "Restore" button. The entire page tree of this site could actually fit on a small screen, so it's not like they would've had to scroll down to see it.
It's a basic UX principle that you need to explicitly guide some user's through the entire site, everything needs to be obvious and intuitive.
I hope that adds some weight to the argument, if that is what you needed.
@CaelanStewart: Just an aside; You know that only superusers can see the trash?
@LostKobrakai, I'm actually quite surprised I've never noticed that before, considering I've built a fair few sites with PW now. Is there any particular reason that only superuser's can see the trash?
If there is no particular reason, then I feel it would be a good idea to add the ability to see the trash as a new permission when adding a role. Or perhaps users with the page-delete role can also restore items from the trash, but not necessarily empty it.
I'm pretty sure there is an older issue or a thread somewhere about the trash thing, but on a mobile so can't really check right now. Primary reason, I think, was simplicity in terms of permissions. If you find the earlier discussion I'm sure it contains more clues :)
Antti's Trashman module brings trash to regular users via a custom GUI.
@ryancramerdesign, considering the above comments, what's the final verdict on this? I would love to see this.