Effective approach for structuring events/bands relationships

[Matt]

Hello everyone! I recently downloaded ProcessWire and after playing around with it I've found its flexibility and ease of use to be really promising.

I'm working on a site to publicize upcoming live music events and archive past events at our venue. Each event has the usual start time/end time/price/etc fields and can be associated with any number of bands (usually just one or two). Each band has name/website/description (short bio)/image fields. At the moment I have a page field on my event template allowing each event to be tagged with the required bands, either by choosing existing band pages (for bands which have played at our venue before) or by creating a new band page. I can then reference each band's name/website/description/image in the event template php.

There are two key ways users will discover events on the public-facing site:

1) Through the events index page, listing events which can be filtered using dates and keywords
2) Through the band index page, listing bands whose pages will list past/upcoming events where they have performed.

However, since:

a) many bands have gone through minor lineup changes since they started playing at our venue,
b) many bands have released (and want to promote) new material since they started playing at our venue,

each band's description and image fields might (but not always) need to vary between events. I would like past event pages to show the band's description/image that was relevant when the event occurred, not the most recent revision. On adding band pages to new events pages, I would like the default description/image to be the most recent version for the band, with the option to replace this with a new description/image if required. It would be unnecessary to provide a new description/image for each band at each event if there were no lineup changes or releases of new material since they last performed.

My first thought was to have a repeater field for description/image/start time/end time on the band template, where the start and end times help my php template decide which description and image to pair with a particular event. However, the band page field on the events template will not allow me to edit the referenced band page's attributes; it only lets me select band pages and reorder them. If I wanted to update the band description (while preserving the history of previous revisions) I would therefore have to find that band's page elsewhere in the admin then add a repeater row and enter the new description there, keeping the image field blank for that row if the image doesn't need updating. This would require the start time (of the new row) and end time (of the previous row) to be input manually... I'm convinced there must be a simpler way to maintain the links between events and band info.

My current structure is:

Home
-- Events Index
---- Event 1
---- Event 2
---- Event 3
-- Bands Index
---- Band 1
---- Band 2
---- Band 3

Apologies if I've misused any terminology  Could anyone advise on sensible strategies for achieving this using Core ProcessWire or modules? Thanks!

[Robin S]

Welcome to the forums!

4 hours ago, Matt said:

My first thought was to have a repeater field for description/image/start time/end time on the band template, where the start and end times help my php template decide which description and image to pair with a particular event.

I think you're on the right track here. Not sure that you need an end date field in the band description repeater - just the start date (a datetime field that defaults to today's date). In your event template file, for each selected band page you would get the most recent band description that is dated earlier than the event date.

4 hours ago, Matt said:

If I wanted to update the band description (while preserving the history of previous revisions) I would therefore have to find that band's page elsewhere in the admin

Inputfields such as AsmSelect have an option to edit pages in a modal window.

[Matt]

Hi Robin, thanks for the tip with the start date - great idea.

I've seen it mentioned on this forum that PageTables are superior to Repeaters... My understanding is that the pages created by PageTables require names - these can be entered manually or automatically generated from the title field (which for the case of my repeating description/image unit, is unnecessary) or using an 'Automatic Page Name Format'. If Repeater fields essentially do the same thing, only storing the repeating unit pages somewhere obscure in the admin category with no need to explicitly specify a name, then am I OK to continue using Repeater fields for this purpose? While I like the idea of the repeated bio pages being children of the band in question, does it really matter?

11 hours ago, Robin S said:

Inputfields such as AsmSelect have an option to edit pages in a modal window.

Somehow I managed to completely miss the 'link selected pages to page editor' setting on my band page field! Now I can update band descriptions as I create new events. Is this a fairly recent addition? I even tried installing the AdminPageFieldEditLinks module (which appears to do the same thing), but this threw an error whenever I tried to edit an event page, all of which contain that band page field.

I was also wondering if it's possible to view selected fields, e.g. the latest description/image from the referenced band page, in a page field, perhaps in tabular form similar to how a PageTable is presented? It would be useful to view such details at-a-glance when bands are added to new events, so it can be easily determined whether the latest revision of their info is still accurate. Each row (page) could then be clicked on to bring up the modal page editor window. Unfortunately, PageTables in their current implementation do not let you reference existing pages.

I found a couple of old threads about this... I know you can set a custom label format for pages listed in the page field but this will not work well with paragraphs or images, nor are there sortable columns.

https://processwire.com/talk/topic/8497-page-table-meets-page-field/
https://processwire.com/talk/topic/11820-page-field-vs-pagetable-field-differences/

 

 

[Robin S]

3 hours ago, Matt said:

I've seen it mentioned on this forum that PageTables are superior to Repeaters

In earlier versions of PW, all repeater items in a page would be loaded when opening Page Edit - this could cause problems if there were a lot of repeater items. But in recent versions repeater items may be ajax-loaded, meaning repeaters can now scale up much better than previously. So there's no reason to avoid repeaters. Also see Repeater Matrix, which is more similar to PageTable in that it allows for multiple matrix types (sort of equivalent to templates).

3 hours ago, Matt said:

I was also wondering if it's possible to view selected fields, e.g. the latest description/image from the referenced band page, in a page field, perhaps in tabular form similar to how a PageTable is presented?

You could use RuntimeMarkup in conjunction with a Page Reference field. You would configure a RuntimeMarkup field to get and format the fields from band pages currently selected in the Page Reference field. Note that after changing the Page Reference field you would need to save the page in order to see the RuntimeMarkup field update.

[Matt]

18 hours ago, Robin S said:

You could use RuntimeMarkup

Thank you for introducing me to this - I had my RuntimeMarkup table up and running in no time!

[Matt]

On my band template I have a Repeater that holds revisions of band biographies - this contains two fields, a 'Description' TextArea and 'Start Date' DateTime which defaults to today's date. Does anyone know a way to set the sort order of Repeater Items, i.e. prevent their rearrangement by dragging? I would prefer to sort, newest first, using the Start Date field.

I know a PageTable can display a grid view with customisable sort criterion, but this option is out of the question as its rows are non-collapsible - my 'Description' fields can be quite lengthy (multiple paragraphs) so expanding all revisions/rows at once will clutter the admin interface. Ideally, my Repeater would only open the Item with the most recent Start Date when the page is brought up for editing; all previous revisions/Items would initially be collapsed.

Could this be solved by writing a simple module that arranges the Repeater Items on loading and saving the page in admin? Or perhaps extending/modifying the Repeater FieldType to disable dragging (even just by hiding the icon)?

[Robin S]

3 hours ago, Matt said:

Could this be solved by writing a simple module that arranges the Repeater Items on loading and saving the page in admin?

You could use a hook to force a sort order on the Repeater field. See here:

To prevent drag reordering you can use the Limit Repeater module:

Not sure about opening a particular Repeater item when Page Edit loads - maybe have a look at the Repeater module code to see how the "Remember which repeater items are open" option is implemented.

Alternatively you could use child pages instead of a Repeater for the band bios. This would allow you to define a sort setting for child pages of the band template in admin. Then use a RuntimeMarkup field to create:

• a list of modal edit links to the child pages, which will open about as fast as an ajax-loaded Repeater item
• a (truncated?) summary of the bio for the most recent child page
• an "Add new" button for easily adding a new child page