search

tractorcow-farm / silverstripe-fluent

Multi-language translate module for Silverstripe, without having to manage separate site trees.
BSD 3-Clause "New" or "Revised" License
93 stars 111 forks source link

CMSPreview should be considered "frontend" #775

Closed chrispenny closed 3 months ago

chrispenny commented 1 year ago

A common complaint that we're receiving from authors is that when they use the CMS Preview window, they are seeing things that they don't expect, EG: content that is not localised, or content that should have been filtered out with their assignment of "Filtered Locales". If the author browses to the frontend with ?stage=Stage, then they will receive the expected behaviour.

Currently, CMSPreview is treated as "backend" (isFrontend = false). This means that localisation and Filtered Locale logic is applied as if you were browsing the CMS. Which, I get that we are "in the CMS", but the practical purpose of the Preview window is to present the frontend experience that users will receive once the page is published.

InitStateMiddleware::getIsFrontend() currently contains a specific condition to treat CMSPreview as "backend".

// If using the CMS preview, do not treat the site as frontend
if ($request->getVar('CMSPreview')) {
    return false;
}

I would like to propose removing this condition, so that the Preview window provides the same experience as browsing to the frontend with ?stage=Stage.

tractorcow commented 1 year ago

Yes I think you are right. preview should be "as frontend", so admin filters don't make sense.

The only point of having an admin filter is so that you could see potential items (unfiltered) in order to make them available on the frontend.

chrispenny commented 1 year ago

I was able to find the reason why we (probably) made CMS preview be treated as "backend".

If you are browsing the CMS in Split or Preview mode, and you click on a page that is not localised, the Preview window redirects you to the 404 page - both in the Preview window (which would be expected), but also in the CMS edit form (which is unexpected).

https://user-images.githubusercontent.com/505788/214195166-2dad12a0-ba49-4dc2-8f8b-692969b7ef35.mov

I'm not entirely sure what the path forward would be. I do think that the expected behaviour for the Preview window would be to receive the 404 page, but it's not ideal that the CMS edit form also loads the 404 page.

tractorcow commented 1 year ago

We could have a message to localise the page in draft before you can preview it?

chrispenny commented 1 year ago

It's maybe just a bit tricky because the localisation interface is in that page (which you can't get to). Yea they could switch to a locale that has content, but which localised have a localisation might not even be immediately obvious to authors.

I don't suppose there's an easy way to force the CMS edit form to load with preview closed? Like a GET param or something that we could attach to the edit link if we see the page is unlocalised?

tractorcow commented 1 year ago

middleware for 404 that detects draft querystring, and renders the message ?

GuySartorelli commented 1 year ago

I don't suppose there's an easy way to force the CMS edit form to load with preview closed? Like a GET param or something that we could attach to the edit link if we see the page is unlocalised?

You could implement updatePreviewLink() in the site tree fluent extension and set the preview link to null if the page isn't localised. That will have the preview panel collapsed (edit mode) by default when viewing that page's edit form, and if you manually swap to preview or split mode it'll just say "no preview available" (or whatever that message is).

GuySartorelli commented 1 year ago

I created a PR to address this: https://github.com/tractorcow-farm/silverstripe-fluent/pull/781