Problem/Motivation

The functionality provided by wse_preview unblocks our client from using Workspaces because they need a way for unauthenticated users to preview a set of content changes. This is really helpful, but upon testing, we discovered that the preview functionality is fully transparent to the end user. So transparent, in fact, that it may give end users the wrong idea.

There is also the question of how they might “get back” to the live version of the site once they’re done previewing the workspace. Both of these problems are solved by an indicator on the admin UI that always shows the name of the current Workspace (Live, Stage, etc), but with the use of preview links for users who are not authenticated, there is no indicator to provide users with this very important functionality.

I propose creating rendering a simple indicator on public pages when a workspace is being previewed. It can be as simple as a div with the name of the workspace and a button element which, when clicked, clears the wse_preview cookie and refreshes the current page (or takes the user to the front page?).

Proposed resolution

Render something like this somewhere in the content region on all public-facing pages when previewing a workspace:

<div class="wse-preview__indicator">
  <span class="wse-preview__indicator__workspace">{{ workspace_name }}</span>
  <button class="wse-preview__indicator__reset-button">Back to live site</button>
</div>
<script type="text/javascript">
  // Untested pseudo-code:
  document.cookie = 'wse_preview=; expires=Thu, 01 Jan 1970 00:00:00 UTC; path=/;';
  // This would need to point to the front page:
  window.location.href = '/';
</script>

User interface changes

Public-facing pages previewing a workspace would receive indicator markup and a button or link that allows them to “get out” of the workspace.

API changes

None that I know of.

Data model changes

None that I know of.

Issue fork wse-3549398

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

agarzola created an issue. See original summary.

amateescu’s picture

amateescu commented
Status: Active » Closed (works as designed)

That's exactly the purpose of \Drupal\wse\Plugin\Block\SwitchToLiveBlock :)

Now that this issue is closed, please review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, please credit people who helped resolve this issue.

cosmicdreams’s picture

cosmicdreams commented
Status: Closed (works as designed) » Active

Hello! I came across this issue because I have exactly this concern. When demoing this feature for clients they were very concerned that the preview is TOO good. That their stakeholders would screenshot the preview (after the redirection enacts) and that the screenshot shared would have no indication that the previewed page wasn't already live.

In the past miscommunications like this led to all kinds of problems.

The response above indicates that there is already a solution developed to handle this concern. I think it's work pointing out:

1. Installing wse_preview does not place this block. You have to do this yourself.
2. There is no documentation for the wse_preview submodule at all. And no mention of this solution in the top level README file.

So how does a user properly implement and adopt wse_preview? Is this module intended to be showcase of functionality that hasn't been properly productized? Feature additions that can make it's way into core?

What does a successful implementation look like? In my view it looks like:

1. Workspaces are extended to provide previews (mostly done, it's just kind of hard to find where previews are)
2. When previews are shared, some kind of warning / disclaimer is present to inform the viewer that they are seeing an unpublished preview.
3. The ability to control that message somehow.

I am reactivating this issue for discussion.

cosmicdreams’s picture

cosmicdreams commented

Proposed changes:

1. Switch to Live Block could look nicer. I've got a bunch of suggestions here. Can I share and we discuss?
2. Write a README for the wse_preview module that guides the user to place the block.
3. Consider code that auto-places the block (at least let's talk about it)

What do you think?

amateescu’s picture

amateescu commented
Title: Provide a Workspace preview indicator » Document how to provide a workspace preview indicator
Project: Workspaces Extra » Workspace Preview
Version: 2.0.x-dev » 1.0.x-dev
Component: Workspace Preview » Code

WSE preview has graduated to a standalone project now, with a proper README of its own :) Let's keep this issue focused on adding some information about using the Switch to Live block.

Switch to Live Block could look nicer. I've got a bunch of suggestions here. Can I share and we discuss?

Of course, but I think this should be done in a feature request for core, essentially for moving (and improving) the existing block from WSE to core.

Consider code that auto-places the block (at least let's talk about it)

I can't think of any scenario how this could be done safely for any site, so maybe this point could be folded into the "provide guidance in the README" one above?

cosmicdreams’s picture

cosmicdreams commented

Are you looking for a co-maintainer? I'm somewhat passionate about previewing experiences. I created. same-page-preview because I thought we could do heaps better with previewing content creation.

What do you want the workspace preview to be?