How to Disable or Enable a Field in SPEAK

I’m not sure if Sitecore Rocks is the only way to do this, but I recently had to enable a disabled field of a SPEAK form. I figured you would be able to change field settings  in the content editor of Core, but I couldn’t find any way to do it from there. This post will describe how to change field properties through Sitecore Rocks; if there is another way to do this, please let me know through the comments. In my case, I was using SPEAK 2 with Sitecore 8.1.

  1. Open your instance via Sitecore Rocks and navigate to your app’s task page in the Core database.
  2. Right click the Item and select Tasks -> Design Layout.
  3. You should see some fields under Renderings and Placeholders. Double click the field you wish to edit.
  4. On the right, a properties dialog will appear.
    1. To disable the field – which will prevent text entry and make the background gray – set IsEnabled to False, IsReadOnly to True and add disabled=disabled to the  Parameters field.
    2. To enable the field, set IsEnabled to True, IsReadOnly to False and remove the disabled=disabled parameter.

Hopefully this helps other SPEAK developers out there! Feedback is appreciated.

Data at the root level is invalid. Line 1, position 1.

I recently ran into this error in Sitecore 8.2 when trying to change a link in a field in Sitecore. The field appeared blank,  so I clicked “Insert Link” and a Sitecore modal popped up displaying this error: “Data at the root level is invalid. Line 1, position 1.”

Sometimes when an invalid value is entered into a link field in Sitecore, the field will still appear blank to the casual observer. This of course, does not mean that the field contains no value at all. It just means that the field does not contain a valid link.

To resolve this issue, in the Content Editor click the View tab, then check Raw Values. The editor will refresh, and you should see something in that field of yours. It might be an ID or some form of garbage data. Clear that out completely, save the item, then uncheck Raw values. You should now be able to insert a link into the field. Hope this helps!

 

 

Resolving ClearScript V8 assembly issues

I recently worked with a colleague on a ASP.NET MVC / Sitecore project that had some references to ClearScript, which is a 3rd party assembly that lets you add and run scripts from C#/.NET. We noticed issues with trying to publish files from the solution to the webroot, which always seemed to break the site. The most common issue was with ClearScript. These issues resurfaced as we refactored the solution and made subsequent QA deployments to the client’s servers.

The first thing we did to fix this was reinstall ClearScript and JSEngineSwitcher through Nuget. We then kept making code pushes to the webroot until we encountered a new error, which we usually had to install through Nuget as well, or troubleshoot/fix in other ways. Many of the assemblies were way out of date, since the solution had not been updated in a long time. Also, because the webroot was part of the solution, we found that some Nuget packages were installed into the webroot project, not the Web project that we were building out of, which also caused issues. To update this, we right clicked the solution and selected Manage Nuget packages for this solution, then checked each package and clicked Manage, and checked the box for the Web project.

We eventually got the code pushes to the webroot to work. The next problem was moving the code changes to QA. The main issue we ran into was an error stating Could not load file or assembly 'ClearScriptV8-(32 or 64).DLL' or one of its dependencies. The specified module could not be found. Some solutions for this issue:

  • Right click the IIS application pool and select Advanced Settings. Change the value for Enable 32-bit Applications to true.
    • Some people have had success with the opposite (setting it to false). I am still not sure what effect this value has.
  • The error can mean that the ClearScript DLLs reference another DLL that is not present on the current machine. This makes sense considering I did not get this specific error on my machine with the same bin folder and site files. I looked into this and it seems like different versions of ClearScript require different versions of Visual C++ Redistributable:
    • For ClearScript versions 5.0-5.3, install Visual C++ Redistributable 2012.
    • For ClearScript versions 5.4 -?, install Visual C++ Redistributable 2013
    • I installed both 32-bit and 64-bit versions of both, although I’m not sure if that was required.
  • In my case, neither of the previous solutions worked, and it turned out that instead of copying over the bin to the QA server files and merging, I had to delete the bin folder and copy over new from my local webroot, which ended up fixing the issue.

I hope this helps others out there, this issue was quite an annoyance!

 

 

The breakpoint will not currently be hit. The source code is different from the original version

If you debug web applications frequently, you probably see this message in Visual Studio a lot. You set a breakpoint and attach to process, but the breakpoint is not active. If you hover over it, you will see this message:

The breakpoint will not currently be hit. The source code is different from the original version.

To begin, let me explain why you got this message.

You made a change to a method, view, class, etc, but you didn’t build the project before attaching to w3wp.exe. That’s all. Note, it’s best to just use ‘Build Solution‘ rather than ‘Rebuild Solution’. I’ve had times where I tried a Rebuild but nothing changed. I can’t quite explain it as anything other than a VS oddity.

Alternatively, you may get this message if you did build the project successfully. In that case, go to your web application and run the method/view, and VS should activate the breakpoints for you. In other words, sometimes you need to begin execution for VS to act correctly.

Now, onto that second part of the message…

To allow the breakpoint to be hit when the source code is different, right-click on the breakpoint, choose ‘Location…’, and turn on ‘Allow the source code to be different from the original version’.

Danger-sign-B

Do NOT allow the source code to be different from the original version.

There may be some weird situation where you actually want it to be different, but I don’t know of one. This is kind of like in VS 2010, where the build fails, and VS asks you if you want to run the application anyway… same weirdness level.

If you DO set allow the source code to be different, your breakpoints will be active, but they won’t highlight the entire line.. causing all kinds of debugger oddities and bugs.

Take this example…

not fully

Sure, your breakpoint works now, but it’s not going to run anything past ‘products’, which causes an exception in the debugger. This can get even more weird as you continue debugging. Oh, and building won’t do a thing.

So, things to remember:

  • Always build before attaching
  • Never allow the source code to be different

 

Happy Debugging.