Assuming you have a running Umbraco website and managed to install the Solis Search Umbraco package without errors, and a running Apache Solr installation, you need to do the following
The manual step you have to do is to copy schema.xml and solrconfig.xml located in the /userscontrols/SolisSearch/Apache Solr folder to the conf folder of your Apache Solr instance index. If you use the example instance in the Apache Solr distribution using Jetty the path is [Apache Solr folder]\example\solr\collection1\conf, and then restart Apache, now Apache will be configured as required for Solis Search.
Edit the SolisSearch.config in the config folder of your Umbraco installation, and verify that the address of the SolrServer section is correctly pointing to your Solr instance.
Then check the DocTypes section. The doctype named ”default” is a fallback doctype, so if you want the property bodyText to be indexed for all pages regardless of doc type, you can use the default doc type. You can add other properties you want indexed to the default doctype or define other DocType sections for your specific doctypes in your project.
Log in to Umbraco and click on the root node ”Content” in the content tree in the content section, you should see a tab called Solis Search. Activate it and if no error message is displayed you are connected to the Solr instance, and if you have content on your site you can click the Rebuild index button, to see that indexing is working.
That’s it to get started! If the index is rebuilt properly you can now start developing your search page and publish to your website, example Razor code is published on our docs, https://www.solissearch.com/documentation/#development, but mainly you use the SearchRepository in SolisSearch.dll, so add that as reference to your project.
The main reason to use Solis Search is that your project has need for the features available in the search server Apache Solr. Apache Solr provides language support with word stemming, search facets, “did you mean”-functions etc. Solis Search creates a link between Umbraco and Apache Solr and adds some nice features like security aware indexing, auto complete and rich text document indexing from different type of Umbraco or Episerver properties. Using Solis Search, you get many advanced search features that modern websites requires to be competitive and give your users a good experience when visiting your website, with very short development time.
Solis Search does index file content from richtext documents like pdf, word, excel, etc. We have implemented so that only published documents are indexed. When you publish a document, either as a href in a richtext-editor or using a related media-property, Solis Search analyses if the document is from the media-section, and if so stores it in the index. This means that your editors can safely upload media to the media section without it being searchable until it is actually published somewhere on the website.
Yes, that is correct, but with some limitations. Since there is no support for configuring security on the media-section in Umbraco, Solis Search store the media content in the index with the security settings from the page it was published on. If your media-content is only published on one page, it’s not a problem, only users with access to that page will get the content in the search result, but if it is published on another page with other security settings there will be a conflict in the security settings that could make the content disappear from the users on the first page it was published on.
This is something we are looking into to find a proper solution for, to join the security settings for all pages the media content is published on. This could be an issue for Intranet solutions where you have serveral member groups accessing different parts of the website. If your solution is only with one member group vs unauthenticated or similiar ”simpler” security settings the solution works fine
UPDATE 2015-04-01: This error was caused by a missing assembly that was used in the IoC in the SolrNet library, these assemblies have been included in all packages from version 2.0.101.437 of Solis Search.
The dynamic object is always internal so it can only be accessed by its own executing assembly and we are not sure right now how the SolisSearch dlls are causing this error, but the simple work around is to use the strongly typed objects in your views and macros instead, meaning instead of using CurrentPage object, use Model.Content, e.g. to get the children for the the current node you use Model.Content.Children instead of CurrentPage.Children.
Also note that it only seems to be the Linq-functions that breaks, look at the working example below. Here we use the strongly typed object to see if there exists any children. When I know that there is children and I loop through them with foreach, we use the dynamic object where the properties work for each individual node, e.g. childPage.Name. So you don’t have to update your views completely for the workaround, only where you use the Linq functions.
@if (Model.Content.Children.Where("Visible").Any())
{
<ul>
@* For each child page under the root node, where the property umbracoNaviHide is not True *@
@foreach (var childPage in CurrentPage.Children.Where("Visible"))
{
<li>
<a href="@childPage.Url">@childPage.Name</a>
</li>
}
</ul>
}
Yes, you only need a license for production sites, so you purchase a license for the production-status site and you can use the same username and key for the dev and stage to remove the unregistered warning in the title.
The spellchecker understands many languages but the datasource for the spellchecker is only indexed content, it will never suggest a word that wouldn’t make a search hit on the site, so if the correctly spelled word is not part of the content, it will never be suggested.
The Breadcrumbs property of the CmsSearchResultItem entity would help. It contains an array of strings with Node id, Node name and Url semicolon separated for the node path.
There is a bug in Apache Solr that was introduced in version 4.7. See status here https://issues.apache.org/jira/browse/SOLR-6475
They’ve managed to break the automatic mime detection from rich text documents therefor you get this error. For now use an earlier version than 4.7 of Apache Solr until this bug is resolved, hopefully it won’t take long, it has status “major”.
UPDATE: Issue is resolved in Apache Solr 5.0, upgrade to latest version of Apache Solr
