Manage Content For Different Domains

[madsem]

Hey,

Twill looks amazing! Thanks for creating this.

I've glanced over the documentation, but I haven't seen anything that would allow me to create "content collections", or something to separate content pieces so that I could, later on, retrieve content through REST API from a client application for a particular domain only.

I want to manage content for several (many) domains, using a headless CMS, where content managers can mark content as published on domain XYZ.com for example.

Those are domains with similar (but unique) content, different assets, and themes. The client application on XYZ.com would then retrieve content that is marked as published for XYZ.com.

Is this possible to do with Twill, or would it require ugly hacks and a considerable amount of tweaking to make this work?

Thanks!

PS: or is it as easy as creating a relationship Entity <--> Domain? :)

[ifox]

Hey @madsem,

Thanks for your kind words :)

Very interesting use case!

Twill actually doesn't know about concepts like domain, site, page, theme or template. It is entirely up to you to setup your Laravel application to render Twill created data however you see fit.

A domain can be an attribute or a relationship you add to modules you create with Twill. This can take many forms in the CMS depending on the form fields you pick and how you setup your models relationships.

Once you have the data modeling figured out and setup using Twill's modules, possibilities are endless as to what you do with data entered through the CMS forms. You can create API endpoints on top of Eloquent models, which could be as simple as returning model instances from routes, or more curated using a package like Fractal for example.

The data structures behind Twill are simple to understand since you have full control over them and it's using classic Eloquent attributes and relationships, as well popular Laravel packages like dimsav/translatable, which means you can create your own custom API on top of it pretty quickly. Modules' models also come with scopes to help with filtering things like unpublished items when outputting to an API/view.

Automatically providing a default read-only API endpoint on modules is definitely on our radar to make it even easier.

[madsem]

@ifox thanks for your in-depth reply, really appreciated!

I guess this sounds like the perfect solution for my endeavor then :) There is now just one question left, is it possible to use the live preview cross-domain? So that content creators can preview the content they create, on the other domain.

[ifox]

When you are saying cross-domain, are you talking about different Laravel codebases?

By default, live previews simply renders a Blade view, with unsaved form fields made available on the model instance that is passed to that view. You could render an iframe from there, as long as your other domains are correctly configured to accept it, but that would mean your users would only be able to see the published version of their content, not their changes, as you wouldn't be able to render any of that information through another domain of course.

We are currently thinking about providing a preview API endpoint, to actually support SPAs that relies on API calls to boot (SPAs that can get state injected from inline json or through props are technically already supported). When this is ready, I guess you could render another domain from the preview view, with a parameter to let your application know that it should send API requests to the preview endpoint instead of the regular one. Does that make sense?

[madsem]

@ifox yes, that would be what it boils down to. Having a separate Laravel code base as headless CMS, and several Laravel code bases acting as clients (i.e the websites).

My thinking also went in the direction of having a script on the client app which renders the preview, just wanted to know if that is already possible.

The API endpoint makes a lot of sense.

I guess I will get back to you regarding this, once we cross that bridge ;)