A plan for Drupal CMS support

Good post. I have been thinking about how allowing multiple registration fields on a single entity type or bundle might solve the difficulties in ✨ Establish host variations as an architectural concept Active . It made things easier to only allow one field, but allowing multiple fields solves a lot of issues and removes a somewhat arbitrary limit that other field types throughout Drupal generally don't have. The "scope" is then still just the single host entity, but becoming multiple "scopes" automatically through the constituent fields. In this way the different fields allows one host to have different capacities and settings for different "scopes". For example, an event may have capacity for 100 seats and 10 special accommodations (wheelchairs etc), and that would now be doable on a single host with 2 different fields instead of requiring 2 commerce product variations or 2 events. A new form class "RegisterMultipleFieldForm" would allow one form to present and accept registrations for multiple fields at once - one registration per field. The edit registration form would still go to the existing RegisterForm in one-at-a-time mode.

I'm doubtful that equating field instances and scopes is a good idea. Field instances are configuration, but my sense is that event variations need to be more like content: lightweight, idiosyncratic to an individual event, and created by event staff not sitebuilders. My experience is that individual events very commonly have idiosyncratic requirements that emerge unexpectedly at short notice during routine event preparation.

At first I thought you meant the parent would have a registration field, and a reference field that referenced children which had their own registration field, and a user registering would (behind the scenes) create two registrations, one for parent and one for child.

Hmm. That means one would have multiple registrations for what was effectively 1 event or booking in the minds of registrants and staff. What's good about this is it allows for different registration types and so different fields for the overall event and for particular variations. But it would also mean the underlying data model is going to be quite divergent from the naive user mental model.

I'm doubtful that equating field instances and scopes is a good idea. Field instances are configuration, but my sense is that event variations need to be more like content.

That sounds right. I guess what I am getting at is the need for "scopes" in an architectural sense may go away if we did not have the arbitrary one-field-per-host limit. Attacking the problem from a different direction.

I guess what I am getting at is the need for "scopes" in an architectural sense may go away if we did not have the arbitrary one-field-per-host limit.

I think I'm not getting what you're seeing.

The use case I'm imagining is:
- a node type called "event" with an entity reference field "variations" that references registration_variation entities using an IEF
- the registration_variation entities have a registration field so each variation is a host
- staff can make as many variation as the idiosyncracies of an event need
- when someone wants to register for the event, they pick the variation they want and (technically) register for that

The question of scopes arises when staff say things like:
- I want to turn enable/disable all the variations at once
- I want to have one default open/close date I specify once, not having to do it seperately for each variation but still having the option to it seperately sometimes
- my event can take max 10 people in single rooms and max 10 people offsite, but the assembly hall only holds 15. So I need a capacity for the event as a whole that is different to the sum of the capacity of the individual variations.

All of these needs suggest the need for a registration settings to be definable on the level of the parent event (scope), as well as on the level of each variation (host). Which requires some basic API for how to communicate between scope and host and combine settings from scope and host. I have ideas for how this could work fairly easily and flexibly.

I'm not sure how having multiple registration fields on one entity helps. Can you say more?

I also suspect that adding multiple fields and providing ways to target a registration to one or other of the fields is a much bigger change to architecture than allowing HostEntity to have the idea of a scope that it considers for settings as well as its own settings.

With multiple fields, the fields take the place of the entity reference. So in your use case, there would be two registration fields, each getting their own registration settings entity:

1) Single room
2) Offsite

There would also still be the "host" settings at the host entity level. Like now, settings are optional, so you could have unlimited offsite, max 10 single rooms, and max 15 at the host level.

Registration entities would get a new property named "field_id" or similar - that property exists now in a sense, but is inferred from the (only) field associated with the host, and thus is not formally defined or stored. With multiple fields allowed, that property would be defined and need to be stored. A registration would have to satisfy the constraints of the settings associated with its field, as well as the "host" settings. So if offsite reaches 15 then the event is full.

The site builder could choose between "register for multiple fields at once", which shows multiple fields and creates multiple registrations on submit, or "user has to select which field".

Conceptually, this is much simpler than scopes, since it doesn't have to introduce the new concept of a scope. I am not saying it's better, but it does seem to be a closer reach. People have already asked for multiple fields in the issue queue, and the notion of multiple fields of the same type per entity is considered natural in Drupal. The only stretch conceptually is the parent/child settings, but you have that same need in scopes, so it's a wash. I'm pretty sure this would require a redo of some of the Registration entity, Host Entity and RegistrationManager public interfaces, not sure what scopes would mean. Not against scopes, but we do need to support multiple fields per host eventually, regardless of whether scopes happen.

I hope this helps, let me know if this is still unclear and I can add more flavor,.

Thanks, that's very clear.

The only stretch conceptually is the parent/child settings, but you have that same need in scopes, so it's a wash.

I think that is perhaps the essence of scopes. So scopes seem unavoidable.

With scopes and entity reference editorial staff can handle idiosyncratic of individual events, whereas (even with scopes) multiple fields per host can only be decided by a sitebuilder in advance.

So scopes seems must-have either way, and relatively non-invasive (as only HostEntity has to know about them), whereas multiple fields touches on the data model and maybe other trickier things all over the place.

We can make it a design goal that scopes should support either scenario (without needing to commit to allowing multiple fields).

I'm happy to do a simple PoC for scopes.

Yes, a PoC would be great! And yes, ideally it would help support multiple fields, but only if that fits. I don't want multiple fields to get in the way. Maybe you should do it without any notion of multiple fields, so we can see how it plays out, and then we can decide next steps, since multiple fields could become obsolete with scopes in place.

Also, I hope RegistrationVariations won't be exposed to site builders as an independent reference field or anything like that. I have nightmares about "entity reference revisions" and Paragraphs, ha ha. The name tells me that won't be a problem, but just making sure.

I pushed a PoC to ✨ Establish host variations as an architectural concept Active . It's just scopes alone, variations can be done seperately.