Thank you for your response...

This made me wonder, cause it is a valid point you have. But it is nearly as I said above. In line 118 (of class-searchengine.php) the "search_structure" is filled with the entries of "$_zp_exifvars".

[code]
$this->search_structure[strtolower($field)] = $row[2];

Other than stated above there is no fault here. This is done the same way as for the other fields above (lines 92 - 113). The "search_structure" array consits of the key (in your quote 'IPTCCity' and as values the entries of 'gettext('City')'

To debug this I made a var_dump of the array generated by getSearchFieldList() (line 223 of class-searchengine.php) and noticed that the values are now mixed up.

key --> value
value --> key

array(89) { ["Title"]=> string(5) "title" ["Description"]=> string(4) "desc" ["Tags"]=> string(4) "tags" ["File/Folder name"]=> string(8) "filename" ["Date"]=> string(4) "date" ["Custom data"]=> string(11) "custom_data" ["Location/Place"]=> string(8) "location" ["City"]=> string(8) "iptccity" ["State"]=> string(5) "state".......
[/code]

The original defined keys are unique (e.g. city, iptccity) but as 'gettext('City')' is always the same (not depending on locale), the old key 'city' gets overwritten when it is filled a second time.

During debugging I made a small code example from where this should be seen.

[code]

[/code]

Link

So, the original 'city' field gets lost when 'getSearchFieldList()' is executed.

Unfortunately it can't be fixed as easy as in the example above as switching $display and $key messes up things up a bit in the admin backend. So additional steps would be required to integrate this.

Is this part of the code relevant for ZP 2?

So, the quickest and easiest fix would still be to alter the gettext('City') as stated above.

Thanks for the investigation that helps a lot. i think we sadly have some other places where gettext strings are used as keys/indexes like here instead of actual "unique" values.

We'll take a look and probably follow your pragmatic suggestion.

Is this part of the code relevant for ZP 2?

Yes, we don't plan to totally rewrite everything if it otherwise works ;-)

So, just to clarify for a newbie ... search function is officially broken? (Actually mine never returns any results, too, no matter what I try.)
Or is there something one can do about it?

No, the search function is not broken. The selection of search field via the front end is.

(Actually mine never returns any results, too, no matter what I try.)

Check Options > Search. Wrong setting certainly will cause no results.

Hm, I noticed that I can get some search results by editing the search field into the browsers address field after an unsuccessful search. It always ends in "&searchfields=", i.e. with a blank search field. If I add "title" or "content" here, I can get some results. However, I can't get it to work through the regular interface, even it I switch themes or change search options.

A general search should look like this:
https://www.zenphoto.org/page/search/?search=theming

"&searchfields=" is related to the searchfield selector on the frontend and normally not printed in the url and not necessary for a search.

Hm, mine looked very different. So I tried to switch on Mod_rewrite, and voila - it works, also with selecting search fields from the front end. Beautifully! Thanks for the hint.

The non modrewrite equivalent should have looked like this and also work…:
https://www.zenphoto.org/index.php?p=search&search=theming

You can select fields but the setting will rather be ignored actually which is the bug. A bit more complicated as search context is cookie powered and such.