Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#109 2023-10-17 11:20:34

etc
Developer
Registered: 2010-11-11
Posts: 5,021
Website GitHub

Re: etc_search: when the default search is not enough

I have quickly updated etc_search (download) to fix a bug with complex queries. This custom-type query should work now, please test:

SELECT 'article' AS type, Excerpt AS description, Posted AS posted FROM textpattern WHERE {Excerpt}
UNION ALL
SELECT 'file' AS type, description, created AS posted FROM txp_file WHERE {description}
ORDER BY posted DESC

You could create article_form and file_form and use something like <txp:output_form form="{type}_form" /> as search output content.

Offline

#110 2023-10-17 12:29:24

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,220
Website GitHub

Re: etc_search: when the default search is not enough

When the hell is this plugin going to become a core component? It’s insanely good and would throw the barn doors open wide for custom searches out of the box alongside unlimited custom fields. Just sayin’.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#111 2023-10-17 21:07:02

etc
Developer
Registered: 2010-11-11
Posts: 5,021
Website GitHub

Re: etc_search: when the default search is not enough

Bloke wrote #335793:

When the hell is this plugin going to become a core component? It’s insanely good and would throw the barn doors open wide for custom searches out of the box alongside unlimited custom fields. Just sayin’.

T’would be nice, sure, but etc_search configuration is not exactly intuitive. When we find something better than {these::weird::patterns}, perhaps…

Offline

#112 2023-10-17 22:09:32

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,220
Website GitHub

Re: etc_search: when the default search is not enough

etc wrote #335796:

etc_search configuration is not exactly intuitive. When we find something better than {these::weird::patterns}, perhaps…

If inspiration strikes, please go for it. I don’t know of any CMS that would be able to touch us in terms of flexibility if we had that ability alongside unlimited CFs.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#113 2023-10-24 17:13:04

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 4,555
Website

Re: etc_search: when the default search is not enough

etc wrote #335792:

This custom-type query should work now, please test:

SELECT 'article' AS type, Excerpt AS description, Posted AS posted FROM textpattern WHERE {Excerpt}...

You could create article_form and file_form and use something like <txp:output_form form="{type}_form" /> as search output content.

Thank you Oleg. After some experimentation – I realized I needed Body instead of Excerpt – I managed to get some way there, but I can’t use txp:tags to output the actual content in the search result forms. This is what I have set in the plugin settings:

Context: custom

Static search form: search_results_{type}

Query:

SELECT 'article' AS type, Body AS description, Posted AS posted FROM textpattern WHERE {Body}
UNION ALL
SELECT 'file' AS type, description, created AS posted FROM txp_file WHERE {description}
ORDER BY posted DESC

search_input (excerpt):

<txp:etc_search id="2" action='<txp:site_url />suche/' …

search_display (excerpt):

<txp:etc_search_results wraptag="div" break="" class="search-results">
    <txp:output_form form="search_results_{type}" />
<txp:else />
    <txp:text item="no_search_matches" wraptag="h3" />
</txp:etc_search_results>

Then I have two forms search_results_file and search_results_article, each with some specific tags like txp:title, txp:article_url_title, etc. analog for files. I do get a larger total number of matches under items_count and I also see that the different forms have been referenced and output and are interleaved by descending date order as per the query.

However, the article and file tags in those forms produce no output, likewise etc_search_result_excerpt, so I have only the markup-scaffolding but no content in the results list.

If I add {description} or {posted} directly into the <txp:etc_search_results>…</txp:etc_search_results> container, they do act as content placeholders. If I try the same in the forms, I just get that as text. It seems the respective article/file details are not being passed through the forms. Any ideas?

PS: I couldn’t choose custom as a context. It required changing ''=>'custom' to 'custom'=>'custom' in the radioSet in the plugin, and also adding that option to the ENUM datatype in the DB: 'article','image','file','link','category','section','custom'.


TXP Builders – finely-crafted code, design and txp

Offline

#114 2023-10-25 21:29:24

etc
Developer
Registered: 2010-11-11
Posts: 5,021
Website GitHub

Re: etc_search: when the default search is not enough

Yep, that’s annoying. Populating article/file/etc data for custom searches is tricky, since the current syntax does not allow mapping to standard txp fields. Parsing etc_search placeholders in forms looks doable, but a bit dirty.

What I can think of, is passing article/file/etc ids to forms via yield and retrieving data individually for each entry:

Query:

SELECT 'article' AS type, ID AS id, Posted AS posted FROM textpattern WHERE {Body}
UNION ALL
SELECT 'file' AS type, id, created AS posted FROM txp_file WHERE {description}
ORDER BY posted DESC

Display:

<txp:etc_search_results wraptag="div" break="" class="search-results">
    <txp:output_form form="search_results_{type}" id="{id}" />
