On a default Sitecore 8 installation, I have a bucket with quite a few items in it. When I issue a content search query on a RTE field in the Greek language, it seems that Sitecore treats the search term in an accent sensitive way, which is wrong for Greek.
Can someone point me to the right direction into making the index accent insensitive for Greek?
You'll want to change your analyzer. Two good options come to mind for this case, as far as how to analyze it:
Use org.apache.lucene.analysis.el.GreekAnalyzer. This will do what you're asking for, as well as add Greek language stemming. This is probably the best option, unless you really don't want stemming.
Create a custom analyzer that uses GreekLowerCaseFilter, instead of the standard lowercase filter. This filter will remove diacritics and the like, so I believe it will do what you are looking for:
public class StandardWithGreekLower extends StopwordAnalyzerBase{
public StandardWithGreekLower() {
}
#Override
protected TokenStreamComponents createComponents(final String fieldName) {
StandardTokenizer src = new StandardTokenizer();
TokenStream filter = new StandardFilter(src);
filter = new GreekLowerCaseFilter(filter);
//If you want to add a stop filter, this would be a good place for it
return new TokenStreamComponents(src, filter);
}
}
It seems that the issue was with the way Sitecore understands cultures and assigns culture execution context to its searches and indexes.
For the particular solution, we had renamed the "el-GR" language to "el" (to show "nicely" in the url). In turn, Sitecore was assigning a CultureInfo with name "el", not "el-GR". But in the defaultIndexConfiguration config file, the Greek analyzer would be assigned only when the CultureInfo of the CultureExecutionContext was el-GR, so the data was actually indexed using the StandardAnalyzer, not the GreekAnalyzer, hence the accent sensitivity.
We added extra config to cover the case where the CultureInfo has name "el" (copied the "el-GR" config node actually) and after the necessary index rebuild, everything was OK.
It is rather obscure though why Sitecore would go and alter the name of the CultureInfo object...
Related
I have following question
Item level Fallback is enabled in “Sitecore.LanguageFallback.config” and fallback/default language is “en”
Languages configured in site : en, de, el, es, fr, it, ja, pt, zh
Scenario: We try to access the site with Russian(ru) or any other language which we have not configured in sitecore . The site still loads without any error, but no contents are fetched, as the language is not configured the fallback to English language doesn’t working.
Does sitecore loads the page for all the valid languages available irrespective of languages we configure under system/languages. If Yes, then should we explicitly handle in our code to restrict this behavior or fallback to English? Or is there a way we can handle this through configuration.
This is the expected behaviour unfortunately, Sitecore will load for all languages regardless of whether you have them enabled/configured in the CMS.
You need to handle this yourself in code. On possible option is to use a similar processor to this by John West and override the StripLanguage processor.
public override void Process(PreprocessRequestArgs args)
{
if (args != null
&& args.Context != null
&& !string.IsNullOrWhiteSpace(args.Context.Request.FilePath))
{
string prefix = WebUtil.ExtractLanguageName(
args.Context.Request.FilePath);
if ((!string.IsNullOrWhiteSpace(prefix))
&& !this._validLanguages.Contains(prefix.ToLower()))
{
return;
}
}
base.Process(args);
}
By simply not stripping out the language code when interpreting request URLs, Sitecore will try resolve the item it will not find a matching ru item under your home and therefore throw as 404 as you would expect it to. (You could also redirect the user to the default language at this stage instead).
The slight down side to this is that the languages are specified in config and any changes would require a deployment. Depending on your exact requirements, you could read these in from an Item specified in the Sitecore tree if you require it to be more dynamic.
Your language fallback is not setup correctly. Read the manual at the Sitecore site.
To have a Russian version falling back to English, you need to create a Russian language (it will appear in the Languages list as in your screenshot). On that item, you can fill the Fallback Language field. Set that to English. This defines the fallback language.
In order to have your items use the item fallback (which is what you want if you don't want to create versions in Russian) you must enable that on your items. The easiest way to do so is set it in the standard values of the templates. The checkbox Enable Item Fallback must be checked for the fallback mechanism to work.
(I'm using Sitecore 8.1 Update 3 with Glass Mapper.Sc version 4.1.1.66)
I've run into an issue where some of the properties of a Sitecore item are not being populated in code through Glass Mapper. The values in our Content Base item (Id, Name, Display Name, typical Sitecore fields) seem to be getting populated correctly, but the child item's fields (I'll call it Overview) aren't mapped at all. They're all strings but they all end up null, even though the Content Base's values look to be correct. We also have child class maps working in other areas of the same, so that may not be the cause here.
Earlier in this project, we had an issue with Glass Mapper where field names that included spaces were not being read. However, I've made sure to leave out any spaces in field names, but this doesn't solve the issue.
Another possible contributor to the issue is that we have multiple languages on the site, so it's conceivable that language fallback may be complicating things. However, we have fallback enabled and working properly across the site without issues.
I can post code if needed, but for the most part, it's just POCO's and mapping classes.
Any ideas on what other parts I should be looking into?
You need to use the VersionCountDisabler(), you can find more details about it in this previous question and this blog post.
The use of the disabler is not supposed to be required on Sitecore 8.1 and when using Language Fallback, but I can confirm that this is an issue and using the VersionCountDisabler() solved the issue for us.
Internally Glass will check if a version of an item exists, if not it returns null. It seems that Sitecore will return a version count for Items with Layout, but not for datasource Items.
We have wired out the disabler slightly different than using the global.asax file, instead patching into the http request pipelines:
using Glass.Mapper.Sc;
using Sitecore.Pipelines.HttpRequest;
namespace MyProject.Custom.Pipelines.HttpRequest
{
public class ItemVersionCountDisablerBegin : HttpRequestProcessor
{
public override void Process(HttpRequestArgs args)
{
Sitecore.Context.Items["Glass::VersionCountDisabler"] = new VersionCountDisabler();
}
}
public class ItemVersionCountDisablerEnd : HttpRequestProcessor
{
public override void Process(HttpRequestArgs args)
{
VersionCountDisabler disabler = Sitecore.Context.Items["Glass::VersionCountDisabler"] as VersionCountDisabler;
Sitecore.Context.Items["Glass::VersionCountDisabler"] = null;
disabler?.Dispose();
}
}
}
And then patch this into http request begin and end pipelines:
<pipelines>
<httpRequestBegin>
<processor type="MyProject.Custom.Pipelines.HttpRequest.ItemVersionCountDisablerBegin, MyProject.Custom" patch:before="*[1]"/>
</httpRequestBegin>
<httpRequestEnd>
<processor type="MyProject.Custom.Pipelines.HttpRequest.ItemVersionCountDisablerEnd, MyProject.Custom" />
</httpRequestEnd>
</pipelines>
After some experimentation, I found the cause of the issue.
In my mapping class, you'll see this line:
config.Field(f => f.HeaderPrefix).FieldName("AssetOverviewContentHeaderPrefix");
The field name seems kinda long, right? We were prepending the category name onto the field name in order to avoid any duplicate names in items since we do a fair amount of inheritance.
That's where the problem lies. When I removed the "AssetOverviewContent" from the field names, everything worked fine. Based on this, I did some more experimentation.
I found that field names up to 23 characters long worked just fine. 24 or more and they won't map. I have no idea why this number in particular is the limit, but my guess is that there's some other mapping going on somewhere that's hitting a limit.
A little more experimentation also found that mapping using FieldId also doesn't work. Guids are going to be more than 23 characters long, so that makes some sense. However, you can't really do a guid in less than 23 characters so I can't confirm.
I may end up looking at the Glass Mapper code sometime soon to see if I can track down the answer. But now that I know there's a problem, I can avoid it.
We have two problems with 'Multilist with Search' controller.
How do we change the display field?
Currently it shows something like below.
136330 (City item - Cities) we want to display the Display name + Language
is it possible?
We have 4 different languages so, we need to filter it by the language as well. We found some resources which says that we can override it by implementing Sitecore.Buckets.FieldTypes.BucketList but we were not able to found a proper solution for these questions.
We already tried the below link but it only works on load but when we search a value the result is as mention in point 1.
How to get a Multilist with Search field to not display referenced items' version and language?
Waiting for a good answer?
Found the answers and just override the OutputString method as below for 1.
public override string OutputString(Item item)
{
return string.Format("{0} - {1}", (object)item.DisplayName,item.Fields["Postal code"].ToString());
}
And for 2 used the following code in the DoRender method.
using (new LanguageSwitcher(Sitecore.Context.Language))
sources = LookupSources.GetItems(current, this.Source);
I'm building a CiviCRM extension, which would also have an admin section with UI for setting various configuration specific to the extension. I'm looking for a recommended approach for storing the configuration in the database.
One way is to create a new table in the database specifically for this purpose, but this seems like an overkill if there are only a couple of options to be saved.
Another way could be to use the civicrm_setting table, which kind of makes sense at first, but I'm not sure if this table is meant to be used for this purpose.
Any advice would be appreciated.
Yes, you can and should definitively use civicrm_setting.
civicrm_setting has a column group_name that should contain a unique identifier for your extension. I usually put the full name of the extension, like org.example.extension but it could be any string, and in core they use label name (e.g., Preference settings).
To interact with those settings, you can do the following :
// save the setting
CRM_Core_BAO_Setting::setItem($value, 'My group name', 'my_setting_name');
// get the setting
$setting = CRM_Core_BAO_Setting::getItem('My group name', 'my_setting_name');
// get all the setting for you extension
$settings = CRM_Core_BAO_Setting::getItem('My group name');
There seems to be an API for Setting but it doesn't seem to work well in CiviCRM 4.4.x. Don't know if it is better in CiviCRM 4.5.
What you could also do (our current practice) is store your configuration logic in a special class using the singleton pattern (as CiviCRM does itslef). If you want to see an example check this:
https://github.com/CiviCooP/no.maf.oppgavexml/blob/master/CRM/Oppgavexml/Config.php
I'm using Sitecore. I want to get the full name/description of a DMS rule in programcode by Sitecore ID, for example: "Where the DayOfWeek has a value that is equal to Tuesday".
Who knows how to do this?
Thanks a lot.
Jordy
I don't know of a simple way, but the class responsible for rendering the rule text is Sitecore.Shell.Applications.Rules.RulesRenderer in Sitecore.Client.dll.
Its constructor accepts the XML from a rules field and you call the Render method, passing in a prepared HtmlTexteWriter. It also has a bunch of fairly self-explanatory private methods like RenderRule, RenderCondition etc.
I'm sure if you decompile that class you can pick out the bits you need.