The extension provides you with the following objects:
Search form
Results listing
Single item view
As the developer, you are able to decide how these objects are going to be printed on your site.
The search form is build using standard typoscript:
plugin.tx_fesearchintable_pi1 {...
form = FORM
form.dataArray {10.label.data = LLL:EXT:fesearchintable/pi1/locallang.php:label.search
10.label.wrap = |:
10.type = sword=input,30
20.type = submit=submit
20.value.data = LLL:EXT:fesearchintable/pi1/locallang.php:label.search
}
form.type = {$plugin.tx_fesearchintable_pi1.resultsPID}form.locationData = 1
form.layout = <td>###LABEL###</td><td> ###FIELD###</td>
form.labelWrap.wrap = <strong>|</strong>
form.stdWrap.wrap = <table cellspacing="2" cellpadding="4" border="0"><tr>|</tr></table>
form.wrapFieldName = tx_fesearchintable_pi1[|]
...
}
To modify the form layout, or its attributes, you need to make your changes on your own template, ie: if you want your form's fields to be of some specific style class, etc. Please refer to the TSRef manual for more information.
This is the part of the configuration which requires the most of your attention.
Important: As each table has its own fields definitions, and no standards exist between tables/content extensions, you MUST set how you want the search AND the results presentation be done.
The provided setup includes an example on how the extension should be configured to look into the tt_news table. Look at the examples.
The plugin.tx_fesearchintable_pi1.searchTables holds the configuration for the tables being searched and the output: It accepts as its properties the name of each table being searched.
These tables' names objects have a group of properties, which you can look in the reference table. They configure the SELECT query options, the results output formatting option, and the single view option.
Look at the REFERENCE table for the properties each table can have.
The plugin.tx_fesearchintable_pi1 object accepts these properties:
Property: | Data type: | Description: | Default: |
|---|---|---|---|
CMD | string | Takes three possible keywords: form, results, both. form: to generate the search form results: to generate a search result both: to generate both on the same page. In this case, the form comes first. You can also use a combination of form and results keywords. For example, if you put: form,results,form the extension would print a form, the result, and another form. Maybe usefull on results pages where you expect to have huge results sets. | both |
Limit | integer | Limit of records searched for each table | 10 |
backLink | boolean/string | Set if the extension should put a “Back” link at the end of a “single view” element. In this case, the back link uses a simple javascript link to go back: <A href=”javascript: history.go(-1)”;> If a String is used, then this would be used as the text of the link. You have to be very carefull with this as, for example, the single view of a news already offer a “back link” option. | 0 |
backWrap | wrap | Wraps the “Back” link | <div align=”center”>|</div> |
form | cObject | Search form configuration. Note: The extension default is a FORM cObject. You can put here your own form (with TEMPLATE, with HTML, etc.). In any case, you need to provide a field named tx_fesearchintable_pi1[sword] where the user can input the searched words, as the extension expects that data in a field named like that. | FORM |
searchTables | ->SEARCHTABLES.PROPERTIES | Configuration for the searched tables. Its properties have to be the table names being searched, which in turn accepts a group of properties to tell the extension how to do the search and present the output. | |
results | [array of properties which accepts stdWrap functions] | This property holds the stdWrap properties used to process the final presentation of the results. .headerWrap stdWrap for the initial header part of the results (ie: “Results for...”) .displayingWrap stdWrap for the browsing information part on the header (ie: “Displaying 23 results in 3 tables”) .keywordsWrap stdWrap for the keywords .tableListWrap stdWrap for the list of tables/count part of the header (ie: “- News: 2 records”) .tableListItemWrap stdWrap for each item on the tables/count part of the header. | |
searchAdditionalPiVars | Array of piVars=>Tags | Array of piVars => tags being used to build the SELECT query, that should appear on the “Search for” message at the beginning of the result list. IT DOESN'T ALTERS THE SEARCH RESULT. ONLY THE MESSAGE. By default, the “Search for [keywords]” message that appears at the beginning of the search result, only shows the keywords being used by search. It may happen that you use other variables as well (look at the example about how to add an “Authors” field to your search form). In these cases you may whish to tell your user which other variables where used. Use this property to tell the plugin to add this to the message. Example: .searchAdditionalPiVars { author = Author } | |
searchAdditionalPiVarsWrap | wrap | Wrap for the searchAdditionalPiVars items | with | as |
debugRecordFields | boolean | If set, instead of giving the search result, the extension will provide the developer with a list of the fields of the searched tables. This is a feature to let the developer know which fields from the table he has available, without needing to go to the database or the config tool. Useful when debugging. | 0 |
[tsref:(plugin.tx_fesearchintable_pi1 )]
“searchTables.PROPERTIES”
Property: | Data type: | Description: | Default: |
|---|---|---|---|
[tableName] | boolean | Has to be set to 1 for the search be done in the table | |
[tableName].name | string | Name used at the beginning of the results listing for this table. | |
[tableName].fields | string | Comma separated list of the fields of this table where the search will be conducted. | |
[tableName].pidList | string | Comma separated list of the page's uid where the searched records should be located. | |
[tableName].recursive | int | Recursive level for the search on the pages on the pidList. | |
[tableName].orderBy | string | ORDER BY clause. Do not include “ORDER BY” nor the table name. | |
[tableName].selectAdditionalParams | string/stdWrap | Additional parameters passed to the SELECT query. Except for the LIST clause, you should be able to put additional WHERE conditions. This property accepts stdWrap functions, so you are able to include more select criterias to your queries: You could add a fields on your form for this purpose. | |
[tableName].listHeader | cObject | Configures how will the header for this table's part of the results list will be presented. Useful if, for example, you would like to add some special icon, etc. plugin.tx_fesearchintable_pi1.searchTables {tt_news.listHeader = COA tt_news.listHeader {10 = TEXT 10.value = News 10.wrap = <h3 style="background-color:#FFCC66; color:white; padding: 4px">|</h3> } } | |
[tableName].listItem | cObject | Configures how each single results item for this table's part of the results list will be presented. If you want each item on the result list to have a link so the single view of the item is presented to your user by the this (“Search in Table”) extension, be sure to add the following vars to your links: tx_fesearchintable_pi1[sTable]= with the table named tx_fesearchintable_pi1[sUID]= with the uid of the record. | |
[tableName].listStdWrap | stdWrap | StdWrap properties for the whole results list. | |
[tableName].singleView | cObject | Configures how the single view for items of this table will be presented to the user if he/she selects an item from the results list. |
Searching inside the News:
The extension includes the following example, a configuration to search in the News (tt_news) table, which is being breaked at this document to include some explanations:
plugin.tx_fesearchintable_pi1 {...
searchTables { #### TT_NEWS is provided as an example###
basic setup for the table:
tt_news = 1
tt_news.name = News
tt_news.fields = title,short,bodytext,keywords,author
tt_news.pidList =
tt_news.recursive =
tt_news.orderBy =
tt_news.selectAdditionalParams = AND 1=1
listHeader setup for the table:
It is a standard cObject. You should try to use the same listHeader for each table, changing only the title to reflect the table's name, to keep an uniformed presentation.
tt_news.listHeader = COA
tt_news.listHeader {10 = TEXT
10.value = News
10.wrap = <h3 style="background-color:#FFCC66; color:white; padding: 4px">|</h3>
}
listItem setup for the table:
It is also a standard cObject configuration. Same considerations as with listHeader should be taken to guarantee an uniformed presentation.
tt_news.listItem = COA
tt_news.listItem {stdWrap.wrap = <li>|</li>
10 = TEXT
10.field = title
10.wrap = <strong>News: </strong><strong style='color:#006699;'>|</strong><br>
20 = TEXT
20.field = short//bodytext
20.crop = 40|...
30 = TEXT
30.value = more<font size=1>></font>
Typolink:
The next lines creates a link using standard typoscript.
The way it is created assumes that you are NOT using Real URL, but the default “index.php?id=” method. If you are using Real URL, please consider modificating the next line to include a “?” at the beginning of the url variables.
30.typolink.parameter.data = TSFE:id
30.typolink.wrap = <strong>|</strong>
30.typolink.ATagBeforeWrap = 1
// we add the tx_ttnews[tt_news] var as this one is the used by the tt_news extension to recognize the uid on single view.
30.typolink.additionalParams.dataWrap = &tx_fesearchintable_pi1[sTable]=tt_news&tx_fesearchintable_pi1[sUID]={field:uid}&tx_ttnews[tt_news]={field:uid} }
tt_news.listStdWrap.wrap = <ol style="margin-top:-10px">|</ol>
single view setup for the table:
In our example, the .singleView property (below) takes advantage of cObject “plugin.tt_news”, so we take care to pass the tx_ttnews[tt_news] var in our link, as the tt_news plugin expects that variable to recognize the single record to show.
tt_news.singleView < plugin.tt_news
tt_news.singleView.code >
tt_news.singleView.code = SINGLE
}
...
}
We could have decided other ways of rendering the Single View of the News record, instead of configuring the “.singleVew” option:
For example, you can decide to send the user to the page which you already have configured to view the single news, like this:
plugin.tx_fesearchintable_pi1.searchTables {...
tt_news.listItem.30.typolink.parameter.data >
tt_news.listItem.30.typolink.parameter = 135
tt_news.listItem.30.typolink.additionalParams.dataWrap = &tx_ttnews[tt_news]={field:uid}...
}
In this example, 135 is the uid of the page which I have already configured to show single news, and the additional parameter adds the needed url var for this to work.
Using the above example, you should be able to do the same with other extensions that allow single view.
Searching in many tables
To search in many tables you need to write the proper setup configuration. For example, to search at the News table AND the Modern FAQ table, you need to write something like this:
plugin.tx_fesearchintable_pi1 { searchTables {### Modern FAQ -> tx_irfaq_q###
tx_irfaq_q = 1
tx_irfaq_q.name = FAQ
tx_irfaq_q.fields = q,a
tx_irfaq_q.pidList = 182
tx_irfaq_q.recursive = 0
the Modern FAQ has 4 tables, and the faqs are held on the “tx_irfaq_q” table.
The Modern FAQ table has many fields, and the fields where the questions and answers are kept, are named “q” and “a” respectively.
We had to put the property .pidList = 182, as there is where our FAQ are held.
We write our results listing header for the section:
tx_irfaq_q.listHeader = COA
tx_irfaq_q.listHeader {10 = TEXT
10.value = FAQ
10.wrap = <h3 style="background-color:#FFCC66; color:white; padding: 4px">|</h3>
}
which prints like this:
and write how each search result item has to be presented:
tx_irfaq_q.listItem = COA
tx_irfaq_q.listItem {stdWrap.wrap = <li>|</li>
10 = TEXT
10.field = q
10.wrap = <strong>FAQ: </strong><strong style='color:#006699;'>|</strong><br>
20 = TEXT
20.field = a
20.crop = 40|...
30 = TEXT
30.value = more<font size=1>></font>
30.typolink.parameter.data = TSFE:id
30.typolink.wrap = <strong>|</strong>
30.typolink.ATagBeforeWrap = 1
30.typolink.additionalParams.dataWrap = &tx_fesearchintable_pi1[sTable]=tx_irfaq_q&&tx_fesearchintable_pi1[sUID]={field:uid}}
tx_irfaq_q.listStdWrap.wrap = <ol style="margin-top:-10px">|</ol>
The final result is like this:
The “more” link is a standard TEXT cObject, and could be easily configured to accept languages using standard stdWrap functions. Look that in the FAQ example, we decided to render the single element using our own cObject:
tx_irfaq_q.singleView = COA
tx_irfaq_q.singleView {10 = TEXT
10.field = q
10.wrap = <h3>|</h3><br>
20 = TEXT
20.field = a
20.wrap = |<br><br>
}
Finally, we put the TT_NEWS configuration, shown in the previous example, so the search can be performed on both tables.
The final search result would look like this:
Using additional parameters to build the SELECT query:
Suppose you need to allow your users to have other options to build their query. For our example, you whish to allow your user to have a preselected options for their search. In our example, your page has a group of news authors, and, as they can be misspelled, you whish to facilitate your users with a list of their names.
The first step would be to modify your Search Form:
[...]
form = FORM
form.dataArray {10.label.data = LLL:EXT:fesearchintable/pi1/locallang.php:label.search
10.label.wrap = |:
10.type = sword=input,30
15.label = New's Author
15.type = author=select
15.value = Carlos Chiari=carlos, Jhonny Smith=jhonny
20.type = submit=submit
20.value.data = LLL:EXT:fesearchintable/pi1/locallang.php:label.search
}
form.type = {$plugin.tx_fesearchintable_pi1.resultsPID}form.locationData = 1
form.layout = <tr><td>###LABEL###</td><td> ###FIELD###</td></tr>
form.labelWrap.wrap = <strong>|</strong>
form.stdWrap.wrap = <table cellspacing="2" cellpadding="4" border="0">|</table>
form.wrapFieldName = tx_fesearchintable_pi1[|]
[...]
At form.dataArray.15, we have included a select field. The ouput would be like this:
Another cool option would be to write a small script to generate the value of this field, and take advantage of the stdWrap properties of the “value” object to generate the values for this field from a database. Yet, this goes beyond the scope of this little example to explain!
The second step would be to build our query with the selected author, using the .selectAdditionalParams, like this:
[...]
tt_news.selectAdditionalParams = AND tt_news.author LIKE '%{GPvar:tx_fesearchintable_pi1|author}%' tt_news.selectAdditionalParams.insertData = 1
[...]
The third step is to add the additional variables to the “Search for” message, at the beginning of your results list, using this in your typoscript:
[...]
searchAdditionalPiVars {author = author
}
[...]
The result:
