Cancel

Sarah Gooding

Customize Posts Plugin and Selective Refresh are Paving the Way for Front-End Editing Powered by the Customizer

photo credit: Paintbrush - (license)
photo credit: Paintbrush – (license)

Last week Weston Ruter and the folks at XWP released Customize Posts version 0.5, which includes a new framework for postmeta and the ability to preview featured images. The feature plugin aims to introduce basic content authorship in the Customizer to improve the new user site setup experience and make it easier to edit existing content.

As of 0.5, Customize Posts supports the ability to change and preview the page template, and will sync changes back to the metabox on the page edit screen. It also supports changing the post author, excerpt, and comment/ping status, with live previews and changes saved to the editor. Check out Ruter’s screencast touring the plugin’s newest capabilities:

Front-End Editing Powered by the Customizer: A Not-Too-Distant Possibility

With all these advanced editing capabilities, it doesn’t take a giant leap to imagine a future where the customizer provides the architecture for a front-end post editor. While WordPress’ front-end editor project seems to have gone dormant, improvements to the Customizer are steadily chipping away at the various aspects of content authorship that are not yet editable on the frontend.

“Now that we have the ability to selectively refresh elements without doing full page reloads, this opens the door to using these Customizer components outside of the Customizer itself, such as in the frontend,” Ruter said.

Front-end editing of partials, which are similar to customizer controls but exist in the preview, is a natural extension of the selective refresh architecture and a concept that Ruter will be exploring in the near future.

“Consider, for example, being logged-in on the frontend,” Ruter said. “You see something you want to edit and you click on it. Since the Customizer partials all have selectors associated with them, if the partials are registered with each logged-in frontend request, then there are containers that can be targeted for editing.”

Ruter envisions that clicking on an element would load the controls for that element on demand via a lazy-loaded Customizer pane or a floating control. He said that this would work in concert with customizer transactions (aka snapshots) to store the changes persistently in a transaction.

Front-end editing powered by the customizer, according to Ruter, would involve the following:

  1. Being able to click Customize in the admin bar to lazy-load the Customizer pane’s controls into the existing page without having to having to navigate to `customize.php`
  2. Being able to click on individual containers that have associated partials to start editing controls that relate to those partials
  3. All changes made on the frontend to be persisted in a transaction draft that is initialized on demand

The ability to edit posts in the customizer on the front-end isn’t going to happen overnight, but Ruter thinks a proof of concept could be available this year.

“It’s going to take some discovery and prototyping, similar to Customize Posts,” Ruter said. “My guess is there would be something to play around with in Q3, depending on other projects and having enough time to put down on paper these ideas that have been floating around for a couple years.”

An important step towards making that possible will be getting basic content authorship added to the Customizer, which Ruter and contributors are working towards for the upcoming WordPress 4.6 release.

These will be welcome changes for those who are looking to do more on the frontend, but it still leaves the bulk of content editing behind the admin. Unless you’re a developer who follows every update to the customizer, it’s still confusing for the average WordPress user to know what content can be edited on the frontend vs. content that requires returning to the admin. The editing experience will remain disjointed until the majority of tasks can be done on the frontend.

Category: ,
Tags:
14

