Yes, there’s something in /wp-includes/js/autosave.js you could call onchange, like window.wp.autosave or similar, I’m not sure.
According to comments on the JS page, autosave runs every 15 sec if there is a change, so you probably do not need to invoke yet another autosave, you just need to get the content from the correct post. You do not use get_post( $post->ID ); The autosave data is in a special post.
If 15 sec is not enough resolution, you are probably going about this wrong. You should perhaps be using a different hook? Perhaps ‘save_post_inherit’ (inherit is the post type for autosaves and revisions). You would not check for $post->ID but for the autosave ID.
Either way you go, you need to identify the correct autosave post. It appears you could query for posts where post_parent is $post->ID and post_name is LIKE %autosave%. There can be several posts returned still if several users have edited the post. I’m not sure how to differentiate them. Perhaps the user ID is in post_author?
While there’s more details for you to figure out, this should at least get you pointed in the right direction.
Thank you for the various pointers. I tried playing with autosave to see what happens in the posts table.
Every time autosave runs, it is simply updating the actual post and doesn’t create any inherit post. So all my changed contents are saved on the main post. When I save the post, it then creates an inherit post with the latest contents.
I also tried to implement the hook save_post_inherit, but it doesn’t get called either on autosave or on actual post save.
Another option I tried was to use WP_Query, since it directly queries the DB. This seems to be work fine for post title and post content, but it doesn’t return any info regarding the tags, categories etc.
Another option is to send these attributes via ajax to the backend, so that we can read the current unsaved data.
any other thoughts?
Wow, you kinda turned my world upside down in a small way! I thought I understood autosave, but I obviously did not do an on-server analysis. The difference between reading and doing. I do kinda wonder how the behavior might change after the autosave post is created – draft status behavior differs from published? I don’t see the point of the autosave post if it’s not updated except when the main post is. To have totally reliable code you’ll need to investigate every possibility. For starters just focusing on one scenario is enough.
The tags and categories need to come from something like wp_get_post_terms(). I’m not sure how that would work with autosave – more testing, woo-hoo. Then there’s probably things in post_meta that are updated as well, custom fields etc., not to mention any meta boxes that plugins add and hook into ‘post_save’ or similar.
Your AJAX idea makes sense on one level, but it seems a shame to add more javascript when autosave is doing the same thing. I thought about hooking into autosave’s PHP AJAX hook, but I’m not sure how to do that, autosave appears to be a “special” AJAX request that is handled differently than the usual AJAX requests. I do know it’s tied into the heartbeat call that occurs regularly when an edit screen is up.
I still think something related to ‘save_post_inherit’ action would be a good solution, if we could just find the right hook. There’s all sorts of actions that fire for various post save scenarios. We just need to identify the right one. Besides those in wp_insert_post(), several possibilities exist in wp_transition_post_status that depend on what the old and new statuses are.
I found a way to invoke autosave using – wp_create_post_autosave(). It’s used by post_preview() in core and it returns a new ID.
This works great. However, it only saves the post contents. It doesn’t save any thing related to tags, categories etc.
So, for all the other stuff, we are still relying on sending over the data via ajax.
