Position the new iFrame so preview and edit are side by side

Created on 19 February 2023, over 1 year ago
Updated 28 February 2023, over 1 year ago

Problem/Motivation

Once ✨ Add iFrame of the preview Fixed is done, we want to make sure that the new iFrame is positioned where we want. We want the preview to appear side-by-side with the content edit page.

Proposed resolution

We might need to introduce a wrapping element so that the iframe can be positioned. It was also suggested that the preview side could have a "slider" to allow the preview area to vary based on user preference.

Remaining tasks

All the above.

User interface changes

Positioned iFrame element.

✨ Feature request
Status

Fixed

Component

Code

Created by

πŸ‡ΊπŸ‡ΈUnited States cosmicdreams Minneapolis/St. Paul

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @cosmicdreams
  • Status changed to Postponed over 1 year ago
  • πŸ‡ΊπŸ‡ΈUnited States mherchel Gainesville, FL, US

    I'd like to help with this when it's unblocked. Marking as postponed for now (since it's blocked on ✨ Add iFrame of the preview Fixed

  • πŸ‡ΊπŸ‡ΈUnited States cosmicdreams Minneapolis/St. Paul

    In ✨ Add iFrame of the preview Fixed , we appear to have a remaining issue of needing to improve the reliability of the preview generation. That effort should no longer be considered a blocker for this ticket: controlling the position and size of the iFrame.

    Feel free to start your tinkering.

  • Status changed to Active over 1 year ago
  • πŸ‡ΊπŸ‡ΈUnited States cosmicdreams Minneapolis/St. Paul
  • πŸ‡ΊπŸ‡ΈUnited States cosmicdreams Minneapolis/St. Paul

    @mherchel with ✨ Add iFrame of the preview Fixed in RTBC we have zero blockers on this issue.

  • πŸ‡ΊπŸ‡ΈUnited States cosmicdreams Minneapolis/St. Paul

    There are a couple of ways we can tackle this problem. I suspect that we'll need to introduce some custom styling at some point. I have a few questions that might steer our thinking about how best to solve this:

    1. Should we introduce a field-level template for this?
    2. Will controlling where the field is placed within the render array even possible?
    3. Do we need a wrapping element like container?
  • πŸ‡ΊπŸ‡ΈUnited States cosmicdreams Minneapolis/St. Paul

    By giving this a little thought it seems like the obvious choice here is to have some kind of containing element that wraps both the content editing side and the preview side. This would allow us to make the display become a single column if the viewport is reduced to mobile.

    This is the portion of the work that I may need to rely upon my collaborators, I spend nearly all of my time in the backend.

    I am aware that this is the kind of thing that has like 10 solutions already, maybe there's one in core we wish to reuse?

  • πŸ‡ΊπŸ‡ΈUnited States cosmicdreams Minneapolis/St. Paul

    It appears we can use CSS Grid to help with this problem https://stackoverflow.com/questions/46931103/making-a-dragbar-to-resize-...

    Here's a full example

    <!DOCTYPE html>
    <html>
    <head>
    	<title>Resizable Two-Column Grid</title>
    	<style>
    		.container {
    			display: grid;
    			grid-template-columns: 1fr 1fr;
    			grid-gap: 10px;
    			width: 100%;
    			height: 300px;
    			background-color: #f5f5f5;
    			padding: 10px;
    		}
    
    		.column {
    			background-color: #fff;
    			padding: 10px;
    			overflow: hidden;
    			resize: horizontal;
    			transition: all 0.3s;
    		}
    
    		.grabber {
    			width: 10px;
    			height: 100%;
    			position: relative;
    			right: -5px;
    			cursor: col-resize;
    			z-index: 10;
    			background-color: #ccc;
    		}
    
    		.column:hover .grabber {
    			background-color: #999;
    		}
    	</style>
    </head>
    <body>
    	<div class="container">
    		<div class="column">
    			<h2>Column 1</h2>
    			<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed sed mi ac tellus malesuada posuere. Donec hendrerit aliquam sapien ut tristique. Proin eget metus mi.</p>
    			<div class="grabber"></div>
    		</div>
    		<div class="column">
    			<h2>Column 2</h2>
    			<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed sed mi ac tellus malesuada posuere. Donec hendrerit aliquam sapien ut tristique. Proin eget metus mi.</p>
    			<div class="grabber"></div>
    		</div>
    	</div>
    </body>
    </html>
  • πŸ‡ΊπŸ‡ΈUnited States shaal Boca Raton, FL

    Here's an example of how same_page_preview side-by-side to editing form, using flex.
    (Which will allow narrow screens to display the preview below the edit form)

  • πŸ‡ΊπŸ‡ΈUnited States brianperry

    Our solution here will have the additional challenge of having to work with any admin theme, but some of these early concepts make me think of the way Gin handles the show and hide of the meta sidebar. Gif example attached.

  • πŸ‡ΊπŸ‡ΈUnited States cosmicdreams Minneapolis/St. Paul

    Re #9: Did you mock that up in dev tools?

    I'm partial to using a Flex / CSS Grid solution. I see the value in having some javascript in there to toggle the visibility of the preview as well. I feel we could do that with CSS Transitions + a little bit of javascript.

  • πŸ‡ΊπŸ‡ΈUnited States cosmicdreams Minneapolis/St. Paul

    When thinking about the preview, I've always thought about having ALL of the editing controls on one side, and just the preview of the page on the right.

    That vision is a little bit different from #9 because all of the right edit column stuff is split from the left column edit stuff with a preview in the middle.

    That sounds like a small change from what #9 is showing.

  • πŸ‡ΊπŸ‡ΈUnited States cosmicdreams Minneapolis/St. Paul

    Is it possible to accomplish any of this without editing node-edit-form.html.twig?

  • πŸ‡ΊπŸ‡ΈUnited States shaal Boca Raton, FL

    I think the right side-panel is a separate issue, out of the scope of the code of same_page_preview itself.

    In my opinion, most people would prefer using the real estate of the editing page for the live preview side by side, and deal with metadata somewhere else, probably at the bottom of that page.

  • πŸ‡ΊπŸ‡ΈUnited States cosmicdreams Minneapolis/St. Paul

    I think what might be proven to be unavoidable is that we won't be able to enforce ONE WAY of displaying / organizing the preview. At the moment, I can't imagine how we're going to accomplish our goals without altering the node-edit template. As a result, we can leave it to various administrative themes to have their own take on where the same-page preview will be shown (if at all).

    For now, let's just focus in on reference implementations. Let's target Claro since it's in D10. That should reduce the time it takes to get 1.0.x out the door. How do we feel about creating implementation A & B, then allowing users to try them both? Or maybe a setting that allows users to pick which template they want to use?

    I'm still partial to the all-the-edits-on-the-left / all-the-previews-on-the-right solution. That can be one of the implementations. @shaal's idea can be the other.

  • πŸ‡ΊπŸ‡ΈUnited States cosmicdreams Minneapolis/St. Paul

    Here's what I have so far

    I'm having some responsive flow issues but that seems like it could be handled via CSS. Used CSS grid for this. here's some of the markup and styles:

    <div class="layout-node-form-page clearfix">
      <div class="layout-node-form clearfix">
        <div class="layout-region layout-region-node-main">
          {{ form|without('advanced', 'footer', 'actions', 'gin_actions', 'gin_sidebar', 'gin_sidebar_toggle', 'preview_pane') }}
        </div>
        <div class="layout-region layout-region-node-secondary" id="gin_sidebar">
          <div class="layout-region__content">
            {{ form.advanced }}
            {{ form.gin_sidebar_toggle }}
          </div>
        </div>
        <div class="layout-node-form__actions">
          {{ form.gin_actions }}
        </div>
      </div>
      <div class="layout-node-preview clearfix">
        <div class="layout-region layout-region-node-preview">
          {{ form.preview_pane }}
        </div>
      </div>
    </div>
    {% if gin_layout_paragraphs == 1 %}
    <style>
      .layout-node-form {
        --gin-lp-layout: "{{ 'Layout'|t }}";
        --gin-lp-content: "{{ 'Content'|t }}";
      }
    </style>
    {% endif %}
    <style>
      .layout-node-form-page {
        display: grid;
        grid-template-columns: 1fr 1fr;
        grid-column-gap: 1em;
      }
      iframe.preview {
        height: 100vh;
        width: 100%;
      }
    </style>
    
  • πŸ‡ΊπŸ‡ΈUnited States cosmicdreams Minneapolis/St. Paul

    And here's a better screenshot of how it looks like with the "Advanced" config collapsed

  • πŸ‡ΊπŸ‡ΈUnited States cosmicdreams Minneapolis/St. Paul

    In πŸ“Œ Take over the Preview button Fixed I created an additional merge request that lands a module provided css file. There we can target the expected selectors to hack our preview to be side-by-side. My instinct here is to override the node-edit form. Let's talk this one through during next week's check-in meeting.

  • πŸ‡ΊπŸ‡ΈUnited States cosmicdreams Minneapolis/St. Paul
  • πŸ‡ΊπŸ‡ΈUnited States cosmicdreams Minneapolis/St. Paul

    I have merged in πŸ“Œ Take over the Preview button Fixed which allows us to continue with this issue without causing conflict. I've been thinking about this a lot.

    If we want to avoid modifying the node-edit template, then we have a finite set of solutions we can pursue:

    1. Use #prefix / #suffix to wrap our preview in a div, use that div to control position
    2. Float the div that wraps the iframe to the side

    Can you think of any others?

  • πŸ‡ΊπŸ‡ΈUnited States cosmicdreams Minneapolis/St. Paul

    After a little exploration, I couldn't get either of these two ideas to work by fiddling with the form API.

    So I looked into having the module override the node-edit template. I was able to succeed in that but I feel I broke the intent of the markup a bit. Here's a full screen screenshot of my work-in-progress.

    I applied a version of the previously discussed display:grid technique.

    As you can see the margins that were previously applied have been overridden which makes the bottom of the page look disconnected. I feel that this change would not be accepted as a core contribution if it came to that. I'm going to see if I can tweak this a little but could use your advice on the best way to fix.

    Next Steps

    1. Tweak the markup / styles to make this look better in claro.
    2. Pursue the ability to check the current theme then provide an override of that theme's node-edit form.
    3. Figure out what a good "default" template would be.
  • Status changed to Needs review over 1 year ago
  • πŸ‡ΊπŸ‡ΈUnited States cosmicdreams Minneapolis/St. Paul

    Ah, given how the margins are 'auto' this is kind of unavoidable. I wonder if this is fine then? I think the person who could tell us that is @ckrina. I pinged her on Slack to jump in and provide an opinion.

    I've also pushed up all the work needed to make the full page screenshot work for your review.

  • πŸ‡ΊπŸ‡ΈUnited States brianperry

    I've been exploring using the off canvas dialog as a presentation for this. I've attached a video of a POC. The POC is currently a pile of hacks (can't easily share it as a result,) but I think it demonstrates how this could behave. I think it could be a way around some of the challenges that Chris is seeing in his work (overriding the node edit template, screen real estate issues, etc)

    The biggest challenge I see is that the off canvas dialog renders it's content using the admin theme. Using an iframe helps but I still think we'll either need to create our own renderer rather than using the offscreen canvas renderer, or create our own preview controller that actually spits out an iframe.

  • πŸ‡ΊπŸ‡ΈUnited States cosmicdreams Minneapolis/St. Paul

    I actually quite like the idea of "popping open" the preview.

    It weird that the preview has the admin theme. One would think you would be using the same preview generation service that our previous attempts use.

    We've been iframing that in with our previous attempts. But it's just a url. We can inject that different ways.

  • πŸ‡ΊπŸ‡ΈUnited States cosmicdreams Minneapolis/St. Paul

    @brianperry do you think you can wrap up the work you've done with off-canvas into a MR so I can review? I might be able to help with the rendering of the appropriate preview.

  • @brianperry opened merge request.
  • πŸ‡ΊπŸ‡ΈUnited States brianperry

    @cosmicdreams opened an early draft MR for the off canvas concept. Currently just gets the off canvas dialog in place. Just using '#url' results in the preview page being rendered using the admin theme. Iframing should solve that (and will also be necessary for our existing preview functionality to work). Considered a few approaches to this:

    * Create a new renderer service that renders the preview page iframed. We can then specify the renderer using the 'data-dialog-renderer' element. In the video demo I faked this by hacking web/core/lib/Drupal/Core/Render/MainContent/OffCanvasRenderer.php:renderResponse to use out iFrame render element as content rather than the render root of the node.
    * Create a controller that spits out our iframe and use that route as the URL. I wonder if that might still bring along some UI cruft though - stuff like contextual links.

  • πŸ‡ΊπŸ‡ΈUnited States cosmicdreams Minneapolis/St. Paul

    I wonder if there's a difference between the method you're using the compile the preview url and my getPreviewUrl method. Are you still getting a preview that uses the admin theme? If so there might be a difference between the ajax vs the backend compiling the url.

  • πŸ‡ΊπŸ‡ΈUnited States cosmicdreams Minneapolis/St. Paul

    Ah, just tested, I see what you mean. Yea It would be ideal to be in complete control what shows up in the modal. Right now we want a modal. But this might also be our mechanism for handling πŸ“Œ Provide a button to open preview in new page Active (by putting a button in there that can launch the a full preview in a new tab).

    Do you want to take first stab at overriding the OffCanvasRenderer?

  • @brianperry opened merge request.
  • πŸ‡ΊπŸ‡ΈUnited States cosmicdreams Minneapolis/St. Paul

    I think my latest change might have broken something. I'm getting out of memory errors. Fixing...

  • πŸ‡ΊπŸ‡ΈUnited States cosmicdreams Minneapolis/St. Paul

    I need to remove at least one of my permission checks. The one to same_page_preview_entity_type_alter was leading to out of memory errors.

    I removed all of my permission checks and saw that the preview was no longer updating. I wonder if we're dealing with cache trouble here.

  • πŸ‡ΊπŸ‡ΈUnited States cosmicdreams Minneapolis/St. Paul

    Ah I was clicking the wrong preview button. The toggle open preview button doesn't generate a new preview.

  • πŸ‡ΊπŸ‡ΈUnited States cosmicdreams Minneapolis/St. Paul

    I am all done with my tinkering

  • πŸ‡ΊπŸ‡ΈUnited States brianperry

    This is ready for a last review. Beyond fixing the add form regression I protected from a minor js bug, and also adjusted the preview button to be labeled 'refresh preview' and also display at both the bottom and top of the form. Assuming that the naming / placement is likely temporary, but this makes a little more understandable / functional for the time being.

  • πŸ‡ΊπŸ‡ΈUnited States brianperry
  • πŸ‡ΊπŸ‡ΈUnited States cosmicdreams Minneapolis/St. Paul

    All good. It's a wrap.

  • Status changed to Fixed over 1 year ago
Production build 0.69.0 2024