OJS OCS OMP OHS

You are viewing the PKP Support Forum | PKP Home Wiki



Search question

Open Harvester Systems support questions and answers, bug reports, and development issues.

Moderators: jmacgreg, michael, John

Forum rules
Developer Resources:

Git: You can access our public Git Repository here. Comprehensive Git usage instructions are available on the wiki.

Bugzilla: You can access our Bugzilla report tracker here.

Search: You can use our Google Custom Search to search across our main website, the support forum, and Bugzilla.

Questions and discussion are welcome.

Search question

Postby Harold » Thu May 31, 2007 10:03 am

Hi,

It seems that Search fields are there either by default or because they are present in the source data. There are some DC fields (eg Source, Rights, etc) which we don't need to offer search against, even if they are present in the underlying harvested data. Is there a way of configuring the Search page to restrict the fields which are offered for search?

On a related note, I notice that DC:Abstract and DC:Description are both referred to in locale.xml and elsewhere in the code. I didn't think that Abstract was a Simple OAI DC field. All our data providers use Description for their abstracts. Is there a way of cutting DC:Abstract out of our application? (Or, at the very least, cutting it out of Search - see above!)

Many thanks.
Harold
 
Posts: 17
Joined: Fri May 18, 2007 6:34 am

Postby asmecher » Thu May 31, 2007 10:24 am

Hi Harold,

This is accomplished easiest by removing the relevant fields from the Search form template; for example, the following snippet from templates/search/advancedSearch.tpl is responsible for displaying the coverage field:
Code: Select all
<tr valign="top">
        <td class="label"><label for="coverage">{translate key="search.coverage"}</label></td>
        <td class="value"><input type="text" name="coverage" id="coverage" size="40" maxlength="255" value="{$coverage|escape}" class="textField" /></td>
</tr>
Commenting out this entire snippet with Smarty's commenting tags, {* and *}, will remove the coverage field. (I'd suggest doing this rather than just deleting the code, as you'll have an easier time upgrading via patch to the next release of OJS when it comes out.)

While it's possible to configure the submission and metadata forms with the metadata fields you want to include, it's not possible to configure the search form via the UI. We might change this in a future release to accommodate cases like yours without imposing the need to make code modifications.

OJS's OAI data provider code does indeed serve up abstracts using the dc:description tag.

Regards,
Alec Smecher
Public Knowledge Project Team
---
Don't miss the First International PKP Scholarly Publishing Conference
July 11 - 13, 2007, Vancouver, BC, Canada
http://ocs.sfu.ca/pkp2007/
asmecher
 
Posts: 8842
Joined: Wed Aug 10, 2005 12:56 pm

Postby Harold » Thu May 31, 2007 11:44 am

That's very helpful again. Thanks for your patience.
Harold
 
Posts: 17
Joined: Fri May 18, 2007 6:34 am

Search - follow-up - harvester2

Postby Harold » Mon Jun 04, 2007 3:30 am

Now we've come to look at this, I think you may have answered the question for OJS rather than Harvester2. Harvester2 doesn't seem to have an advancedSearch.tpl.

Can I ask the question again? Is there something we can do in templates/search/index.tpl to suppress certain useless fields from the advanced search screen?

Thanks again.
Harold
 
Posts: 17
Joined: Fri May 18, 2007 6:34 am

Postby asmecher » Mon Jun 04, 2007 9:51 am

Hi Harold,

My mistake -- yes, those instructions apply to OJS and OCS.

To suppress fields in the Harvester, look for the loop that iterates through fields in templates/search/index.tpl:
Code: Select all
    {foreach from=$fields item=field}
To suppress a field by name, add a second line:
Code: Select all
    {foreach from=$fields item=field}
        {if $field->getDisplayName() != 'Coverage' && $field->getDisplayName != 'Type'}
Then find the end of the foreach loop:
Code: Select all
    {/foreach}
</table>
Add the matching end if before the end of the foreach loop...
Code: Select all
        {/if}
    {/foreach}
</table>
The above example suppresses the fields named "Coverage" and "Type".

Regards,
Alec Smecher
Public Knowledge Project Team
---
Don't miss the First International PKP Scholarly Publishing Conference
July 11 - 13, 2007, Vancouver, BC, Canada
http://ocs.sfu.ca/pkp2007/
asmecher
 
Posts: 8842
Joined: Wed Aug 10, 2005 12:56 pm

Postby Rob » Mon Jun 11, 2007 4:20 am

Hi Alec,

