Explore leveraging Customizer for previewing post and postmeta changes

[westonruter]

I was chatting a bit with @helen on IRC a couple weeks ago about any investigation that has gone into leveraging the Customizer to implement previews for changes to post and postmeta changes.

Based on experience I've had with implementing Widgets in the Customizer, I've come up with a functional prototype which currently shows a "Posts" Customizer section populated with fields to change the currently-queried post appearing in the Customizer preview: https://github.com/x-team/wp-customize-posts

Changes to the post/postmeta fields in the customizer trigger refreshes of the preview with the changes reflected. Upon hitting Save & Publish, the changes get saved to the post and postmeta.

I've logged issues on the GitHub project for additional features and enhancements that are needed. For example, this Posts section should allow you to customize any post that appears anywhere in the preview, even when it is not the queried object.

Likewise, the Customizer section should actually get populated with the metaboxes that appear on the post edit screen, although all in the side context so that they fit in the Customizer panel. Naturally, the metaboxes would have to be opt-in since many custom metaboxes wouldn't support being rendered in the Customizer.

I wanted to submit it for consideration to be included in the Frontend Editor plugin project.

[doctored]

that's pretty interesting.

[ellatrix]

Thanks for letting me know that you're working on this. I've cloned the plugin from GitHub, but I can't figure out how to use it. :)

Can inline editing be achieved in the customiser? I'm not sure how you see both this plugin and the customiser combined, but even if it's possible to edit the content inline, why would it be better to take front-end editing to the customiser?

[westonruter]

@iseulde To use the plugin, currently you navigate to a post that you want to edit, and then select Customize from the admin bar:

Then you will see a "Posts" section in the Customizer and fields for the post data and metadata:

As you make changes to the post/postmeta fields, the preview will refresh with the template loading with the post/postmeta filtered initially when first accessed, and so the template will automatically render without having to manipulate the frontend.

That being said, the Customizer can certainly manipulate the DOM elements in the preview window. This is how the live postMessage transport updates are accomplished, as you often see in themes, for example _s (customizer.php and customizer.js). The problem with these live updates, however, is that they are theme-specific. It is extremely challenging to code-up such live updates in a universal way, which I'm sure you've been wrestling with as well. So by default, changes to settings in the Customizer will trigger a refresh which will result in the underlying values getting filtered up front so that the template will automatically “do the right thing”.

