You are not logged in.
IE9 has issues currently (unles you use it in compat mode), recent threads right here in the forums explain it and workarounds.
What it will be complaining about is "e.childNodes(i)". Try changing to "e.childNodes[i]".
Or possibly even "e.childNodes.item(i)"
Which form editing plugin are you using? A quick look at tmy (ancient) FormOperations code doesn't show anything that would disable the plugin if there is no form. To me, it looks like it should work fine.
The purpose of that code seems to be to only do the full cleaning if there is no selection. If you were seeing the problem without having selected anything, then it's a problem with the selection handling (which indicates you might be using an older version of Xinha, try with the latest trunk).
If your change works for you, go with it.
Yeah, use the latest trunk, there hasn't been much activity apart from a few bug fixes, by and large, it's fairly stable. The only problem by the sounds of it you might run into is with IE9.
At some point I'll have a look at that, unless somebody wants to jump on it sooner :-)
Editing of forms in Xinha has not been looked at in many years, at least not by me. Frankly, I would not recommend it, in so far as I remember there were too many issues in Firefox particularly with regard to selecting form elements inside Xinha to make it practical.
Are you using the latest trunk?
Clipboard restrictions. You can edit your toolbar to put them back if you want to try it out, search XinhaCore.js for "paste" and you'll find it, just short circuit the check for a quick test.
HTML transformation is dependant on your config -- yourconfig.getHtmlMethod = 'DOMWalk' or 'TransformInnerHTML'
DOMWalk is the default.
Remember, the HTML is going through a HTML->DOM->HTML process, the second half of that knows little about the first half, what you get out is a valid representation of the DOM in the middle, regardless of what the HTML at the start looked like.
For general plugin writing, learn by example...
SelectCharacter is a very simple plugin which has a dialog
See contrib/php-xinha.php and plugins/MootoolsFileManager/config.php to see how we pass "backend configuration details" around securly, you would have to implement something similar.
ImageManager and ExtendedFileManager are VERY php centric, the entire things would have to be rewritten, they are also pretty antiquated, prone to security issues, and unpleasant to use IMHO.
MootoolsFileManager (MFM) on the other hand is not highly coupled to PHP, I've recently created a branch in the subversion with an updated MFM, there are some more (slightly heavy I believe) changes coming to that branch.
Get it by:
svn co http://svn.xinha.org/branches/MootoolsF … er-Update/
Essentially, in MFM, you'd need to rewrite (here's your reading list, in order :-)):
plugins/MootoolsFileManager/backend.php
plugins/MootoolsFileManager/config.php
plugins/MootoolsFileManager/contrib/php-xinha.php
plugins/MootoolsFileManager/Assets/Connector/FileManager.php
Broadly speaking...
your backend.py or whatever needs (in conjuction with FileManager.py or whatever)
take 'event' as GET/POST, event can be
list (default if no event)
create (create directory)
upload (upload file)
download (download a file)
destroy (delete a file)
move (move a file)
detail (get information on a file)
do stuff based on event (including checking permission!) and the data provided to it in get/post
return a JSON encoded response of appropriate format
I don't have time to dig through and work out the JSON response formats and I don't think it's documented in the mootools-filemanager itself (maybe I will do myself that when I have time to spare), but you should be able to get it from reading the PHP, Javascript, or probably easier, just sniffing the requests on a working mootools-filemanager using Firebug or Chrome Developer Tools (CTRL-SHIFT-J in Chrome, select Network tab).
If you do write a py backend, I'm sure the mootools-filemanager people would like to have it available, and we certainly would in Xinha.
Official version mootools-filemanager:
https://github.com/cpojer/mootools-filemanager
The version I'm tracking in my Xinha branch:
https://github.com/sleemanj/mootools-filemanager
The version that is going to be merging a pile of stuff back to cpojer and which I'll pick up:
https://github.com/GerHobbelt/mootools-filemanager
No. Both require PHP. We do not have any alternate backends.
Feel free to write one :-)
Suggest you replace quote marks at server end when you get output from Xinha, simple regex would suffice.
For word, look at cleaning plugins, SmartClean etc.
You'll probably need to debug the code then to see why in your particular case it is doing this.
Search XinhaCore.js for stripBaseHref and you'll find where it's used.
Or. Just use some regexp to fix the links when you get them back to the server might be easier in the long run.
Xinha itself does not require PHP.
But many of the most common plugins to Xinha (ImageManager, ExtendedFileManager...) do require PHP.
You can use Xinha without the plugins that need PHP if you don't have PHP, edit your configuration accordingly to remove those plugins.
See the NewbieGuide.
Not familiar with the "flex" and "drumbeat". All I can suggest is that you use the IE developer tools and look for an error in the console, there must be one somewhere (make sur eyou have display errors flagged in the IE preferences, otherwise it's a bit silent!)
I do not know if "saveAs" command is supported on any Mac browser (Safari, Chrome?, Opera), possibly it is not.
It would be far smarter for you to submit the form to the server which can create the file and return it as a Content-Disposition:attachment; then you do not need to use the "saveAs" command and do not worry about what the browser supports.
I do not use IE, I don't know what your problem will be with that, you must use the IE developer tools to debug. Ensure your page is in standards mode.
I think that Firefox does not support "saveAs" execCommand, that is IE only.
Your application probably will only work on IE if you need to use "saveAs".
"saveAs" is for saving the file to the computer of the browser, not to the server.
Use getHTML, don't just get the textarea value.
Config option "stripBaseHref" should be false.
Simply write your own Linker backend which returns absolute URLs to your liking.
Section 2
http://trac.xinha.org/wiki/Linker
The format that your scan.php needs to return is pretty simple.
Standard linking is built in in a rudimentary fashion, or use the Linker plugin for a better system.
ExtendedFileManager plugin provides the ability to upload files and link to them.
Impressive looking setup there.
No we don't have a showcase, that I recall, but you could create a wiki page, I will PM you shortly.
A "textbox button"?
That makes little sense, you would have to describe more fully, but the appropriate manner in which to add something to a toolbar is generally by writing a plugin.
If you wanted to insert an actual text field in the toolbar, you would need to modify Xinha's core code fairly considerably I expect.
There are no plans to move to a different version control system.
The file link button comes from extendedfilemanager plugin (or mootoolsfilemanager) I don't think there is any "built in" file link, so probably you have one of those plugins loaded. Solution: don't use the plugin.
You may need to see in the plugin code where the button is added.
Usually you can insert the button name (check the plugin code to find this) into your toolbar, before the plugin is loaded, and the plugin will use that location.