Any thoughts as to what I might be missing. My site seems fine and the tag list populates, but clicking on them brings up the "Sorry, no matches for (search term)" page. Any manual search does the same. I refreshed the database to no avail. All the metadata is there (as can be seen via each image's individual page). I have the exact same site working on my local NAS without issue... I have a very similar site (slight variation to theme) on the same host working without issue as well, so I feel like I just missed a setting with this install.

Search is not password protected and fails whether logged in as master user or not.

Since I can't delete this post: UPDATE... it seems my FTP only uploaded a part of one of my templates (inc_header)... I will update again if I've not fixed it, but feel free to delete this post (as I can not).

Grrr, I hate not being able to edit posts after an hour. My fix was not a fix. I was in a rush and thought it was fixed, but I refreshed my NAS copy, not the one live on my host. I still can't figure this out.

I completely re-uploaded the site from my working NAS copy and am still getting the error (initially I had done a fresh install from the 1.6.1a download)

Here is my error in the error log that I believe is related, but this references a core file I have never altered, so I don't know. Any help is still appreciated:

WARNING: mysqli::query(): (HY000/3685): Illegal argument to a regular expression. in /home/(mydomain)/zp-core/classes/class-dbmysqli.php on line 69

mysqli->query called from dbMySQLi->query (class-dbmysqli.php [69])

from dbMySQLi->queryFullArray (class-dbmysqli.php [114])

from SearchEngine->searchFieldsAndTags (class-searchengine.php [1097])

from SearchEngine->getSearchImages (class-searchengine.php [1590])

from SearchEngine->getImages (class-searchengine.php [1673])

from SearchEngine->getNumImages (class-searchengine.php [1556])

from getNumImages (template-functions.php [2113])

from include (search.php [24])

from include (index.php [128])

from index.php [79]



I can say I have discovered if I only check to search in tags, or if I click a tag link, it will fail. If I search for everything, including tags, it will now work, but it seems to ignore any tag results, but if tags is checked by itself, it fails, or if I click a tag link, it fails.

IE: If I check tags/title/date/description - and search for the term "Aladdin" which is in one description and 30some tags, I'll get one result, even though tags was checked - it ignores the tags. So the search issue seems to be it is ignoring tags altogether, saying that there are no identified tags, even though the tag list populates correctly and the tags noted on each individual picture page (image.php) shows the correct tags for each image.

When I go into the databases for the working and non working sites and look at the tags entries, they all seem to be there for both, formatted the same. IE, the database structure looks the same as far as I can tell. One site working, one site not.

OKAY, I found what causes this, finally.

On my local install, for Tag matching under the search options, I can select all three choices (partial, word, or exact) and each one will work correctly.

On my host, for Tag matching, if I select "word" it will NOT work. Changing it to partial will work and exact will work (but with exact, for manual typed searches, you do have to be exact), but if I select "word" no results will be found, whether you type a search in manually or simply click a tag link.

This seems to be a glitch, and I'm not sure why it's a glitch, but moving it to "partial" allows my tag links to work and allows me to search for tags, albeit a bit more loosely than it would if I could select to search tags by "words"

No idea, I just changed that option on our own site and it seems to work for me. Try clearing the search cache if you have it enabled, that sometimes can cause weird results.

I'm not sure how to do this. I see no option for clearing search cache. If you mean under Options/Search> set Cache expiry: Redo search after "0" minutes. I have tried that and it makes no difference. If there is another clear search cache feature, please let me know.

Otherwise, the workaround of not using "word" for tag searches does work for me.

Now if I could only figure out why my site crashes as soon as I save my first favorite with the favorites plugin...

Maybe all these issues are Dreamhost issues...

Weird… If you set the option on the Search option to 0 it is disabled.

You need to have the cacheManager enabled to get a button for clearing it on the overview page. For historic reasons that plugin combines reset buttons for various cachees even if those belong to other plugins (this will eventually be changed),

> Now if I could only figure out why my site crashes as soon as I save my first favorite with the favorites plugin...

That is most likely another issue (unless your host in general does not play well right now…) There should be something in the logs. If you find anything please open a new topic though.

Thanks for the quick response. I missed that plugin. I enabled and cleared search cache manually, then set tag search to "Word" and the search fails still. I pulled the error from the log for you:

WARNING: mysqli::query(): (HY000/3685): Illegal argument to a regular expression. in /home/(mysite)/zp-core/classes/class-dbmysqli.php on line 69

mysqli->query called from dbMySQLi->query (class-dbmysqli.php [69])
from dbMySQLi->queryFullArray (class-dbmysqli.php [114])
from SearchEngine->searchFieldsAndTags (class-searchengine.php [1097])
from SearchEngine->getSearchImages (class-searchengine.php [1590])
from SearchEngine->getImages (class-searchengine.php [1673])
from SearchEngine->getNumImages (class-searchengine.php [1556])
from getNumImages (template-functions.php [2113])
from include (search.php [24])
from include (index.php [128])
from index.php [79]



As for the favorites plugin, I'll post that log in a new post reflective of my 1.6.1a install (it is interesting that the error for both seem to originate with line 69 of class-dbmysqli.php).

We'll try to take a look. Are you using some special chars like accents in French or similar a lot?

Just the normal characters, as far as I can recall. I can't think of any photo that would have a special accent, even in the exif. I do have many filenames with parentheses () or dashes - , though.

Today I have updated my zenphoto installation to 1.6 and during checks/ adjustments of my theme, I have noticed a similar problem to the one mentioned here. Tough I'm posting here instead of opening a new thread.

So during test searches I've noticed, that all content stored in the 'city' tag can't be found. The other tags seemed to work just fine. So after several hours and testing various things (e.g. different themes, backend settings, new database - set all entries in cities to NULL except for one picture to minus out problems with chars and so on) I found what's probably a bug in zenphoto itself.

As one of the last things I had a look in zp_options table and found under the row 'search_fields' that there is no entry for 'city' instead only one for 'iptccity'. After manually altering the entry values stored in the 'city' tag can be found just fine. If the 'city' tag is disabled applied and reenabled in the backend the 'search_fields' value is back to 'iptccity' and values under 'city' can't be found any more.´

I quess this problem is easy to reproduce and maybe also easy to solve.

Check your fields list option on the search/options tab. It is there that you choose which fields (not tags, those are something else) of the database are searched.

Ok, maybe I didn’t use the right words… Unfortunately I said tag where it should be field.

It is exactly the field list entries/values I‘m taking about. You should be able to easily reproduce the problem by yourself:

- deselect all fields in the list
- apply settings
- select the field ‘city’
- apply settings
- if the field ‘city’ is not populated at all choose an arbitrary picture and enter e.g. ‘test’ as the field value
- search for ‘test’ - it gives no results
- do the same for other fields (I tested ‘state’ and ‘credits’), the chosen picture will be found just fine

The problem causing the issue is as mentioned above that the fields list option on the search/options tab creates internally in the zp_options table / ‘search_fields’ the field ‘iptccity’ instead of ‘city’.

If the entry under ‘search_fields’ is changed manually from ‘iptccity’ to ‘city’, searching for entries in the ‘city’ field just works fine. If the field list is updated using the search options tab, searching for entries in the ‘city’ field is broke. again.

Hope this makes things a bit clearer and sorry mixing up tags and fields.

Thanks

Also, if you have the search cache enabled try clearing it after changing search field settings (or just disable it completely). Otherwise it may certainly still may serve wrong "old" results.

Just to mention the city field is a standard field just like state or credits and all are treated the same actually.

Nevertheless we will try to reproduce…

Yes search cache cleared and then disabled, I tried quite a few things before digging into the database.

I also think that the cache should have no effect on the permanent setting in the database.

I had also the impression that there should be no difference between the individual fields. But the field list option from the backend turns ‚city‘ into ‚iptccity‘ for some when it’s stored into the database.

As said, should be easy to reproduce.

> But the field list option from the backend turns ‚city‘ into ‚iptccity‘

Those are actually two different fields (database table columns). "city" is a standard field that is filled manually only and "iptccity" is a image metadata field that is filled via image metadata import.

So, why does then the option 'City' in the fields list option on the search/options tab result in a 'iptccity' string in the zp_options table 'search_fields', whereas it should be 'city'?

How does image metadata import work? Could this probably cause my problem? Although it shouldn't be that way...

> So, why does then the option 'City' in the fields list option on the search/options tab result in a 'iptccity' string in the zp_options table 'search_fields', whereas it should be 'city'?

Okay, I got it now. That should not happen and sounds like there is a typo somewhere. We'll take a look at that.

So, as I was genuinely interested in what causes this strange behaviour, today I have ingestigated a bit and found the cause for this behaviour.

It is no typo, the problem is that "city" is not unique and gets overwritten. It is caused by adding "$_zp_exifvars" to the "search_structure" (class-searchenginge.php line 118). The previously (line 100) defined field for 'city' gets overwritten/double populated by the matching element of "$_zp_exifvars" (line 2717 of functions.php).

As far as I see, this only happens for 'city' as this is the only element that has a duplicate. The other similar ones have a different iptc name e.g.:

State --> State/Province
Location --> SubLocation
...

Easiest way to fix would be a different name for "gettext('City')" (line 2717 of functions.php).

Thanks for investigating. Are you sure that it is not the plain entry for "City" (labeled as "meta key" in the doc block) right before that in the array?

'IPTCCity' => array('IPTC', 'City', gettext('City'), false, 32, true, 'string'),

The gettexted part should actually IMHO not be the actual field name as it is for display and is of course translated. IF it is this is a bad habit from the old days… I admit we have not looked at these parts in details for years…