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

Why do I need $URL_PREFIX?

RonaldV

From the manual:

"The $URL_PREFIX token is used to abstract the URL to be independent of whether it is viewed in Page Edit, any of the various forms of preview (Page preview, Component preview, Page Edit preview, Static HTML preview), or in the LiveSite runtime."

What do I need this for when Teamsite already contains a perfect proxy-remap-mechanism for this purpose?
Is there anything that this token handles that proxy-remap can not?

Find more posts tagged with

Comments

AlexC

In preview and runtime the base URL is very different and runtime does not have a remap.

$URL_PREFIX[rest of relative path to resource] to maintain consistency in preview and runtime and the rendering engine takes care of inserted the correct base.

RonaldV

Well, the old style of doing things was:

- insert a url that works in 'runtime'
- create a remap for 'preview' that rewrite 'url' into something the 'preview' understands

So, what triggered Iwov to create the url-prefix functionality?

AlexC

$URL_PREFIX has been around since 2.2.x which is about 5 years old. I am not familiar with the method you are describing (was that something support recommended for your specific requirements?) but the preferred way to do URLs is with the tokens ($URL_PREFIX[], $PAGE_NAME[], etc), it has been for a long time.

Adam Stoller

$URL_PREFIX has been around since 2.2.x which is about 5 years old. I am not familiar with the method you are describing (was that something support recommended for your specific requirements?) but the preferred way to do URLs is with the tokens ($URL_PREFIX[], $PAGE_NAME[], etc), it has been for a long time.

They're comparing TeamSite / FormsPublisher preview with SitePublisher / LiveSite preview.

One might be able to use iwproxy to remap URLs that SitePublisher generates for previewing - but my guess is that it isn't recommended and might not even work.

RonaldV

ALex,

thank you for your prompt answers. Not very Iwov-like :-)

As ghoti says, yes I refer to refer to the 'teamsite'-preview via the iwproxy. I done done digging into ls-preview and found that, to my believe, for livesite the /iw-cc/command/iw.group.preview-file command has a builtin exception for .page extensions. (This exception must have been introduced with livesite) Any preview-request for a *.page is directly routed to the tomcat-servlet and thus is never passed over to the iwproxy.

This is important info for any teamsite-expert that must get to know livesite, and should have been mentioned, in red, in the manual.

It was also a bad idea, i think:
- it is simply not the 'best-practice' way to handle previews in teamsite
- it would block any website that would use .page extension for something different
- it (mis)uses the ts-servlet for preview, something that Iwov has moved away from with ts6.0. This is also the cause for problem that a change to a java-class requires a re-start of the servlet (and thus teamsite downtime for other developers)
- the need for $URL_PREFIX :-)
- takes away the option for customers to use the iwproxy for custom web-virtualisation over a custom preview-livesite-runtime. Note: on a per branch/workarea/folder detail-level!

To me it confirms my suspicion that livesite is never *integrated* with teamsite but instead is added to ts as an exception.

Anyway, I would like to hear from you whether the above is correct, or not.

Hope to hear.

AlexC

SitePub/LiveSite works as an extension to TeamSite, you can't integrate too deep given a requirement of TeamSite running with and without SitePub, given those requirements there had to be some compromises to allow this flexibility. The LiveSite runtime also runs without TeamSite so the preview was done in a separate context to allow closest view of the runtime without actually running runtime all the while remaining within the confines of the content center (which is why it would not work when integrated with TeamSite preview, the browser session and server session must be separate and isolated and not pollute the TeamSite session context with customer injected cookies, session data, etc). A stable and repeatable environment is a must for predictable development and preview, thus the choices.

tec_iwov

the problem we've seen with people using rewrite rules is that everything works fine in preview and then ends up /w 404's and broken images and links in runtime.

As Alex said the URL_PREFIX has been in Livesite since the dawn of time and minimizes preview vs. runtime differences.

That is one of the the big rules in LS (all though there are still some issues now and again) that it's got to work the same in preview as it would in runtime.

RonaldV

the problem we've seen with people using rewrite rules is that everything works fine in preview and then ends up /w 404's and broken images and links in runtime.

If that is the case, your proxy-rewrites are wrong!

AlexC

Right, we are not going to help everyone write correct rewrite proxy rules thus we have something that works in runtime and preview without requiring any knowledge of regex or rewrite rules or web server re-config. In some places access to the http server is not allowed by IT or it is hosted or it remaps into akamai/content service or they only use MS-IIS by policy (where rewrite rules are not trivial or easy to do) or ...list goes on. You get the idea why we need to have a way to get the right URL in 2 different environments that are linked by deployment and must be consistent, if we had absolute control over OS/http server/etc we would have used rewrite but unfortunately we do not have such a luxury.

RonaldV

From your answer, it looks like you have not idea what iwproxy is or used for. Maybe you can ask your colleagues. It has, whatsoever nothing to do with 'webserver config or url-rewrite'

And my answer "why does livesite by-passes the iwproxy" is still unanswered.

Let me try a new approach:
1. would it be possible to add a remark to the manual that 'livesite ignores all iwproxy settings'?
2. would it be possible to add the option to teamsite/livesite to NOT by-pass the iwproxy for preview, leaving the iwproxy- and preview-config to the customer?

And finally, for all of you who are unsure of how to write a remap-regex, this template should cover you in 99% of the cases:

_regex=^/iw-mount/default/main/my/branch/WORKAREA/jackinthebox/(.*)$=http://my.server.name:82/$1