Short question - is it possible to add an (additional) search bar, with only the News being searched?
The part should be independent of the "global" search. I hope I have made myself clear.
I would like to offer a search something like this:
Search only in the news.
Thank you !
You can set one (or multiple) reference pages in your search result module. The search module will then only display search results from these pages. So if you set the reference page to your news detail page for example, you'll only see search results from the news.
Note: this applies to the most recent Contao versions. I am not sure if this feature is already present in Contao 2.11. Regardless of that, it is important that you immediately update your Contao installation to the most recent version (currently Contao 4.4 for LTS or Contao 4.7 for the newest features).
Related
I'm currently learning how to extend Sharepoint Online (ie Sharepoint Modern) and am not sure how to achieve the below, so any pointers would help.
We want to create a site to be used as a knowledge base for pages on specific subjects.
(as this site would only have these pages would it matter f it were a Team Site or a Communication site? I suspect it dsoesn't matter)
There will be multiple revisions to each page, but we would like to keep earlier versions and just flag which is the current one.
Example :
Page 1 : Introduction to company systems
Initially this would be created as Version 1, and be visible to all users.
Later we create a new,edited copy that is Version 2.
Both remain published but we want to make sure visiters are offered Version 2.
What we would like:
A way to flag the version number against each page. I assume this would normally be done by a column in a list of the pages eg column 'Version'?
A way to flag the page that is the current version. Again, a list column eg column 'IsCurrentVersion'?
Is there any way to edit these columns (ie 'Version' and 'IsCurrentVersion') from within the page rather than having to open the list and edit the list row? (eg Possibly using PowerApps?)
Is there a way so that when an editor flags a page as the current version, an automated process goes through all other version of that page, and sets 'IsCurrentVersion' to 'No', so only one page is ever seen as the current version? (eg using Power Automate?)
A way so that when a user views a page, it checks to see if it is the current version (eg by checking the list column 'IsCurrentVersion') and:
if it IS the current version it offers a link to a list of previous versions,
or if it IS NOT the current version, javascript adds a class to the page so it is obvious this is not the current version (eg, a tinted overlay, pseudo element watermark) and offers a link to the current verison (would this be done with spfx extensions)?
Finally, (this may not be needed) a way so that some users cann ONLY see the current version - -e if they manage to get the url to a page which is 'IsCurrentVersion' set to 'No', they can not open it, or it redirects them to the current version, or sets a class with styling to hide the content (the last option is least desirable as it it is easily overcome by the user).
I am hoping this is possible in Sharepoint, and showing me where to look for solutions would be fantastic.
I would like your support in order to get some help in customizing the search component in Liferay DXP 7.0 Enterprise.
I have reviewed all the available documentation but although I have found many articles about the issue, the step by step is not so clear for me.
I need to customize the native search component:
Change the input component to give suggestions while the user is typing the search terms
Change the search result page look and feel.
Anyone ever implemented anything like this?
I know this is an old thread, but StackOverflow keeps showing it as the first open question when I am navigation this particular tag...So here are some pointers, as this is a pretty broad topic...
The search is really confusing for adding customization. Mainly you have to provide some of them as contributors, using the asset framework. following the regular steps to build an asset for the asset publisher you will hit the best place to find documentation about the search contributors.
About the search page, best is to create a new page, besides the default one for extra freedom. As long you use the friendly URL /search it will a basic replacement. In this page you can add everything you need, except for translations for the friendly URL - not great. Another option is to keep the default page (which will not be visible in the build area 7.1.x, but you can edit after you search something and fall inside it).
I use typo3 7.6.10
I have crawler that index all pages and in search result are showed but crawler is not indexing the "content" of the page.
I have to write something in Configuration?
This tutorial by Xavier Perseguers tells you everything you need to do to index pages and records with Indexed Search. It was made for an older version of TYPO3 (as you can see from the screenshots) but it should work for newer releases too.
We updated our Sitecore CMS from version 6.3 to 6.6 SP2. This Sitecore version has the Intranet Module installed. Everything is working fine, but the Lucene Search doesn't seem to work properly.
There are two indexes defined. One for the whole content tree and one for the media library. The search only delivers results with media items (images, PDFs), but no pages. With the tool Luke I'm able to look into the indexes and I see the items there. But they are not in the search results on the website anymore.
I rebuilt the search indexes using the Sitecore Control Panel, but that didn't help.
As I said, it was working fine on Sitecore 6.3, but not on the updated 6.6 SP2.
Any idea what could be the problem?
Thanks in advance :)
Here is a blog post about Troubleshooting Sitecore Lucene search and indexing .
In shortcut:
Check if items are indexed correctly either using Luke.
Check if MatchAll query return page items:
SearchManager.GetIndex("your_index_name").CreateSearchContext()
.Search(new MatchAllDocsQuery(), int.MaxValue)
.FetchResults(0, int.MaxValue).Select(r => r.GetObject<Item>())
Check included templates:
<include hint="list:IncludeTemplate">
It turned out that the 3 missing fields _sclsMedia, _sclsSearchable and _scLang in the Content Lucene Index that are causing the search not to function. So I removed the 3 fields from the code in my solution and now I get search results again.
The question is why were those 3 fields lost during the update from Sitecore 6.3 to 6.6.
There is some precedent for search-engine-ranking-related questions on StackOverflow, so please don't close this question. It's programming-related to the extent that HTML META tags can be called "programming".
Here's the problem:
We make FogBugz, the software project planning and bug tracking suite.
Either we did a great job with our old documentation or a crummy job with our new documentation, but for most of the popular searches on FogBugz terms, documentation for our old versions comes up.
Here's an example. For context, our current FogBugz version is FogBugz 7. The top two results for that search are for FogBugz 5, which is positively ancient.
As best I can tell, there are several options for getting these results out of the top slots, but each has problems:
A NOINDEX tag, but what happens if someone is actually searching for help on an old version?
Finding the incoming links to the old documentation and placing a NOFOLLOW on them to deprive the old docs of PageRank. Problem here is that it's really fiddly to find the links to the content, rather than changing the content itself.
The unavailable_after tag, which is just a time-delayed NOINDEX, with the same problem of removal rather than demotion.
I just want these old documentation versions to stop competing with our current versions, without being completely unavailable.
An approach I used in the past (3 years ago)
Change the URL to your old documentation, and change your own links to point to the new url. e.g. abc.com/docs/fogzbugz/v5/xyz becomes abc.com/docs/fogzbugz/ancient/v5/xyz
Using the old URLs, implement a 301 redirection to your new v7 content. e.g. a request to abc.com/docs/fogzbugz/v5/GettingStarted.html is redirected to abc.com/docs/fogzbugz/v7/GettingStarted.html
In this way, existing links from external sites will take browsers to the latest documentation, and inform indexing robots that the page has moved.
Google will find the new links to your old documentation by indexing your site, but there will be no external links, thus reducing page rank.
Google will also find the new links to your new documentation, and as more sites link to it, its page rank will increase and so take priority.
This worked for me on a small scale (100 or so pages) site, and visitor attempts to view the old content rapidly dropped off.
If a user does land on a v5 page, how about the MSDN approach of explicitly stating the version that the page describes, and providing links to the equivalent topic in the v6 and v7 docs?
I would suggest that external links to older versions get redirected to the latest version - with some sort of note that if you really needed version 5 the link is here.
I think a lot of the problem deals with the fact that search engines give something a high rank if a lot of people are linking to a specific page. Unless you can get all the people linking to your old documentation, to link to your new documentation, then you are going to have a problem with the older documents being rated artificially high. In order to overcome this, you might need to change the way you handle documentation pages. One good way would be to always show the newest information on a particular topic, and then only by clicking on a link on the page, do you get to the older versions. Optimally, this would be the same page, with a different parameter, to state which version you want to get documentation for.
What about trying the MSDN approach? You assign a version tag to your pages. When this page is displayed, its version number is displayed as well. Users will be able to see immediately that this information is deprecated.
You may need to write some stubs for new version pages like "This problem has been resolved in the current version" so that the users don't have to think you didn't do anything in 5 years. Some writing work, some interlinking but it's doable for a limited number of problematic pages.