|
Home > Archive > Microsoft Content Management Server > December 2004 > "Ugly" links and "WBCMODE=PresentationUnpublished" links
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
"Ugly" links and "WBCMODE=PresentationUnpublished" links
|
|
| MurrayTh 2004-12-04, 5:47 pm |
| In our CMS 2002 site, after updating and approving a page, we keep getting
links of the form:
/NR/exeres/4D6C1F2B-0D20-44AA-B05E-18056D8367EB.htm?NRMODE=Unpublished&wbc_purpose=Basic&WBCMODE=PresentationUnpublished
This form appears for subscribers, not just Web Author users, and (sometimes
it does not have the "NRMODE" section).
I believe that the "NR" and GUID-type part will appear if CMS cannot create
a managed link to a page to in Web Author (for example, if two or more
postings have been saved with the same name in the same channel, a "normal"
link would not uniquely ID a posting). However, we are getting this form of
URL's even appears when the posting name linked to is unique. When editing
the page and even viewing the link in HTML view, it appears just like a
"normal" directory-based URL, based on the selected posting item. However,
after saving the page, the link is changed to the form above.
Although the GUID type form is ugly and I'd like to avoid it showing up, I'm
more concerned about why the "NRMODE=Unpublished" and
"WBCMODE=PresentationUnpublished" parts show up in the query string. With
"NRMODE=Unpublished" a subscriber gets a broken link, as a subscriber
shouldn't be able to view the unpublished edit site contents. With
"WBCMODE=PresentationUnpublished", I am not sure if this could allow
subscribers to see unapproved content or not, but it is a concern. As well,
if a subscriber does go to a page with this in the query string, the query
string is maintained in any subsequent site pages the user navgates to from
links that original ugly-URL.
Why would these URL's appear? Could it be some problem with the code on our
end, or with CMS functionality? We have script that looks for URLs of this
type and cleans them up to "normal" links where possible (by finding if a CMS
item based on the URL exists, and storing that item's URL attribute back in
the link), but when the pages are edited again, the "ugly" form returns. Any
help on avoiding these type of URL's would be appreciated.
| |
| Stefan [MSFT] 2004-12-04, 5:47 pm |
| Hi Murray,
there are a couple of bugs related to this.
Please check
1) if this only happens to non-administrators
2) if this only happens to cross-site-links (means if the map channel to
host header name feature is enabled and the link goes to a different site
3) if this happens always.
4) if CMS 2002 SP1 or SP1a has already been installed.
Cheers,
Stefan.
"MurrayTh" <MurrayTh@discussions.microsoft.com> wrote in message
news:190C317B-124D-4540-9794-8F7B449361A6@microsoft.com...
> In our CMS 2002 site, after updating and approving a page, we keep getting
> links of the form:
>
>
/NR/exeres/4D6C1F2B-0D20-44AA-B05E-18056D8367EB.htm?NRMODE=Unpublished&wbc_p
urpose=Basic& WBCMODE=PresentationUnpublished
> This form appears for subscribers, not just Web Author users, and
(sometimes
> it does not have the "NRMODE" section).
>
> I believe that the "NR" and GUID-type part will appear if CMS cannot
create
> a managed link to a page to in Web Author (for example, if two or more
> postings have been saved with the same name in the same channel, a
"normal"
> link would not uniquely ID a posting). However, we are getting this form
of
> URL's even appears when the posting name linked to is unique. When editing
> the page and even viewing the link in HTML view, it appears just like a
> "normal" directory-based URL, based on the selected posting item. However,
> after saving the page, the link is changed to the form above.
>
> Although the GUID type form is ugly and I'd like to avoid it showing up,
I'm
> more concerned about why the "NRMODE=Unpublished" and
> "WBCMODE=PresentationUnpublished" parts show up in the query string. With
> "NRMODE=Unpublished" a subscriber gets a broken link, as a subscriber
> shouldn't be able to view the unpublished edit site contents. With
> "WBCMODE=PresentationUnpublished", I am not sure if this could allow
> subscribers to see unapproved content or not, but it is a concern. As
well,
> if a subscriber does go to a page with this in the query string, the query
> string is maintained in any subsequent site pages the user navgates to
from
> links that original ugly-URL.
>
> Why would these URL's appear? Could it be some problem with the code on
our
> end, or with CMS functionality? We have script that looks for URLs of
this
> type and cleans them up to "normal" links where possible (by finding if a
CMS
> item based on the URL exists, and storing that item's URL attribute back
in
> the link), but when the pages are edited again, the "ugly" form returns.
Any
> help on avoiding these type of URL's would be appreciated.
>
| |
| MurrayTh 2004-12-09, 8:48 pm |
| Stefan,
1) As we have multiple sites in CMS, we do not edit as an Administrators
user to avoid seeing elements from more than one site. However, I was able
to sign in an Administrator, and the "ugly" links still do appear after
approval.
2) It happens for links within a site. I haven't seen a cross-site link
appear this way yet, but we don't have too many.
3) It does not always happen- I'm still puzzled when it actually occurs. I
believe one time it comes up is when linking to a new, unapproved page in the
site, but it does not go away even when the page is approved. But there are
other times as well... looking into it a bit more, it seems that if there is
more than one managed link in the page, the ones that were edited last turn
out fine, but the ones that previously existed and were left alone turn into
the "ugly" ones.
4) SP1a has not been installed. We are currently running MCMS Version 5.0
(5.0.1581.0).
"Stefan [MSFT]" wrote:
> Hi Murray,
>
> there are a couple of bugs related to this.
> Please check
>
> 1) if this only happens to non-administrators
>
> 2) if this only happens to cross-site-links (means if the map channel to
> host header name feature is enabled and the link goes to a different site
>
> 3) if this happens always.
>
> 4) if CMS 2002 SP1 or SP1a has already been installed.
>
> Cheers,
> Stefan.
>
>
> "MurrayTh" <MurrayTh@discussions.microsoft.com> wrote in message
> news:190C317B-124D-4540-9794-8F7B449361A6@microsoft.com...
> /NR/exeres/4D6C1F2B-0D20-44AA-B05E-18056D8367EB.htm?NRMODE=Unpublished&wbc_p
> urpose=Basic&WBCMODE=PresentationUnpublished
> (sometimes
> create
> "normal"
> of
> I'm
> well,
> from
> our
> this
> CMS
> in
> Any
>
>
>
| |
| Stefan [MSFT] 2004-12-10, 5:51 pm |
| Hi Murray,
you should open a support case to get this analyzed in more detail.
Cheers,
Stefan.
"MurrayTh" <MurrayTh@discussions.microsoft.com> wrote in message
news:DDAEB8B8-B741-460E-88EA-505C2DDFD9B2@microsoft.com...
> Stefan,
>
> 1) As we have multiple sites in CMS, we do not edit as an Administrators
> user to avoid seeing elements from more than one site. However, I was
able
> to sign in an Administrator, and the "ugly" links still do appear after
> approval.
> 2) It happens for links within a site. I haven't seen a cross-site link
> appear this way yet, but we don't have too many.
> 3) It does not always happen- I'm still puzzled when it actually occurs.
I
> believe one time it comes up is when linking to a new, unapproved page in
the
> site, but it does not go away even when the page is approved. But there
are
> other times as well... looking into it a bit more, it seems that if there
is
> more than one managed link in the page, the ones that were edited last
turn
> out fine, but the ones that previously existed and were left alone turn
into[vbcol=seagreen]
> the "ugly" ones.
> 4) SP1a has not been installed. We are currently running MCMS Version 5.0
> (5.0.1581.0).
>
>
> "Stefan [MSFT]" wrote:
>
site[vbcol=seagreen]
getting[vbcol=seagreen]
/NR/exeres/4D6C1F2B-0D20-44AA-B05E-18056D8367EB.htm?NRMODE=Unpublished&wbc_p[vbcol=seagreen]
form[vbcol=seagreen]
editing[vbcol=seagreen]
a[vbcol=seagreen]
However,[vbcol=seagreen]
up,[vbcol=seagreen]
With[vbcol=seagreen]
query[vbcol=seagreen]
on[vbcol=seagreen]
if a[vbcol=seagreen]
back[vbcol=seagreen]
returns.[vbcol=seagreen]
|
|
|
|
|