9.0: Edit Preview Mode Support

[mficzel]

Since the nodes have no .context anymore this cannot be used to determine the edit preview mode in neos 9.

PRs:

• Neos: FEATURE: Edit preview mode support for Neos 9 #4067
• Neos-UI: WIP: HACK: 90 edit preview mode support neos-ui#3411
• Neos-Ui: 2 TASK: Replace usage of Neos.Node.inBackend(node) neos-ui#3571
• Neos: !!! FEATURE: Reimplement EditPreviewModes for Neos 9 #4505
• Rector: TASK: Adjust migration for renderingMode.isEdit rector#22

See also #4396 for an explanation about why we opted in for removing the workspace based inBackend

[mhsdesign]

Related Issues

• my duplicate task: 9.0: Rebuild editPreviewModes #3984
• we should think of fixing this too Node URIs are not converted in frontend preview of workspaces #2347
  • opening the preview in the iframe should not have the node uris converted, but when using the preview button (effectively the same route) the uris should function normally and be converted)
• TASK: 9.0 migrate node.context.currentRenderingMode.edit rector#23
• FEATURE: Fusion renderingMode semantic correct inBackend #4396

[bwaidelich]

At todays Neos 9 weekly we came up with the following suggestions:

• Allow for custom Context Variables (including Eel Helpers) to be registered upon Fusion runtime creation (implemented by @mhsdesign with !!! FEATURE: Global variables for the Fusion runtime FusionGlobals #4425)
• Adjust the Neos FusionView such that it resolves the current edit/preview mode (aka "UI mode") from the HTTP request and pass it via above feature to the Fusion runtime apparently I misunderstood (see @mhsdesign's comment below)
• Implement the following Eel Helpers:
  • Neos.UiMode.isEdit(): bool – true if in the Neos Backend and one of the edit modes is active
  • Neos.UiMode.isPreview(): bool – true if in the Neos Backend and one of the preview modes is active
  • Neos.UiMode.name(): ?string – name of the current mode (to resolve custom Fusion entry points etc)
  • Neos.UiMode.options(): array – user defined options that are taken from the Settings for a corresponding UI mode
• Ajust the rector migrations accordingly
  • node.context.inBackend should be replaced with Neos.UiMode.isEdit() because that will solve most of the use cases. But it should also add an inline comment like "if you want this to be true for all edit & preview modes in the Backend, use Neos.UiMode.isEdit() || Neos.UiMode.isPreview() instead"

[mhsdesign]

Adjust the Neos FusionView such that it resolves the current edit/preview mode (aka "UI mode") from the HTTP request and pass it via above feature to the Fusion runtime

I thought we discussed that one needs to set the uiMode as option for the view from outside? Otherwise we gain nothing i think, as the Neos Ui will need to extend the FusionView or sth

TODO:

document why we decided against ...

• enforce that a mode cannot be isEdit AND isPreview at the same time
  • or set type: "edit" | "preview"??
    • this would allow us to remove the two distinct actions as the behavior of the mode is defined on the server and only the mode name is needed. previewAction(string $uiModeName)
• Naming Neos.Backend or Neos.EditPreviewMode
• Neos.UiMode.isLive(): bool

TODO

• rename setting editPreviewMode to uiMode
• should Neos.UiMode.name() be nullable or return live (there is a dummy live configuration)
  • YES

[mhsdesign]

Hmm after thinking about this again - im sure that passing the edit preview mode somehow to the runtime via #4425 is the correct way, but i have concerns about it being passed as eel helper.

First of all anyone actually wanting to understand fusion at a deeper level, will be first confused that the helper Neos.UiMode is not configured in the Neos.fusion.defaultContext while it still clearly looks and behaves like a helper.

A second thing is, that sometimes one wants to pass the ui mode to an eel helper, or as a fusion object property. Now one must actually pass the whole helper (which works but is super strange) or we have to call methods like isEdit and the like in eel.

${Foo.Bar.forUiMode(Neos.UiMode)}

// and

${Foo.Bar.forUiMode(Neos.UiMode.isEdit(), Neos.UiMode.name())}

To me it makes more sense to name it like a "normal" context variable and dont pretend its an helper.

like: uiMode

uiMode.isEdit: bool
uiMode.isPreview: bool
uiMode.name: ?string
uiMode.options: array

A third thing would be how to use the RuntimeFactory. In the case of having a nested helper one needs to created a nested array:

$this->runtimeFactory->createFromConfiguration(
    $fusionConfiguration,
    FusionDefaultContextVariables::fromArray(["Neos" => ["UiMode" => $uiModeHelper], "request" => $request])
)

it would feel much more natural to just do this:

$this->runtimeFactory->createFromConfiguration(
    $fusionConfiguration,
    FusionDefaultContextVariables::fromArray(["uiMode" => $uiMode, "request" => $request])
)

[bwaidelich]

@skurfuerst wrote on Slack:

the main problem I have with this is that it opens yet another API to the user (= a syntax he needs to remember). As a user, why is this not an Eel helper like everything else?
=> "node" and "request" etc are more "domain data" objects IMHO which are to be expected by the user.
The problem I am having in the long run is having 10 or 15 "magic variables" available, which are not discoverable by checking out the registered Eel helpers. (becuase that's where I would look for registered helpers).
I won't block the other syntax if you all say it's the right way to go; but at least above are my concerns

I have the same gut feeling, and re:

anyone actually wanting to understand fusion at a deeper level, will be first confused that the helper Neos.UiMode is not configured in the Neos.fusion.defaultContext

That might be confusing indeed, but is IMO just an issue of the overlapping concepts in general.
Maybe we can just register it to the custom context (from Neos.Neos) for good measure?

A second thing is, that sometimes one wants to pass the ui mode to an eel helper

IMO that mode should never be passed around in the first place to avoid the feeling that this value is allowed to change in other prototype levels etc.

So instead of

${Foo.Bar.forUiMode(Neos.UiMode)}

I would strongly encourage do translate the actual mode to something more contextual relevant, for example:

${Neos.UiMode.isEdit() ? Foo.Bar.showEditButton() : '-'}

(please imagine a better example)

[mficzel]

I also think it is weird that the value "UiMode" would appear magically below "Neos" and that this value has state where others default helpers usually do not have that. I remember us doing quite a bit of work to convert q from a magic value to a function that is visible in the settings to be able to explain where this comes from.

If we have to change this at a later point migrating from "UiMode.isEdit()" is just as easy to migrate as Neos.UiMode.isEdit(). So i would rather keep this simple now and avoid adding weirdness if possible.

" to avoid the feeling that this value is allowed to change in other prototype levels etc."

We change node all the time and even documentNode and request is modified in places like fusion form / 404.

Maybe we should think more about @cache.context rather than the fusion-runtime context. It is possible we are trying to mount this horse from the wrong side.

[mhsdesign]

"node" and "request" etc are more "domain data" objects IMHO which are to be expected by the user.

i dont see how a user would expect an eel helper with state as more natural than another context variable. And actually currently "request" is not much expected for fusion users unlike "node", as its also currently just magically present - we just need a documentation of "always there" runtime default context variables like "request" and the upcoming "uiMode".

Maybe we can just register it to the custom context (from Neos.Neos) for good measure?

we could do this but then we would need to unset this at a wrong place (the runtime factory should not know about it, as this would be a Neos concept and not Fusion. As written above, we just need a way good place to document the "request" properly as well. And maybe having an built in syntax in eel to check what current variables exist like ${__dir} and ${request.__dir} and what accessors they have would make things even easier for devs? neos/flow-development-collection#3154

---

Maybe we should think more about @cache.context rather than the fusion-runtime context. It is possible we are trying to mount this horse from the wrong side.

Are you rethinking the approach to make it a "normal" context variable via $runtime->pushContext("uiMode", $mode);?
To document why we currently decided against this approach:

If we add any new context variable besides "node" and "documentNode" and "site", we currently cannot guarantee it will always be present. The problem being uncached cache segements: To start from the minimal set of context variables (to speed up deserialization) we only serialize a user specified set. Currently users know these and include the three variables "node" and the like. But adding a new variable would force all users to adjust the declaration to also include it to be serialized, as otherwise it will not show up.
A solution for this problem would be to have some kind of "default" uncached variable names, or remove the optimization of serializing only a set of variables, as the use of @context is currently declining and people prefer "props".

But even if we wouldnt have those limitations, @skurfuerst argued, that the "uiMode" would be better of like a variable like "request" which is magically reached backdoors than have it conceptional in the fusion runtime variables (where it could also be unset)

[mhsdesign]

Fyi initially the request was once also a "normal" context variable set from the outside (the view). But the property mapper cannot serialize it to a string -> which is required for uncached context variables see link.

To solve this @kitsunet made the request a "magic" variable in the runtime that is always present and always the current one.

95ad8e1#diff-61be780dafcd0a3d9838012d82db9bd15c74a18ec5cc9fd2ef768ba07307be93L581

[BUGFIX] Request in context cannot be serialized
The request in the TypoScript context cannot be serialized for uncached
segments. This means an uncached TypoScript cannot use the request.
To have the current Request at any time in the context it is injected
together with the default context variables.

aditonally pushing the request variable from outside was removed