sujag

To be honest I don't think that stopwords are the problem. I checked this a few days ago and got only an english stopword list. Then I switched to testing different phrases and decided to ask others. Another try to explain the problem: I get the same results when searching for "Gesang der Mönche" and "Gesang Mönche" but different when searching for "Festival für Freunde" und "Festival Freunde" Why?

I'm on a shared hosting, don't know about a custom config. But anyway, shouldn't stopwords just be ignored? In the search phrase and the result? Then there shouldn't be a different result searching for "Festival Freunde" and "Festival für Freunde"

It does indeed work with the *= operator, but I don't quite understand why and I get more than the wanted results. I think, too short can't be the reason, cause the search without "für" works as well another search after "Gesänge der Mönche" where the article "der" doesn't interfere with the result.

Thanks, but the quotes are added by the template, they are not part of the search term and this wouldn't explain a difference between the search phrases "Festival für Freunde" and "Festival Freunde" (both submitted without quotes)

I have a strange problem with finding a certain (german) text in my page. On kulturfeste.de a search for "Festival für Freunde" https://kulturfeste.de/suche/?q=festival+für+freunde&submit= doesn't get results, omitting "für" https://kulturfeste.de/suche/?q=festival+freunde&submit= get's beside others the expected result https://kulturfeste.de/feste/festival-fuer-freunde/ The used selectors for $pages->find are 'title|headline|Intro~*=festival für freunde, limit=50, template=fest' and 'title|headline|body~*=festival für freunde, limit=150, template=veranstaltung,sort=eventTime' The search text appears multiple times in the relevant fields, it seems not to be the word "für" as possible stopword and not the umlaut 'ü' Now I'm running out of ideas. What else could I check for?

Is there a way to sanitize email-Adresses from IDN Domains? $connInfo = $sanitizer->email($connInfoRaw); bd($connInfo); .../kulturfeste/kfweb2021/site/templates/import_geoloc.php:477 'post@kirchlein-im-grünen.de' bd($connInfoRaw); .../kulturfeste/kfweb2021/site/templates/import_geoloc.php:476 'post@kirchlein-im-grnen.de' This is obviously wrong. $sanitizer->email() has no options to allwo IDN. Any ideas, workaround how to fix this? Or at least get a warning? Since this a mass import there might be more than just this single case, which I know.

Thanks for the suggestion. This works without syntax error, but doesn't give the expected results. Looking for a single (known) parent works. $regionEvents = $pages->find("template=veranstaltung,selectLocation.parent=14692,limit=$limit");

I'm stuck with the selector syntax for a page reference field. After changing the site structure the old query $regionEvents = $pages->find("template=veranstaltung,selectLocation.parent=$reg,limit=$limit"); won't work any more, cause I now need a match for the grandparent of the page that is stored in the "selectLocation" page reference field. Just changing to $regionEvents = $pages->find("template=veranstaltung,selectLocation.has_parent=$reg,limit=$limit"); results in a syntax error "Unknown subfield: has_parent" What would be the right syntax in this case?

Thanks, that works

I'm stuck finding the right selector syntax for an empty page reference field. I can select all pages with template "fest" that have an entry in selectLocation $oF = $pages->find('template=fest,selectLocation.id>0'); but now I need the contrary. Find all pages with template "fest" and an empty selectLocation My selectLocation Field is setup to reference a single page, but all tests with $oF = $pages->find('template=fest,selectLocation=FALSE'); or 0 or false won't work.

There is no need to xxx the whole IP-address, this would indeed make no sense, only the last three digits are masked. Google analytics implements this as IP Anonymization (or IP masking) in Analytics to allow compliance to privacy statements and laws. https://support.google.com/analytics/answer/2763052?hl=en

Another question. Would it be possible to partly anonymize the IP-Adresses? German (european?) privacy laws prohibit the permanent logging of ip-adresses as private data. A common solution that respects this while still allowing some analysis is to set the last triplet to 0 or xxx before it get's stored.

no it was indeed the old PHP-Version. I finally found the place to switch and now the module works as expected. Thank you

Yes it is the row LIMIT but it's indepedent of the value. Changing the value just alters the text of the error message: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''100'' SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''25'' But I just notices, that this server still works with PHP5.6 I ask the hoster, if it is possible / planned to upgrade.

Interesting module. It works in my local environment, but unfortunately online. Trying to view the statistics I get an unspecific server error (500), with Tracy debugger I get some details but don't have a clue what's happening. I assume some security setting on the host, but have no idea to find this.