Xinha Discussion Forum

I suspect it would be a big job.  Plugins welcome though   The plugin would have to replace the switch mode button to instead of switching mode to change the gui editor into a gui sourcecode editor. 

This feature would be desirable especially for when we get "shielded code" ability (including php code into the html being edited).

I'd be interested to see what the htmlarea config you were using looked like.  i can't think of anything that would create the problem you experienced, so maybe it might turn up something interesting

If you still have that config that caused the problem could you please submit a ticket.

As niko says, replaceAll does still exist, theoretically it should work.  But I've never used it.  If you find it doesn't please ticket it.

You might however be better to follow the example (using the nightly build) and specify each area that should be replaced, as it's the "preferred" way of doing things.

You can use
  config.stylistLoadStyleSheet('/path/to/mystyles.css', {'p.pink_text' : 'Pretty Pink'});

if you can think of a better way, submit a ticket, or better, a patch

It's currently hard coded into plugins/Stylist/stylist.js, like 484.  I'll make it into a config option.

See the config object (in htmlarea.js), it's in there.

Do a search for CMSimple, here, or at google, hat might be what you're looking for.

No it's not a problem with the host, seeing as it's hosted on my workstation until I can figure out the problem.  I dont' know why it's doing it, basically two of the tables in the sqlite database get corrupt for some unknown reason, this brings the system partially to it's knees.  Sometimes the entire database gets b0rked.

I initially thought the root cause was the BDB SQL repository was getting locked up, so I changed to FSFS.  Helped a little.

So I thought an upgrade of trac might be in order, so I did but it didn't make any difference.

So then I thought it might be sqlite2 was the problem so I upgraded to sqlite3 which helped a lot, but still didn't cure it, just reduced the frequency.

There is a PostgreSQL "backend" for trac, but it's not official and would require patching trac each time an upgrade comes through, I want to avoid that.  However  edgewall is working on database independance for trac, so hopefully we can soon move to either MySQL or PostgreSQL.

I've written a script now so I can quickly fix the primary problem, and I'll shortly write one to try and automate the process so that every x minutes it will check the db for corruption and fix it.  At least that should keep things running until something better happens.

In so far as hosting goes, the requirements area at
http://projects.edgewall.com/trac/wiki/TracInstall

Probably not, I may have just done that to be compatable with htmlarea.  Trac is back up for now (damn sqlite is freaking unstable, at least for us - I've asked at the trac mailing list a couple of times and nobody else seems to have the problem).  I have no objection to the change so go ahead as far as i'm concerned,

You might want to ticket it incase it causes anybody problems.

Hmm.  Create a ticket for this as a feature enhancement.  When time permits I'll look at creating a plugin to do what you want.

I believe that this all extends from a problem in IE, where by IE will make any link a full URI (ie including http:// ) wether you want it or not, at least if I'm remembering correctly. 

I wanted at some stage to standardize that between the browsers so I must have made the links absolute - it's not a problem for me because I have "special replacements" run on the outgoing html to turn them into relative links where appropriate.  But obviously it's something that should be changed really.

If you can come up with a good way of fixing that, I'm ok with it.

Edit: by fixing it I mean making links relative or absolute within server.  Of course, relative to what is the question, I guess a "destination URL" would have to be passed in via config so that relative urls could be calculated from that.

I believe this is the relevant bug - https://bugzilla.mozilla.org/show_bug.cgi?id=264403 (it's essentially the same problem).  basically document.open, which is used to dynamically write the contents of the editor's iframe, inserts an item into the window history, when it shouldn't.