References #148
The js and css config files are directly placed in /htmlarea directory. The old ones downunder are not reset with this commit, until we give OK to go.
The lang constant will be placed to addlang.txt in a 2cd commit, since this may change and there is already a pending constant.
I have not added another option by now to explicitly choose the s9y configs in htmlarea, if someone has custom ones in 2k11/admin and wants to switch back to the origins. Is this really a real and valid user case?
Before this, ckeditor was configurable by editing the wysiwyg_init.tpl in 2k11/admin. Now, the flow is like this:
1. wysiwyg_init.tpl is responsible for initializing the editor and the plugins
2. we provide a htmlare/ckeditor/serendipity_config.js where we specify a sane default configuration, including a small toolbar without harmful elements
3. if the user wants to overwrite our configuration upgrade-safely, he can do this in htmlare/ckeditor/userconf.js
This time, I deleted ckeditor/ckeditor/.git and removed everytjing before. I hope that the line in .gitignore will prevent the linking the next time if someone forgets to delete the file
Instead of using global JS-variables and ignoring serendipity[textarea]={$view}, this
approach actually uses the variable and therefore reinstates wysiwyg_init.tpl.
ckeditor_custom_config.js (Thx Ian!) is still respected, but the toolbar got restored to the old version. We need an easy way to remove _underline_, for example. It could be extended though.
This fixes #{107} somewhat, as serendipity_image_selector.php is useable now, but still with display errors (and without an upload widget). Probably still a good idea to copy the ML-eapproach of the normal textareas
This also works with htmlnuggets, without using spawnnugget from the core, instead wysiwyg_init.tpl gets reused in the plugin-config.
ckeditor_custom_plugin.js got emptied, the relevant code (which should only be the part that adds the plugins into the toolbar) should be integrated into wysiwyg_init.tpl).
