2 Replies Latest reply on May 12, 2008 3:43 AM by james_w4

    Big Problem with Server Side Includes (SSI)

      We're experiencing a major problem with Server Side Includes that are written in ASP.NET / C# code, i.e.

      <% Response.WriteFile ("/includes/en/header.inc"); %>

      Most of the time Contribute CS3 behaves well and the SSIs work as you'd expect. When in Edit mode the SSI content isn't visible, but this isn't a problem as the Editable content can still be accessed. However, if a template is changed in Dreamweaver, and the updated page subsequently edited in Contribute, Contribute attempts to save the SSI content in the actual .aspx file. So rather than saving an .aspx file with the C# include code, the content of the .inc file becomes "hard coded" in the .aspx file.

      This is a major issue and the only way I've found to overcome it is to delete the connection in Contribute and then create a new connection every time a change is made to one of our templates. Refreshing the templates by choosing New... Refresh Templates -> for all websites works occasionally but not reliably. For one user this is not the end of the world, but getting all our users to delete and recreate their connections every time a template has changed is not possible.

      The problem seems to be related to Contribute "caching" an old version of the template, and then thinking that the template for the page being edited is different to the actual template used to create the page. It only occurs when the template has been changed from the version that existed when the Contribute connection was created. The only solution I can think of is to use Dreamweaver Library Items instead of our SSI approach - however the site has 500+ pages and LBI's don't offer the flexibility that we require from SSIs.

      This is a major issue for us - please can anyone help?
        • 1. Re: Big Problem with Server Side Includes (SSI)
          Do you update the template, then log into Contribute before editing? Contribute only downloads templates right when you first connect to a site.

          A) Close all contributes
          B) Update Template
          C) Open Contributes
          D) connect to site
          --- this will cause the templates to update.
          --- are u getting the error at this point?
          --- or, are you getting it while logged in and have not gotten the updated templates?
          • 2. Re: Big Problem with Server Side Includes (SSI)
            james_w4 Level 1
            (sorry for the delay in replying, first day back at work after holiday...)

            Simply "reconnecting" to Contribute (i.e. closing then reopening after uploading the new template) doesn't seem to solve the problem - only deleting the connection entirely then re-establishing it ensures that the SSI code is handled correctly (I'm assuming because the latest template is being correctly used).

            Moreover - getting every Contribute user (we only have a handful at the moment but this may grow) to delete and re-establish their connections isn't reliable, especially as the "problem" doesn't report itself well and you need to understand what is going on to realise that there is a problem at all.

            I guess what I really need to get to the bottom of is why on some occasions the .aspx file is saved with the correct original SSI code (<% Response.WriteFile ("/includes/en/header.inc"); %>) and sometimes the actual contents of the .inc file are saved ("hardcoded") into the .aspx file. If it is related to the latest version of the template being used, and the only way to overcome this is to request everyone deletes and re-establishes their connections then this is what we'll have to do - but if there is anything else I can do to ensure Contribute NEVER hardcodes the SSI code then this would of course be the best solution.

            Any other ideas?

            Thanks again for your help.