Home › Forums › Add-ons › Repeater Field › Pagination for Repeater in Admin
Hi guys,
I have an options page with a repeater field that has maps in it. As you can imagine, this gets pretty crazy with lots of entries on the back end. Is there a way I can paginate the repeater on my options page?
There are lots of help topics about pagination on the front end for a repeater, but I need this on the back end.
Thoughts?
Since the fields are created by ACF in admin I don’t think you can create pagination yourself. Maybe by doing some hacky custom javascript pagination which would just be hiding rows.
My suggestion is (and I know this is a pain) to change your architecture. If you have that many rows with google maps perhaps consider creating a custom post type instead which’ll host the fields currently in your repeater. That way you won’t have an issue with crazy long repeaters, long loading times/unresponsive pageloads and you can keep better track of each map row. Plus you can selectively fetch the maps posts by date, different orders etc in the future 🙂
Hi Jonathan,
I am trying to solve a similar problem but I’m not sure I follow your suggestion.
We created a front-end form, only available to admins. We use a couple repeater fields set up as tables, where each entry is basically a single line with a couple of items (a date, a couple words of text and a checkbox or two). The entries update a custom post type (a “report”) and we paginate the results to the end-user using jQuery Bootgrid (which works great, btw).
Our problem is on the form. Since the reports are updated weekly it doesn’t take long for the repeater fields to get lengthy. We’d like to paginate the repeater in the front-end form for the authors (who will mostly be working with only the latest 3-4 entries in the repeater anyway).
I tried implementing the jQuery Bootgrid approach on the form, but there are too many jQuery conflicts to make it work. Can you give me more details on your suggestion above? Perhaps you’re suggesting some way to only display X number of results in the repeater in the front end form?
Hi Dano,
I’m not sure I understand your setup completely.
But my suggestion to linkhousemedia sounds to work the same for you.
Instead of having all those reports in a single repeater. Split them up so you have a single report as a bunch of fields on a custom post type.
So on this page where your authors work with these. You can output all the posts in this post type for them to view (and you could create a front end editing form as well). And for creating new ones you can use acf_form() to post to your CPT.
Hi Jonathan,
Sorry — I might not be explaining things correctly. As you say, we are already set up so each report is a custom post type and each single report is made up of a bunch of fields. So let me give you a more specific example:
One field in our front-end form uses a repeater to enter ‘events’ that occur on a ‘date.’ Say, an ‘Earnings announcement’ happened on ‘April 14th.’ Reports are edited weekly by returning to the front-end form to make edits.
After a while — say one year — there may now be 50+ entries in that one repeater field (and there are more repeaters in the form). Soon there may be 100 or 200 entries. So when the analyst goes to the form to enter another ‘event’ — they have to scroll through all the previous entries to get to the bottom to enter a new event.
This is where creating pagination, in a repeater field, in a front-end form, would help compact things. Does that make more sense? Screenshot attached.
Dan
Hi Dan,
Okay.. well the problem with a front-end pagination is that you’d still hit your servers max_input_vars limit etc eventually.
I have a clearer image of your setup now but not completely. So you’re creating a single report post and in this you add “infinite” rows of events. Why are you not just creating a report per event?
If you need to “organize” or “group” these events (reports) somehow could you maybe use a taxonomy? So say you now have a report called “Traffic” in which you have 100 rows of events. What if you have a taxonomy called “Traffic events” and have 100 report posts each with a single event in them (doesn’t have to be a repeater any more since it’s just one instance).
say IF that works.. then you’re thinking “My god, we can’t change our structure that much this late”. Well you can.. you just need a smart way to convert your existing data.
You could code a function which would look through each current report post. Add a term in your new taxonomy for each report post (maybe just use the reports title as the term title). Then loop through each repeater row and create a new report post and assign it to the newly created term along with the rows fields as meta fields on this post. If you got a decent coder it shouldn’t be a problem!
One advice tho, I’d create a new report post type for transferring to. If there’s an issue (might require some trial and error) in converting you can just clear out all posts in this post type and start over not worrying about mixing old with the new. Then when you’re satisfied you can delete the old report posts and use a plugin to convert all new posts into the old report post type (and then delete the new report post type which would now be empty anyway).
Hi Jonathan,
That’s a very thoughtful response and I appreciate it. But I think we got off track with your first assumption. All the information is specific to a company. So each CPT “reports” post is built around a single company.
Let’s see if I can give you a visual…
We have a custom post type called “reports” and we write a single report for each company.
CPT “Reports”:
–Company A
–Company B
–Company C
So in the example above we have three “posts” in our custom post type.
Each post makes use of several dozen custom fields, including text, selects, taxonomies and repeaters, etc.
CPT “Reports”
–Company A
— title
— description
— taxonomy
— repeater for “events”
— event 1
— event 2
— etc.
— commentary
— price
— etc
–Company B… same fields as company A
–Company C… same again…
Now, the report is published and a customer can view the report for Company A. This is the key–> when things need to be updated, the analyst uses a front end form to go into that Company A “reports” CPT and he updates the post. (In other words, he does NOT create a new report for that company.)
(It is important that the analyst works on a single view of the company on one page/form — it would be difficult to enter information about a company by jumping around to different forms.)
Some fields in the report never change — like “title.” Some fields are overwritten, like “price.” Other fields are added to over time, like the repeater field on “events.” We do this because we keep track of historical events that were logged over time and we display them in a data table.
The setup is working great for us except for the fact that those repeater fields will get very long over time.
Does that make more sense?
Ah I see..
Yeah I understand your setup now.Unfortunately your issue remains that at some point you’re gonna run into server-limitations.
The thing about acf_form and manipulating the output would be that it’d affect the repeater field when you save the changes.
You could probably hide all but the last 5 rows in the form using CSS but that’s a dirty fix.
So now that I know a bit more and also your requirements here’s what I’d rather do.
I would create a new CPT called events. Then setup a new field on each company report which is a relationship field for the events posts. You can have this field in your original acf_form is you like just to be able to remove/add posts that already exists.
Now you say you don’t want your analysts to jump from a single view.
Well you can create a separate acf_form on the same page with just the fields for each event which when posted creates a new event which automatically connects to the relationship field for the report (you code this yourself, very simple).
This would also allow you to manually query all events or maybe just the latest 5-10 to display to your analysts. You can also provide an edit-button for each event. This gives you the ability to separate older events from newer in whatever fashion you want. You could also prevent editing of older events by only allowing events from the past month to be edited (for example).
Anyway, here’s that dirty CSS fix as well.. You’ll have to change “<yourkey>” to the key of the repeater field. This assumes you’ve set your repeater to display as row.
.acf-field-<yourkey> .acf-table tbody .acf-row{
display: none;
}
.acf-field-<yourkey> .acf-table tbody .acf-row:last-child,
.acf-field-<yourkey> .acf-table tbody .acf-row:nth-last-child(2),
.acf-field-<yourkey> .acf-table tbody .acf-row:nth-last-child(3),
.acf-field-<yourkey> .acf-table tbody .acf-row:nth-last-child(4),
.acf-field-<yourkey> .acf-table tbody .acf-row:nth-last-child(5) {
display: table-row;
}
I have the same problem. In the backends, im ending up having too much lines row one page.
A pagination is required for me.
Have you seen that in later versions of ACF you can collapse/shrink a repeater row to a single “line” with your chosen field value on it?
If you still find it unmanageable, to be frank, you should reconsider how you structure your data. There are more and worse issues with dumping everything into a repeater field. For example hitting your servers limits like max_input_vars resulting in you unable to add information.
Hi @jonathan I stumbled upon this topic trying to learn more about big data in the repeater field.
You mention more and worse issues with dumping big data in a repeater field. Can you elaborate on this? What would you consider to be feasible for the repeater field?
Hi @geert
Hard to know where to start…
Okay, so most people on the web with a WordPress site probably has shared hosting (I’m guessing). They have little to no control over the servers settings and limitations. Here’s some standard PHP values which are unlikely to be set higher in such shared hosting:
http://php.net/manual/en/info.configuration.php
disclaimer: I’m not gonna research everything here before (limited time) so some is a little bit of guesswork when it comes to numbers.
max_input_vars
there is one of the most interesting ones. Basically it says that PHP will accept a maximum of 1000 input fields to send to a single request (page load). In the case of WP admin that would likely be a POST request. WordPress per default already have quite a bit of fields for a standard edit screen. There’s a whole bunch of hidden fields as well as formats, categories, tags, featured image, title, editor, permalink, visibility, status etc. Let’s say you also have a few regular custom fields. Then you also add a repeater field to this. Each row might contain 2-10 fields + some hidden fields ACF uses to keep track of everything. Maybe you even have nested repeaters! So for each row there’s 2-10 fields + a nested repeater which in term contains 2-10 fields. And say you add in a gallery field there as well. That’s at the very least 1 field for each image.
You’re quickly gonna find that you hit the 1000 input vars limit if you abuse repeaters. That’s gonna stop you from adding any new content to the page before you delete other. That in itself should be enough to reconsider huge repeater fields. But to make matters worse there’s also server limits like max_execution_time
and max_allowed_packet
(mysql). Saving all these fields will take some time and if you’re not on a great internet connection you may hit the max_excecution_time
which will lead to your page save ending abruptly and unfinished. max_allowed_packet
is a variable for mySQL which basically limits how large of data chunk you may insert in one go. It’s much harder to hit but it’s possible.
If you’d be on a VPS you could prevent all of this by just upping your server stats. However you’ll still get a very slow admin experience and let’s face it, you’re patching a leaking boat and probably have to pay a hefty price for it (big servers aren’t cheap).
Then there’s also the issue of WordPress database structure and the performance of WP_Query
. 10up has written a great article on performance with WP_Query
and one of the things to avoid is post meta lookup. Usually there’s no choice BUT we can at least do what we can to use simple post meta like a single date field or a boolean. And of course try to minimize the amount of post meta for each single post. https://10up.github.io/Engineering-Best-Practices/php/#performance
Consider that ACF adds two rows to wp_postmeta for each field (both regular and sub fields).
So if we can refactor our data structure to use a custom post type which would contain some fields and then perhaps link different posts/post types together with the post object or relationship field we’ll end up with safer and quicker admin requests, faster and often more versatile use of wp_queries in our front end and a better DB structure more fitting of WordPress strengths and weaknesses.
It’s hard to say a number of repeater rows that’d be “too much” since it depends on what they contain. But for me, if I find that I’d end up with more than 20-30 row of simpler repeater data or 10-15 rows of more complex ones I would consider a different solution. Sometimes it’s hard to predict tho. We’ve had customers where they were supposed to use repeaters for just a few categories of Press media attachments but they ended up dumping soooo much media there that we eventually had to rebuild it for them with a CPT where each post was a single media file and a taxonomy for the categories of media.
Hope that was a sufficient answer 🙂
Thanks for taking the time to answer my question @jonathan! That’s definitely a sufficient answer. 🙂
I understand that putting a number on repeater rows is difficult, so I’ll take that in mind for the future when I’m thinking about adding a repeater field. Up till now I didn’t realize that could have been a problem. I’m not a backend developer (but a frontend developer), so I’m not very experienced in servers, databases, PHP and their limits.
I already switched my setup from a repeater field to a CPT. And to be honest, it’s already making way more sense. 😉
I’ve read the article from 10up, thanks for the link, pretty interesting stuff too!
No worries!
Yeah for you as a front end developer in WordPress knowing about the ways you can optimize the wp_query is really important. I’m always finding myself using at the very least one of the parameters to remove a query. I also regularly refactor older queries to give them a performance boost!
The topic ‘Pagination for Repeater in Admin’ is closed to new replies.
Welcome to the Advanced Custom Fields community forum.
Browse through ideas, snippets of code, questions and answers between fellow ACF users
Helping others is a great way to earn karma, gain badges and help ACF development!
We use cookies to offer you a better browsing experience, analyze site traffic and personalize content. Read about how we use cookies and how you can control them in our Privacy Policy. If you continue to use this site, you consent to our use of cookies.