0

We're encountering a strange issue from one environment to the other that we can't seem to get to the bottom of. We're using Azure for hosting as well.

On all environments, we have the following code:

<div class="col-12">
@foreach (var service in Model.AdventureForm.AvailableServices)
{
    <label>
        <input name="serviceType" 
               type="radio" 
               value="@service.QuestTypeValue" 
               class="serviceType-radio" 
               data-sc-field-name="serviceType" 
               @(service.QuestTypeValue == "2" ? "checked" : "") /> 
                   @Editable(service, x => x.DisplayText)
    </label>
}
</div>

On our Local, Dev and QA, the code for a single radio button renders as follows, which is perfect and as it should be:

<label>
    <input name="serviceType" 
           type="radio" 
           value="2" 
           class="serviceType-radio" 
           data-sc-field-name="serviceType"
           checked="">
               Exploration
</label>

However, on our Prod environment, the code renders this way and we have no idea why this is happening:

<label>
    <input name="serviceType" 
           type="radio" 
           value="#{Sitecore.Settings.AdventureForm.ServiceTypes.ExplorationId}" 
           class="serviceType-radio" 
           data-sc-field-name="serviceType">
               Exploration
</label>

Differences Between Environments

Local is a locally installed Sitecore instance.
Dev and QA are Standalone, Azure-hosted environments.
Prod is a Multi-server, Azure-hosted environment.

What We've Checked So Far

  • Templates seem identical between environments.
  • Datasources seem identical between environments.
  • Renderings seem identical between environments.

Any help or ideas would be appreciated. We're all very confused here.

  • what is the type of "service.QuestTypeValue"? – Ahmed Okour Dec 28 '18 at 20:37
  • @AhmedOkour It's supposed to just translate to a string equal to "1", "2" or "3". – Villanite Dec 28 '18 at 21:30
  • So the type is string? Or could it be an enum? – Ahmed Okour Dec 28 '18 at 21:31
  • @AhmedOkour - I've updated the question with a "More Info" section hopefully answering your questions. Let me know if you need more details. – Villanite Dec 28 '18 at 21:43
  • 1
    This is going to be difficult to answer without much more in-depth knowledge of your solution, as there is no way to see how QuestTypeValue receives its value. For what it's worth, the format #{..} is used by Octopus Deploy variables, so you could look to see if there is something different about the deployment on your Prod environment. – Kasaku Dec 29 '18 at 0:14
0

We were led to the root problem of this via a comment from Kasaku. Unfortunately, this is our team's first time working with Octopus and didn't have enough experience with it to realize that the #{variable.name} format was related to Octopus. Of course, my first initial Google Search for '#{}' returned nothing useful (as more-or-less expected), so now I'm just feeling silly for even posting the question here. Hopefully, though, it's useful to someone else in our situation in the future.

As it turns out, our deployment process was populating this variable for a particular deployment channel, but not the channel we were using this time. Once I fixed the population of this variable in Octopus, this began to work just fine again.

Thanks again to both Kasaku and Dan Sinclair for mentioning Octopus and pointing me in the right direction!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.