It has been a long time since we’ve started to work on the second version of our multi runtime file uploader. And here you have it finally – first public beta of Plupload 2.
Bit of backstory, since it’s quite complicated. First of all I would like to make one thing very clear, until it gets confusing – functionality of Plupload on a big part has stayed the same. Yes – it has gained huge potential for growth, but on the surface it shouldn’t feel to you any different. And this is actually good – ’cause if you feel the difference, then something went not as it was expected to and you should immediately report it to us 
As you might know, so far Plupload consisted of two distinctive parts – the Core (a small framework that made it easy to quickly implement cross-browser file uploader of any kind) and the Widgets – UI Widget and Queue Widget (two visually rich implementations of the Core and basically examples of Plupload’s potential). But while having a core completely separate turned out to be very handy, it still felt a bit constraining. For example it wasn’t possible to easily get the hold of a raw file data – to display thumbnails for example, or access file meta tags. Yes – Plupload was able to extract Exif and GPS info from images, but it was doing this on it’s own, without giving any control to the user. Another problem was that it was nearly impossible to control the flow of the chunks – resend them separately for example, if they failed to reach the server, calculate checksums for increased reliability, and so on.
So the necessity was obvious – we required to expand the Core farther. But how? Provide more events and methods (much more in fact)? Or separate low-level file manipulation and upload logic into a separate set of libraries? The answer was laying on the surface, but felt so crazy that it took us quite some time to comprehend that it was the only proper way to proceed. So what we did in our major update, is that we’ve extracted all the low-level logic from the Core and wrapped it up in standalone multi-runtime and cross-browser pollyfills, that are closely resembling behavior and functionality of HTML5’s File and XMLHttpRequest Level 2 APIs!…
Now, maybe currently it doesn’t sound as crazy as it did, back in early days when we started, but believe me it still opens up some very interesting opportunities for legacy browsers, that are still around (and not only). While working on pollyfills, we tried to follow existing W3C specs as close as it was possible in our circumstances, which means that our implementation of FileReader interface, or XMLHttpRequest will act and have all the properties and methods that according to W3C are expected for them to have. And if for some reason they lack some (specs were noticed to mutate quite often), let us know and we will take on them
Therefore now we have three tier system: very first level – File and XMLHttpRequest API pollyfills, second level – Plupload Core and third level – Core implementations, like our UI and Queue Widgets. Bottom levels can be extended separately – just as easy as anyone can use the Core to build customized file uploader, pollyfills can be used to create all kinds of components and obviously not only file uploaders.
Currently we publish our first beta of Plupload 2. On big part you should be able to simply drop it in instead of the previous one and everything should simply work. But there are some precautions to take into account. First of all, we’ve dropped BrowserPlus and Gears support, mostly because their authors dropped them themselves. Second point to consider is the fact, that we’ve renamed .swf and .xap shims, since they are not strictly Plupload specialized anymore (they are now part of pollyfills and not the Plupload). So in the places where you reference plupload.flash.swf and/or plupload.silverlight.xap, you must now put correspondingly - Moxie.swf and Moxie.xap (as these are the names of updated shims).
That’s it! You can download Plupload 2 here. Together with minified Moxie (combined name for pollyfill code) and Plupload code, we bundle our Widgets. Queue plugin wasn’t touched, but UI got updated to leverage the power of new APIs and now is able to show the client-side thumbs (even in IE6!).
Happy testing. We are ready to accept bug reports and feature requests. Now that we’ve mostly done with the major update, bug hunting will get top priority.
March 19th, 2013 by 
Afraithe 
Comments Off 
Today we released a new service, to allow you to try different configurations and setups with TinyMCE, as well as aid in examples for our bugtracking system, we introduce 
The buzz around 
We have had many questions about how paragraphs are handled in TinyMCE and users wanting to have <BR> elements instead of <P>. Adrian Sutton at our partner 
In order to provide better TinyMCE support for those who need it, we have started a Partner network, and our first partner signed up is