HEADLESS_PREVIEW_CLIENT_URLS requires hardcoded hostnames
jaap3 opened this issue · comments
I use wagtail as a headless CMS for multiple sites. Having to hardcode hostnames in HEADLESS_PREVIEW_CLIENT_URLS is somewhat counter intuitive when the Site objects themselves live in the database and hostnames can be changed at will.
I can think of other solutions that would work better (for me at least)
i.e. a template string:
HEADLESS_PREVIEW_CLIENT_URL = '{root_url}/_cms_preview/
then get_client_root_url could return HEADLESS_PREVIEW_CLIENT_URL.format(root_url=self.get_site().root_url)
Or even a model that's related to Site and can be configured in the Wagtail settings interface.
Is this something you would consider? If so, which approach (or any other alternative) is preferred?
Hey @jaap3,
You raise a valid point re changing hostnames.
In a headless setup, though, the preview URL would be under your front-end client domain, rather than the backend, so HEADLESS_PREVIEW_CLIENT_URL.format(root_url=self.get_site().root_url) doesn't work in that it returns a backend URL. Multiple domains usually imply multiple front-ends with their own data fetching logic. If, in your setup /_cms_preview/ is in fact a path that your backend registers and does additional routing, then IMHO all you need to do is override get_client_root_url to cater for that.
It is possible I am missing something, so do expand on this.
Yes, the previews are on the "frontend" domain. The Site objects already contain that same (frontend) hostname. It's the only way I could get the "view live" button and API working for each site managed in Wagtail.
The frontend site proxies the Wagtail site for certain requests. So for example: www.example.com/api ends up at cms.example.com/api (with an X-Forwarded-Host header of www.example.com, and Django "trusting" the X-Forwarded-Host header by setting USE_X_FORWARDED_HOST = True). That way the API knows which site tree to retrieve pages from and there's not issues with CORS or whatever.
I'm not sure if this is an uncommon setup (it's really convenient). I'm wondering how other multi site headless Wagtail setups handle the API and "view live" things.
Anyway, in my case all the frontends would pretty much have the same preview url (except for the domain). The domain is already available from the site object retrievable from the page.
It's also entirely possible that the preview url is unique for each frontend. But then configuring those in the database (similar to the Site object) would still feel more "Wagtaily" than having some site configuration in the database and some in settings.
It's not extremley inconvenient, and I can get by with the current way of configuring things. It's just that when adding a site/moving domain I need to remember to add/edit a Site object and update settings.py (and have some switch in place for dev/staging/prod).
Heya,
realised I did not reply to this. I like your setup, but not all can do it.
It's also entirely possible that the preview url is unique for each frontend. But then configuring those in the database (similar to the Site object) would still feel more "Wagtaily" than having some site configuration in the database and some in settings.
The idea was to keep this as simple as possible. At the same time I do not have any active headless multisite setup that would throw this type of pain points. Configuring the mapping in the UI can work, but you need to cater for relative paths and full URLs.
Happy for a PR that changes the way we configure the client URLs.
IMHO, if you go down the settings route, then we do not need a separate setting, just https://github.com/torchbox/wagtail-headless-preview/blob/master/wagtail_headless_preview/models.py#L71 needs updated to cater for {root_url} + updated docs/instruction.
For the settings ui / data in db, we will need an upgrade path (i.e. take all sites on HEADLESS_PREVIEW_CLIENT_URLS and transform to relevant site + path records).