CKEDITOR.on('instanceReady', function (e) {
e.editor.on('simpleuploads.startUpload', function (ev) {
var filename = ev.data.name;
//var extension = filename.match(/\.\w+$/)[0];
var newName = CKEDITOR.plugins.simpleuploads.getTimeStampId() + '_' + filename;
ev.data.name = newName;
});
});
2016/05/23
How to generate unique file names with SimpleUploads
If for any reason you can't change the server back-end that saves your file uploads in CKEditor and you want to prevent the overwriting of existing files with new ones that have the same file names, you can add this code to your page to generate a unique filename for each upload (adjust it to your tastes)
2016/05/21
Debugging client-side and server-side
In the Google I/O 2016, one of the sessions was dedicated to what's coming to the Chrome Dev Tools.
Besides the improved features in the tools themselves, they also announced that they are planning to enable debugging of Node.js from Chrome, this way Node developers can use Chrome to debug both the client side as well as the server side once that pull request is accepted.
On the other side, Microsoft announced on February the ability to debug Chrome from VSCode. By using the Chrome Debugger protocol, they have created a VSCode extension that connects with Chrome and enables you to debug your script from your editor.
This reminds me of the feature of VS that integrated with IE11 and below so that when you started debugging a project, besides debugging the server side, the javascript debugger in IE itself was disabled and any error was launched in VS.
I must confess that I always hated that behavior, when I'm debugging a web page I'm not looking only at the Javascript, I must check the DOM to verify if the elements exist, check their attributes, view how does the page react to changes, etc... so a debugger that only allows me to look at the javascript is a bad option and when I had to debug IE I launched a new instance that wasn't hooked to VS so I could use the F12 tools of IE.
I guess that this must be useful for some people or they wouldn't have spend the time to make it work with Chrome, but I really can't see how using VSCode for Javascript is any better than using only the Chrome Dev Tools as they are constantly updated and improved and I wouldn't say that they are missing important things to debug JS. To debug client-side I certainly prefer the client-side tools to keep all the context, I'm not looking only at a JS file.
So going back to debugging Node from Chrome, I guess that it might depend on the quality of your editor (I would say that some people use very bad editors). Until Chrome becomes a full IDE, you're still using another program to write your JS, that includes plugins, it's adjusted to your taste, integrated with other tools... If it's able to debug Node itself, then I think that I would prefer to do that there instead of using Chrome, but obviously this depends on the quality of that debug experience. I can understand that the context provided in this situation can be similar by the editor and Chrome, although on one hand your editor might be able to provide better context and Chrome might have better debugging tools.
The only fear is that people is focusing too much on Chrome, and so we might see soon that any other browser dies because the web developers don't test them, users find problems and are told to use Chrome instead, then the statistics say that people only use Chrome and more developers focus their testing only on Chrome and we end in IE6 land: A browser monoculture.
Besides the improved features in the tools themselves, they also announced that they are planning to enable debugging of Node.js from Chrome, this way Node developers can use Chrome to debug both the client side as well as the server side once that pull request is accepted.
On the other side, Microsoft announced on February the ability to debug Chrome from VSCode. By using the Chrome Debugger protocol, they have created a VSCode extension that connects with Chrome and enables you to debug your script from your editor.
This reminds me of the feature of VS that integrated with IE11 and below so that when you started debugging a project, besides debugging the server side, the javascript debugger in IE itself was disabled and any error was launched in VS.
I must confess that I always hated that behavior, when I'm debugging a web page I'm not looking only at the Javascript, I must check the DOM to verify if the elements exist, check their attributes, view how does the page react to changes, etc... so a debugger that only allows me to look at the javascript is a bad option and when I had to debug IE I launched a new instance that wasn't hooked to VS so I could use the F12 tools of IE.
I guess that this must be useful for some people or they wouldn't have spend the time to make it work with Chrome, but I really can't see how using VSCode for Javascript is any better than using only the Chrome Dev Tools as they are constantly updated and improved and I wouldn't say that they are missing important things to debug JS. To debug client-side I certainly prefer the client-side tools to keep all the context, I'm not looking only at a JS file.
So going back to debugging Node from Chrome, I guess that it might depend on the quality of your editor (I would say that some people use very bad editors). Until Chrome becomes a full IDE, you're still using another program to write your JS, that includes plugins, it's adjusted to your taste, integrated with other tools... If it's able to debug Node itself, then I think that I would prefer to do that there instead of using Chrome, but obviously this depends on the quality of that debug experience. I can understand that the context provided in this situation can be similar by the editor and Chrome, although on one hand your editor might be able to provide better context and Chrome might have better debugging tools.
The only fear is that people is focusing too much on Chrome, and so we might see soon that any other browser dies because the web developers don't test them, users find problems and are told to use Chrome instead, then the statistics say that people only use Chrome and more developers focus their testing only on Chrome and we end in IE6 land: A browser monoculture.
2016/03/20
New plugin for CKEditor: ImageToolbar
Recently I've been working in order to create for Uritec a new plugin for CKEditor, it was needed due to the way that the Style system works in CKEditor.
First the Styles dropdown shows the styles that can be applied to the current element as well as its container(s); look at the official demo and select the image, now click on the Styles selector and you'll see there "Object Styles", "Paragraph Styles" and "Character Styles", something that it's not too user friendly if they just want to modify the image. The normal user wants simple things.
The second main problem is that even if they focus just on the Object Styles, you (as page author/designer) can't restrict the way that the styles work between them, so if you want to use a class to apply a 1px gray border, and a different class to create a slight rotation and shadow, the user can't apply both at the same time (unless you apply inline styles that we all know it's bound to fail).
So the goal was to allow to apply groups of classes that can be mixed so you set one group of classes to define different types of borders and another one to apply color filters, etc... Also, let's keep in mind that the align center has been disabled in CKEditor for those who prefer to use the classic Image plugin although it's easily done using display:block and margin:* auto, so one obvious group is alignment.
Putting all those buttons to show up always in the toolbar was considered a bad idea because most of the time they won't be used, and providing instead a "contextual" toolbar that shows only when an image is selected was considered the best option.
Taking all of that into consideration ImageToolbar was born, designed to work in both classic (framed) editor as well as new inline mode, and compatible with the normal Image plugin and the Enhanced Image plugin. You can play at its demo with some predefined styles, but you can define whatever you want as long as you're able to do it with CSS classes. Or if you feel lazy today, check the 1 min. demo on YouTube.
If you use the Enhanced Image plugin you should know already that the way to define your CSS file requires taking some extra care, we have added some notes about it in a small guide about styling images in CKEditor, and due to those widget wrappers and upcast/downcast you'll find that it's much more powerful when you configure ImageToolbar with the classic image as you aren't restricted by the "Enhanced image" limitations.
Lastly, remember that unlike other plugins that claim to be free but then require you a monthly payment, this is a one time payment that will give you any future update.
First the Styles dropdown shows the styles that can be applied to the current element as well as its container(s); look at the official demo and select the image, now click on the Styles selector and you'll see there "Object Styles", "Paragraph Styles" and "Character Styles", something that it's not too user friendly if they just want to modify the image. The normal user wants simple things.
The second main problem is that even if they focus just on the Object Styles, you (as page author/designer) can't restrict the way that the styles work between them, so if you want to use a class to apply a 1px gray border, and a different class to create a slight rotation and shadow, the user can't apply both at the same time (unless you apply inline styles that we all know it's bound to fail).
So the goal was to allow to apply groups of classes that can be mixed so you set one group of classes to define different types of borders and another one to apply color filters, etc... Also, let's keep in mind that the align center has been disabled in CKEditor for those who prefer to use the classic Image plugin although it's easily done using display:block and margin:* auto, so one obvious group is alignment.
Putting all those buttons to show up always in the toolbar was considered a bad idea because most of the time they won't be used, and providing instead a "contextual" toolbar that shows only when an image is selected was considered the best option.
Taking all of that into consideration ImageToolbar was born, designed to work in both classic (framed) editor as well as new inline mode, and compatible with the normal Image plugin and the Enhanced Image plugin. You can play at its demo with some predefined styles, but you can define whatever you want as long as you're able to do it with CSS classes. Or if you feel lazy today, check the 1 min. demo on YouTube.
If you use the Enhanced Image plugin you should know already that the way to define your CSS file requires taking some extra care, we have added some notes about it in a small guide about styling images in CKEditor, and due to those widget wrappers and upcast/downcast you'll find that it's much more powerful when you configure ImageToolbar with the classic image as you aren't restricted by the "Enhanced image" limitations.
Lastly, remember that unlike other plugins that claim to be free but then require you a monthly payment, this is a one time payment that will give you any future update.
2016/02/06
Deprecation plan of IE8 in SimpleUploads
tl:dr
Die IE8, Die.
IE8 is too bad according to any current standard, too limited and lacks too many features, it has bad security track, it's time to put it to rest and everyone of us has to work towards that goal and obviously one thing that we can do is to claim that those old versions aren't supported in our products, so people can realize that they have to change their browser to another one that has all those missing features.
So by the end of February I'll publish a new version of SimpleUploads just to remove the little parts that tried to add some kind of support for IE8.
I'll remove right now any claim in its description about support for IE8 and I'll update shortly the demo with the new version without support for any browser that lacks the FormData feature.
If you have any concern about this change, please comment here or send me an email, but remember that you can keep using your current version as long as you want if you prefer to support IE8 instead of embracing the future.
Die IE8, Die.
Planned deprecation of support for IE8 in SimpleUploads
We're already in 2016, Microsoft has stated that old versions of IE are no longer supported, and since some time ago Windows XP is not supported either.IE8 is too bad according to any current standard, too limited and lacks too many features, it has bad security track, it's time to put it to rest and everyone of us has to work towards that goal and obviously one thing that we can do is to claim that those old versions aren't supported in our products, so people can realize that they have to change their browser to another one that has all those missing features.
So by the end of February I'll publish a new version of SimpleUploads just to remove the little parts that tried to add some kind of support for IE8.
I'll remove right now any claim in its description about support for IE8 and I'll update shortly the demo with the new version without support for any browser that lacks the FormData feature.
If you have any concern about this change, please comment here or send me an email, but remember that you can keep using your current version as long as you want if you prefer to support IE8 instead of embracing the future.
2015/12/08
Die XP: Another benefit of Let's Encrypt
The Let's Encrypt project is a great initiative to move towards a more secure web, removing the costs to apply a secure certificate to a site and providing an automated client to take care of renewals.
This means of course huge changes across the whole the web industry:
Other CA will be forced to drop the price of their equivalent certificates to a bare minimum or make them free also, just to try to keep on some people looking at them.
Hosting providers will have to allow everyone to use a one click install of a free SSL certificate or at least manually update their certificates unless they want their clients to move to a friendlier hosting that allows setting up SSL without paying huge fees.
Website owners now will be able to avoid one of the problems (money) to install a SSL and this will be specially important for small websites. Big companies have enough resources that the cost of a certificate is nothing to them, but for a small website it's clear that every Euro counts, so most of the people didn't think at all about paying just to say that their site now can be used with https.
Hopefully this will mean the end of self-signed certificates or expired certificates, so end users will be able to understand better the difference between a secure site and a non-secure one and so after a while people will reject "old" sites that aren't using SSL, forcing those sites to install one, pushing their hosting companies to allow install of free SSL.
The government spies will have a harder time trying to track what everyone does, and no, this won't be an improvement for terrorists because they are already able to use secure communications but in Paris it has been clear that they used normal non-secure methods.
But there's one more benefit: Most of those small sites that now are installing SSL en masse are using shared hosting, so they don't have a unique IP and that means that they rely on SNI to enable https and it turns out that no version of IE under windows XP (as well as old Android 2.x phones) don't support it, so those that still keep using the old IE8 will now face a new problem because they will have constant security warnings whenever they try to visit all these new https sites.
And this is a good thing!!!
That people keep on using that old IE. I mean, it's old, old, old. Full of bugs, full of problems, a pain for all of us that try to create modern websites if you have to keep supporting it, and now those users will feel a little of that pain (although I guess that they are already suffering from all of us that have left IE8 behind and no longer test it).
Time to ditch IE 8 and move to a modern browser.
This means of course huge changes across the whole the web industry:
Other CA will be forced to drop the price of their equivalent certificates to a bare minimum or make them free also, just to try to keep on some people looking at them.
Hosting providers will have to allow everyone to use a one click install of a free SSL certificate or at least manually update their certificates unless they want their clients to move to a friendlier hosting that allows setting up SSL without paying huge fees.
Website owners now will be able to avoid one of the problems (money) to install a SSL and this will be specially important for small websites. Big companies have enough resources that the cost of a certificate is nothing to them, but for a small website it's clear that every Euro counts, so most of the people didn't think at all about paying just to say that their site now can be used with https.
Hopefully this will mean the end of self-signed certificates or expired certificates, so end users will be able to understand better the difference between a secure site and a non-secure one and so after a while people will reject "old" sites that aren't using SSL, forcing those sites to install one, pushing their hosting companies to allow install of free SSL.
The government spies will have a harder time trying to track what everyone does, and no, this won't be an improvement for terrorists because they are already able to use secure communications but in Paris it has been clear that they used normal non-secure methods.
But there's one more benefit: Most of those small sites that now are installing SSL en masse are using shared hosting, so they don't have a unique IP and that means that they rely on SNI to enable https and it turns out that no version of IE under windows XP (as well as old Android 2.x phones) don't support it, so those that still keep using the old IE8 will now face a new problem because they will have constant security warnings whenever they try to visit all these new https sites.
And this is a good thing!!!
That people keep on using that old IE. I mean, it's old, old, old. Full of bugs, full of problems, a pain for all of us that try to create modern websites if you have to keep supporting it, and now those users will feel a little of that pain (although I guess that they are already suffering from all of us that have left IE8 behind and no longer test it).
Time to ditch IE 8 and move to a modern browser.
2015/10/25
Updated demo for SimpleUploads
I've uploaded right now an updated demo to show the latest features of SimpleUploads and its compatibility with CKEditor 4.5
This post is part of the release as it aims to document the latests additions introduced since the last post about it (full details are in the history.html file).
I also have to review and publish the full documentation about all the configuration options, public methods and events related to the plugin (instead of keep adding it in the plugin.js file or several pages and blog posts) (this will mean probably that I'll add more changes because I'll find some detail that I don't like)
PS: The current release of MS Edge doesn't support dropping files, but that's a missing feature in the browser, the next version currently available as beta already fixes this issue. You don't have to do anything on your side when it's finally released.
This post is part of the release as it aims to document the latests additions introduced since the last post about it (full details are in the history.html file).
- Removed support for CKEditor 3.6. It's not a lot of code, but currently there's no reason at all to keep using a version so old and I doubt that there is anyone interested, so less code and less things to test.
- Workaround for the CKEditor 4.5.2 change that prevents dropping files on a dialog
- Added ability to handle both the classic response from the upload of the new JSON format
- Cleaned up and unified coding style with EsLint
- Improved API and integration with other plugins like ImageCrop.
- If the Upload Image button is used, launch a file picker showing only the images on your computer
- Other minor adjustments and fixing of all the reported issues.
I also have to review and publish the full documentation about all the configuration options, public methods and events related to the plugin (instead of keep adding it in the plugin.js file or several pages and blog posts) (this will mean probably that I'll add more changes because I'll find some detail that I don't like)
PS: The current release of MS Edge doesn't support dropping files, but that's a missing feature in the browser, the next version currently available as beta already fixes this issue. You don't have to do anything on your side when it's finally released.
2015/08/03
Taking a break to breathe is good and healthy
There's lot of truth on the post by @ppk "Stop pushing the web forward", and it has lots of replies, some very insightful and others that don't follow the reasoning. This is my take on it and you can bet that it will be closer to the clueless ones.
Browsers are adding new features, are constantly trying to find out what's missing and fill those gaps. That's great! we don't really want a whole full stop because we're always wishing than something works better, it's faster, it's doable...
But the current problem is that there are just too many new experiments, while old problems remain ignored and unfixed. You find a post stating that something is coming to the alpha version of a browser, that they plan to work on new features for the next release, but we're not able to correctly use the previously released features because it fails in some situations or it's implemented only in one browser and so it can't be used on the public web.
We need that those gaps are solved, we need to be sure that the existing problems are fixed before even more features are added.
For example pasting images into web pages:
Firefox pastes the data as base64, but it won't work on an input. But if you save it as a file in your computer, then you can Copy&Paste it and no other browser allows that.
IE11 won't paste any image unless you're using a contentEditable element, and in that case it even embeds the images included in a MS Word document, this isn't possible in any other browser.
Chrome allows nicely to paste a screenshot into an input, as explained above the other browsers don't allow this.
So a "basic" feature that users would enjoy across so many sites but that it isn't available in full form in all the browsers, don't you think that this is a good example of something that should be fixed before adding something absolutely new?
We'll always need better developer tools, tools that allow us to look at the pages and get more information, options to show warnings when something is wrong or we are using deprecated APIs. Don't get me wrong, the current tools are a million times better than what we had a few years ago but they still can be better: I'm in love with the CSS changes pane in IE11, there's no match for the mobile options in Chrome, I enjoy the UI from Firebug. And surely you can tell many things that you miss and wished that they worked better. All of this without new APIs.
So taking the time to review the bug trackers and clean them up doesn't mean that the web stops, it means that we remove the problems that we have and we can have a better solid future instead of lots of APIs that we can't rely on due to the number of bugs.
Browsers are adding new features, are constantly trying to find out what's missing and fill those gaps. That's great! we don't really want a whole full stop because we're always wishing than something works better, it's faster, it's doable...
But the current problem is that there are just too many new experiments, while old problems remain ignored and unfixed. You find a post stating that something is coming to the alpha version of a browser, that they plan to work on new features for the next release, but we're not able to correctly use the previously released features because it fails in some situations or it's implemented only in one browser and so it can't be used on the public web.
We need that those gaps are solved, we need to be sure that the existing problems are fixed before even more features are added.
For example pasting images into web pages:
Firefox pastes the data as base64, but it won't work on an input. But if you save it as a file in your computer, then you can Copy&Paste it and no other browser allows that.
IE11 won't paste any image unless you're using a contentEditable element, and in that case it even embeds the images included in a MS Word document, this isn't possible in any other browser.
Chrome allows nicely to paste a screenshot into an input, as explained above the other browsers don't allow this.
So a "basic" feature that users would enjoy across so many sites but that it isn't available in full form in all the browsers, don't you think that this is a good example of something that should be fixed before adding something absolutely new?
We'll always need better developer tools, tools that allow us to look at the pages and get more information, options to show warnings when something is wrong or we are using deprecated APIs. Don't get me wrong, the current tools are a million times better than what we had a few years ago but they still can be better: I'm in love with the CSS changes pane in IE11, there's no match for the mobile options in Chrome, I enjoy the UI from Firebug. And surely you can tell many things that you miss and wished that they worked better. All of this without new APIs.
So taking the time to review the bug trackers and clean them up doesn't mean that the web stops, it means that we remove the problems that we have and we can have a better solid future instead of lots of APIs that we can't rely on due to the number of bugs.
Subscribe to:
Posts (Atom)