Consider adding Same Page Preview to core

I have seen this demo'ed at various stages of development and am impressed.
I think Content Creators and Editors will find this very useful. I find Same Page Previews has better usability than the preview currently available in core. I think this aligns with the "ambitious site builder" experience.

Thanks for the speedy work on this useful module.

I've updated our module page to reflect the current state of the module. I suppose I should also work on what a commit to the 11.x branch might look like to give folks here something to critque.

+1 on this aligns with the "ambitious site builder" experience.

+1 for same page preview in core! It's one of those things that seem required once when you see it in action. Bravo for the job done so far!

Inline editor was added to core in the past but didn't succeed. I think one of the reasons was, that people were not used to inline editing and also the frontend themes were often broken when inline forms were added to markup.

Instant (same page) preview is something that cloud CMS's are selling as a feature and I also think that it has much better chance of succeeding in core than Inline editor.

+1 from me to add this to core in light of "ambitious site builder" experience.

A very BIG +1 from me; this is precisely the kind of thing we need to promote Drupal

Into core ASAP I say!

I've done a very quick test with:

1. Drupal 10.1.6
2. PHP 8.1.0
3. Theme: Bootstrap 5 → subtheme 3.0.10
4. Admin theme: Gin 8.x-3.0-rc7 →

Note sure about these enormous buttons, but maybe that's just a Bootstrap 5 / Gin combo thing...

Great work team!

Thanks for the excellent bug report!

We might need to provide better protection of our elements to ensure that our buttons aren't impacted by administrative themes.

I'm eager to have time to fix this but am under a terrible crunch right now. I should have time in a few weeks to fix.

+1 for adding to Drupal core! I am very impressed, this looks awesome, and it would be a huge improvement for the Ambitious Site Builder.

Yes, huge +1.

This would be a fantastic addition to the Drupal content editorial experience. I've been aware of this, but I just wanted the video on the project page to get a proper understanding of how it works, and I think this is something that I know the content designers I work with would love.

One thing that comes to mind for consideration, and I expect these are already being considered or have been worked on, but wanted to raise them here for the record: How well does this work on small screens and mobile? Should we consider more than just a horizontal arrangement.

Either way, looks great, I'm excited for the day this lands in core!

Next steps:
* Try to get this into some kind of Recipe or Distribution.
* Continue refining / being active in the issue queue.
* Listen to use cases I didn't consider and ensure we can adapt.
* Which means reorganzing my work/life to ensure I can give proper time to this effort (working on that).

Timing:
Given my silly desire to use Single Directory Components, perhaps I set back the inclusion of this work a ways since it would depend on another experimental feature. So.... Drupal 10.3+ might be a good target.

If Same Page Preview was in core, there would be a number of changes we would do.

• There are number of places we are extending core: NodeForm, PreviewControlsForm. We wouldn't need to do that and instead would refine our overrides further and include them in the Core objects.
• CSS: We've had to include a small amount of changes to styles the we may not need to do if we could teach a future off-canvas dialog how to be resized without artifacts.
• JS: We anticipate that much of the work of including this module into core is going to be spent refining the javascript. There's totally room for improvement. And in a world where experience builder and other dynamic user experience also exist, there's probably a lot of new ways of accomplishing what we're doing.

If it helps, we could produce an MR that would show what including this into core would look like.

Given the changing landscape of Drupal recently, could Same Page Preview be added to Starshot, that seems like a good option, then decide whether it needs to be in "Core" beyond that.

@AaronMcHale there is actually an issue and a related PR in the Starshot prototype repo:

https://github.com/phenaproxima/starshot-prototype/issues/17
https://github.com/phenaproxima/starshot-prototype/pull/61

As @brianperry has shown, yes. And we agree that's a great first step.

It should be noted, that the Next Steps are still on the Same Page Preview team.

We need to demonstrate what the actual change would be to include this into core. That said, before Starshot, the typical first step would be to be included as an experimental module. And for that step, same_page_preview would likely change very little. We do anticipate some change due to feedback / core contributor's direction. Fundamentally thought, we've already tried to only use core and to do as little as possible.

But if this work was in core, some obvious changes would be made. Such as:

• No longer need to extend @internal objects
• spread our logic to existing administrative forms
• As a result, probably won't need to any any new objects, forms, or other objects. Just extend existing ones with additional logic.

In addition, I'm personally very excited about the new navigation bar and the top navigation bar specifically. We have an excellent opportunity to demonstrate the utility of both with our preview pane. Eager to learn more about making use of it.

Experience Builder turns the node form inside out and you edit the content on a preview-first UI with the form on the side. I think that solves this problem?

@gabor is this true when using 'content type templates' or the equivalent of layout builder default layouts, as described in 🌱 [META] 7. Content type templates — aka "default layouts" — clarify the tree+props data model Active , or only when using the XB field/landing page mode?

