Undesired Root Relative Link

Document relative link changes to root relative link in new documents created from a template. When saving changes to the template, this link changes back to document relative in the new document. The link points to the content source for an iframe.
What will I have to do to make this link remain a document relative link? Making and undoing a change to the template and re-saving it every time a new document is created constitutes a workflow problem. It also unnecessarily updates all other existing documents based on that template and uploads all of them to the server during synchronization.
I looked through the preferences and couldn't find anything that I might have accidentally changed to cause this phenomenon.

Ah - that's not a root relative link, it's a file:/// link (I don't think there is any name for it), and it's definitely wrong if you are finding it in a file that you have SAVED.  But it's how all links in a newly created child page will look BEFORE IT'S SAVED.  Once you have saved the file within the site, then DW can manage the links so that they reflect the location where you saved the file.
I do that because the links in the header's navigation change whenever new content is added to a category and the current content moves to the archive. So far I changed the links in the basic template and re-uploaded all the child pages. That's getting a little too much already, so I want to have to update only a single file with the header that the iframes in the uploaded pages are already linked to.
Good golly man, use Server-side includes, not IFrames!  This kind of this is exactly what SSI is for.
Not all child pages are at the same level. Most are just one folder down from the top, others are two and even three folders down. That's why proper updating is important. I may stick with the absolute URL.
You must use real ROOT relative links in the include files - then all things will work.  With a root relative link it doesn't matter where the page carrying the link is located within the site.

