One-off Page Types: Globals or Collections?

[damnsamn]

TL:DR;

I have structured my site so that one-off pages (eg. Homepage) are Globals, which introduces certain limitations (specifically being unable to reference Globals within Relationship fields). How do people generally structure these types of one-off and distinct pages within their projects?

---

I'm in the process of migrating our agency website away from another CMS - so far Payload has been fantastic, but I'm having some troubles understanding the intended (or otherwise optimal) architecture for structuring content within Payload. I can't tell if this is a missing feature, an idealogical schism, or just a mental model adjustment.

We deal primarily with highly-custom, highly-art-directed, bespoke websites and apps, we generally have a need for one-off page types. Homepage, Contact, About, etc. might all have vastly different needs, layouts and business requirements, to where a modular block-based approach to building one-off layouts does not make a great deal of sense. These are often pages where layout is largely static due to the high level of art-direction of each page, and fields are not often shared between them.

I've currently got my project structured so that the static art-directed pages are Globals, and other content types are Collections. This fits the bill nicely for defining the content models, but given the intrinsic differences between Globals and Collections, this structure has begun to pose some insurmountable obstacles.

My project structure looks like this:

• Globals
  • Home
  • About
  • Contact
  • Settings
  • Navigation
• Collections
  • Projects
  • Categories
  • Media
  • News
  • Users

Our Home, About, and Contact pages are each navigable pages - but being Globals, are omitted from Relationship fields (especially frustrating because this makes the custom Link field only allow certain internal links). I understand that there are also certain API differences between Globals and Collections as well, though I've not encountered those yet.

Looking at other projects, there seems to be a general pattern of creating a Pages collection whose content is largely driven by block-based layout building and hero "types". While I could restructure things to be this way - it would essentially mean that the Pages collection would have to contain a type field which basically every other field is conditional on. To re-iterate, the content model between these pages is generally not shared and not modular, and their layout is fairly static and bespoke.

Am I going about this wrong? Are there other solutions I've just not encountered yet? Requiring a Pages Collection for one-off page content feels like an unnecessary hurdle that I would like to avoid entirely if I can help it.

This quote from the docs would support the use case for once-off navigable pages, though this seems to not be the intention.

The big difference is that Collections will potentially contain many documents, while a Global is a "one-off".

[DanRibbens]

I think you came to your own conclusions correctly on your own.

it would essentially mean that the Pages collection would have to contain a type field which basically every other field is conditional on.

There isn't really a better way. Anything I think to extend in Payload's core to accomodate referrences to globals or something, it is still isn't a better solution than moving to a Pages collection. If you're expecting some magic undocumented tricks, I have bad news for you.

Globals are great for variables in your projects like headers and footers, social media links, and 3rd party vendor variables that you want to expose to editors.

[alecreed]

Instead of having a type field, you could make the page-specific fields conditional on the slug/URL of the page, couldn't you? That way the admin enforces the one-off nature.

You could relieve the stress of having a gigantic config for your pages collection by splitting the field sets for the one-off pages into separate files similar to how richText() is typically handled. It would probably feel very similar to defining a global for each one.

[damnsamn]

I guess that's fair enough. It is a bit frustrating that you can only have "a single global dataset" and "a collection of non-global datasets" without "a single non-global dataset". I think it would be great in future to maybe have Collections to be optionally single-instance. Maybe a max Collection limit?

[DanRibbens]

That's an interesting idea to have a max on the collection level. Is it really going to have a better UX than conditional fields though?
What happens when a user tries to create 2? Do we remove the buttons to create? You could do that with access control now.
How does this interact with the versions and drafts feature? Ideally you can have only one published, but many drafts for the same thing. This is also possible with a custom publish access control function.

There is another discussion about adding conditions to blocks so that only certain block types are available based on other document data. I feel like that opens up a better solution.

Let me explain exactly what I would do in your situation, tell me what you think.

If your motivation is to have more clear navigation in the admin UI for these pages, you could make custom admin nav link components for the dedicated page types. It would need to fetch the pages having a type in your array of dedicated page types, then loop over the array displaying the nav link to edit each of the found documents.

You could seed your project with a migration that makes each page type with the correct slugs.
Then you could make the page type hidden so that editors don't even have the option to change it.

The slug field would get a simple access control function so that it cannot be updated either.

You would also want to restrict delete with access control for any dedicated pages.

If you did all this it could feel just like editing globals to the editor and solve the issue of not being able to link to these pages.

What do you think?

[damnsamn]

@DanRibbens I've started down the path of the solution suggested above, with one Pages collection with all of its fields conditional on its type - but it comes with definite drawbacks that feel insurmountable, unless I'm misunderstanding something (I'm only a couple weeks into using Payload at this point).

My Pages collection config looks like this currently:

fields: [
  {
    type: "text",
    name: "title",
    required: true,
  },
  {
    name: "pageType",
    type: "select",
    required: true,
    admin: {
      position: "sidebar",
    },
    options: [
      { label: "Home", value: "home" },
      { label: "About", value: "about" },
      { label: "Contact", value: "contact" },
    ],
  },
  slugField(),
  pathField(),
  ...HomeFields,
  ...AboutFields,
  ...ContactFields,
],

Each imported array contains a labelled (not named) tabs field which is conditional on the value of pageType. Its child fields contains all the fields that belong to that page type. This setup poses several problems.

1. Empty Array fields bleed over between page types. Despite being empty and untouched, these fields bleed over and pollute the API response of other page types. For example, in this screenshot of the Contact page type - the only config fields it should include are title, pageType, slug, path, form, meta. The fields logos, workRows and bottomStatistics are from the HomeFields array, and do not belong in the contact API response at all.
   

2. Generated types becomes overly broad. Since the type generation doesn't take conditions into account, required fields for one page type that do not appear on other page types are generated as non-optional, non-null properties for all Pages documents regardless of their pageType field.
   This could be mitigated somewhat by utilising interfaceName, but that would generate interfaces that are subsets of what each page type is actually expecting, omitting shared fields such as title, slug, path.

3. Page types cannot have fields of the same name. The build will break if there are two fields with duplicate names. This makes sense generally. There shouldn't ever be a need for a document to have duplicate fields. But because we're dealing with taxonomically different and mutually exclusive page types here, a Contact page having a "heading" field and a Home page having a "heading" field, is an intuitive decision, since they belong to different page types. Sharing a Collection and content model like this makes that infeasible.
   This could be mitigated by naming the tabs or wrapping page type fields in Groups, or otherwise just namespacing the fields directly, so that all the fields are namespaced - page.home.heading vs. page.contact.heading. I'd like to avoid this if i can, because within the context of one page type, it is an annoying and unnecessary level of nesting. Eg. contactPage.contact.heading is ergonomically frustrating.

Given the issues above, it feels like there is still room for a different, once-off, non-global document "Single" type that lives somewhere between a Collection and a Global.

[ccapndave]

I'm in exactly the same boat as you. Given the problems you experienced with a generic Page collection, I am going to investigate the solution of having collections with a single item to see if that behaves better. Did you happen to find any other solutions over the last few months?

[damnsamn]

@ccapndave I was working on a POC Payload integration at the time which I've since moved off of. Hadn't solved any of the problems above, was just trying to work around them instead - that was as far as I got.

I think a single-item collection is probably a nicer way of going about it for now