Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Node URIs are not converted in frontend preview of workspaces #2347

Open
maya-shines opened this issue Jan 18, 2019 · 9 comments · Fixed by #4733
Open

Node URIs are not converted in frontend preview of workspaces #2347

maya-shines opened this issue Jan 18, 2019 · 9 comments · Fixed by #4733

Comments

@maya-shines
Copy link
Contributor

The ConvertUrisImplementation only converts URIs, if the workspace is live (line 86). This means that editors that preview their workspace in the frontend won't be able to check if the links they set work as intended. Is there a better way to check whether or not the user is viewing something in the backend or in a frontend preview?

@kitsunet
Copy link
Member

Sadly we have no real good way of knowing the difference. I am currently working on a workspace preview feature to let non backend users see workspace contents and had a similar problem. In that case I can find out because those users don't have actual backend access roles, so I can differentiate, but for backend users using the frontend preview we can't. We could think about introducing some parameter to the link, but that means it will probably lost if the eidtor clicks a link.

@Nikdro
Copy link
Contributor

Nikdro commented Jul 2, 2019

Is there a workaround available for this?

This is really annoying. Our customers often build page areas in a workspace and then present them to the company in preview mode before publishing.
If the links don't work, it's very annoying.

@lorenzulrich
Copy link
Contributor

@Nikdro Did you find any workaround in the meantime?

@Nikdro
Copy link
Contributor

Nikdro commented May 6, 2022

@lorenzulrich Sady not, AFAIK.
But to be hornest, I can't remember what was my usecase or even which project it was 3 years ago... Sorry.

Looks like there where some PRs related here, @bwaidelich mentioned this and similar issues in. But I don't know the current state here.

@lorenzulrich
Copy link
Contributor

lorenzulrich commented May 6, 2022

@Nikdro I thought it was still open, but I see that links are rendered, pointing to the same workspace. The links I had the problem with have a different rendering for frontend and backend, and the problem is that Preview behaves like backend, even if it is frontend. But this is handled in #3019.

It looks to me as if this issue could be closed?

@bwaidelich
Copy link
Member

There is a flag forceConversion:

renderer.@process.convertUris = Neos.Neos:ConvertUris {
    forceConversion = true
}

doesn't that help`

@mhsdesign
Copy link
Member

mhsdesign commented Dec 19, 2022

I just stumbled on this issue too (there was also a slack discussion about this some time ago: https://neos-project.slack.com/archives/C050C8FEK/p1635416386088300)

As far as i can tell Neos.Neos:ConvertUris DOES work fine in my usecase in the preview mode.
BUT Neos.Neos:Editable doesnt seem to work correctly in the preview mode, as it thinks due to this condition, that one is still in edit mode in the iframe:

condition = ${props.node.context.inBackend && props.node.context.currentRenderingMode.edit}
${props.node.context.inBackend && props.node.context.currentRenderingMode.edit}

Just for clarification, there is no direct difference between the preview url (see screenshot) and the url of the iframe.
image

There is almost no way of telling from inside the rendering if one is truly in the backend (inside the iframe) or not.
... With a slight exception, which should imo not be relied upon: in the iframe, the node parameter is in the user workspace, in the preview mode the node parameter is in the base workspace ...

The only current workaround is, to switch the edit mode to Desktop and then open the preview (or reload)
This works, because the edit mode is stored in the via session (which may or may not be the unpleasant #965)

(Also, not being a big issue, but still: the content element wrapping is also rendered in the preview mode.)

edit:
this mentiones a similar issue: #2934 (comment)

@mhsdesign
Copy link
Member

mhsdesign commented Jan 15, 2023

i was able to correctly determine if the page is rendered in the iframe or in the external preview via my discovery above:

... With a slight exception, which should imo not be relied upon: in the iframe, the node parameter is in the user workspace, in the preview mode the node parameter is in the base workspace ...

this can be formulated like ${node.context.workspace.personalWorkspace}
The workspace is always a personal fork in the iframe and in the preview we see the base.

and now we could extend f.x. the Neos.Neos:Editable to also consider this to differentiate between iframe and external preview

prototype(Neos.Neos:Editable) {
    renderer.editable.condition = ${
        props.node.context.inBackend
        && props.node.context.currentRenderingMode.edit
        && props.node.context.workspace.personalWorkspace
    }
}

im not sure where to go from now - and with a view to the new CR a lot will change ...

@mhsdesign
Copy link
Member

The issue still persists: #4959

@mhsdesign mhsdesign reopened this Mar 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants