Xinha Discussion Forum

allow_delete has been added to ExtendedFileManager today, checkout the latest trunk.

http://trac.xinha.org/ticket/1205

Make sure you look at the latest trunk (SVN) for both those suggestions.

You are correct, my_config.js

  //this is the standard toolbar, feel free to remove buttons as you like
  xinha_config.toolbar =
  [
    ["popupeditor"],
    ["separator","formatblock","fontname","fontsize","bold","italic","underline","strikethrough"],
    ["separator","forecolor","hilitecolor","textindicator"],
    ["separator","subscript","superscript"],
    ["linebreak","separator","justifyleft","justifycenter","justifyright","justifyfull"],
    ["separator","insertorderedlist","insertunorderedlist","outdent","indent"],
    ["separator","inserthorizontalrule","createlink","insertimage","inserttable"],
    ["linebreak","separator","undo","redo","selectall","print"], (Xinha.is_gecko ? [] : ["cut","copy","paste","overwrite","saveas"]),
    ["separator","killword","clearfonts","removeformat","toggleborders","splitblock","lefttoright", "righttoleft"],
    ["separator","htmlmode","showhelp","about"]
  ];

You would need to see what, if any, errors are being printed to the javascript console.

At a rough guess,
  1. try in the current trunk version of xinha
  2. check permissions for where the images would be written to
  3. check that your backend_url etc settings are correct

For just inserting images, I'd personally use ImageManager, not ExtendedFileManager, ImageManager is probably better tested (in my opinion).

I wouldn't have thought Xinha would mess with an onunload event.  That said.  I vaguely recall that onunload when actually closing a window doesn't work.

Maybe that's old knowledge though.

Xinha development is always a bit spasmodic, because it's written by people who "have an itch to scratch". 

That is, we use it in our "day jobs" and when something doesn't work, we decide "oh I should probably fix that".

The lack of development of Xinha, in my opinion, is testament to the fact that it quite simply "does the job it's made for" most of the time.

Fellow developers are always welcome to join the effort if you've got a similar itch to scratch.

This goes in where you have your xinha_config (of course, you need to have PHP run over it)...

  with (xinha_config.ImageManager)
  {
    <?php
      require_once('/path/to/xinha/contrib/php-xinha.php');
      xinha_pass_to_php_backend
      (       
        array
        (
         'images_dir' => '/home/your/directory',
         'images_url' => '/directory'
        )
      )
    ?>
  }

Similar for ExtendedFileManager.

You would need to write a plugin to detect such changes and, if it's possible at all, use the methods like getAllAncestors() to determine where you should insert nodes.

In short.  Hard.

This is beyond our sphere of influence I think, your problem is likely solvable, but with programming written by you to suit the specific way in which you're using Xinha.

In short, you'll need to re-initialize after scrubbing it (or better, don't scrub it at all, just move it out the way somewhere and put it back later).

Beware memory leaks when doing that though.

You should probably use the trunk if you will be using IE8.

Not fixable.  Your server is munted.  Get a better host.

I'd work around the issue by using chr(60) for < and chr(62) for >

<?php
$string = chr(60)."?php
echo \"test\";
?".chr(62);

eval (" ?".chr(62).$string.chr(60)."?php ");
?>