How would you go about modeling "branches" of content updates (and other common CMS-y problems I'm ignorant about!) 😂

[mdwheele]

Hey everybody!

I'm new to PayloadCMS and loving it so far! I'm trying to develop a model for how I might solve a problem we have and could use some advice from someone more experienced with the platform. This is likely going to be kind-of rambling so I apologize in advance!

The idea

I'm working on a platform that allows users to create technical guides for a particular topic. Think of them as a multi-paged tutorial with custom navigation, etc. An author would create a Guide which then has it's own Navigation and Pages. An author might own several guides and want to make changes to them over time. These guides typically have 15-50 pages. I feel like this is a common "solved" problem, but I'm new 😅

The authoring experience

I originally figured that the default admin interface would be "good enough", but after getting into it, it really feels cumbersome to just drop a user on an unmodified Pages collection where all the pages across all guides are just dumped on their lap. I'm thinking it's going to make more sense to have a customized experience here, but I don't want to "eject" too soon. What are folks thoughts here? I've seen that you can do things with hooks + nested pages to display (and sort/filter) on full-title, which uses breadcrumbs generated by the plugin. What else have folks done to kind-of "scope" or group pages like I'll need to do?

When it comes to the UX immediately after "Creating a New Guide", I want to try and guide the user towards creation of their first Page and orient them to how Navigation works. Are folks building this sort of "rich" UX through customization of the Payload admin interface or are they just building their own frontends that interact with the API?

Releasing changes to multiple pages together

Another problem I'm anticipating is how updates are made to the guides. Today, we use a Markdown-based SSG and everything goes through git. This is great IFF you're an author that knows git and knows Markdown. I want to lower barrier to entry for making and suggesting changes. Authors use branches to group changes across many pages together and they're merged all at once.

My concern with using drafts to pull this off is that someone will have to either script publishing automation or manually publish each draft. Even then, I don't have a great way of handling multiple contributors to the same content (which doesn't happen often, so I'm honestly thinking about leaving it out of scope).

My thoughts here were to create a Branches collection that each Page was associated to. When I make changes to a page, it's actually creating a new Page under the hood which is associated with a branch. Perhaps users could also just "edit in place"; in which case, they're just editing the page associated with the main branch. When I want to "publish" / "commit" / "merge" a Branch, I could have a custom endpoint that just removes the Page associated with main and updates the new Page branch to be main.

When I render the individual guides, I scope the collection query to show main by default. This also gives me an opportunity for someone to "set" a branch that they want to review and see the content as it looks after multiple changes have been made across the guide.

Anywho, I apologize for the rambling. What are folks thoughts here? Any ideas? Any advice?