As soon as I come across some thing new and is a small piece of info, but, could be useful, I can immediately think about my Did you know series. This would be a latest addition to the pile.
Interesting piece of information that I bumped in to yesterday while running Broken Links report on a huge database and sitecore instance that has many versions on CM side of things in many different languages. When I run the broken link report, there were huge number of items listed on the report and I randomly picked bunch of those to check more deeply. Most of them were outdated and old versions.
I immediately thought there should be a way to force Sitecore not to consider old versions when running broken links report. Unfortunately, there is no way to do so currently. When I dig deeper in code of kernel, I did see the default is to consider all versions.
I got a feature request logged with sitecore if you like to track it, here is the reference number – 178492
If you really need this feature, then, the only other way is to build your own Speak View and scanner that could be custom function to grab only the latest version of each item in each language to keep the list to what you really care about. 🙂
So psyched to share this quick piece of info, this is my first time working with a fully Sitecore Paas infrastructure, so, getting to know it more intimately. I did know that Sitecore Paas comes with Azure Search and Redis cache for instance, but, what I did not know is that Lucene is not at all supported which means that all Lucene related config files were actually disabled on the upper environments that were set up with help from Sitecore.
Reality hit me hard when trying to set up a computed index field that worked beautifully fine on my local, but, completely broke on upper environments.
So, folks out there if you are using Paas pay attention to the index configuration and ensure all the steps listed below were actually completed thoroughly on your Paas sitecore servers.
Two quick follow up questions that would come to mind, how do I know which type of Search Indexes are used, this is the simple one, look at showconfig.aspx to see what is listed under Index configuration which defines type of Index.
The second one which is more important when there is custom search/Index based functionality is, how to ensure locally too Developers are using Azure based Indexes and not Lucene based one’s? Would love to hear from every one who has experience on this. This would be an open question for now, hoping to resolve this based on feedback and would potentially reach out to Sitecore to understand what do people generally do for Development in this case.
Happy Sitecoring and hope you are all enjoying your holidays!
There are times when you bump in to this issues which feel like are present in out of the box version, when you are confident that it is Sitecore issue, feel free to put in a support ticket, they are usually prompt in getting back, especially, if this issue has been known to be existing. Similar thing happened when our QA logged a bug for us which states image dimensions are missing on tree view and look fine on the other view. See screenshot below as a reference.
Support got back in no time and here is the patch for the same if you are on version Sitecore 8.2 and above.
With Helix, it gets a little tricky to apply these kind of patches by Sitecore. Below are the steps I followed, hopefully it helps some one who is looking for some guidance on the same.
- Go to Sitecore Official and Nuget sources to see if there is already a package by Sitecore, I am assuming on critical sitecore patches they would release Nuget packages to ensure folks can use from the same repository to battle their issues.
- In my case, the issue is minor, so obviously could not find a patch that was a Nuget, I made my own Nuget and hosted it on our company Nuget Server. If you do not have your company one and are working with set of local developers, you could ask them to create a Local repository on some shared location and host the package from there.
Note: Ensure your build servers also have access to that shared location. 🙂
That is it! Issue behind us and we move forward to attack other fun problems.
Super excited to post my second post on ‘Did you know’ series. This is in relation to thing/step that developers could potentially forget as they were so happy that they wrapped up a module that was complex, but, still felt super simple with help of Glass to get children loaded with exact object types they need and performance efficient and maintainable code as they parse through the list of objects only once. 🙂
How cool, right?
But, what about your content author who uses Experience Editor for them daily chores of adding/updating modules. We tend to forget them often in this busy world of making functionality. The mantra “They are the ones who use the system when you call it done and deploy the code”. So, remembering them for nth time, lol, to ensure they are still happy, do not forget to add Insert option to Experience Editor buttons that show up on the rendering. Go to your rendering that has children being read as part of implementation and add in Insert as an option to show up.
A picture is better than 1000 words, here you go:
Another problem you would need to address when you utilize children is to ensure when an item (Datasource item) is published, the children of that particular item are also published when related items are pushed. Out the box sitecore does not do that, pay close attention and ensure you customize it.
Helpful link for this publish issue:
Deep Publishing Of Related Items With Sitecore Experience Editor
Welcome to my series “Did you know”, I will keep posting as and when I find interesting issues and how I solved them. This would a tiny tidbits of information which could help some one in need. Some times you spend half day resolving an issue only to realize how petty that was. 🙂
I wish I could find a blog on each of these issues, the reason I choose to post is because I could not find a Blog or direct link to these type of issues. Pesky little issues that eat our brains out, well, hope this helps some one.
Problem: Very weird behavior on Glass Editable controls, specifically on looping an object, all is well when you run the debugger, but, when you actually visit the live page or preview mode the problem shows up. On Experience Editor though things might look okay.
Resolution: I spent hours thinking my objects are not correct, data is not loaded properly by Glass as I was mapping the children and then looping over them. No errors on logs either. Finally! light at the end of tunnel, the paid attention to Model being passed to @Editable Glass fields, the Engineer was copy pasting this line of code by passing it as generic X, so, it is up to Glass to decide what the object is vs we clearly stating what is the object over which we expect the looping to occur. Once I passed in the Model using the override method of this Html control, everything starting working on all modes preview, EE and live mode.
Example Usage: @Editable(Model, x => x.Title) //explicitly stating the model
Helpful References : http://glass.lu/Mapper/Sc/Tutorials/Tutorial22
Hope this helps!
Thought of the day: I am super jealous with all folks at Sitecore symposium right now, hope to join you all next year. :)