Live preview of new post/page via XML-RPC for mobile clients.

[daniloercoli]

We'd like to have the possibilty to load the 'live preview' for a post/page you're writing on a mobile client.
(New post not already "synched" with the server, or post edited within the mobile app).

The only solution that I can see at the moment is the following:

• Upload the post/page to the server with the status set to 'Draft'.
• Load the permalink of the post.
• Open the post in a webview by using the WP login form and the redirect_to parameter.

[markoheijnen]

Can't we just use the current implementation with a parameter to only use get_default_post_to_edit() and not use wp_insert_post.
Because the way you describe will only work for new posts.

[daniloercoli]

Replying to markoheijnen:

Can't we just use the current implementation with a parameter to only use get_default_post_to_edit() and not use wp_insert_post.
Because the way you describe will only work for new posts.

Sorry, I missed an important part in the description of the workaround. Replace "The only solution that I can see at the moment is the following" with "One solution we can use client side...".

[markoheijnen]

I believe we can combine this one with #21397. Basically what you want to do is creating a revision for existing posts and for a new one you can create a new post and set the status to draft

[maxcutler]

This could be as simple as a new method wp.getPostPreview( post_id[, revision=latest] ) that is very similar to post_preview (in wp-admin/post.php) and just returns a URL that contains the preview, preview_id, and preview_nonce URL query args. Then the client can open this URL in a webview.

[redsweater]

Ideally this would be solved in a way that allows the client to download a reusable template for the current theme. You don't want to be sending changes up to the server every time you want to get an update for how the post is going to look. In my Mac desktop client, MarsEdit, I update the live preview within a second or so after the user ever pauses typing. If this was hitting the network every time it would not only be agonizingly slow, but it would be a major bandwidth hit. The bandwidth hit is, of course, especially undesirable on mobile devices.

Ideally we would get a call like wp.getPresentationTemplate with parameters for whether the template will be applied to a post or a page, and perhaps further options to allow different templates based on the new post formats.

Essentially if the API could do a dry-run through the render loop for the pertinent type of post, supplying dummy template placeholders wherever the theme asks for e.g. post content, it would be ideal for clients who want to offer an accurate, highly efficient preview of how the post will look on the blog.

Daniel

[markoheijnen]

Hey Daniel, That doesn't make sense to do because of different templates, stylesheets, shortcodes and what a theme loads more. We want an exact copy how it shows on the site.

Also this isn't a major bandwidth it. Unless you reload the screen after every word you type.

[redsweater]

markoheijnen: Isn't the API in a position to do a dry run through the render process the same way it would for presentation? Then it would get all the "different templates, stylesheets, shortcodes and what a theme loads more."

As I said I update the preview within a second after the user stops typing, which can lead to hundreds of refreshes in a typical session. It's a lot of bandwidth to do a full request to the server for each of those, and would provide a poor user experience, to do all of those through the server.

Finally, without some way of templating this offline, the app becomes useless for preview unless there is a current internet connection. I don't know if the official WordPress iOS app prioritizes offline functionality, but it's a beloved feature of mine and other apps.

[markoheijnen]

Update the preview within a second after the user stops typing is something really unwanted and I can believe it leads to hundreds of refreshed. Specially when you are on a mobile device. That said on a mobile you are not going to do this. Maybe on a tablet

I don't think the API is in a position to do a dry run. We can make it happen but with a lot of time and most likely after that it is still buggy.

About offline, yes I would love to get it in to but being realistic I don't see that happening soon. But if you got the time to get it working really well go for it and I'm happy to look into it and get it in core.

[redsweater]

I can only offer my perspective as a developer who has been using the API for many years and experienced use cases you may not be familiar with. If you don't value features like preview updates every second, then you can discard my feedback as you see fit. Suffice to say, "hundreds of refreshes" is not a big issue when you don't have to query the web for every single one.

[markoheijnen]

I use API's a lot so I can see your perspective. I do value feature as some kind of live preview but I also see the issues with it.
But the question is do you see how difficult it is to integrate something like this. When you dealing with a CMS a lot of things can change when the content change like with a shortcode. That is hard maybe even impossible to get it right.

Also thinking about future implementations like post types supports doesn't make it easier to handle everything.

[redsweater]

Hi Marko - thanks for the clarification. I don't see the difficulty implicitly in implementing my suggestion, because I don't have a lot of experience with the internals of WordPress apart from the API.

So, if it's too difficult or error-prone to provide the kind of templating behavior I suggested, I respect that. I'm happy to have my points recorded here in the ticket in case anybody has insights that would make such as solution more manageable.

[azaozz]

As @markoheijnen mentions above "live preview" as you type is really bad from UX point of view. It's fun watching for a while but as soon as the user starts typing something "more serious" it's super distracting. It's the exact opposite of DFW :)

On a small screen it's even worse: half of the screen is already taken up by the keyboard, then there is editor area where the user types on the other half. A live preview would split that editor into two making it really small and would "mirror" the content from the editor in the preview.

[redsweater]

azaozz: in 5 years I don't think I've ever had a single complaint about my app's live preview being distracting. As I said above, I wait to update until there is a delay after typing, which probably avoids the UX problem you are worrying about.

Anyway, this shouldn't be a debate about whether or not any client of the WordPress API has reasonable cause to create frequent preview updates. I laid out some reasons for why a template solution would be desirable and so far the reactions have mostly been dismissive of the rationale. The reaction that it would be difficult and error-prone are valid and that sounds like the legitimate reason to resist implementing something like I suggest.

[koke]

Replying to markoheijnen:

I believe we can combine this one with #21397. Basically what you want to do is creating a revision for existing posts and for a new one you can create a new post and set the status to draft

I think this would work for us.

Replying to redsweater:

Ideally this would be solved in a way that allows the client to download a reusable template for the current theme.

I also like this approach, although I understand it can be really hard to implement. Not sure how hard exactly, but doesn't feel like a trivial task.

I don't care so much about live preview, but being able to preview offline, and avoid any redundant bandwidth usage would be nice for us.

[nacin]

Punting this in favor of #21397.

[wonderboymusic]

#21397 happened.