Create pages per model type

[dleadbetter]

Config

When configuring a project, we want the ability to include specific model types for which we should allow separate content pages.

config.json

{
  ...
  "pages": [
    "events",
    "people"
  ]
}

Routing for the pages should be:

/en/events/:uuid
/en/people/:uuid
...

Search

If the model being searched is included in the list of pages, we should include a link on the result card to open the page in a new window/tab. There may be a little bit of problem solving here. It may not always be obvious to the site what types of records are coming back from the Typesense index.

Similarly, if the user opens a page and a related record type is included in the list of pages, clicking on the related record should redirect to the page.

On the side panel viewer, if a related record type is included in the list of pages, clicking on the related record should open the page for that record in a new tab/window.

Pages

At this point, I don't think we'll need pages for Media Content or Taxonomy type records.

Page layout/content TBD, but keep in mind these pages will need to be generic enough to work for all projects using the site.

[ajolipa]

I do believe the cleanest way to do this will be making use of the Astro content layer, which means we'll want to be using Astro 5. PR #19 was my first pass back in December of doing that, so a first step here could be for me to update/rebase that PR and ideally get it merged, so that we're all working with the same versions of things (although your (@dleadbetter) other current work is probably pretty Astro-version-agnostic I guess), and then I'll make a feature branch for these static pages off of the Astro 5 branch. Does that sound reasonable?

[dleadbetter]

This sounds to me like a good first step. Let's add a separate task for upgrading to Astro 5 to keep it isolated from the work we'll do here.

[dleadbetter]

@jamiefolsom - Do we have designs for the content/layout of each of the pages for the different types of models? We'll need to keep in mind that these pages will need to be organized in a generic way in order to work for all projects.

[jamiefolsom]

@dleadbetter we don't have generic designs, but we have some initial designs from @cblissg for the specific needs of the PAD project. In this case, since as you point out, every project will be different, I might recommend we create components which can be configured and styled, or replaced in a number of ways. Something like:

• For the primary record, a block for all native fields (at top)
• For each related model, a block containing a list of records.