For the Widget Customizer plugin, I initially added support for Live Widget Previews which leveraged the postMessage transport to dynamically (via the DOM) update the widgets in the preview window when changes were made (see §Live Previews in my proposal blog post). However, this support had to be theme-specific. We decided in the end to drop that feature Widget Customizer was merged into Core, opting instead to explore generalizing the mechanism so that any customizer control could register areas of the preview for live updates (see #27355: Customizer: Add framework for partial preview refreshes). So, integrating the frontend editor into the Customizer would mean that changes made to post/postmeta could be made on any theme whatsoever, even ones that don't explicitly opt-in for any frontend-editor support.

When doing live updates via postMessage, the controls need not reside in the Customizer panel. They could be placed inside the preview as the frontend editor is doing.

[ellatrix]

Have you seen http://wordpress.org/plugins/post-customizer/?

[westonruter]

@iseulde yes, am familiar with the Post Customizer plugin. (I would have called my POC “Post Customizer” instead of “Customize Posts” otherwise 😄) That project came out while we were working on the Widget Customizer. The Post Customizer plugin, however, does not actually leverage the Customizer framework. What it does is emulate the Customizer UI (and it does quite a good job), doing all edits/previews via DOM manipulation. Such live DOM manipulation (i.e. transport=postMessage), I think, needs to be opt-in and by default do updates via refreshing the preview with the post/postmeta data filtered on the PHP side. This is what the Customizer is designed to facilitate.

[ellatrix]

Ah, okay, haven't looked at the code, and I'm actually not familiar with the customiser at all.
So how do you see this included in this project? I mean, it's all front-end editing, but approached and written differently. So I'm wondering if you mean melting plugins together or just have more than one plugin/approach in the project and see how they evolve?
I've always thought it would be good if someone else could explore front-end editing with the customiser and make a prototype. I think I talked about that back in September. :) Have one project exploring different front-end editing experiences.

[westonruter]

@iseulde yeah, I'm happy if Customize Posts develops in parallel to Front-end Editing. I was just hoping it might be a useful reference for how to leverage the Customizer to preview changes to post/postmeta. I'll continue hacking on my Customizer prototype to see what comes out of it. 👍

[ellatrix]

Hi Weston,
Did you continue work on this or the other post customiser?

[westonruter]

I've continued work on customize-posts. Here's the pending release: xwp/wp-customize-posts#16

From the develop branch: https://github.com/x-team/wp-customize-posts/tree/develop

By the way, I wanted to also draw your attention to this core ticket I just filed this afternoon which could be very useful a Front-end editor which draws upon the Customizer: https://core.trac.wordpress.org/ticket/28602

[celloexpressions]

My idea (which I also wrote in a comment on make/core, but here seems better) is to leverage the Customizer for any UI that can't be consistently managed from the front-end across different themes, which I think would include taxonomies, featured images, and pretty much everything other than title and contents. We could also incorporate things like linking to revisions (maybe get the revisions UI to open up in a modal) and the whole publish metabox.

If we create a Post: [title] panel, then use sections for each item that would traditionally be a metabox, we could deep-link to that panel, but have the Customizer "collapsed" by default. So when you open the front-end editor, you can write/edit and publish directly, but there would be some sort of an options button that expanded the Customizer to show the post options (pending user testing, and how frequently they want to set these options when posting/editing from the front-end). If necessary, users could back out of the panel and directly access any other Customizer controls from the same interface.

Also, general note that we're trying to make the Customizer more front-end contextual. If FEE integrates with the Customizer, we would have one integrated way to manage pretty much any part of a site from the front-end.

[ellatrix]

I have no experience with the Customizer API, but I'll explore a bit soon. Note that the front-end editor loads on every post where the user has the right caps, so using the Customizer would mean loading it almost all the time... Wouldn't that be a bit over the top? On the other hand, if the experience is smooth enough, we could always load it on the front-end. The alternative is the have a page refresh between edit and view mode, but if possible, I'd like to keep it the way it is.
And yes, I'm totally up for experimenting.

[celloexpressions]

@avryl and I chatted about this during Customizer office hours today, log: https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2014-09-05&sort=asc#m919310

The most important thing for me for the FEE is that it should be fully functional on every theme out-of-the-box. The Customizer accomplished this with preview-refreshing. Something similar could be done for FEE to avoid needing theme support for things like taxonomies and featured images to work. My primary idea would be to do what we've been thinking about with partial preview refreshes, backwards: do a full refresh of the preview, except for the editor (and maybe title field), then silently move the editor into the new DOM in place of the old one.

If we can get a POC for that working, then we can look at whether it makes sense to leverage the Customizer itself for that, and exactly how such a thing would work in the context of WordPress.

[ellatrix]

I decided to branch the FEE and try it with the Customizer instead. I'll see where I get. I'll have to "fork" the Customizer though, since there are a few problems if you want to seamlessly integrate it with the front-end. What I want to do is to load it all the time for posts, and maybe later, together with all the other sections, on every page. For that we probably need to optimise it a little so it's not as slow. We could render just the iframe and any other controls afterwards with JS when the user opens the Customizer. Another thing that's necessary is to update the URL when the user navigates through their website, along with the title of the page.

The name "Customizer" is also a bit weird... You don't really customise a post. :)

The backwards partial refresh sounds a bit weird though. It's full refresh after which you reattach DOM to it? You may as well reinitialise any JS if that's the reason. For TinyMCE, we'll have to listen for any refreshes and reinitialise anyway. In theory this should work, though it may be slow and the change may be visible. The other option is to only allow partial refreshes (like I've been doing with this FEE without the Customizer), but that needs theme support again...

[ellatrix]

*Needs theme support in some cases for some things.

[ellatrix]

One month later... Second rewrite... :|

[celloexpressions]

We definitely want to re-work the Customizer to load more efficiently, which probably means eventually being able to load it entirely via JS. See several tickets on core trac with ideas. Also, the Customizer roadmap draft: https://docs.google.com/document/d/1UI2YhmliKAadYJNX-V_C1FQL_GBZ0f7zi1EZijgfm8w/edit?usp=sharing. A couple of the things you mentioned have core patches from @westonruter (like updating document titles and URLs), so it would be good to get those into core during 4.1.

I think we would want to use "edit" when in the post context, and "customize" outside of it. But it would make sense to customize the page template, for exampe

[westonruter]

@iseulde @celloexpressions I felt inspired and took a quick stab at seeing what it would take to add basic inline editing to the Customizer. I was surprised at how easy it was! Very little code is needed. I pushed the plugin up to GitHub: https://github.com/x-team/wp-customize-inline-editing