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.
Subscribe to:
Posts (Atom)