Search-Talk

This is a talk page for improving Search.


I have a weird effect when searching: If I search for a name removed from the Wiki, I get sites as hits which include content that has the name in the history - but not the included site directly. OK that sounds confusing. I'll try to explain. I have the page "Some page to include" which once had the text "The person is named OldName", but has been edited to "The person is named NewName". The page "Some bigger page" includes the page "Some page to include". When I now search for "OldName" I get "some bigger page" as search result (incorrectly!), but not "Some page to include" (which is correct, since OldName is not part of the current version of that page). How can I stop that false positive?

While I could erase History for the pages in question, I'd prefer a systemic approach. Deleted things are deleted for a reason, they shouldn't be found by the search. Martin Bohnet? April 04, 2021, at 08:14 PM

The search doesn't include page history. The search finds pages where every searched word (or part of word) exists, unless in quotes, then it searches for the exact phrase. If you really don't have any of the words from "OldName" in the bigger page, I suspect something prevented PmWiki to index the page, in that case it is recommended to delete the hidden file wiki.d/.pageindex and PmWiki will regenerate it. If you have recipes/addons directly modifying pages, they should save the pages with UpdatePage() not WritePage(), and if you use external programs to modify the files in wiki.d, they should update the time= page attribute, otherwise PmWiki may not reindex them. --Petko April 05, 2021, at 05:25 AM

unfortunately, recreating the pageindex does not change this behavior. I've also searched the newly generated .pageindex file for "OldName", it is not there. Martin Bohnet? April 05, 2021, at 08:18 AM

Can you make a couple of pages in the Test group to demonstrate this? Otherwise I would suspect something else comes into play -- do you have any recipes/addons that work around the search function? Can I look at the wiki? You can email me at 5ko [snail] 5ko [period] fr if you prefer to do it privately. --Petko April 05, 2021, at 08:47 AM

Thank you for your help via email - you were right, the missing space between the parts of the name were a hint towards the targets="..." area. And I mixed up 2 similar pages, that's why the regeneration didn't work in the first place. mea culpa! Martin Bohnet? April 05, 2021, at 02:12 PM

pmwiki.org lists first the pages with matching page names ("Page names:") - how can I do this on my installation? OliverBetz February 07, 2021, at 04:21 PM

I wrote a quick dirty function to do this, I am not proud of it and I haven't found the free time to review it and publish and document it. --Petko February 07, 2021, at 05:06 PM

Thanks for the information, I stay with my own quick and dirty hack then <g> OliverBetz February 07, 2021, at 07:33 PM

See https://www.pmwiki.org/pipermail/pmwiki-devel/2021-July/002423.html. --Petko July 25, 2021, at 08:54 AM


Would it be possible to restrict the search results to show only pages which the user has read access to ? I have been successful in implementing the id and password restrictions to pages however looks like an unauthorized user can still open the page when directed from the search result-Kannan

Yes, see $EnablePageListProtect. --Petko January 15, 2020, at 04:10 PM

Thank you it worked!!!


The documentation says "Whether you use the search box below, or the regular search box that appears at the top of this page, any search that you run from this page will provide the customized results."

I want searches entered in the top search box to produce the normal results, while searches entered in the custom search box to produce the customized results. But how? - RandyB November 13, 2013, at 08:59 AM

The customized results at Search are not done via (:searchbox :) directives, but by markup that handles the ?action=search directive.

Both searchboxes are "vanilla" searchboxes -- the customization comes in the page-markup.

To build a searchbox that provides custom twiddling, see the (:searchbox:) section at PageLists

MichaelPaulukonis November 13, 2013, at 02:47 PM

Thanks. This helped. I was looking for an unusual amount of control over the page body's searchbox results, with page formatting beyond the formatting of results dependent on whether the user entered the query into the normal searchbox in the page's header, or into the special searchbox in the page's body. In case this helps others: The solution I'm using for now is to specify in the special searchbox a parameter such as count=9999, which is unlikely to be entered by the user into the page header's search box query. Then before reaching the searchresults on the page I check the value of the count query in the URL, using the Request recipe. If it's the default value that I specified in the page body's searchbox, I know the user probably entered the query in the special search box, and can process the page accordingly. RandyB November 13, 2013, at 10:47 PM

Randy - it might be useful for others if you write that up as a recipe. MichaelPaulukonis November 14, 2013, at 03:40 PM

Done. See Cookbook:SearchboxRecognition - RandyB November 14, 2013, at 10:01 PM


Is there any way to search for A or B or C?