<txp:else />
    <txp:text item="no_search_matches" wraptag="h3" />
</txp:etc_search_results>

Forms:

<txp:article_custom yield="id" />
<!-- same idea for files -->

That’s not very effective, but should be fast enough if search results are paginated in a reasonable way, since textpattern and txp_file tables have indexes on id.

Thanks for the remark on custom context. Could it be browser-related?

Offline

#115 2024-02-27 08:53:10

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 4,555
Website

Re: etc_search: when the default search is not enough

Apologies if this has already been mentioned in this long thread. On recent PHP8+ I get a

passing null to parameter #1 ($string) of type string is deprecated on line 576

with etc_search. It results when parse_url($action, PHP_URL_QUERY) returns NULL and then parse_str tries to process that into variables.

Presumably this only ever returns something when a user actively specifies an action attribute that contains other own url queries.

I have worked around it by changing line 576 from:

else parse_str(parse_url($action, PHP_URL_QUERY), $qs);

into

else {
        $parts = parse_url($action, PHP_URL_QUERY);
        if($parts) parse_str($parts);
    }

though I suspect you may have a more elegant solution.


TXP Builders – finely-crafted code, design and txp

Offline

#116 2024-02-27 09:12:34

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 4,555
Website

Re: etc_search: when the default search is not enough

A second minor query:

The search is pleasantly unfussy in that if you search for burgerzentrum, you get matches for “Bürgerzentrum”, which is good.

However etc_search_result_excerpt is more exacting. You get no search result excerpts with burgerzentrum but you do with bürgerzentrum (i.e. with the umlaut, as is contained in the actual article).


TXP Builders – finely-crafted code, design and txp

Offline

#117 2024-02-28 11:22:15

etc
Developer
Registered: 2010-11-11
Posts: 5,021
Website GitHub

Re: etc_search: when the default search is not enough

Thank you, Julian, will take a look as soon as time permits.

Offline

#118 2024-02-29 13:29:17

etc
Developer
Registered: 2010-11-11
Posts: 5,021
Website GitHub

Re: etc_search: when the default search is not enough

jakob wrote #336763:

A second minor query:

The search is pleasantly unfussy in that if you search for burgerzentrum, you get matches for “Bürgerzentrum”, which is good.

However etc_search_result_excerpt is more exacting. You get no search result excerpts with burgerzentrum but you do with bürgerzentrum (i.e. with the umlaut, as is contained in the actual article).

This one does not look minor, unfortunately. The search uses sql LIKE query, which (for your server collation) considers u and ü as equivalent. But this is not necessary the case for other possible collations. On the other hand, (etc_)search_result_excerpt calls php preg_match_all() function to extract matching chunks from article bodies returned by sql query. But php regex does not seem to support character equivalents, so /u/ pattern does not match ü. We could construct these equivalents ‘by hand’, but they depend on sql collation, and I can not see how to efficiently extract equivalent characters groups atm.

Offline

#119 2024-03-01 10:21:21

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 4,555
Website

Re: etc_search: when the default search is not enough

etc wrote #336810:

This one does not look minor, unfortunately. The search uses sql LIKE query, which (for your server collation) considers u and ü as equivalent. But this is not necessary the case for other possible collations. On the other hand, (etc_)search_result_excerpt calls php preg_match_all() function to extract matching chunks from article bodies returned by sql query. But php regex does not seem to support character equivalents, so /u/ pattern does not match ü. We could construct these equivalents ‘by hand’, but they depend on sql collation, and I can not see how to efficiently extract equivalent characters groups atm.

Thanks for investigating. Could the \pL escape sequence help here? I’m not sure I understand it fully, so I may have it exactly the wrong way around, but if I’ve understood, for example, this discussion then it’s designed to allow matches of equivalent characters in regexes.

Otherwise, is your alternative suggestion that – for search purposes – the article bodies (and the search term?) would be transliterated to ‘plain ascii’ characters, i.e. diacritics removed, to check for matches, but then the actual term and matching chunk be used for displaying the excerpt? Might the Transliterator::transliterate help there?

EDIT: extensive discussion here of transliteration alternatives.


TXP Builders – finely-crafted code, design and txp

Offline

#120 2024-03-01 14:23:36

etc
Developer
Registered: 2010-11-11
Posts: 5,021
Website GitHub

Re: etc_search: when the default search is not enough

jakob wrote #336811:

Could the \pL escape sequence help here?

As I get it, \pL matches any ‘letter’ character. But what we need here is a pattern that matches, say, u, ü and ù, but not ë or à. We could construct some [uüù] equivalent letters groups, but ‘equivalent’ depends on the current db charset/collation. In German, for example, ss and ß could be considered equivalent, but not in other languages. And I have no idea which ‘letters’ are ‘equivalent’ in non-European languages.

Offline

Board footer

Powered by FluxBB