How to display search box in all the frontend page sidebar typo3 - search

We have developed a site with typo3 v8.7.11. We want to display the search box in the sidebar section, for this we installed the indexed_search extension. B
How to display a search box in all the frontend page sidebar section?

Edit:
The search and form action of the SearchController are both non-cacheable. This means that you would place a non-cacheable plugin on each of your pages, if you used my old answer. This harms performance and could have other side-effects.
Nowadays I usually simply include a search form on each of my pages by including this in my Fluid Template:
<form action="{f:uri.action(controller: 'Search', action: 'search', extensionName: 'indexedsearch', pluginName: 'Pi2', pageUid: searchPid)}" method="POST" role="search">
<input type="text" name="tx_indexedsearch_pi2[search][sword]" spellcheck="false" autocomplete="off" />
<button type="submit">Search</button>
</form>
I hand over the searchPid variable via TypoScript like this:
page.10.variables.searchPid = TEXT
page.10.variables.searchPid.value = <Pid where search results should be displayed>
Old answer:
My tip would be to create a TypoScript object that actually includes the plugin, like this:
lib.headerSearch = USER
lib.headerSearch {
userFunc = TYPO3\CMS\Extbase\Core\Bootstrap->run
extensionName = IndexedSearch
pluginName = Pi2
vendorName = TYPO3\CMS
switchableControllerActions {
Search {
1 = form
2 = search
}
}
features {
requireCHashArgumentForActionArguments = 0
}
view < plugin.tx_indexedsearch.view
view.partialRootPaths.10 = Path/To/Partial/
view.templateRootPaths.10 = Path/To/Template/
settings =< plugin.tx_indexedsearch.settings
}
Then, in your template, include it like this
<f:cObject typoscriptObjectPath="lib.headerSearch" />
Note that you should create a new "Search.html" Template in Path/To/Template/Search/ for this TS-Plugin, so that it does not interfere with the regular plugin. Also, be careful if you include the search slot on the same page as the search Plugin itself.

you have multiple options:
copy the HTML of the form from the search plugin in the normal content and insert it in your page-(html-)template.
create a special BE-column, insert the search-plugin into this column and render this column inherited in all pages
make a special page not visible in FE, where you insert the search-plugin and include this special CE in the rendering of every page (use a CONTENT object in typoscript to select that special CE)
include and configure the plugin in typoscript. (see answer of Thomas Löffler)
I prefer option 2 as it is most flexible and does not need any special page or content IDs, which might change with time (option 3). It also can handle any kind of CE.
Option 1 needs manual fixing if there are changes in the plugin rendering after an update for example.
Option 4 is not possible for each plugin or CEs at all to inherit. If you can configure the plugin with typoscript it is a fine option because you do not need any record (from tt_content)
for option 2:
temp.inheritedContent = CONTENT
temp.inheritedContent {
table = tt_content
select.orderBy = sorting
// -- use your own column id: --
select.where = colPos = 100
select.languageField = sys_language_uid
slide = -1
}

