I need to implement content site search based on sitecore API.
I know how to set up crawler for Lucene.Net, but this would be some kind of search by predefined template, I need to implement search by result content (final html), it should works like close to google search. Is is possible to do in sitecore ?
Thanks.
If you want the search to be based on the rendered HTML (are you really sure about that), some custom magic is required.
Crawling the content is needed in such case, thus if the publised item is visitable (has an URL), you can use the HTMLAgility framework to get the HTML, strip the tags and add the content to the index in any (new) field you like...
Related
A client is using Sitecore 9 - we are not Sitecore developers.
We've been asked a simple thing: add social media links to the Footer of their Sitecore site.
Its proving more difficult than expected.
I've added the links on other pages by editing the HTML directly via the WYSWIG editor.
But the Footer appears more restricted, only accepting the addition of templates like 'Link'.
The 'Link' template has an option to add an external URL but doesn't have an option to add an image.
The CMS looks like this:
Is there any way to add a link, with an image, via the CMS (without the need to write Sitecore code), so the page chnages from this:
to this:
If you dont want to write Sitecore code, maybe you should think about using frontend.
Find the views that holds the footer (probably Foundation/Footer.cshtml) or something like that.
-To easily find where it is, follow these steps
Go to a content page Presentation Details that has footer (probably any)
Go to Controls
Find the footer rendering in there
Click on it
Grab the Datasource's value
Go to the Datasource's path
There should be a field holding the value of the view.
Add some css class on the div that holds those items, and do your frontend stuff in there...
It is not a scalable solution, so I would highly recommend updating the Footer rendering by adding new fields and adapting the model/view. So that way a content editor could easily add a new value for each socials.
I'm a greenhorn with typo3 templating. Actually I'm using "bootstrap_package" (standard layout). I would like to create a sub-page without logo, menu and footnote. I just want to have the content elements on a blank page. How do I do this? Can anyone help me?
Best regards
cgroughy
You should give some more information why you need such a special rendering to get some more detailed help.
The usual reasons for such a page are design flaws as there are more suitable solutions inside TYPO3.
In general: You need to create a new page rendering, where you switch off the generation of the HTML header.
add on:
make a page where you collect all the pages which should be available in this special rendering. This page should be a subpage from your root-page. regarding relaurl: [x] exclude from path
in this page create a typoscript template record.
as these pages need only one rendering I propose to modify the default page object instead of creating a new page object (with a new typeNum).
in the setup field of this template record remove all headers with:
config.disableAllHeaderCode = 1
You might need to disable further CSS and JS, especially if they are loaded at the end of the page.
if you need another html-markup than the default you can modify the configuration here: wraps, (fluid-)templates, ...
Then add your special pages with content.
I used to implement listing/detail scenarios using wildcard items, meaning that, for the sake of URL, I create a regular item to display the list and then under that node, I create a wildcard item to represent all possible detail pages, like:
/news/*
(i generate a friendly name by code to replace wildcard and produce the full URL such as: mywebsite.com/news/the-meeting-press-release)
Then I create a folder or a bucket of content items somewhere else as my repository. Then I assign same datasource to listing node and wildcard node to give them same repository of content items.
Main reason I want to do this is to use datasources and make navigational nodes (which generate actual pages and URLs) to be separate from Content folder structure. In other words, separation of concerns: navigational items as presentation nodes and content items as my data repository.
This is an easy way to work around master/detail requirements but I always feel guilty about this, it feels like this technique breaks integrity (sitecore links table on database) and design pattern in Sitecore back-end.
For example when I look at Analytics, I get * as name of items, clearly the it feels like aliens to back-end system.
I know this is not a new topic. I have seen threads like this or ideas like Sitecore Pipeline Processor for Virtual Items to implement such requirements.
Is there any best practice about this? Have anyone good example of what is most sitecore-friendly way to implement such pipeline processor? How do you address this issue with wildcards on Analytics?
I'm going to go a different way to Martin here. I have successfully used Wildcards many times for the exact purpose you are suggesting (For an example have a look at http://www.atpworldtour.com/news - all news articles are items in a bucket with a wildcard to resolve the url).
There are 2 options to enabling the page editor.
The news article item becomes the page. In this way, you need a new processor in the httpRequestBegin pipeline that resolves the url to the item and then sets Sitecore.Context.Item to the current item. IIRC you do this by setting one of the pipeline argument properties. This will work fine in the page editor as the context item - the one being edited - is the news article. And then other renderings on the page can just use data sources as needed.
The news article resolves to a Datasource. I have also tried this method. To do this, you need a custom Datasource resolver. I sill used a processor in the httpRequestBegin pipeline so that I didn't have to resolve the Url multiple times for each rendering that needed the datasource. But then in the RenderRendering pipeline I had a processor that detected if I wanted a wildcard Datasource and used the item that had been resolved in the httpRequestBegin processor.
There are pros & cons for each method.
Option 1 is nice and simple. It means that you could use a single wildcard to resolve different "types" of page item as the presentation is on the page item and not the wildcard item, also each item can have its own custom presentation, so Datasources set in the page editor would be unique to an article. That is also a disadvantage in someways. A/B testing becomes more difficult with main article text etc... You are limited to testing article versions.
Option 2 is more flexible in the testing area - you can easily test/personalize parts of the article by changing the Datasource. But you are more limited as the presentation must be set on the wildcard. So renderings that are not part of the main article will have the same content/settings across all news articles.
I was previously in the same boat as you are. The are few issues with wildcard items, like resolving datasources or disability to run a page in Page(Experience) Editor or nested wildcards. Regardless of that, I have used wildcard few times and they do their job.
I've managed to resolve datasources properly, based on URL (see blog post: Automatically resolving correct Datasources for wildcard items based on URL), still did not sort the rest others.
Update: Richard suggests the way of implementing Page Editor below, you may find this helpful
Thus, my answer would be:
I would recommend you to keep classical approach of having a page item for each news item, rather than using wildcards. Content authors would use habitual approach (and page editor) rather that editing datasources somewhere on the content tree in Content Editor. If you configure that properly with templates and standard values - there would minimal hassle to create new news article.
In case if you worry about potential raise of number of news articles - use Buckets along with it (or suggest manual strategy to group them into folders).
We have a requirement to implement tooltips for words that are authored in Sitecore RTE.
The idea behind is that user should be able to hover over the word and see it's description/meaning.
Is this possible to achieve in sitecore? Did a quick search on marketplace but could not find any modules.
Below are some options to consider for achieving what you described.
Inject Tooltip HTML in a renderField pipeline
In this option, you would extend the renderField pipeline. First, you will need to ensure that you are dealing with a rich-text field, and if so, locate terms and replace them with the necessary markup that is required for the tooltip. This could be as simple as wrapping the word in an <abbr> or perhaps a <span> element with a CSS class. The list of terms and tooltip content could be sourced from items in Sitecore or a custom Sitecore Dictionary. Caching the terms would be essential as this pipeline processor is invoked frequently every time a field is rendereded.
Progressive enhancement with JavaScript
This approach is almost entirely based on the client-side. Terms could be located and replaced fairly easily with the help of JQuery. If the list of terms is of a reasonable size, they could be bootstrapped into a JavaScript variable. Once terms are located and enhanced, a separate, asynchronous call to a REST endpoint could be made when hovering or clicking the term. The API would accept a term and respond with the term's definition.
HTML Snippet in RTE Editor
Sitecore RTE editor can be extended with additional buttons. One of these options allows you to insert predefined snippets of HTML. The RTE editor also has a setting to specify a CSS file to style the content within the field (<setting name="WebStylesheet" value="/css/yourstylesheet.css" />). Styling would be necessary in order to target the description markup and make it visible to be edited, whereas, on the public site, the description markup would normally be hidden by default until the term is clicked on or hovered over.
Dynamic Link Replacement
http://www.layerworks.com/blog/sitecore-token-replacement
For a website we're working on, we had a pretty complex design to support. So, we chose the strategy where all content on each page is made up of components. Authors can insert various components such as a heading, rich text block, images, etc, allowing them flexibility in laying out pages. This was the only away we could support the complex design that was created.
This set up is working well except when it comes to versioning and search. When pages are versioned, the components on the page are not. When items are indexed for search, the components on the pages are not being indexed as part of the page. We think we may be able to solve the search issue with a custom search index, but the versioning issue seems much more complex.
Has anyone else faced these issues or have thoughts on solutions? We're on Sitecore 7.5.
A simple answer would be to upgrade to version 8 as soon as its released as version 8 will add versioning to the renderings field.
My Guess is that you are setting the content of the fields on the rendering parameters of each item? If that is the case I would suggest taking a slightly different approach. Use DataSources. You could have a few templates that hold the data, e.g. RichTextTemplate, SingleLineTextTemplate, ImageTemplate - all with a single field in, then when you add a heading or rich text block to the page, setup the rendering to all the editor to create the data source.
This way all the content can be versioned properly and you are still separating your content and presentation.
To keep the tree un-cluttered, we use an "Assets" folder under the item for all content:
Example Tree:
Sitecore
Content
Home
Assets
Page 1
Assets
Heading
Rich Text Block
Page 2
Assets
Heading
Rich Text Block
Image Block
etc...
The search problem sounds similar to this post: How to index sub-content in Sitecore with Lucene?
That suggests a computed field. In your computed field, check that your template is a page and then get all the renderings for that page. Once you have those, get the renderings DataSource items and you can build a big search field using the content from the DataSource item's fields.
This would save having an extra index with a custom access layer. It all stays within the Sitecore API.