This is just a short post to explain…

Cross-posted from here

 

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.

@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.

navigator.onLine blues

Well, apparently, of the browsers I have available on Ubuntu 11.04, only Opera checks the actual state of the connection when you use navigator.onLine, and returns false when you’re offline. Firefox checks if Work offline is checked in the File menu, and afaict Chrome/ium just returns true.

the automatic requests sent by autosaves are the way to go, apparently.

copied from the WordPress Gsoc 2011 blog

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 it just went 1.0!) 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.

Abstract

Following feedback from my first proposal and from the #wordpress-gsoc channel on freenode, I have decided to split it into two different proposals. This works because the tie between the two parts of the project were the reliance on new technologies (File API and localStorage) to provide  a better,smoother experience to WordPress users, but they were not explicitly interwoven.

My vision is that at the end of this project, a WordPress user will not care at if any time during him/her writing a post on his blog, his Internet connection goes down.Editing files (and posts) on the client and using localStorage to save drafts when the Internet connection goes down can make everyone’s experience with WordPress a lot more safe and maybe a little more enjoyable.

Implementation

When it comes to saving drafts, I believe it would be pretty straight-forward. Check if the connection to the server is still alive. If it is not, rely on localStorage to save the draft. When the connection comes back up, check client and server revisions, see if the client has revisions which are newer than the ones on the server. Synchronize. If at any point when the connection is down the user clicks the “Publish” button, the post he’s working on will be published when the connection returns.

A talking point would be whether to save deltas (differences between draft versions) or states. Saving deltas would save space, but would complicate the development and may lead to complications unforeseen at this point.

The W3C recommends a 5MB limit on localStorage allocated space for a given domain, but also specifies that when a domain is approaching that limit, the user be prompted to allocate more memory. When it comes to text, I believe 5MB could be more than enough.

Challenges

As with my other proposal, one of my main concerns is inter-browser compatibility. I have not done my research in this field yet ( this will be one of my main focuses during the bonding period). While caniuse.com says that 77% of the browsing public supports localStorage, browser subtleties and bugs could put a dent on time spent developing features.

Another challenge will be coming up with a format for encapsulating all post data in a series of strings (localStorage supports key – value pairs and nothing more). A combination of serialized data and XML will probably be used. This will be one of the main talking points I will approach with my mentor during the bonding period.

Preliminary schedule

I will use the bonding period to research localStorage browser incompatibilities, available libraries, limitations and best practices. I will also research (and talk out with the mentor and community) the best way to save the states of drafts (format and implementation-wise) and explore the existing code related to saving posts (automatic drafts especially).

• Week 1 ( May 24th – May 30th) – Iron out all (most) design issues that might arise.
• Weeks 2  – 4 (May 31st – June 19th) – Save drafts to local storage.
• Weeks 6 – 8 (June 20th – July 10th) – Detect connection state changes. Implement restoring from localStorage when connection goes back up.
• Weeks 9 – 10 (July 18th – July 31st) – Documentation, code clean-up.
• Week 11 onward – Bug fixes, polish and unit tests.

Conclusion

Accidental refreshes, browser crashes or simple internet black-outs all leave users in frustration over their lost work. LocalStorage is here today and using it would bring  a sigh of relief for everyone who has lost precious work due to causes out of their hands.

GSoC 2011 Draft Proposal – File API Enhancements.

Following feedback from my first proposal and from the #wordpress-gsoc channel on freenode, I have decided to split it into two different proposals. This works because the tie between the two parts of the project were the reliance on new technologies (File API and localStorage) to provide  a better,smoother experience to WordPress users, but they were not explicitly interwoven.

Abstract

Working with media in WordPress is by no means broken, but I believe it can be improved. Adding support for the HTML File API would bring improvements in this area, including drag and drop support, editing files (images,audio,etc) on the client, dropping (in due time) Flash, etc.

The deliverable would be a plugin, which would replace swfuploader with an uploader based on the File API, integrate in the Post editor/media upolader portion of any blog/site.

Implementation

I’m no usability expert, but here are my thoughts on how the plug-in should integrate in the current admin panel:

• a meta-box with a droppable area in the new post screen, which would extend to provide file previews, and enable dropping them in the post. Double clicking on an image thumbnail would bring up a basic JS based image editor, which would edit the file before sending it to the server.
• a similar setup when bringing up the “traditional” file uploader. Key components would be file preview and basic editing before sending it to the server.
• integrating the unified progress bar (if the project is selected for GSoC)
• available hooks to enable front-side easy upload of local files, for quick, “tumblog”-style blogging.

It has been made clear from the proposal idea that all existing hooks should be preserved, and that will be a guideline along the way.

Challenges