simon July 02, 2012, at 04:07 AM

No. --Petko October 06, 2012, at 07:24 PM


How can the searchbox be embedded in a line of text?

this should be on one line
[[{*$Group}/Recent changes]] - [[Site/Search | $[Search]]]: (:searchbox target=PmWiki/Search-Talk size=16 wrap=none:)
Recent changes - Search:
[[{*$Group}/Recent changes]] - [[Site/Search | $[Search]]]: (:searchbox target=PmWiki/Search-Talk size=16 wrap=inline:)
Recent changes - Search:
simon October 06, 2012, at 04:59 PM

Normally, a HTML <form> is a block level element like a <div> so it is usually on a new line. You may be able to use some CSS like display:inline or float:left to let it be on the same line.

this should be on one line
>>float:left<<
before &nbsp;
>>float:left<<
(:searchbox size=16:)
>><<
&nbsp; after

before  

  after

You could add some CSS rules to your local.css file. --Petko October 06, 2012, at 07:24 PM

This was an attempt to place the code from pmwiki.tmpl into a wiki page.[1]

(:input form action='{$ScriptUrl}/PmWiki/Search-Talk':)
[[{*$Group}/Recent changes]] - 
(:input hidden name='n' value='PmWiki/Search-Talk' :)
(:input hidden name='action' value='search' :)
[[PmWiki/Search-Talk | $[Search]]]: 
(:input text name='q' value='' class='inputbox searchbox smaller' :)
(:input submit class='inputbutton searchbutton' value='$[Search]' :)
(:input end:)

Recent changes - Search:

and then it occurred to me it would make more sense to use the searchbox directive.


How to suppress 'Results from' message
(:searchresults req=1 request=1:)

Is it possible to make searches accent insensitive?, eg "Te Tāhuhu" and "te tahuhu" return the same search result?

simon November 26, 2013, at 03:15 PM

You can define your own $StrFoldFunction, something like this:

  $StrFoldFunction = 'MyFoldFunc';
  function MyFoldFunc($str) {
    $str = utf8fold($str);   # if using UTF-8
    $str = strtolower($str); # if not using UTF-8

    $letters = array('ā'=>'a', 'é'=>'e', ); # etc., all letters
    # note: save the file with the encoding of the wiki (utf-8 or cp1252)

    return str_replace(array_keys($letters),array_values($letters),$str);
  }

Then delete the file wiki.d/.pageindex. That should do it.

Note that for this to work, these characters need to be stored as characters in your wiki source text, not as HTML entities like T&#257;huhu. And they will be stored as entities if your wiki is in an encoding that doesn't contain them, like Windows-1252. The encoding UTF-8 supports all characters. --Petko November 26, 2013, at 03:53 PM


PmWiki online search-results

How can I replicate on my website the behavior of the online pmwiki search-results, i.e. take advantage of the page-break every 100 lines?
Is it a particular page list template?,... or is it already incorporated and I have done something wrong that is preventing the correct operation? -- Frank Feb 25, 2018, at 8:50 PM

Here I use a more complex custom recipe (highlighting, then splitting per group) which I haven't found the free time to document, yet. For something less scary and already published see Cookbook:BreakPageList. --Petko February 25, 2018, at 01:54 PM

Ok, while I'm waiting for that recipe (there's no hurry), I can use the BreakPageList. Thanks. -- Frank February 25, 2018, at 04:34 PM

See https://www.pmwiki.org/pipermail/pmwiki-devel/2021-July/002423.html. --Petko July 25, 2021, at 08:54 AM


Shouldn't (:searchbox:) take "id=search" & label or aria-label directives or otherwise allow for accessibility features? Am I missing something? see https://www.w3.org/WAI/tutorials/forms/labels/ XES November 16, 2019, at 01:45 PM

The markup already produces a semantic "search" input field (not "text"[*]) with a semantic "submit" button with the label "Search". ([*] This is in the default HTML5 pmwiki-responsive skin, if yours doesn't, set $SearchBoxInputType.) We can add the aria-* attributes, but the (:searchform:) directive needs to stay backwards compatible, maintainable and documentable -- label= is already assigned; should an id= or an aria-* attributes in the directive refer to the "form", the "search field" or the "button"? So if you have to build a more complex search form with aria-* attributes, just use Forms. I'll add the aria-* and role form attributes for 2.2.121, or you could add them now by redefining $InputAttrs in config.php. --Petko November 16, 2019, at 04:23 PM

This is a talk page for improving PmWiki.Search.