nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

TinyMCE adding http:// to all links on second generation

System

Hey all,

Weird thing is happening for us. All of our links are relative to the root, so /foldername/pagename. When we generate the page in Teamsite the first time, everything is fine. However, if someone generates the page again, all the links become http:///foldername/pagename. It is as if the URLEncoder function is not working on the second page generation.

Any ideas? We have tried triggering this function in various ways, but nothing seems to help.

Thx

Find more posts tagged with

Comments

TimTodd

We are having this same problem. Have you found a resolution?

Migrateduser

Interwoven has confirmed it is a bug and they have sent it up to Engineering. I will let you know when we get more info.

Valentine

They've promised a solution since november ...

TimTodd

I have an open ticket in for this and supposedly 6.7.2 will include a fix for the bug

73227. Also, I did find out that this only happens for us in Internet Explorer... Not Firefix. So if your users are having issues, you can suugest using an alternate browser.

Migrateduser

My users are experiencing similar issue when using Internet Explorer 8, which our IT department is not even yet supporting use of.

As administrators, we're going in to our Teamsite with IE6, and removing the extraneous foldername path, then regenerating. This resolves the problem, but its really inconvenient.

Ive started suggesting our users only use IE6/IE7.

ccprofessional

I have an onsave event to take care of this issue.

Bhargav Coca

can you post the workaround, if it not much trouble for everyone else. IF not the code, be more explanatory on how exactly you incorporated the onsave event.

Thanks

CRB

what version of TS? TinyMCE are you on?

I have the same issue, but I was expecting this issue to be fixed in 6.7.2 and patch 5 for TS 6.7.1 ( latest version of TinyMCE). so i was thinking to just install latest patch for 6.7.1 to reslove it.

check out httpd/iw/tinymce/jscripts/tiny_mce/tiny_mce_src.js and search for TinyMCE.prototype.convertURL function. it looks like they tried to fix the issue in there but i dont think the fix works all time. maybe you will have better luck in fixing the src code Smiley Happy

ccprofessional

[html]
IWDatacapture.callServer("http://"+servername+"/iw-bin/iw_cgi_wrapper.cgi/clean_tinymce_links.ipl", params);

[/html]

I wrapped the above code in an onSave Event.

To get servername

[html]
var servername = window.location.hostname;
[/html]

The params object has servername and a couple of other things specific to my implementation.

The ipl just does a find/replace within the dcr

Not the most elegant, but that should give you everything you need.

CRB is probably right.. I believe its fixed in 672sp1, but I havent tested it. There may be other options within the tinymce configs.

Bhargav Coca

but this is starange, this behavior is only apperent while setting a link with target set to none, in all other scenarios, it wouldn't append any server name.

Thanks

ccprofessional

No thanks for what I provided ?!

If your QA folks did their job (even if you didnt), they would have also seen that the behavior is different in IE and FF.

Bhargav Coca

No thanks for what I provided ?!

If your QA folks did their job (even if you didnt), they would have also seen that the behavior is different in IE and FF.

Thank You for the help as always. I was just pointing out what we found. But most of our customers use IE, cuz we forced them to use it. As long as i do not face this issue on IE, I am fine.

Thank You for you valuable input.

single_pie.JPG

multiplepie.JPG

cmatsyk

Anyone have a fix for this????

gzevin

Anyone have a fix for this????

I m kind of got used to CONSTANT string of bugs in both Ektron and tinyMCE related to this kind of issues.

So every time I see it, I simply amend our HTML cleanup function, that every TPL invokes.

much easier than to wait for IWOV to fix the issue. Usually a fix brings more bugs, as they almost never do regression testing.

nipper

I m kind of got used to CONSTANT string of bugs in both Ektron and tinyMCE related to this kind of issues.

So every time I see it, I simply amend our HTML cleanup function, that every TPL invokes.

much easier than to wait for IWOV to fix the issue. Usually a fix brings more bugs, as they almost never do regression testing.

Plus an unlimited opportunity for you to get called back to update as new bugs are introduced.