There are a list of benefit of using the Helix, like keeping the module separe, upgrade point of view and so, It's highly recommend that to create the Helix structure.
Example, If we wann add a new dictionay enty which is specific to a feature, Plesae create the proper folder structure as example below
Sitecore/System/Dictionary/Feature/ABC (Module Name/ FeatureName
Same for the Core database.
Sometimes working on the feature, we forget to remove the duplicate, orphan or redundant Sitecore content item, and it got sync as part of the content serialization. So we need to make sure that those should not be part of the serialization.
It gives me an idea to create a custom PowerShell script based on the feature which takes the Sitecore serialization module configuration and checks each item if they are orphan or redundant or need any cleanup or not :)
It's general practice and recommendation that we should create the module if the site is going to be a multisite,
Sometimes we created a new variant for the existing component and missed including it under the branch template (scaffolding), so we need to update the structure based on the latest changes. Otherwise, the new site will not have all the latest changes.
It's very important as BE and FED we shoudl follow the proper naming convenstions. mostly for the BE we usually work on C# patterns but while working on the SXA feature, we need to make sure that we undrestand the basic of BEM naming convenstions.
These are the some example of good and bad practices -
http://getbem.com/naming/
Harry Roberts - This is the main reason we end up with bloated code bases, full of legacy and unknown CSS that we daren’t touch. We lack the confidence to be able to work with and modify existing styles because we fear the consequences of CSS’ globally operating and leaky nature. Almost all problems with CSS at scale boil down to confidence (or lack thereof): People don’t know what things do any more. People daren’t make changes because they don’t know how far reaching the effects will be.
Philip Walton mentioned - While 100% predictable code may never be possible, it’s important to understand the trade-offs you make with the conventions you choose. If you follow strict BEM conventions, you will be able to update and add to your CSS in the future with the full confidence that your changes will not have side effects.
Again below lines are from the Harry Roberts
There are a number of common problems when working with CSS at scale, but the major two that namespacing aims to solve are clarity and confidence:
Clarity: How much information can we glean from the smallest possible source? Is our code self-documenting? Can we make safe assumptions from a single context? How much do we have to rely on external or supplementary information in order to learn about a system?
Confidence: Do we have enough knowledge about a system to be able to safely interface with it? Do we know enough about our code to be able to confidently make changes? Do we have a way of knowing the potential side effects of making a change? Do we have a way of knowing what we might be able to remove?
There are a pleny of existing methodology to define the name like below
(Ref - http://getbem.com/introduction/)
The reason I choose BEM over other methodologies comes down to this: it is less confusing than the other methods (i.e. SMACSS) but still provides us the good architecture we want (i.e. OOCSS) and with a recognizable terminology.
<section>
<h1>Sample Calculator</h1>
<form action="test.aspx" method="post">
<p>
<input name="amount">
<input type="submit" value="Calculate">
</p>
</form>
</section>
<section class="widget">
<h1 class="widget__header">Sterling Calculator</h1>
<form class="widget__form" action="test.aspx" method="post">
<p>
<input name="amount" class="widget__input widget__input--amount">
<input type="submit" value="Calculate" class="widget__input widget__input--submit">
</p>
</form>
</section>
Here Section element is a block (widget) and
widget__form - double underscore to recongnize that form is a part of widget
widget__input - double underscore to recongnize that input is a part of widget
widget__input--amount - amount is a variant of input
the complete css class will look like this
.widget {
background-color: #FC3;
}
.widget__header {
color: #930;
font-size: 3em;
margin-bottom: 0.3em;
text-shadow: #FFF 1px 1px 2px;
}
.widget__input {
-webkit-border-radius: 5px;
-moz-border-radius: 5px;
-o-border-radius: 5px;
border-radius: 5px;
font-size: 0.9em;
line-height: 1.3;
padding: 0.4em 0.7em;
}
.widget__input--amount {
border: 1px solid #930;
}
.widget__input--submit {
background-color: #EEE;
border: 0;
}
Excellent example is here -https://www.integralist.co.uk/posts/bem/#4
References-
This is very very basic but just wanted to cover here, when we start a new feature don't involve the .sln (Solution) project as we have the main solution for the project.
I would sugget to create a new VSIX (extension template)
References -
Recently, I was doing a development and came to know that we need to make sure to use the correct version of the dependent assembley, As a example of Newtonsoft which we generally used for the custom solution/feature, We need to make sure to use the same version which is being used by the current sitecore version.
We can see the version details here
https://sitecore.myget.org/feed/sc-packages/package/nuget/Sitecore.kernel/10.0.0
Recently, We got a few issue after applying the SCS fix patch and it stopped working a few filters, Usually for any filter we have identify the field name from the Solr.
Example - Filter
Configuration name - Sitecore.ContentSearch.Solr.DefaultIndexConfiguration.config
This is happening while adding the document example as below
Here are the exact method for AddTypeMatch
Hope that will help to others to understand how Sitecore is adding the field name during the document add, It's supported out of the box in Solr after version 6.6 because of the managed schema,
I was working on creating a custom map component, while doing the implementation, I found a small spelling mistake, raised a Sitecore issue and they have mentioned that it will be fixed in upcomign release
public reference number 486264
I recently got a quick request to investigate and provide the fix for the search issue, had to download the luke and check the Lucene index.
A handy query
_fullpath:"/sitecore/templates/feature/media/parameterstemplates/xxxx"