Similar Messages

  • Remote and testing server don't see root relative links the same

    My site works fine on my testing server (Apache, MYSQL,
    PHP). I use root relative links in a library
    file (include file) so that it will work with all pages. For the testing server these links look like this:
    /my_sites_root_folder/aaa/bbb/ccc etc.
    If I use these same links on the remote server they won't work. To get hem to work I have to change all these links to the form
    /aaa/bbb/ccc etc.
    When dreamweaver uploads files to the remote server, the site name folder  (my_sites_root_folder) doesn't go along for the ride--just the files in it. So on the remote all the site files are stored in htdocs. On my testing server, the files are stored in htdocs/my_site_root_folder.
    I think it must have something to do with the way I'm setting up the remote and testing servers, but I'm read a hundred pages of instructions without being able to figure it out. I think I'm just seeing something wrong, but I've already spent days on this. Can someone please point me in the right direction?
    I'm using DWCS5. Internet explorer 8, Windows 7.

    Thank you for your prompt response. I'm afraid I'm still totally puzzled here. It sounds like you're very knowledeable about your comments, but I would like to know more. I accept that using the local site root in links would be bad, but I'm not clear WHY. Structuring the links as I have doesn't cause any links to break. I've structured them this way because it's the only way I can find that everything works. But I still do not understand WHY I have to do it. Using different libary include files doesn't seem like a good way to go, though
    You suggest that if I use any root relative links at all, I need to use vitual hosts. I'm not finding any good coverage of what these are, and especially why they are necessary. If this is the case, does that imply that templates (which use root relative links) also will not work on the test server (at least without vitual hosts)? The conclusion I'm coming up with, given your remarks, is "Dreamweaver doesn't work with root relevant links when you're trying to test a site with a test server." Is this right?

  • Root-relative links & local testing server

    Yesterday I figured out that I'd have to use root-relative links in an included SSI file so that it would work from both templates and pages in my main directory (or other directories, for that matter), e.g., 'src=/image/picture.jpg'. However, since my site is PHP, in order to test the pages or even to use Live View, I have to make use of a "testing server". I did this without much trouble using a package called EasyPHP, which sets up a local web server as well as the PHP module, MySQL support, etc. This all works very well.
    The problem is that, in order to support several web sites, I have to use a "virtual directory" spec to direct the web server to the correct location for my site's files. In the setup for the testing server, I therefore have to specify a URL prefix such as 'http://localhost/corinthian' for this particular site. That has worked previously, but breaks when using root-relative links since the server sees the "root" as being the main "localhost" directory instead of "localhost/corinthian". So now my SSI doesn't display correctly because it's not being resolved to the correct directories.
    I don't think that this is fixable unless someone else has run into it and can think of some gimmick I could try. Anyone? Breaking out some of my code into an SSI has definitely been more of a challenge than I expected!

    I use 1&1 Internet as my hosting service. They apparently have my site set up in a virtual directory / virtual host fashion. Going to http://corinthian241.org, the root directory for root-relative links would have to be the directory pointed to by the URL. However, running phpinfo.php on the site shows the following result for $_SERVER['DOCUMENT_ROOT']: '/kunden/homepages/29/d246935068/htdocs/corinthian'.
    So I'm pretty sure that a link from a page in my site home directory using this as a prefix would definitely not work, since the first "/" implies starting in the "corinthian" subdirectory -- not the real root of the server itself. Correct?
      Doug

  • How to make site root-relative links work in DW and Server both?

    See details on buggy DW image link behavior, below. My question is:
    1) how to make site root-relative links work in DW and Server both? Or…
    2) how to reliably automate the change of several hundred legacy root-relative links of the form
    /images/image.jpg  to document-relative?
    That is, to
    ../images/image.jpg or
    ../../images/image.jpg or
    ../../../images/image.jpg etc…depending on where the directory is.
    The old format (/images/image.jpg ) used to work fine in my previous DW 8 configuration but appear grey in DW after “upgrading” to DW cs5.5 mac. (they look fine on the server, but it’s hard to edit image-heavy pages locally when they are all grey).
    I tried changing the files to how DW creates root relative links now:
    /public_html/images/image.jpg, which is a very easy, attractive root flow since there’s a one-to-one mapping. These look great in DW but are broken on the server!
    I looked at the “advanced” site setup, and it looked like it might be possible to nuke the /public_html/ part of my server info…but it also looked like there was the potential for doing damage changing these settings, which are automatically generated from our server connection settings, which seem to work.
    The “links relative to document/ site root” toggle…does that change how DW interprets existing links, or just change the default when you are adding a link?  I have made 80% of the file links document relative…before wondering if root-relative isn’t better?
    It sure seems less ambiguous for all those images if theres a way to make root relative work for DW design view, DW link check, and server.
    Summary of buggy behavior: (see test with images here)
    "old style" site root link
          /images/img_book/WScover120x150_NEW.jpg
          Design veiw in DW: broken (grey w/ broken icon)
          Link check in DW: "external link" (i.e., uncheckable, + file could appear orphaned)
          Browser: good
          Ease of switching: n/a (existing format)
    "new style" site root relative link
          /public_html/images/img_book/WScover120x150_NEW.jpg
          Design veiw in DW: good
          Link check in DW: good
          Browser: broken
          Ease of switching: easy
    Document relative link
          ../../images/img_book/WScover120x150_NEW.jpg
          Design veiw in DW: good
          Link check in DW: good
          Browser: good
          Ease of switching: hard (how to automate?)
    Absolute link
          http://www.oasisdesign.net/images/img_book/WScover120x150_NEW.jpg
          Design veiw in DW: broken (grey w/ broken icon)
          Link check in DW: external (i.e., uncheckable, + file could appear orphaned)
          Browser: good
          Ease of switching: n/a...not a real option
    Thanks!
    Similar discussion on "/"

    Hello again Jon!
    Thanks for jumping on this.
    All clear and understood about where publc_html is etc.
    No contemplation of nuking the actual public_html directory on the server, just the "/public_html" text string at the start of the DW-generated links.
    "/public_html" is automatically added to the front of the link in DW if I create the link with any of the GUI tools, if I have "site root relative" selected. And ""/public_html" ends up in the code, and gets uploaded that way to the server, where it (obviously) doesn't work.
    Doesn't sound like it is supposed to work this way. Also, what seems to be the usual root relative format (/images/image.jpg) shows as a broken link in the GUI and an external link in the DW link check. All this togther makes me thinkI have some obscure setting incorrect?
    The setting that caught my eye is manage sites/ site setup/ advance settings/ local info/ web url,  which is automatically set to http://www.oasisdesign.net/public_html/
    it gives an option to change it but it makes every effort to make this NOT look like something users should mess with:
    Having gone through the more careful thought process during this post, I'm ready to do the experiment of changing the remote server web URL (why is it wrong by default?)...think I'll eat dinner first so there's 45 min to avert disaster if anyone knows this to be a bad idea!
    Art
    PS--don't  have a local testing server...don't think this will solve the GUI broken link/ link shows as external problems.
    Is there an easy, automated way to change links sitewide from document to root relative?

  • Root Relative Linking not possible?

    I'm trying to set up my site so that the links are relative to the Site Root, but it doesn't seem to allow me to do that.  I can click on the Site Root button in Local Info, but when I click Save and then go back to it, it has reverted back to Document-relative links.  I don't have a Web URL that I can enter in, and I do need to use the root-relative linking (I can go into detail as to why, but I'll save that for now). 
    Is there something I'm missing that allows me to do that? 
    I'm using the Mac version of Dreamweaver CC.  There was no problem of this sort when I used a PC version of CS6 prior to switching computers. 

    We are unable to reproduce this issue. @bradthames or MurraySummers, can you please share a video of the issue?

  • Root relative images and design view

    I have many sites that have root relative image paths
    (src="\images\sample.gif") that I've coded by hand in DW8.
    I don't use design view that much, buy one of our designers
    does. The problem is none of the images with root-relative paths
    will appear in design view.
    I have specified valid paths in my site definitions, so
    what's the issue?

    > I have specified valid paths in my site definitions, so
    what's the issue?
    Hard to say - perhaps the developer's site is not properly
    defined. There
    should be no issue displaying root relative linked images in
    DW's Design
    view, since DW knows where the root of the site is. What is
    in the HTTP
    address field of the local site definition?
    Murray --- ICQ 71997575
    Adobe Community Expert
    (If you *MUST* email me, don't LAUGH when you do so!)
    ==================
    http://www.projectseven.com/go
    - DW FAQs, Tutorials & Resources
    http://www.dwfaq.com - DW FAQs,
    Tutorials & Resources
    ==================
    "Diodeus" <[email protected]> wrote in
    message
    news:g91jhj$imv$[email protected]..
    >I have many sites that have root relative image paths
    > (src="\images\sample.gif") that I've coded by hand in
    DW8.
    >
    > I don't use design view that much, buy one of our
    designers does. The
    > problem
    > is none of the images with root-relative paths will
    appear in design view.
    >
    > I have specified valid paths in my site definitions, so
    what's the issue?
    >

  • Link to site-root relative style sheet not working CS4

    I am trying to define links to site-root relative external style sheets - as I believe that IE conditional comments prevent Templates from correctly updating the links. The styles are not being applied when I use any href path begining with "/".  So, the following do not work:
    <link href="/styles/myStyleSheet.css" rel="stylesheet" type="text/css" />
    <link href="/myStyleSheet.css" rel="stylesheet" type="text/css" />
    Dreamweaver can open the css file from a right-mouse click and even give me warnings about css properties as a tool-tip as I hover over the file. The styles are applied fine with document relative paths:
    <link href="../myStyleSheet.css" rel="stylesheet" type="text/css" />
    Any ideas?
    Jeff

    Close your meta tag.
    <meta name="description" content="blah, blah, blah...>
    Nancy O.
    Alt-Web Design & Publishing
    Web | Graphics | Print | Media  Specialists
    http://alt-web.com/
    http://twitter.com/altweb

  • New From Template Changes Relative Links to Local Root?

    Thank you for taking the time to read and understand my plight with Dreamweaver CS3 for Mac. I apologize for the lengthy question, but in the effort to provide detail I shall go. First the background:
    I'm updating, editing, and appending an existing site that was previously created with Dreamweaver.
    I'm new to Dreamweaver but have a pretty good understanding of things
    I created a new site on the local drive on my MacBook Pro and then downloaded the entire site via FTP (live site: domain.com)
    I then replicated the site and exact file structure using FTP to a staging server (staging.domain.com)
    There are three existing .dwt templates. I've successfully updated the template file and auto updated all other pages that were based on this template.
    But my problem comes from creating new pages FROM the template. It appears that while the .dwt template file shows relative links (../xxxx) in the code, when create a new file from the template the url of these links is replaced by the path to the file on my local drive... I want non of this (.../xxxx) is fine.
    What is happening is that a javascript drop down menu is disappearing when I create new from template. I am assuming it's because of the path changes.
    This is the ORIGINAL (good) code from the .dwt:
    <!-- Top Navigation -->
    <tr>
         <td height="31">
              <table width="718" border="0" cellpadding="0" cellspacing="0">
                   <tr>
                        <td width="24"><img src="../images/L-Header-Corner.gif" width="30" height="50" border="0"></td>
                        <td width="342" style="background-image: url(../images/Header-BG.gif);"><img src="../images/spacer.gif" alt="" width="337" height="1" border="0"> </td>
    But when I create a NEW page from the above template the code is changed to the local path: 
    <!-- Top Navigation -->
    <tr>
         <td height="31">
              <table width="718" border="0" cellpadding="0" cellspacing="0">
                   <tr>
                        <td width="24"><img src="file:///Grasshopper/Users/allan/Documents/clients/site/site staging master/images/L-Header-Corner.gif" width="30" height="50" border="0"></td>
                        <td width="342" style="background-image: url(file:///Grasshopper/Users/allan/Documents/clients/site/site staging master/images/Header-BG.gif);"><img src="file:///Grasshopper/Users/allan/Documents/clients/site/site staging master/images/spacer.gif" alt="" width="337" height="1" border="0"> </td>
    To be sure all links in the template file are changed too.
    This is the .dwt file itself
    This is a random page created from the above template.
    And this page was created by simply altering the .dwt template file linked above and then SAVING AS. You can see the relative links remained and the navigation bar looks and operates as normal.
    To provide easier visual reference I offer the following:
    This is the .dwt file when opened in dreamweaver:
    Note the black area where the javascript drop down menu is in the top navigation when the page is correct:
    But when I create a NEW page from template this is what I get in the top navigation bar:
    And then this is what it looks like when posted:
    Ultimately what I'm trying to do is:
    1) work on site files on my local drive
    2) sync the local drive with staging.domain.com so my client can proof and approve
    3) sync to the actual live site at domain.com
    I assume I could simply do this by changing the ftp info and given the site structure and all files are same and ideally all links are relative this should be accomplished easily.
    Though perhaps my problem stems from the fact my local site is buried several layers deep on my local drive Local Drive/Users/Me/Clients/Client.... etc... but I haven't checked this yet.

    Great... Thanks for your patience....
    Here are links to all questioned files on the staging server:
    This is the .dwt file itself
    This is a random page created from the above template that shows the image/navigation incorrect.
    And this page was created by simply altering the .dwt template file linked above and then SAVING AS. You can see the relative links remained and the navigation bar looks and operates as normal. (obviously the wrong thing to do.
    And this page is one that was created prior to my working on the site and was based on the subpage template and displays correctly.
    Now bear with me here as I notice this behavour too.
    In the code snipped taken directly from the DW .dwt template (linked above)
    <td width="24"><img src="../images/L-Header-Corner.gif" width="30" height="50" border="0"></td>
                        <td width="342" style="background-image: url(../images/Header-BG.gif);"><img src="../images/spacer.gif" alt="" width="337" height="1" border="0"> </td>
    you'll notice there are two images L-Header-Corner.gif and one that is Header.BG.gif.
    The difference here is that the BG gif has a style attributed to it "Background-Image) which is followed by some strange code that says (url)../
    Opening that file Background Image and it's a tiny slice of what I think is part of the entire missing gray bar:
    In a page that displays correctly the code looks like this:
    <td width="24"><img src="../images/L-Header-Corner.gif" width="30" height="50" border="0"></td>
                        <td width="342" style="background-image: url(../images/Header-BG.gif);"><img src="../images/spacer.gif" alt="" width="337" height="1" border="0"> </td>
    And in a page that is displaying incorrectly the code appears like this:
    <td width="24"><img src="../images/L-Header-Corner.gif" width="30" height="50" border="0"></td>
                        <td width="342" style="background-image: url(file:///Grasshopper/Users/allan/Documents/clients/koolfog/koolfog website staging/images/Header-BG.gif);"><img src="../images/spacer.gif" alt="" width="337" height="1" border="0"> </td>
    So you can see that the link in this case (with the URL and style) has actually been converted to a site (my hard drive) relative link when saving.
    So the pressing question stands: Why doesn't dreamweaver convert that URL link when saving a page created from a template back to the same directory?
    Also, it appears that in that .DWT all the links have the leading periods and therefore are document relative... since I didn't set this up, how do you think this happened?

  • Site-relative links fail on local testing server

    Using CS4/WAMP/XP, I have a testing server set up. All works well except that when I specify site-relative links, on the testing server they go back to localhost, not localhost/Frances. They work fine on the live site, but not on my testing server.
    This prevents me from using (well, testing) 'include' files for things like menus when parts of the site are in different folders.
    I have my site setup as follows:
    Local Info
    Site name "FFG2009"
    Local root folder C:\wamp\www\Frances\
    Default images folder C:\wamp\www\Frances\images\
    HTTP Address: http://localhost/Frances/
    Testing Server
    Server model: PHP/MySQL
    Access: Local/Network
    Testing Server Folder: C:\wamp\www\Frances testing\
    URL Prefix: http://localhost/Frances/
    In my Apache config file I have a virtual directory set up like this
    Alias /Frances/ "c:/wamp/www/Frances/"
    <Directory "c:/wamp/www/Frances/">
        options all +includes
        AllowOverride all
        Order allow,deny
        Allow from 127.0.0.1
    </Directory>
    I have been advised that I could temporarily change the Apache webroot folder to my "Frances" folder, but that stops other things like PHPMyAdmin from working. Also I have other sites within my www directory and I'd rather not have to change the Apache rootweb directory every time I need to work on a different site.
    Is there a way to set up my site in CS4 so that site root links go to localhost/Frances rather than just localhost?
    Thanks
    Tone'z

    Many thanks Mark.
    I fact I spent all yesterday coming to the same solution. Finally at around 12:30am this morning it worked!
    Early in the day I found the same reference you mentioned in an on-line copy of David Power's book where he exactly described the very problem I had - and with the VH solution.
    However, I had a problem with an obscure syntax error in the virtual hosts include file. I still don't know what it was. The flag to perform a syntax check on HTTPD startup didn't discover it. The problem actually prevented the Apache service from starting at all but that little point escaped me for a long time because the WAMP system tray icon is so small I didn't spot that it was telling me "some services are running" (half yellow) instead of "all services are running" (white).
    It wasn't until I ran (in desperation!) Apache Monitor that it became obvious that Apache was tripping over this virtual host definition and failing to start.
    It also seems that if you have any virtual host directive in an include file, then it negates the localhost directive in the Apache config file. So when I define the Frances virtual host, I also need to have localhost defined in the include file.
    It was this localhost directive that was causing the problem. I found it by having Apache Monitor running so I can see the true state of the Apache service and, after pointing the config file 'include' directive to a vhosts file...
    empty the vhosts file - Apache starts - 'localhost' works, frances doesn't - makes sense.
    add the frances virtualhost definition to the vhosts file - Apache starts -  'frances' goes to the frances site, 'localhost' does too (dam')
    add the localhost virtualhost definition to the vhosts file - Apache fails to start - "IE cannot display this page"
    pull out the localhost definition - Apache starts... hmmmm... .
    find an example localhost definition from somewhere else - to all intents and purposes identical to mine - add it in - Apache starts!
    Both localhost and frances now work! Maybe there was a space where no space should be - I don't know.
    Of course I also had to add entries into windows/system32/drivers/etc/hosts to point to 127.0.0.1.
    Oh yes, virtualhosts are fussy about folder names. You cannot have spaces in a folder name.
    Thanks
    Tone'z

  • Relative Links and Microsoft  IIS not working, why?

    I've searched high and low for the solution to this problem
    and no one seems to give a definite answer.
    I have a typical home server set up using Microsoft IIS on
    Windows 2000 as a test server for websites.
    The typical folder structure of the IIS is Inetpub >
    wwwroot > content
    Since I am working on multiple websites at a single time I
    place my websites as such Inetpub > wwwroot > websiteFolder1
    with multiple websites under wwwroot
    Now I setup the dreamweaver sites with the root directory as
    websiteFolder1 but when I go to use relative links, dreamweaver is
    looking at the wwwroot level instead and the relative links won't
    work. So incase that seems hard to understand when I have a css
    file that is in Inetpub > wwwroot > websiteFolder1 >
    library and I want to relatively link to it, dreamweaver is instead
    of seeing websiteFolder1 as the main, it is starting with wwwroot
    and that makes the file not found.
    How do I get the relative links to see the folder under
    wwwroot as the root directory instead of wwwroot?
    Thanks Much!

    You would have to set up virtual sites in your IIS
    installation. Google
    that term, and I'm sure you will find lots....
    Murray --- ICQ 71997575
    Adobe Community Expert
    (If you *MUST* email me, don't LAUGH when you do so!)
    ==================
    http://www.dreamweavermx-templates.com
    - Template Triage!
    http://www.projectseven.com/go
    - DW FAQs, Tutorials & Resources
    http://www.dwfaq.com - DW FAQs,
    Tutorials & Resources
    http://www.macromedia.com/support/search/
    - Macromedia (MM) Technotes
    ==================
    "Visionology" <[email protected]> wrote in
    message
    news:ee18ce$jej$[email protected]..
    > I've searched high and low for the solution to this
    problem and no one
    > seems to
    > give a definite answer.
    >
    > I have a typical home server set up using Microsoft IIS
    on Windows 2000 as
    > a
    > test server for websites.
    >
    > The typical folder structure of the IIS is Inetpub >
    wwwroot > content
    > Since I am working on multiple websites at a single time
    I place my
    > websites
    > as such Inetpub > wwwroot > websiteFolder1 with
    multiple websites under
    > wwwroot
    >
    > Now I setup the dreamweaver sites with the root
    directory as
    > websiteFolder1
    > but when I go to use relative links, dreamweaver is
    looking at the wwwroot
    > level instead and the relative links won't work. So
    incase that seems
    > hard to
    > understand when I have a css file that is in Inetpub
    > wwwroot >
    > websiteFolder1 > library and I want to relatively
    link to it, dreamweaver
    > is
    > instead of seeing websiteFolder1 as the main, it is
    starting with wwwroot
    > and
    > that makes the file not found.
    >
    > How do I get the relative links to see the folder under
    wwwroot as the
    > root
    > directory instead of wwwroot?
    >
    > Thanks Much!
    >

  • Relative links in interactive pdf

    Hi. I'm building an interactive pdf that will work as the content of an interactive cd. The main document is saved on the "cd" directory, on the desktop. I created a button that will open an external pdf file. The link to the file is an absolute link:
    Macintosh HD:Users:myuser:Desktop:cd:files:file1.pdf
    Now, I need this to be a relative link so I can burn the cd and make sure it works, independently of the file's root address. How can I achieve this?
    I tried changing the : to / and doing something like ./cd/files/file1.pdf but it didn't work. This probably has a simple solution, I just don't know how to express relative links in InDesign. Any advice? Thanks.

    Hi. Honestly I don't remember how I solved this at the time, it was over 3 years ago... The problem was just as described. I had an interactive pdf that I had to burn on a CD. On the CD was another file that could be opened via a button on the interactive pdf. Thing was I didn't know how to create a button with a link for the document on the CD, I could only do it with guaranteed results using a link to the file on my computer. Hence the need to have a relative link.

  • Root path links and tomcat

    Hi!
    I'm using tomcat 5.5 and I made a simple webapp:
    tomcat_dir/webapps/myapp
    I'm using root paths when refering to images, docs, servlets, and so within myapp (servlets, jsp, html, etc.)... For example:
    <img src="/myapp/imgs/pic1.jpg" ...>
    <form ... action="/myapp/servlets/sendMail.do">
    request.getRequestDispatcher("/es/thanks.jsp");all this root path links works fine whenever I'm running my web app from localhost (http://localhost/myapp/index.html) but whenever I running it from internet (http://myapp.mydomain.com) I can't get the web app to work, instead I get the glamorous HTTP 400 error
    What do I'm doing wrong? I've tried using relative paths and myapp works both localhost and internet way... but what do i need to do to use root paths?
    thx

    when u are getting error code 400, pls notice what the url has formed...copy and paste it here inthis forum..

  • Qualified links to Relative links

    Hi All-
    I have created a course with links to pdfs in two if the
    scos. They work fine when tested on my computer but when tested in
    the LMS the pdfs won't come up: I need to change it from being a
    fully qualified link to my hard drive, to being a relative link
    pointing to the file in my course folder (in this case, it would
    need to be ../Power_Handle_Training1a.pdf as the PDF exists in the
    root of the overall course folder). I am not sure how to do this.
    Please help.
    Many thanks,
    Rita

    Simply set your button to open url or file and put the name
    of the file in the box without any other info for ex.
    Power_Handle_Training1a.pdf .
    then make sure that everything including a copy of the pdf is
    in the same floder after you publish. this should do it.

  • Runtime error in MSS - Team- General Information- Related links- Employee Dates

    Hello All,
    We recently upgrade from 7.01 to 7.31, we also updated the respective XSS components also to compatible levels. All applicatoins are coming up well except the Employee dates and Desciplinary actions based on related links under MSS ->Team->General Information.
    Below is the error -
    java.lang.ClassNotFoundException: com.sap.pcuigp.xssfpm.wd.interfaces.wdp.IExternalIVAC ------------------------- Loader Info ------------------------- ClassLoader name: [sap.com/mss~hras] Loader hash code: 5ed59f53 Living status: alive Direct parent loaders: [system:Frame] [interface:webservices] [interface:cross] [interface:security] [interface:transactionext] [library:webservices_lib] [library:opensql] [library:jms] [library:ejb20] [service:p4] [service:ejb] [service:servlet_jsp] [library:tc~bl~exception~lib] [library:tc~aii~base~offline~facade] [library:tc~cmi] [library:tc~ddic~runtime~facade] [library:tc~bl~logging~api] [sap.com/tc~wd~api] Resources: /Q1ETP001/usr/sap/QP4/J44/j2ee/cluster/apps/sap.com/mss~hras/servlet_jsp/webdynpro/resources/sap.com/mss~hras/root/WEB-INF/lib/sap.com~mss~hras.jar ---------------------------------------------------------------
    Please note our ECC is on EHP4, so we cannot proceed as mentioned in http://scn.sap.com/thread/3415508
    Thanks,
    Vamshi

    Same here: ClassNotFoundException in getting connection>>java.lang.ClassNotFoundException: com.sap.portals.jdbc.db2.DB2Driver Found…
    cheers

  • Templates / script / relative link

    I'm trying to use relative links within a javascript menu in
    a template. Is this even possible? You will see at the bottom under
    MENU ITEMS all my links are coded as absolute paths. I would like
    to use relative paths. It this possible?

    dreamweaver does not "manage" paths buried in custom
    javascript.
    They will be exactly the same in the child pages as they are
    in the template
    file.
    So- no, you shouldn't use document relative paths in that
    menu.
    Only use absolute or site root relative paths, because dw
    will not alter the
    paths when the child pages are created and saved at different
    folder levels
    in the site.

Maybe you are looking for