You are not logged in.
Remember to clear your cache(s) when updating BTW. Javascript files tend to get themselves stuck in cache (esp when loaded over XMLHttpRequest like in Xinha) so best idea is to clear cache and then restart browser.
Provided you are using a Xinha which has a file called XinhaCore.js in it's main directory then updating should be a simple matter of moving your old xinha directory out of the way somewhere, extracting the new xinha, and enjoying your new Xinha.
We try to keep it backwards compatable.
Naturally, you should always test before putting it in production!!!
If your xinha directory does not have XinhaCore.js (it's quite an old version then) you can probably still just replace the old one with the new, but you might run into some small incompatabilities, maybe.
IE has always done this, it is IE's way. Word does the same.
Gecko will do it with "built-in" as Xinha.config.mozParaHandler.
It has been discussed many times. Search. It's not changing.
deactivateEditor and activateEditor are your friends here in lots of cases. Essentially you should deactivate before changing anythng regarding the style of the editor (especially visibility, even if it's "inheritied") and reacivate it after.
Xinha should also be visible at least when it is created, otherwise sizing will probably be messed up.
Sounds like a server issue, check all permissions, use LiveHeaders and see what is getting loaded and if anything is getting an HTTP error of some sort.
Will work now.
Move has now been initially completed, I have a few tidy up things to do.
The URL to the Subversion repository has changed, the new url is http://svn.xinha.webfactional.com/ the old url was http://svn.xinha.python-hosting.com/
Anybody who has a checked out copy, will need to issue a switch --relocate command in your checked out copy, in the command line client that's something like:
svn sw --relocate http://svn.xinha.python-hosting.com/ http://svn.xinha.webfactional.com/and remember, you need to tell me your username and (choice of) password so I can re-enable you for checkin.
Thanks all!
Hi guys, the kind people at Webfaction.com (originally python-hosting) have given us an upgraded trac account etc, we will shortly be on a full Webfaction account rather than the limited freetrac one, this will give us much more flexability. Unfortunately all the user accounts for subversion and trac have been dropped in the move (the data, wiki, tickets etc come across though). Can everybody with current subversion, and trac access (who still wants it) please drop me a line with your username and (choice of) password and I'll recreate the user accounts.
Please refrain from committing to svn or making wiki/tiket changes for a few days (Ray I've got a copy of the wiki changes you made today),
Once again, our enduring thanks for the hosting services provide by Remi at www.webfaction.com
emmett: sorry I put you wrong there, that 404 is the result of a bug in simple_example - FullScreen is no longer a plugin but simple_example was still trying to load it, your config doesn't appear to make that mistake.
Remove FullScreen from your plugins list, it is no longer a plugin.
You have a permissions problem or missing files (this was shown using LiveHeaders plugin for firefox).
https://www.banweb.mtu.edu/xinha/plugin … -screen.js
GET /xinha/plugins/FullScreen/full-screen.js HTTP/1.1
Host: www.banweb.mtu.edu
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2) Gecko/20070208 Iceweasel/2.0.0.2 (Debian-2.0.0.2+dfsg-1)
Accept: */*
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
HTTP/1.x 404 Not Found
Content-Type: text/html; charset=iso-8859-1
Content-Length: 233
Server: Oracle-Application-Server-10g/9.0.4.2.0 Oracle-HTTP-Server OracleAS-Web-Cache-10g/9.0.4.2.0 (N)
Connection: Keep-Alive
Keep-Alive: timeout=5, max=999
Date: Sat, 12 May 2007 02:28:09 GMT
emmett: are you using firefox, if so check the javascript error console, if not, try it.
bluewolf: problem is you aure using a crummy windows server, you may need to modify aspell_setup.php to work, and of course you will need a windows version of aspell.
mswiryn, can you try:
open XinhaCore.js in an editor
Find: req.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded; charset=UTF-8');
Replace With: req.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
make sure you clear your cache etc and try again.
I came across a server once (I don't remember exactly the details) which simply failed when given UTF-8 as a charset (maybe any charset) as part of a POST request.
First, do you have PHP on your server and is it properly configured?
Try the ImageManager plugin, EFM and ImageManager will co-exist from the current SVN revision. ImageManager is more advanced for inserting images (EFM was based off ImageManager originally).
Textarea only. What is a "textbox"? Not an element in HTML last time I've looked.
http://xinha.python-hosting.com/wiki/SpellChecker
There is also the ClientSideSpellcheck plugin, but that only works for IE AFAIK.
Try using the GetHTML plugin,
Use a body onload event, not a form one. I expect the form onload is fired before the body is completed in some instances.
XStandard was the one I was thinking of.
Not possible in Xinha, it's not on the plan either. Basically, the browser is what produces the HTML, you shouldn't really expect much better than HTML 4 transitional.
There is an editor out there, the name escapes me, which produces valid XHTML, it works in an entirely different way than Xinha and other similar editors. On the other hand, it's much more limited. Google it.
Ensure both the name and id of the textarea are 'xinhacontent' and that the HTML on your page is well formed.
Email me and I'll discuss with you.
I think mokhet was working on that sort of thing in his branch ( http://xinha.python-hosting.com/browser … es/mokhet/ )