One of my main concerns is cross-browser compatibility. Though this should not be a huge issue yet, considering the File API is currently only implemented in Firefox (3.5+), Chrome (8+ IIRC) and Safari (6+), browser with a good track record of playing nice with standards. However, should there be browser implementation differences, and no suitable library is to be found, lots of development time will be spent on exactly that, a suitable library.

Another concern of mine will be making a good user experience. Though I consider myself a good coder/developer, I cannot say that I’m a good designer. I WILL need community input on this, and am very open to changes and modifications.

Preliminary schedule

I would use the bonding period to read up and compare File API libraries, also to bring me up to speed on the uploader hooks, By the end of this period I should know if I am to use an external library or have to write everything from scratch. I will also look into the existing picture editor, see exactly how I could use it to edit pictures on the client. Will also use this period to gather ideas on the interface, build mock-ups, etc.

• Weeks 1 – 4 ( May 24th – June 19th) – Focus on having a working, stable HTML5 uploader, that allows preview of files to be viewed on the client.
• Weeks 5 – 8 (June 26th – July 15th) – Add new hooks, implement  client-side image editing.
• Weeks 9 – 10 (July 18th – July 31st) – Documentation, documentation, documentation. Code clean-up. Gather community feedback on interface.
• Week 11 onward – Tweak interface according to community feedback, unit testing and bug fixing.

Conclusion

This project would future-proof WordPress, when it comes to handling files. While Flash is today a de-facto standard on PCs, relying on it for something as basic as uploading a file is wrong and we have consider the open standards when developing. It is my hope that this project will provide a better user experience while implementing the Web as it was supposed to be: open.

2011 GSoC Draft Proposal – File API Enhancements + localStorage backup of drafts.

Hello, this is a draft proposal for GSoC 2011 for the WordPress community.

Abstract

Working with media in WordPress is by no means broken, but I believe it can be improved. Adding support for the HTML File API would bring improvements in this area, including drag and drop support, editing files (images,audio,etc) on the client, dropping (in due time) Flash, etc.

My vision is that at the end of this project, a WordPress user will not care at if any time during him/her writing a post on his blog, his Internet connection goes down.Editing files (and posts) on the client and using localStorage to save drafts when the Internet connection goes down can make everyone’s experience with WordPress a lot more safe and maybe a little more enjoyable.

As I see the project now, the deliverables would be two plugins: one to replace the swfuploader with a File API uploader (either based on an already existing library, or something developed from scratch), and a plug-in to enable localStorage backup of drafts and revisions. After proper reviewing of the plugins, I can see the functionality included in them valuable enough to be included in core.

Personal Data

My name’s Mihai Chereji, I’m a sophomore at Babeș-Bolyai University, in Cluj-Napoca, Romania. I’ve been working as a web-developer since August last year (until December at a web agency here in Cluj, and since then as a freelancer with my brother), and have been using WordPress for projects for clients and friends ever since.

Pages I have developed on WordPress so far include:

• Luna Amara
• Gunas
• Visionwise

I have also implemented sites on CodeIgniter and done maintance and feature upgrades on other sites. It would be fair to say I have at least an intermediate (to advanced) understanding of PHP, and quite a good grasp on Javascript (which I love and hope to develop a lot more in that language).

I have not started blogging on WordPress until now because I’m still searching for an awesome domain (and some decent hosting) for my blog (or family of blogs) and some inspiration .

I have not contributed to WordPress yet, except as a somewhat,kinda active member of the WordPress StackExhange (user name cronco), and a patch that is at the moment of this writing not reviewed. Frankly, contributing in any way has been very intimidating, (even writing this proposal is )

Preliminary Schedule:

I would use the bonding period to read up and compare File API libraries, also to bring me up to speed on the uploader hooks, By the end of this period I should know if I am to use an external library or have to write everything from scratch.

• Weeks 1 – 5 ( May 24th – June 26th) – Focus on having a working, stable HTML5 uploader, that allows preview of files to be uploaded on the client.
• Weeks 6-8 (June  27th  – July 15th) – Focus on integrating existing hooks in to HTML5 uploader and (if necessary, which I foresee will be), add new hooks.
• Weeks 9 – 12 ( July 18th – August 9th) -  Create working offline/online hooks and add localStorage drafts and revisions backup.
• Weeks 13 – 15 (August 10th – August 31st) – Debugging, polish, extra documentation.

I expect not to be able to complete the second plug-in as I would desire, which would be to log into localStorage also media manipulation, in addition to simple post backup.

Conclusion:

caniuse.com, the premiere site when it comes to estimating new web technologies support, estimates that 40.17% of the current browsing public has support for the File API features (all users of Firefox up from 3.5, Chrome up from version 8, and Safari 6), and a whopping 78.41% for localStorage. This proportion will only grow, and I believe it’s a large enough number of users to make this project worthwhile today.

 

Update

I have decided to split this proposal into two: File API enhancements and localStorage drafts backup