I have not seen recent designs for content type editing, but Lauri presented a UI for mapping dynamic fields from content types to props in https://youtu.be/5ViCxc8ksb4?si=TqFStM83dgjzJTw7&t=942 (this timestamp going forward) that is based on the same UI based editing as XB for static pages, so I assume that is roughly what will happen. (Those are designs not working implementation).

Hey gang. Thanks for kicking off this conversation again.

XB's preview is very awesome. Laying out content from a composition of components is pretty awesome in practice too. I've been following along the best I can to try to answer to myself what further life Same Page Preview could have within a XB driven world.

At the heart of this discussion are the questions:

* How will users engage with content types in the future?
* Will they be in the practice of filling out fields on a traditional node edit page?
* Will there be any other structure that needs to be previewed that isn't directly connected to experience builder?

Keep in mind that all same_page_preview is doing is putting Drupal's existing preview functionality in a more prominent place on the page. So on a technical level, the maximum that I asking is, are we going to be removing NodePreviewController any time soon?

If you're going to remove existing ways of previewing content, then same_page_preview is dead. If not same_page_preview should be allowed to continue to exist if folks find it useful.

I personally think we should be doing 📌 Rewrite the node preview functionality on top of workspaces Postponed: needs info to phase out the current node preview functionality, because it will enable full site preview - e.g. a menu item added on the node form will be accounted for etc.

The benefit of Same Page Preview is that it allows Drupal to incorporate a feature of competing CMS solutions that user testing has identified gives content authors a higher degree of confidence that they are using the system properly. Being able to see the rendered version of a piece of content as they are filling out a structured form does provide value to the user.

If XB is planned to offer live preview while filling out a content form (e.g. not working with components etc) then Same Page Preview is not needed, but I think we should validate that before we close this issue.

Same Page Preview's use of NodePreviewController is merely to override the methods:

* view
* title

And we add a method:

* getPreviewUrl

But honestly we're not trying to do anything clever with it. We're just getting the output of the preview so we can shove it into an off-canvas dialog.

I'm hearing you say that you want to keep some kind of non XB preview functionality around, just something that ALSO works with workspaces. I'm all for that. I love workspaces already and thing XB's awesome. I'd like to help out in this space where I can.

There's just a lot going on that I'm not up to speed on. I don't know:

1. If Drupal's preview functionality can get any of that XB magic (I'd love to isolate the thing being built into it's own preview).
2. What the next steps are on any of this.

How can we continue this conversation?

FWIW, re #25, I'd suggest to not extend the core controller and define your own controller and route. sounds like you override and customize more than the controller actually has code for in the first place, so I'd duplicate into a custom route. That should also make the whole thing much more future proof. See also 📌 Deprecate NodePreviewController::title Active . Per https://www.drupal.org/about/core/policies/core-change-policies/bc-polic... → , I think we wouldn't even need to provide BC for that.

on topic: Same page preview is interesting, but I don't think there is a good reason for it to be in core, considering the product strategy changes given with Drupal CMS/XB and so on where the focus of core is on providing APIs and building blocks that contrib/CMS can build stuff on.

Maybe it would be more appropriate to discuss getting Same Page Preview into Drupal CMS?

Yes I think almost anything editor-facing would need to be included in Drupal CMS to be considered for core at this point, moving this issue there.

@gabor is this true when using 'content type templates' or the equivalent of layout builder default layouts, as described in #3455629: [Needs design] [META] 7. Content type templates — aka "default layouts" — affects the tree+props data model, or only when using the XB field/landing page mode?

It has been designed to work with both. In fact, it looks very similar to Same Page Preview but in Experience Builder!

I'll let @pameeela weigh in on whether this should be in Drupal CMS or not, but it doesn't seem ideal to target this for core at least.

@laurii yea that's the ticket. And given that this appears to be working with XB, I bet you've got the live update of preview working.

This does beg the question about how Drupal core's preview functionality may change in a post-XB universe. Does it even make sense to attempt to provide this update capability to non-XB contexts?

Thanks everyone for your input! After reading all the comments, I think it probably doesn't make sense to introduce this to Drupal CMS at this point. For sure, SPP is great for existing sites and will be for those using the legacy node form for a long time to come. But since Drupal CMS is a starting point for new sites, and we are now working on 2.0 as the XB-ready version, I don't think it is the right fit.

> It has been designed to work with both. In fact, it looks very similar to Same Page Preview but in Experience Builder!

I'll just add that I'm happy that Same Page Preview was able to help with some super early XB prototyping and concepts, and that I'm really excited about the prospect about the example in #29 that provides a similar experience using XB.

Also I want chocolate for some reason.