Use a TYPO3 extension, which can be a copy (fork) of the newly developed version of macina_searchbox
Template Module: Add "Macina Searchbox" under "include static from extensions" .
Use this or a similar TypoScript to include it, where '6' in this example is the search page. Use your own page id instead.
Constants:
lib.macina_searchbox {
pidSearchpage = 6
}
Setup:
10 = TEMPLATE
10.template = FILE
10.template.file = fileadmin/template/template.html
10.workOnSubpart = DOKUMENT
10.marks {
SUCHE < lib.macina_searchbox
LOGO = TEXT
LOGO.value = <img src="fileadmin/template/img/logo.png">
NAVI= HMENU
NAVI {
Then you can edit the Fluid template files in the folders below macina_searchbox/Resources/Private/ to modify the output of the searchbox. This method is necessary in order that the search result list will not be shown on the page. You must instead insert an Indexed Search plugin on your search page, which has id=6 in this example. SUCHE is the marker in the main template of the website. Use your own marker.

The easiest way is to copy the given plugin from indexed_search to a variable you use in your template.
When you e.g. use FLUIDTEMPLATE:
page.10 = FLUIDTEMPLATE
page.10.variable.searchBox < plugin.tx_indexedsearch
After that you can assign a separate template and make other modifications by changing page.10.variable.searchBox with the possible configuration here: https://docs.typo3.org/typo3cms/extensions/indexed_search/8.7/Configuration/Index.html

Related

Visual Studio Coded UI: Select HTML Element by CSS Selector

I have run into a problem selecting an item within Microsoft's CodedUI framework. I have a page full of items that can be added/removed via selecting a checkbox. The checkboxes do not have unique id on them, and I am having trouble selecting other than the first item when looking for a particular Tag/class combination. Is there some trick to doing this that isn't immediately obvious.
There are a couple different options here:
1. You could select the object by selecting the item related to it
<div id="parent">
<label id="checkbox1234">MyCheckBox</label>
<input checked="false"></input>
</div>
... could be selected as:
HtmlDiv parent = new HtmlDiv(browserWindow);
parent.SearchProperties["innerText"] = "MyCheckBox";
HtmlCheckBox target = new HtmlCheckbox(parent);
target.SearchProperties["TagName"] = "INPUT";
return target;
or
HtmlLabel sibling = new HtmlLabel(browserWindow);
sibling.SearchProperties["id"] = "checkbox1234";
UITestControlCollection col = sibling.GetParent().GetChildren();
foreach (UITestControl control in col)
{
if (control.ControlType.ToString().Equals("HtmlCheckBox"))
{
return (HtmlCheckBox)control;
}
}
You can use these test utilities created by Gautam Goenka. They worked wonders for me as far as identifying the content of an object and using it for assertions. Still, if you don't have any meaningful way of identifying the objects based on content, this won't help you either. When all else fails, add some useful identifying properties to the HTML.

Alloy user interface (access a tag value)

I'm working with liferay portal 6.2. And I want to get the value of the text in a tag with alloy user interface.
exemple:
<div>
<p> Paragraph </p>
"value"
</div>
the desired result is: value
please help.
AlloyUI, being an extension of YUI3, uses get/set methods to access and manipulate the properties/attributes of the object (YUI3 Node / AlloyUI Node) that is returned when looking up elements from the page.
Some examples can be reviewed in this documentation as well as this documentation.
In general you'll need something unique (i.e. id, css class) to the div in order to fetch only that element. Once you have that element, divNode.get('text') will give you all of the text within the element. There is not a means to easily "skip" the paragraph contents within the div without the value being contained within some other markup. If you have control over the markup and can do this, that would be the best option. Otherwise you are left to using the replace function to strip out the paragraph contents from the text.
<script>
AUI().use('aui-base', function(A) {
var paragraphText = A.one('#myDiv>p').get('text');
var divText = A.one('#myDiv').get('text')
var onlyValue = divText.replace(paragraphText, "").trim()
console.log(onlyValue)
})
</script>

Customize the search portlet in Plone for specific content types

I'm using the search portlet in certain areas of my website, but I'd like to restrict the results to only search for a specific content type: for example only search the news items, or only show Faculty Staff Directory profiles.
I know you can do this after you get to the ##search form through that "filter" list, but is there a way to start with the filter on, so that the "Live Search" results only show the relevant results (i.e. only news items or only profiles).
I suspect you know it already, but just to be sure: You can globally define which types should be allowed to show up in searchresults in the navigations-settings of the controlpanel, and then export and include the relevant parts to your product's GS-profile-propertiestool.xml.
However, if you would like to have some types excluded only in certain sections, you can customize Products.CMFPlone/skins/plone_scripts/livesearch_reply, which already filters the types, to only show "friendly_types" around line 38 (version 4.3.1) and add a condition like this:
Edit:
I removed the solution to check for the absolute_url of the context, because the context is actually the livesearch_reply in this case, not the current section-location. Instead the statement checks now, if the referer is our section:
REQUEST = context.REQUEST
current_location = REQUEST['HTTP_REFERER']
location_to_filter = '/fullpath/relative/to/siteroot/sectionId'
url_to_filter = str(portal_url) + location_to_filter
types_to_filter = ['Event', 'News Item']
if current_location.find(url_to_filter) != -1 or current_location.endswith(url_to_filter):
friendly_types = types_to_filter
else:
friendly_types = ploneUtils.getUserFriendlyTypes()
Yet, this leaves the case open, if the user hits the Return- or Enter-key or the 'Advanced search...'-link, landing on a different result-page than the liveresults have.
Update:
An opportunity to apply the filtering to the ##search-template can be to register a Javascript with the following content:
(function($) {
$(document).ready(function() {
// Let's see, if we are coming from our special section:
if (document.referrer.indexOf('/fullpath/relative/to/siteroot/sectionId') != -1) {
// Yes, we have the button to toggle portal_type-filter:
if ($('#pt_toggle').length>0) {
// If it's checked we uncheck it:
if ($('#pt_toggle').is(':checked')) {
$('#pt_toggle').click();
}
// If for any reason it's not checked, we check and uncheck it,
// which results in NO types to filter, for now:
else {
$('#pt_toggle').click();
$('#pt_toggle').click();
}
// Then we check types we want to filter:
$("input[value='Event']").click();
$("input[value='News Item']").click();
}
}
})
})(jQuery);
Also, the different user-actions result in different, inconsistent behaviours:
Livesearch accepts terms which are not sharp, whereas the ##search-view only accepts sharp terms or requires the user to know, that you can append an asterix for unsharp results.
When hitting the Enter/Return-key in the livesearch-input, the searchterm will be transmitted to the landing-page's (##search) input-element, whilst when clicking on 'Advanced search...' the searchterm gets lost.
Update:
To overcome the sharp results, you can add this to the JS right after the if-statement:
// Get search-term and add an asterix for blurry results:
var searchterm = decodeURI(window.location.search.replace(new RegExp("^(?:.*[&\\?]" + encodeURI('SearchableText').replace(/[\.\+\*]/g, "\\$&") + "(?:\\=([^&]*))?)?.*$", "i"), "$1")) + '*';
// Insert new searchterm in input-text-field:
$('input[name=SearchableText]').val(searchterm);
Update2:
In this related quest, Eric Brehault provides a better solution for passing the asterix during submit: Customize Plone search
Of course you can also customize the target of advanced-search-link in livesearch_reply, respectively in the JS for ##search, yet this link is rather superfluous UI-wise, imho.
Also, if you're still with Archetypes and have more use-cases for pre-filtered searchresults depending on the context, I can recommend to have a look at collective.formcriteria, which allows to define search-criteria via the UI. I love it for it's generic and straightforward plone-ish approach: catalogued indizi and collections. In contradiction to eea.facetednavigation it doesn't break accessibility and can be enhanced progressively with some live-search-js-magic with a little bit of effort, too. Kudos to Ross Patterson here! Simply turn a collection (old-style) into a searchform by changing it's view and it can be displayed as a collection-portlet, as well. And you can decide which criteria the user should be able to change or not (f.e. you hide the type-filter and offer a textsearch-input).
Watch how the query string changes when you use the filter mechanism on the ##search page. You're simply adding/subtracting catalog query criteria.
You may any of those queries in hidden fields in a search form. For example:
<form ...>
....
<input type="hidden" name="portal_type" value="Document" />
</form>
The form on the query string when you use filter is complicated a bit by its record mechanism, which allows for some min/max queries. Simple filters are much easier.

Magento - Change attribute select to dropdown list in Adv Search

I've been trying to find a way of forcing an attribute to show as a dropdown rather than a block of options but had no luck. The code current looks like this:
case 'select': ?>
<div class="input-box"> <?php echo $this->getAttributeSelectElement($_attribute) ?> </div>
<?php endswitch; ?>
Does anyone know how to make this look like a dropdown list instead?
Thanks in advance
I had the same problem earlier today and the strangest thing was that I had the attributes (drop down) with the same properties but one displaying a drop down menu and the other a multi select menu in the advanced search.
I did some testing with different settings and it turned out that in the advanced search every attribute that is a list (drop down and multi-select) and it has more than 2 options is displayed as multi-select.
I had a look at Mage_CatalogSearch_Block_Advanced_Form stored in /app/code/core/Mage/CatalogSearch/Block/Advanced/Form.php and I saw where this condition of 2 is checked. The magento core team made it like this to make sure that the 'yesno' or boolean list are displayed as dropdown.
In the above mentioned file, starting from line 173 (on the current version of magento)
is the following code:
public function getAttributeSelectElement($attribute)
{
$extra = '';
$options = $attribute->getSource()->getAllOptions(false);
$name = $attribute->getAttributeCode();
// 2 - avoid yes/no selects to be multiselects
if (is_array($options) && count($options)>2) {
. . .
If you change the number two on the last line with the number 5, advanced search will display drop down menu on every attribute that has less than 6 options.
What I did for myself is I added a new method, getAttributeDropDownElement(), bellow getAttributeSelectElement() that looks like this:
public function getAttributeDropDownElement($attribute)
{
$extra = '';
$options = $attribute->getSource()->getAllOptions(false);
$name = $attribute->getAttributeCode();
// The condition check bellow is what will make sure that every
// attribute will be displayed as dropdown
if (is_array($options)) {
array_unshift($options, array('value'=>'', 'label'=>Mage::helper('catalogsearch')->__('All')));
}
return $this->_getSelectBlock()
->setName($name)
->setId($attribute->getAttributeCode())
->setTitle($this->getAttributeLabel($attribute))
->setExtraParams($extra)
->setValue($this->getAttributeValue($attribute))
->setOptions($options)
->setClass('multiselect')
->getHtml();
}
The next thing you need to do is a small if statement within the switch of the form (see bellow) that will check the name of the attribute and base on that to call either getAttributeSelectElement() or our new method getAttributeDropDownElement(). I leave this job to you :)
case 'select': ?>
<div class="input-box"> <?php echo $this->getAttributeSelectElement($_attribute) ?> </div>
<?php endswitch; ?>
Sorry for my English...i'm french ;-)
In your admin panel, you can choose the type of your Attributes
Make sure that your attribute is declared as a list. In my Magento version, it's the third information in the attribute admin panel after code and scope.
PoyPoy
Magento has a class for generating selects available as a Mage_Core_Block_Html_Select class (/app/code/core/Mage/Core/Block/Html/Select.php).
On your design template directory template/catalogsearch/advanced/form.phtml, replace
echo $this->getAttributeSelectElement($_attribute);
With
echo $this->getLayout()->createBlock('core/html_select')
->setOptions( $_attribute->getSource()->getAllOptions(true))
->setName($_attribute->getAttributeCode())
->setClass('select')
->setId($_attribute->getAttributeCode())
->setTitle($this->getAttributeLabel($_attribute))
->getHtml();

SharePoint 2010 Two search boxes on the master page

I would like to have two search boxes on my master page.
One that would search for content and the other one that would search for people.
I see the code in the master page that searches for content:
How would i do to add another box that searches for people?
if you know or have info on how to achieve this I would appreciate it.
thank you much
W
You can do something simple which is to put an HTML text box directly in your master page. It may not be as elegant as writing a customer user control that reads the location of the Search site, but if the URL to your search results page is static then something like this might work for you:
<script type="text/javascript">
function SearchPeople()
{
var termArr = document.getElementById("SearchTextBoxPeople").value.split(" ");
var retStr = "";
for (var i = 0; i < termArr.length; i++) {
retStr += termArr[i] + "* ";
}
document.location.href = "/Search/Pages/peopleresults.aspx?k=" + retStr;
}
</script>
<input type="text" id="SearchTextBoxPeople" />
Search People
One additional benefit of this is that you can control the input to include wildcards (which are horrible out-of-the-box for people searches). The JavaScript is simply including * in the search which allows wildcard searches. So a search for jo sm will actually send jo* sm* to the search page which will then match on John Smith.

Resources