Quick Update: WP-Gistpen Version 0.5.0
I’ve been working hard on getting the next version of WP-Gistpen out the door. The “killer feature,” Gist interoperability, is underway. This a huuuge deal, which required a number of precursor features to be implemented, the biggest one (previously) being revision saving.1 Unfortunately, as I started work on importing from Gist, I realized the current revision implementation wasn’t going to work the way I want it to.
Part of the difficulty is getting some visibility on what, exactly, is being saved and when. WordPress won’t save a new revision unless the new version is different from the previous version. For WP-Gistpen, the main Post probably won’t change all that often, because there isn’t any content in it; all the content is saved in child posts, so the comparison filter would return false and not save a revision. I stuck in a terrible solution, forcing the comparison to pass no matter what, but that also impacts regular posts as well.
I’ve been watching with interest to development of WP-API, which is undergoing and major rewrite for version 2.0 and will hopefully land in core in 4.2 or 4.3, but there isn’t currently any timeline for integration. There has been discussion about the future of WordPress as an app framework/foundation, and the JSON API is a big step towards that future.
My plan was to rewrite the editor front-end in Backbone in version 0.6.0, but WP-Gistpen’s infrastructure makes it much easier to save this completely myself rather than hooking into WordPress’s save process. This can be bypassed by sending the data to save via AJAX, rather than POST’ing the data to post.php2 and then redirecting after the save. Instead, I’m bumping the Backbone rewrite up to this version and rewriting the saving mechanism as an AJAX hook3, which will accomplish a couple things:
It will give me a lot more control and visibility on exactly what is being saved when and how.
The data can be sent as JSON, rather than the current hack-y
$_POSTvariable set up.4The editor in general will function more like an app and will save and update “in-place,” rather than WordPress’s current “POST-and-redirect” method.
That rewrite is currently in process here. I’m doing all my development publicly like this going forward, in the hopes of getting feedback from other developers as I go. The Gist interoperability PR until the Backbone rewrite is merged into it.
That’s the current state of the project. There’s a lot of work to be done to get this functioning the way I need to proceed with Gist syncing, but it’ll be awesome when it’s complete. The settings page in the Gist Interoperability PR above was written in Backbone and it works very well. I can’t wait to unleash to this on the world.
Lastly, I want to leave you with a pair of tutorials that were instrumental in getting the JS part working in WordPress:
Using Backbone Within the WordPress Admin: The Front End from Tuts+ – this will will be more useful going forward
Using Underscore.js Templates To Render HTML Partials – this was really helpful for the settings page.
Stay tuned!
I also added the beginning of some WP-CLI commands, including most importantly, the addition of test data so you don’t need to be currently using the plugin to help work on it. Also, Scrutinizer, which has been incredibly helpful and is a feature that will be backported to wppb-mod. ↩
Which is what happens when you save it in the editor. It also manipulates the data a bit in a function called
edit_post(), thenwp_insert_postdoes its own manipulation and validation. So it’s a lot of steps and I’m not entirely clear what gets called when. ↩All the current AJAX hooks will be migrated over to WP-API hooks when that lands in core as well. ↩
You can see that awfulness here. While the current version looks a lot cleaner than this, as I’ve refactored and broken things down into chunks quite a bit, it doesn’t function all that differently, and I’ve always hated it. ↩