contribute rewriting special characters in links

[mgm36]

Hi all - We have some complicated links we need to create (example is something
like:
[url]http://www.myhost.com/cgi-bin/something.cgi?url=http://www.someotherpage.com/[/url])

Contribute is rewriting the special characters in the url (namely the ":" to
the ascii codes). The result is a broken link.

Is there any way to stop contribute from doing this?!?

Thanks in advance!

[LDudd]

Yes.

In you inert link dialogue box you should have an advanced button, paste your URL into this box and it should remain unencoded.

LDudd

[mgm36]

Even if I paste my link into the "href" portion of the advanced tab, it will
show up correct in that field but then the actual link has the ":" converted to
a "%3A". Even if I reopen the link window and manually change the encoded
characters back in both places, it still reverts it again once I close it.

Is there another work-around for this?

[LDudd]

I did the same and even reopened the link dialogue and it was still coded correctly.

I am running CT3.1. Which version are you running as that may be an issue?

[LDudd]

Oops,

soz I didnt test it as fully as I thought I had done, but on a retest I get this lssue too.

[ransom66]

I'm relatively new to using Contribute and have just ran into this same issue.
I am trying to create a link to a file on a server on our network, but the
server name has an @ at the beginning. Every time I attempt to create the link
Contribute removes the @.

I tried putting the destination in the HREF field too, but it didn't work
either. When I come back into the link properties it removes the @ sign again.

Any info on how to make the character stick is greatly appreciated.

[mgm36]

As the original poster, let me tell you what I've found out from contribute so
far. I contacted their tech support, they recognize this as a bug and it has
been assigned to the engineering team (and from what I understand is in the
process of being fixed). However, they could not give me any time frame as to
when the next major or minor release of contribute would come out, so it may be
a bit of a wait.

In the meantime, the suggestion was to allow editing in an external
application - so you need to open your page in dreamweaver or notepad or
something and then manually fix the characters in the link.

[WILL_CHE]

I've just discovered this issue. Any word from support on when a patch will be coming out?

[seshelby]

I have the same problem and am now anxiously awaiting a patch to correct the problem.

[Smarcin]

Has this problem been fixed since it was originally posted in 2005? It's 2007
now, and we just launched a site in Contribute at my University. We see this
problem occurring even now.

We realized on our own that we could manually edit our links in an external
application to fix them, but we have quite a lot of links that need this extra
editing. A fix would be preferable to manual editing. Was there ever a fix
discovered for this?

Thanks for any advice!

[q]Originally posted by: mgm36
As the original poster, let me tell you what I've found out from contribute so
far. I contacted their tech support, they recognize this as a bug and it has
been assigned to the engineering team (and from what I understand is in the
process of being fixed). However, they could not give me any time frame as to
when the next major or minor release of contribute would come out, so it may be
a bit of a wait.

In the meantime, the suggestion was to allow editing in an external
application - so you need to open your page in dreamweaver or notepad or
something and then manually fix the characters in the link.[/q]

[NateWeb]

Wow, I can't believe this hasn't been fixed in a 2 year time period. We are also running into the problem at our University. This needs to be fixed ASAP.

[niffummuffin]

I am also having this problem we bought contribute CS3 yesterday is there a fix yet?

[NateWeb]

I came up with a javascript workaround for the time being. Basically, it just
prints out the url on the client side.

In a .js file that is imported in the header:

function urlFix(url) {

var url = 'http://www.firstpartofyoururl.com?url=http://'+url
window.location = url;

}

Then, when you are adding or editing a link in Contribute, just type this into
the url field:

javascript:urlFix('destinationurl.com')

[muffinniffum]

Oh dear, have just noticed that contribute is corrupting the links even after
correcting them in Dreamweaver.
If I make any subsequent changes to the page (even just text - not links) then
all the links on the page are corrupted when I hit 'Publish'.
So you basically cannot update a page without ruining your links. Great.
Adobe you really need to sort this problem fast.

[muffinniffum]

Appreciate your help - thanks for the tip!

I have also found that you can add the link as a HTML Snippett and this works,
but you can't edit it only re-write it.

Another problem I came across is when you have really long links the browser
cuts them off ?!?!?

:--(

[lisa3711]

It seems ridiculous this has not been fixed!

[Bailstoke]

[q]Originally posted by: LDudd
Yes.

In you insert link dialogue box you should have an advanced button, paste your
URL into this box and it should remain unencoded.

LDudd
[/q]

[Bailstoke]

i have a somewhat related question... Our issue is when we send a draft to a reviewer, and they approve it, when prompted to publish it the file name changes?

[Smarcin]

That tip has never worked for me. I think it's the same process described in
one of their TechNotes:
[url]http://kb.adobe.com/selfservice/viewContent.do?externalId=bd557a81&sliceId=2[/url]

[q]Originally posted by: Bailstoke
[Q]Originally posted by: LDudd
Yes.

In you insert link dialogue box you should have an advanced button, paste your
URL into this box and it should remain unencoded.

LDudd
[/Q]

[/q]

[beansnrice]

I am having this same issue except that I am adding Library items that includes
the following script:

<a href="http://<!--#ystore_catalog id="b01" field="product-url" -->">

And after adding the library item that contains this code, Contribute changes
it to the following:

<a href="http://<!--#ystore_catalog id="b01="b01"" field="product-url" -->">

Dreamweaver does not have this problem when I add the same library item to a
page.

I am just getting onto this thread late but it sounds like this is a two year
old known issue. Makes me wonder just how effective these forums are as far
as gaining attention from Adobe tech support. I certainly don't have $1200 to
blow on a tech support plan which may help problem solve this.

There's a good chance that I am doing something wrong as I am more of a
designer inserting code than a coder who knows what they are doing. But it is
confounding that there is such a difference in behaviors here between
Dreamweaver and Contribute.