I've tried implementing the code you've provided Harold with and it doesn't seem to be taking effect (I've re-started Apache).

Can I double-check with you that I've added it correctly, i.e. in /templates/search/index.tpl I've opened the if statement as follows:

Code: Select all
     {foreach from=$fields item=field}
        {if $field->getDisplayName() != 'Coverage' && $field->getDisplayName != 'Type'}   
           {assign var=fieldType value=$field->getType()}
                {assign var=fieldId value=$field->getFieldId()}
                {if $importance !== null && $field->getImportance() < $importance}
                        {* This field isn't important enough. Don't display it. *}
                {elseif $fieldType == FIELD_TYPE_DATE}
                        {assign var=fieldValueFromVar value=field-$fieldId-from}
                        {assign var=fieldValueToVar value=field-$fieldId-to}



and finished it like so:

Code: Select all
 <td class="value" colspan="2">
            {assign var=fieldValueVar value=field-$fieldId}
               <input type="text" id="field-{$fieldId}" name="field-{$fieldId}" size="40" maxlength="255" value="{$fieldValueVar|get_value|escape}" class="textField" />
                                </td>
                        </tr>
                {/if}
             {/if}   
  {/foreach}
</table>


Thanks,

Rob
Rob
 
Posts: 3
Joined: Mon Jun 11, 2007 3:53 am

Postby asmecher » Mon Jun 11, 2007 9:10 am

Hi Rob,

That looks OK to me -- can you double-check that your web server has sufficient permissions to administer all files in the cache directory (including subdirectories)?

Regards,
Alec Smecher
Public Knowledge Project Team
---
Don't miss the First International PKP Scholarly Publishing Conference
July 11 - 13, 2007, Vancouver, BC, Canada
http://ocs.sfu.ca/pkp2007/
asmecher
 
Posts: 8842
Joined: Wed Aug 10, 2005 12:56 pm

Postby Rob » Thu Jun 21, 2007 7:23 am

Hi Alec,

In the end I've taken a slightly different approach as follows:

Code: Select all
{if $field->getDisplayName() == 'Publisher' || $field->getDisplayName() == 'Type' || $field->getDisplayName() == 'Title' .....etc.}


This code displays the fields I want to see in the search interface but I'd also like to change their order. It looks as though they're sorted by field ID - is there an easy way of changing this?

Thanks,

Rob
Rob
 
Posts: 3
Joined: Mon Jun 11, 2007 3:53 am

Postby asmecher » Thu Jun 21, 2007 9:32 am

Hi Rob,

The search form doesn't specifically sort the fields, so they typically appear in the order that the first metadata harvest for that schema supplied them in. The easiest way to provide your own sort order will require a little bit of monkeying around in the database:
  • Add a new column to the raw_fields table in MySQL:
    Code: Select all
    ALTER TABLE raw_fields ADD COLUMN seq INT;
  • Sort by this field in classes/field/FieldDAO in the getFields function. Change approx. line 203 from:
    Code: Select all
    'SELECT * FROM raw_fields' . (isset($schemaId)?' WHERE schema_plugin_id = ?':''),
    ...to...
    Code: Select all
    'SELECT * FROM raw_fields' . (isset($schemaId)?' WHERE schema_plugin_id = ?':'') . ' ORDER BY seq',
  • In MySQL, assign a value for the new "seq" column that reflects the order you want things to appear in. To get a list of fields:
    Code: Select all
    SELECT name, raw_field_id FROM raw_fields;
    Then assign values using the listing generated:
    Code: Select all
    UPDATE raw_fields SET seq = 2 WHERE raw_field_id = 8;
    UPDATE raw_fields SET seq = 3 WHERE raw_field_id = 9;
    UPDATE raw_fields SET seq = 4 WHERE raw_field_id = 10;
    UPDATE raw_fields SET seq = 5 WHERE raw_field_id = 12;
It's not strictly necessary, but I'd suggest adding the new column to the Harvester's XML schema descriptor (dbscripts/xml/harvester2_schema.xml) so that when it comes time to upgrade you'll have a proper record of the changes you've made.

Hope that helps...

Regards,
Alec Smecher
Public Knowledge Project Team
---
Don't miss the First International PKP Scholarly Publishing Conference
July 11 - 13, 2007, Vancouver, BC, Canada
http://ocs.sfu.ca/pkp2007/
asmecher
 
Posts: 8842
Joined: Wed Aug 10, 2005 12:56 pm


Return to Open Harvester Systems Support and Development

Who is online

Users browsing this forum: Bing [Bot] and 2 guests

cron