This is just a short post to explain theme and plugin developers how to use my plugin (LocalStorage Plugin), which, btw, made it’s way into the official wp plugin repo – feedback and impressions always welcome.

Thanks to the awesomeness of amplify.js, it’s easy to have something akin to WP PHP hooks in JavaScript – beyond events and callbacks.

You see, the core of the amplify library offers two methods –  publish and subscribe, which are equivalent to do_action and add_action.For more info, check out amplify.js documentation

The cool thing about it is that you can send parameters, and they’re sent by reference, so it works both as actions and as filters.

In the hooks I’ve added so far, you can modify the post_data which will be saved, or submitted, before the actions take place

a.publish('aboutToSave', action, post_data);

The “plugin” example I’ve chosen to implement backs up the post format and modifies the value when showing the backup (on request).

amplify.subscribe("aboutToSave", function (action, post_data) {
	post_data.post_format = $('input.post-format:checked').val();
});
amplify.subscribe("showBackup", function (action, post_data) {
	$("input.post-format").filter("[value=" + post_data.post_format + "]").prop("checked", true);
});

And this is basically it! I’ll add some more examples later, but this is what it’s mostly about.

Last week was pretty good.

The plugin now has a component that loads on all admin pages and checks if you have backed up pages and syncs if it needs to.

It also checks when an autosave request fails in the post editor, and also sends a dummy request when you press the “Publish” button.

(this part was also posted here but I might as well copy-paste it, as this blog gets a lot more visitors)

@mitchoyoshitaka believes that when the server is not reachable, the “Publish/Update” buttons should be greyed out. I think a notification that the post will be submitted later suffices, and greying out the buttons detters the user from clicking, and (part of) what I’m trying to do is to make it ok to push that button even when offline.

We’d both love some more input from more UX-savvy people.

This week I’ll work on some user notifications and some bugs to bring it to a really usable version before midterm

Local Storage weekly update & various stuff

Well, this was a productive week, if I say so myself.

What’s done:

• Backing up is mostly done, I believe. In it’s current form, the plugin differentiates between autosaves, drafts and intentions to publish. It puts the IDs  in different lists in storage, and each entry is of the format ID-autosave, ID-draft, ID-publish. This is easily extendable, as the lsBackup function, which does the backup, takes the ‘action’ parameter, and simply concatenates the paramter to the ID of the post. Don’t know the specific case for which this should be extensible, but, hey, power to the people, right?
• Syncing to the server works for autosaves. I took the ‘action’ case from admin-ajax.php and modified it a little bit (disabled nonces temporarily,etc). I’ll have to do something similar for drafts and published posts.

What will I do this week:

• Finish the server-side code. This entails treating published and draft posts, adding back nonces, detailing error messages (like ‘the post has been edited by someone else since you started working’, credentials, etc).
• Start working on a reliable way to determine when the connection is down. My very shallow tests have shown that navigator.onLine, which I had planned to use isn’t really useful. In Firefox, it doesn’t detect whether there’s an established connection, but rather if the ‘Work offline’ switch from the File menu is enabled. Chrome doesn’t even have that switch (or I couldn’t find it), so it always returns true. Will keep checking other browsers’ behavior. @azaozz (Andrew Ozz) also made the very good point that while you might have a working connection, the server itself may go down, so the best way to check is with a dummy request.
• Polish client-side code. Right now it doesn’t have anything in the way of error handling, or stuff like that, but that will quickly change. Also, I need to remove posts from the list once they were successfully synchronized.

I think I can safely say that I’m back on schedule, and by mid-week, I should be a bit ahead.

Questions / opinions needed:

• Right now, I send a request to the server for each backed up post, be it autosave, draft or published post. Realistically speaking, I don’t expect a server to have all that many posts at a time to send to the server, so I’m not sure if it penalties performance all that bad, but I sense that I should send one request with all the posts at once, but that complicates things a little. So, I’m really at a loss as to what to do.
• Plugging into the Javascript code in WordPress is harder than it needs to be. Other than replacing the entire autosave function with your own, there’s no way to actually plug in. After a discussion with @mitcho and @azaozz, it’s become clear that a pub/sub system, or something similar to the actions model in the PHP code is necessary. I’d like to plug amplify.js again (it hit beta not long ago) as a potential candidate for inclusion. It features a pub/sub module, which, as @mitcho pointed out, is pretty close to the do/add action model in WP PHP. I’ve yet to check on any performance issues.

That’s about it for now.

PS – this may be noobish, or may have been discussed to death, or it may simply be an issue of style, but sifting through admin-ajax.php and other parts of the code, I came across a lot of examples of what I heard being called “Yoda expressions” (e.g. “if( 0 == $id)” instead of  “if( $id == 0)”). When translating the code in my head, it just sounds completely un-natural in both Romanian and English (and even in my poor French). Does this bring some performance bonus in PHP that I’m not aware of, or is that code maybe written by someone whose native language finds this particular construct natural, or is this a legitimate coding style I haven’t encountered too often before?