Hello Stéphane,

I had problem with related object when I was editing french content. Here is what I did to solve the problem:

First, when the language (fre-CA) isn't included in the URL, the related object windows doesn't show up correctly. I didn't investigate further.

In file ezxmltext.tpl, I've added at line 1:

edit_language=''

then the line

objectLang = '{$edit_lang}';

has been changed to

objectLang = '{$#edit_language}';

Honestly, I don't know if what I did was ok but the related object now works fine here in Quebec, Canada.

Hope this help,

Jade

Modified on Monday 11 April 2005 9:13:35 pm by Jade Tremblay

Salut Jade,
I'll give it a try, although I'm using XMLarea on two sites set to eng-CA. Maybe XMLarea works fine when using eng-UK only... or is it a cache problem?

<b>Bug report </b>

Firstly, I found a bug, when you try to add an object (Insert/Modify Object) and you want to use an existing related object, you can't browse correctly the whole site... It displays a page with few checkboxes on a strange template but if you want to select an object under an other one it's not possible...

<b>EDIT</b> : <i>I have downloaded latest xmlarea from trunk and it seems to be fixed... thanks !</i>

<b>EDIT 2</b> : I understand know what happened.
When I log into the admin siteacces and when I use xmlarea, everything goes well... If I try to use an existing related object this is the screen i have when i browse : http://prigal.free.fr/siteaccess_admin.JPG
But when I want to use XMLarea from the user siteaccess (when I edit an article for example) this is the screen I have : http://prigal.free.fr/siteaccess_user.JPG

So I can't browse anything !

<b>... and feature request </b>

Secondly, I think a nice feature which is not implemented yet neither on your XMLarea Editor nor on the official one will be to add the ability to the user (when he choose to create a link) to browse the whole site and select a node (Then when a node is selected, the link is automitically created, entitled with the node name and linked to the node view).

Hope you understand my english
Thanks.

Modified on Tuesday 12 April 2005 12:17:23 pm by Pierre Rigal

Hi STEVO,

There seems to be a bug in the currently latest version (rev 555) of xmlarea causing the Insert/Modify Object button not to work in IE (v. 6). By "not work", I mean that nothing happens when it's clicked.

I have modify the "insert object" template to allow translation. Where should I upload the object.tpl file and my french translation's strings?

A few points / questions:

1. I'm experiecing the same bug as reported by Eirik.

2. XMLArea does not appear to obey roles, in that when I remove permission to use XMLArea from certain roles the effected users still see XMLArea load up.

3. A side issue - I'm looking into using XMLArea in a forum enviroment, does anyone feel XML text fields are not a good choice for forums? I'm interested in peoples thoughts.

3. A side issue - I'm looking into using XMLArea in a forum enviroment, does anyone feel XML text fields are not a good choice for forums? I'm interested in peoples thoughts.

I guess it comes down to how much you trust your users. I generally don't, and therefore make use of text fields instead. If you were to use the xmlarea, you would of course have to remove most of the buttons, the code view being one of them so that the use couldn't edit the code directly.

Just my 2c.

blimey i'm getting behind here. not much spare time at the mo.

<b>jade:</b>

thanks for your work. it's prolly easiest to just email your files to stevoland+ez [at] gmail [dt] com.

it'll come as no surprise that as an englishman i'm shockingly ignorant of eZ's translation functions!

<b>eirik + brendan:</b>

i can't reproduce this problem. are any javascript errors produced? could you try adding some alert(); calls around line: 199 of design/standard/javascript/initeditor.js to see how far it gets.

brendan - i hadn't thought about roles. i suppose i could just add a check in ezxmltext.tpl to see if the user has permission to use xmlarea?

<b>Pierre:</b>

the add exisiting object just uses content/browse. this works fine with admin but the node/view/line.tpls are overridden in the standard user site designs + break this functionality. i tried to force the use of an admin view in my module but with no success. anyone?

i think you could fix this by going through the templates in, say, design/plain/override/templates/line/ + surrounding them with:

{default node_url=$node.url_alias}
...
{default}

+ changing the {$node.url_alias} references in them to {$node_url}

this way the template should use the correct content/browse/node_id url. <i>i</i> think this is a bug in the eZ distribution.

eirik's requested your feature too + it would be nice but i'll only do it when these insert object window path issues are fixed once + for all. this would also run into the same content/browse problem!

Hi STEVO,

Here's something strange. When I went back to reproduce the error, the pop-up box now suddenly appears. However, now the page in the pop-up box can not be displayed (page can not be found).

can you right-click + select the properties for the page that isn't found + post the url.

Hi STEVO,

The URL is:

res://C:\WINDOWS\System32\shdoclc.dll/dnserror.htm#http://layout/set/xmlarea/xmlarea/object/1/12//

I have a problem with the "Insert/Modify Object" operation.

I'm using the latest xmlarea code from pubsvn (updated Fri, 01 Apr 2005) with eZpublish 3.5.1 in a linux box.
The siteaccess for testing xmlarea has simple URL mapping (no virtual host).

I reproduced this behaviour with different types of clients (under Windows and Linux: IE6, FireFox, Mozilla).

Description:
When logged with an administrator account the click on the button for "Insert/Modify Object" open a working popup window for the related operations;
when logged with an editor account (with full permissions on "content" module and "xmlarea" module) clicking such button open a popup window with this message:
"The requested page could not be displayed. (1)
The system is unable to display the requested page because of security issues.
Possible reasons:
* Your account does not have the proper privileges to access the requested page.
* The requested page does not exist. Try changing the URL."

All the other buttons/functions seem's to work fine on both type of accounts.

Thanks for any suggestion or workaround.

Mauro

I found a possible solution...

Adding to the editor role (for editor accounts) the unlimited access to the "layout" module, the popup window for inserting/modifing object start working correctly.

Bye,
Maueo

<quote>
Adding to the editor role (for editor accounts) the unlimited access to the "layout" module, the popup window for inserting/modifing object start working correctly.
</quote>

I don't think this will solve my problem as I'm already logged in as an admin user.

eirik, could you try the latest revision. for some reason in your case the popup is looking for 'layout/set...' instead of '/layout/set...' + therefore is trying to load 'http://layout/set...' rather than 'http://domain.com/layout/set...'.

this explains why stéphane was getting glish.com as the default behaviour in firefox etc. is to do an 'i feel lucky' google on a url it can't resolve.

if this revision doesn't work i might have to resort to using an absolute path.

Considering the browsing problem, I think I have found a good solution. As you explain, when you're in admin interface it works well because we use the admin templates.
I have a look on the xmlarea module, it has its own design folder, so we can use our own template when using the module.

So I just copy the browse.tpl template located in design\admin\templates\content to extension\xmlarea\design\standard\templates\content ... and it works fine

aha, i never tried that. good show!

Hi STEVO,

I just tried rev. 580, and the same error occurs.

Hi Stevo,
I want to know why you don't try to display the Editor Bar just over the textarea, like the Official Online Editor does.
I say that because for the final user, it is easier to understand and so to use...

Hope you understad me...
Pierre.

I'm finding that XMLarea is malforming URL's by design or fault I'm not certain yet. If I disable the editor and then publish it works fine? And it also never remembers the target setting, i.e. _blank etc. Any ideas?