Allowed Controls Issue Fortis Dynamic Placeholders

I know many folks out there love and use Fortis Dynamic Placeholder either via Nuget or in package form.

The following link provides some information and background about what it does.

http://fortis.ws/fortis-collection/dynamic-placeholders/

While picking a dynamic placeholder support for my 8.2 Sitecore Instance I did a lot of research to see and weigh my options and picked this as this has been actively used by many of Sitecore enthusiasts.  The hope was it will be seamless and easy to use.  It was both of these on many levels and so far was working fine for our requirements.

On this specific implementation of Sitecore, we do use a lot of modules with placeholders for re-use and ease of dropping different type of content within the parent wrapper for instance.  It gives immense flexibility and power when done right.  I was skeptical that we would potentially run in to an issue or two, but, was also confident that this module is backed up by Habitat as well along with about 60k downloads on Nuget that any issue could have a potential solution.

Issue :  When you have a placeholder within a Dynamic Placeholder , this inner placeholder could be a sitecore one or dynamic one, incorrect allowed controls were showing up on Inner placeholder.   It was actually pulling allowed controls of parent(wrapper) instead of inner placeholder.

Steps to resolve:  I decided to approach the channel and folks I know who love/recommend Fortis, unfortunately none of them yet encountered this issue of mine.  So, I decided to debug further.  The issue is in the patch that the module does before Sitecore.Pipelines.GetPlaceholderRenderings.GetAllowedRenderings to get the allowed controls of placeholder based on regex match and add it to list of renderings.  For this patch, if you use dotpeek or reflector, you will notice the below lines of code :

Match match = new Regex(PlaceholderKeyRegex.DynamicKeyRegex).Match(placeholderKey1);
if (!match.Success || match.Groups.Count <= 0)
return;
string placeholderKey2 = match.Groups[1].Value;

What this does is get the match from the args placeholder key that Sitecore pushes in to see if this is a dynamic type of placeholder and if it is, it tries to look in to groups to find the value and correspondingly get the Allowed Controls on placeholder in question.  This is an issue because it is by default picking up the first match and not considering the most inner match possible.

I revamped this piece of code to use Regex match collection instead and pulled up the most inner one available and that seems to do the trick.  I will attach the fix below for your reference if you are curious.  I left rest of the code untouched to ensure I introduce no bugs. 🙂

Note:  Still under testing and not been shipped to live site, so, use this with caution.

Regex regexForPlaceholderKey = new Regex(PlaceholderKeyRegex.DynamicKeyRegex);
var allMatchesOnPlaceholder = regexForPlaceholderKey.Matches(placeholderKey1);
Match match;
if(allMatchesOnPlaceholder.Count > 0 )
{
//Always get the highest match, last match as that would be needed for allowed controls
//If there is just one matcg it should still get the first one
match = allMatchesOnPlaceholder[allMatchesOnPlaceholder.Count-1];
if (!match.Success || match.Groups.Count <= 0)
return;

After you change, ensure you patch your config to your updated code for this specific pipeline process code. Observe caution when you upgrade Fortis Nuget version for instance in the future before swapping the config file.
If I were you, I would test the below scenarios post change to ensure all is well.  Go to experience editor and click on Add Here on each of the corresponding cases in design mode.

1. A simple sitecore placeholder
2. Sitecore placeholder inside a parent placeholder
3. Simple Dynamic Placeholder
4. A Dynamic placeholder inside a Dynamic placeholder
5. Sitecore placeholder inside dynamic placeholer.
6. If possible/existing use case – Dynamic placeholder inside Sitecore placeholder

Hope this helps some one like  me. 🙂
Logged an issue on git hub page for this Nuget reference as well.

https://github.com/Fortis-Collection/dynamic-placeholders/issues/3

 

 

Did you know – Paas does not support Lucene

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.

https://doc.sitecore.net/sitecore_experience_platform/setting_up_and_maintaining/search_and_indexing/configure_azure_search

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.

Index Info

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!

 

Sitecore Shared Content Issues

On the day one, when I started my blog, I made a promise that I will share good and not so good side of Sitecore.  So far, did not find anything that was very counter intuitive up until now.

One of the main purpose of CMS is to share a piece of repetitive content so you are not changing something in ten different places when there is a need for change, you change one single datasource item that is shared across multiple pages and all pages will reflect the change when the datasource is pushed live either via a workflow based approach or through some kind of publish.

But, the stinky part is that when this specific datasource is shared across multiple pages, all pages will be in some sense updated, but, are never thrown in to a workflow of any sort, they just magically are updated on live website.   In many heavy compliance driven environments, it get’s super important to track when a page or any content living on the page has changed.  With current inherent behavior of Sitecore, there is no way to track when a page truly changed due to datasource driven modules and how the page and datasources are disconnected for many good reasons.

When asked, Sitecore mentioned that this is possible to do so by tapping and finding related items of the datasource and doing something with those layered related items.  It just seems surprising to me that this is not something that is available out of the box.

Below are few references I read up while ensuring that I am not some how dreaming or in an illusion and that Sitecore does support this behavior.  Sitecore confirmed that, nope, the page items that use a datasource that has been modified do not go through any workflow and will not be published.

https://doc.sitecore.net/sitecore_experience_platform/content_authoring/creating_and_editing_items/editing/manage_associated_content

Suggested approach is that you use the Link database and get all references as stated above which per me seems to be expensive operation especially if you do not have a workflow set on datasource templates for instance.  In which case, you will already be pushing all datasource templates as true related items when a page is published.

I would love to hear what others do in situations like this.  This feature when implemented could come in handy in many situations with all clients that are more Compliance driven due to legal aspects of the site and information they would need to track.

Example of sample approach to read from Link database is below.

Get referrers as Sitecore items through the link database