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; } } }

Edited DCR will not save

Paul

Hey All -

We've just moved from Windows NT to Windows 2003 and Version 5.5.2 to Version 6.1 (SP1) and have a problem We can create a new DCR and save it fine but when we try and edit an existing DCR (even the one we JUST saved) we get an invalid path error.

Save was unsuccessful. Invalid path //WDCINP061/default/main/Portal/WORKAREA/content/templatedata/Portal/CHCInfo/data/WDCINP061/default/main/Portal/WORKAREA/content/templatedata/Portal/CHCInfo/DATA/1aatest was received.

I see where that path is invalid, but I don't see how to change it.

after data the WHOLE path repeats itself. That's not right correct?

Find more posts tagged with

Comments

Migrateduser

It looksl like something in the iwproxy configs is screwed up. Please paste the [iwproxy*] sections of your iw.cfg

Regards,

Dave

Paul

[iwproxy]
iwproxy_host=localhost
customer_webserver_host=WDCINP061.internal.cigna.com
iwproxy_port=1080
customer_webserver_port=81

[iwproxy_fullproxy_redirect]
_regex=^http=http://sorry-no-fullproxy-available/

[iwproxy_remap]
global_default_map=/

[global_default_map]

[iwproxy_preconnect_remap]

[iwproxy_plugin_remap]
_regex=(.*)/www_CIGNA_com/([^/]+)/((WORKAREA|EDITION)/[^/]+|(STAGING))/(.*/shared/.*)=$1/Production_CIGNA_com/STAGING/$6
_regex=(.*)/www_CIGNA_com/([^/]+)/((WORKAREA|EDITION)/[^/]+|(STAGING))/(includes/.*)=$1/Production_CIGNA_com/STAGING/$6

[iwproxy_failover_remap]
_maxfail=3
_regex=(.*)/www_CIGNA_com/([^/]+)/((WORKAREA|EDITION)/[^/]+|(STAGING))/(includes/.*)=$1/Production_CIGNA_com/STAGING/$6
_regex=(.*)/www_CIGNA_com/([^/]+)/((WORKAREA|EDITION)/[^/]+|(STAGING))/(.*/shared/.*)=$1/Production_CIGNA_com/STAGING/$6
_regex=(.*)/www_CIGNA_com/([^/]+)/((WORKAREA|EDITION)/[^/]+|(STAGING))/(.*/images/.*)=$1/Production_CIGNA_com/STAGING/$6

[iwproxy_hostheader_remap]

[iwproxy_smartcontextedit_allowed]

[iwproxy_access_control_enabled]

[iwproxy_external_remap]

Dwayne

You are right - that is not correct.

Are you using FormAPI, perhaps with an onSave event handler? It may be getting confused by the change in the format of a VPATH. Well, it's not really a change, since this format is still valid according to the "old" rules. But, before, a system generated VPATH always started with the store (/default). Now it starts with //servername/store, which messes up some people's regexes.

I noticed that in the second instance of the 'data' directory in that path, it's in upper case. I can't imagine a TeamSite internal function doing that, which is what leads me to believe it might be something that's being done by some custom code on your end. If nothing else, it might give you something to search on - do a case-sensitive search for 'DATA' and see what comes up.

Good luck.

--

Current project: TS 5.5.2/6.1 W2K

Dwayne

I really don't think that the proxy would have anything to do with this. It isn't on viewing the file, but on saving it that there's a problem. As far as I know, the proxy only comes into play when viewing a file via the customer web browser.

--

Current project: TS 5.5.2/6.1 W2K

Paul

We are NOT using ForpAPI or any custom code except for the datacapture.cfg. This works as expected from 5.5.2 but I did notice the path starting with the servername and was wondering where it picked that up from.

Our templating .cfg file looks like:

<data-type name="CHCInfo">
<presentation>
<template name="narrow.tpl" extension="html">
<locations>
<branch vpath-regex=".*" preview-dir="/">
<directory dir-regex=".*" />
</branch>
</locations>
</template>
<template name="wide.tpl" extension="html">
<locations>
<branch vpath-regex=".*" preview-dir="/">
<directory dir-regex=".*" />
</branch>
</locations>
</template>
</presentation>
</data-type>

Adam Stoller

Can you post your DCT (as an attachment)?
Perhaps that will expose the source of the problem...

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Paul

The answer was even simpler than that. The data directory was capitalized (DATA) the ones that worked were lower case (data) changing the name fixed the problem. Go figure...

Migrateduser

Aah, that's very interesting... so, I guess there's an Interwoven-internal regex that's expecting to see (data) and then attempting to save to a subdirectory BENEATH the "data" directory. But, in this case, there wasn't a "data" directory (instead, a "DATA" directory) and so it concat'ed everything after the implied "data" directory.

I know, morning rambling...

So, hmmm... my guess is that Li Wong did it in the server room with a regex :-) was never a big fan of that game, actually.

Dave