14 responses to “Customize Posts Plugin and Selective Refresh are Paving the Way for Front-End Editing Powered by the Customizer”

  1. A many people didn’t realize WordPress customize is the (future) base tool for live-editing any visual aspects of site/blog.

    Love how customize getting there eventually. Thanks for the immersive hard-work done by the team- looking forward for seeing more awesomeness.

  2. Thanks for the writeup! I will note that it was we together at XWP who released the plugin, not just me. There is a lot of work by my colleague Derek Herman in this release.

  3. The amount of work here is amazing. I don’t want to take anything away from how impressive this is.

    I wish I thought the Customizer was a great idea. It’s not a good place for “regular people” to work on content. It’s just a different version of the bad content creation and editing process – but it still doesn’t make sense to “regular people”. My clients are exact those folks and I won’t even teach them this. Way too confusing. They have to see the effects of CSS in their theme to understand what they are doing. If they can’t see that . . . it isn’t a successful process. Now we’ll have two such unsuccessful processes.

    This plugin is the one that should be headed for core. Instead, it doesn’t seem to be a “popular kid” which confuses me. https://wordpress.org/plugins/wp-front-end-editor/

    I guess I suspect why the customizer is getting all the attention and I think it is a mistake. Let me put it this way. If you want to get to that magic 50% number, you have to make content creation more intuitive than it is now and more intuitive than your competitions. This Customizer won’t get you there. Those regular people are my clients and they are tired of waiting for this process to get better.

    Invest resources, please, please, in that Front End Editor plugin. Busy people with other jobs can learn that!

    • Hi Kristen,

      If you haven’t already, I’d encourage you to install WP Customize Posts and have a play around. A lot of what you’re describing around Front End editing has been achieved, and in an incredibly intuitive way.

      I agree that the Front-end Editor plugin is amazing. We’ve taken a lot of inspiration from it in WP Customize Posts. One of the problems I have with it, though, is that it’s really hard to do things like updating a page template, or a feature image, or categories and tags without those dedicated controls. You don’t have that problem in the Customizer.

      To your point of seeing the effects of your changes right away, that’s exactly what WP Customize Posts addresses. For me, I use it to quickly updated headings (do I use a h2 or h3 here?) and see the effect of that in the post immediately. It’s also great for previewing changes on mobile devices as you make them.

      We’ll be doing some user testing on the plugin soon, to get a feel for what “regular people” think about using the Customizer for editing posts and pages. If it’s too confusing, we hope to address that. If you’d like to take part, or maybe you have clients who would like to participate, shoot me an email. :) luke@xwp.co

      • I think you’ve missed the point, Luke. I don’t care (and, it seems, neither does Kristin) how good you make the Customizer because it’s the wrong concept to begin with.

        Nor do I care (and, I suspect, neither does Kristin) whether the specific front-end editor plugin to which she has linked is the focus of greater attention; the point is that the very concept of a real front-end editor is the way to go, and it’s sad to see it so neglected.

        So yes, your improvements to the Customizer provide … well, improvements to the Customizer. But they don’t provide significant improvements to the writing and editing experience for most non-techie users.

        It’s sad to see so much effort and talent so misguided. But the writing and editing facilities in WordPress remain — strangely, for software that was first and foremost for blogging — distinctly ordinary.

    • @Kristin @KTS915 Thanks for your comments. I don’t think we ultimately disagree here. I too want to see front-end editing happen, but we have to first build up the foundations, and I believe the Customizer is the best foundation to get us there.

      The Customizer is WordPress’s framework for previewing changes. I believe it is the natural place to develop features like content editing because users need to be able to see what their content looks like without a “save and surprise” experience. See an issue on the Front-end Editor project from two years ago where we discussed using the Customizer as the framework for previewing changes.

      I believe the Front-end Editor project may have stalled because of the huge challenges with implementing an inline front-end editing experience that is compatible across all themes. The Customizer was designed for theme compatibility and because there is a separation between the preview and the controls for making changes, it is much easier to develop controls for editing posts and postmeta. Changing a page template is a great example: a change to a page template necessitates a full page reload because a template could have a radically different structure. Since the control for changing the template is not inline, a full page refresh doesn’t cause the UI for editing to momentarily go away while the refresh is happening

      For changing aspects that don’t carry the risk of a full page refresh to preview properly, there are other challenges. Consider editing the post content and how the content in the visual editor in the backend is visually different than how the post content appears on the front-end. Sure there are editor-styles.css to help approximate the style, but it’s not perfect. Beyond styling differences, a bigger challenge is how to deal with shortcodes. Even with the Shortcake project (a plugin which gives Shortcodes a UI with a visual representation of a shortcode similar to how the gallery shortcode is handled in core), the shortcodes appear differently in an editing context than in a regular front-end context. So there is a challenge for editing content on the front-end, where if you start editing the rendered content would have to be replaced with the editor content, and then then to preview the change you’d have to then leave the edit mode to go back to the preview mode.

      The selective refresh functionality mentioned in this post provides the mechanism to preview changes to parts of a post without refreshing the entire page. This is critical for implementing front-end editing since, as noted above, you can’t have the page reloading all the time while you are trying to type in the page.

      Selective refresh (aka partial refresh) opens a door for the Customizer framework for previewing changes to be used on the front-end. A first phase for the Customizer on the front-end would be to lazy-load the Customizer sidebar and controls without having to navigate to customize.php. The second phase would be inline editing on the front-end. For an example of how this could work: say you’re on the front-end and see a post you want to make a change to. You could click the regular post “Edit” link and the title and the content could then appear as editable fields, while the admin bar could reveal two new buttons for “Preview” and “Save”. Clicking “Preview” would apply the changes you made and apply selective refresh to see the title and content as they would appear on the front-end after saving. You could then click the Edit link again to make additional changes, or you could then click “Save” to persist the changes to the database. The changes you make could be added to a Customizer transaction and so persisted as a draft, allowing you to navigate to other areas of the site (e.g. going from the homepage where the excerpt is displayed to the post’s permalink to see the full content), and you could continue editing the changes you made on the previous page. When you’re satisfied, you could then click “Save” to persist all of the changes you made while in the Edit context while navigating around the front-end of the site.

      Using the Customizer as the framework for front-end editing does not necessarily require using the Customizer UI as it currently exists.

      So, please don’t write-off the Customize Posts project as a waste of time. Front-end editing is a huge challenge and requires a lot of architecture. We’re working on the foundational pieces for content editing in the Customizer with the goal of using them to power front-end editing as you are longing for.

      • @Weston Ruter,

        Thank you for taking the time to respond at such length.

        I understand the challenges involved in developing a usable front-end editor, but I don’t think you’ve justified the Customizer as the best means of working out how to address them. It just happens to be what’s there, which isn’t much of a reason at all.

        To me, the most interesting thing you said was embodied by your last sentence:

        We’re working on the foundational pieces for content editing in the Customizer with the goal of using them to power front-end editing as you are longing for.

        If that was how the Customizer project had been presented from the start, it would have made so much more sense. But if it had been seen from the start as really just a means to an end, it wouldn’t have been forced into core, and we wouldn’t have to install a plugin to turn the whole thing off.

        So I’m not clear whether you have always viewed the Customizer project as a means to an end or are simply trying to provide a new justification for it after the fact. Either way, I wish I believed that others working on the Customizer take the same view as you apparently do. If not, then I will continue to write off the Customizer as a waste of time.

      • Thank you Weston, from that explanation I now understand a lot more about the process of bringing advances to core and about the customiser and it’s role.

        The plan you outlined to bring front-end editing to WordPress is solid and I’m impressed the concept is this far along.

        I wish you all the best.

  4. The drafting of a post on Medium remains – for me – the best and most intuitive approach yet. Why can’t WordPress, with its plethora of resources, manage something like this?

    Editus is the closest concept yet. Be nice to see WordPress step-up to encourage more innovation like this.

    • @Danny: Medium can make such an intuitive editor because they have complete control over their platform: they have a closed ecosystem. They know all of the elements that can be displayed in an article and they can craft a seamless visual editing UI for these elements. I see Medium supports adding images and URL embeds into article content. Images are added via an upload UI, and the UI for URL embeds is just pasting in the URL and hitting enter. The WordPress visual editor largely supports these already. But WordPress is an open ecosystem where you can install thousands of themes and plugins that extend the editor and customize how the content is displayed:

      Representing shortcodes in a way that can be edited while displaying it identically to how it will be presented on the frontend is a big challenge here, but one that is being worked on in the Shortcake project.

      Consider also plugins that add filters to the_content to modify how it appears when rendered on the frontend. Even in Core, the infamous capital_P_dangit filter. In the editor you can write “Wordpress” but on the frontend you will see it as “WordPress”. Supporting such filters is a big challenge for a seamless inline editor.

      So yeah, I would say WordPress’s extensibility is the primary reason why there is no seamless inline front-end editor in Core. It is a big challenge to add such an editor while also support infinite variations introduced by themes and plugins.

  6. Now that’s a cool feature. But I all like minimal design, look and feel. I think front end based editing should only be plugin based features. Adding these sort of features will only make customizer more heavy to load and hard to manage.

    • @WPVKP Thanks. I will note that Customize Posts does not load any posts initially. All of the posts get lazy-loaded via the preview, so there shouldn’t be a perceptible degradation in load time.

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: