1-888-365-2779
+1-888-365-2779
Try Now
More in this section

Forums / Bugs & Issues / Compilation Error, Parser Error (ID already used by another control)

Compilation Error, Parser Error (ID already used by another control)

8 posts, 0 answered
  1. Pavel
    Pavel avatar
    14 posts
    Registered:
    25 Sep 2007
    20 Apr 2011
    Link to this post
    After the upgrade to SF 4.1 our clients' website is experiencing page rendering failures due content controls with duplicate IDs. Under 4.0 all pages and content rendered correctly. See attached images.

    Our observations:
    1) It seems to be related all the time to Content Blocks
    2) The error varies between Compilation Error and Parser error
    3) Pages render in design mode correctly
    4) In design mode, we have confirmed the existence of duplicate IDs by looking at the Content Block's advanced properties. Changing it, or deleting the content block and re-creating the content seems to aleviate the problem. We cannot fix it consistenly due to the error being thrown sometimes in content in page footer (part of template)
    5) We searched the forums for similar issues and we found this link http://bit.ly/iab7MX. We implemented the solution and are still experiencing the issue.

    We waited for the 4.1 release because of breaking issues in 4.0 and 4.0 SP1 that prevented us from deploying an important client website. 4.1 fixes some issues and at the same time introduces new CRITICAL issues that prevent us from completing our work and instead spend infite time posting support forum requests and tickets.

    Your immediate attention to most critical of issues is requested.
  2. Antoine
    Antoine avatar
    1 posts
    Registered:
    18 Mar 2011
    21 Apr 2011
    Link to this post
    I have encountered the same issue when upgrading form 4.0.1210 to 4.1.1339.

    Parser Error Message: The ID 'C000' is already used by another control.
  3. Ivan Dimitrov
    Ivan Dimitrov avatar
    16072 posts
    Registered:
    16 Jun 2017
    25 Apr 2011
    Link to this post
    Hello,

    Please try to change the control's ID from its designer. The problem comes, because we changed the parser.

    Regards,
    Ivan Dimitrov
    the Telerik team

  4. Srekis
    Srekis avatar
    1 posts
    Registered:
    07 Feb 2011
    19 Jan 2012
    Link to this post
    Hi,
    we have the same problem for our custom user controls included on pages. We are running on version 4.4 already and the problem is still there... Please, change the parser back to previous (in version 4.0.xxxx.x) or fix it somehouw, because it is really strange to fix ID on all our pages and keep in mind it and inform new involved users that if they wants to put some usercontrols to page they have to also change its ID etc... Thanks for repair.
  5. Ivan Dimitrov
    Ivan Dimitrov avatar
    16072 posts
    Registered:
    16 Jun 2017
    23 Jan 2012
    Link to this post
    Hello,

    Could you send the stack trace of the error and tell us where it occurs. Is this a clean installation or an upgraded project?

    Kind regards,
    Ivan Dimitrov
    the Telerik team
    Do you want to have your say in the Sitefinity development roadmap? Do you want to know when a feature you requested is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items
  6. Greg
    Greg avatar
    16 posts
    Registered:
    11 May 2011
    26 Jul 2012
    Link to this post
    I am also seeing this behavior in Sitefinity 5.1, but in my case I have a custom layout following the examples in the documentation with three nested div tags all marked as runat="server" with different ID's.  This works great as long as I only add one of them to the page, but as soon as I add more than one, I get this same parser error complaining that there is another element with the same id as the outermost div tag.

    This is a clean installation, not an upgrade and the error occurs in /SFPageService/  There is no stack trace as this is a parser error.

    The ID 'OuterBox' is already used by another control.
    <div runat="server" id="OuterBox" class="sf_cols gradient-box-outer">
        <div runat="server" id="ShadowBox" class="sf_colsOut sf_1col_1_100 white-border shadow">
            <div runat="server" id="MainBox" class="sf_colsIn sf_1col_1in_100 gradient-box-light content-container gradient">
      
            </div>
        </div>
    </div>
  7. Greg
    Greg avatar
    16 posts
    Registered:
    11 May 2011
    26 Jul 2012
    Link to this post
    I am also seeing this behavior in Sitefinity 5.1, but in my case I have a custom layout following the examples in the documentation with three nested div tags all marked as runat="server" with different ID's.  This works great as long as I only add one of them to the page, but as soon as I add more than one, I get this same parser error complaining that there is another element with the same id as the outermost div tag.

    This is a clean installation, not an upgrade and the error occurs in /SFPageService/  There is no stack trace as this is a parser error.

    The ID 'OuterBox' is already used by another control.
    <div runat="server" id="OuterBox" class="sf_cols gradient-box-outer">
        <div runat="server" id="ShadowBox" class="sf_colsOut sf_1col_1_100 white-border shadow">
            <div runat="server" id="MainBox" class="sf_colsIn sf_1col_1in_100 gradient-box-light content-container gradient">
      
            </div>
        </div>
    </div>
  8. Greg
    Greg avatar
    16 posts
    Registered:
    11 May 2011
    26 Jul 2012
    Link to this post
    I actually found a solution to this on my own--it turns out that the sample code provided in your documentation is wrong (actually the code that processes these custom layouts is wrong, but this is a workaround.)

    It turns out that Sitefinity prepends the ID attribute of the INNERMOST div tag ONLY.  So the two outer div tags (and presumably any other element in the control) must NOT be marked runat="server" and given an id or this parser error will occur.

    What SHOULD happen (and please correct this in future versions) is what asp.net does--use a client ID separate from the server id and prepend the parent id in front of EVERY server element before sending it to the page.
8 posts, 0 answered