Reply To: Pagination for Repeater in Admin

• dano23

• April 16, 2016 at 2:12 am

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?