Jump to content

HerTha

Members
  • Content Count

    34
  • Joined

  • Last visited

Community Reputation

29 Excellent

About HerTha

  • Rank
    Jr. Member

Profile Information

  • Gender
    Male
  • Location
    Leipzig, Germany

Recent Profile Visitors

1,541 profile views
  1. Thank you guys for digging into this! This forum is just awesome! I am trying to summarize: We found out that array syntax is able to handle "!" properly. We also found that there are other workarounds for accepting (or filtering) "&". So, that are all interesting details, good to know. However, the question from my original post is still circulating my head: I thought this has been done a thousand times...
  2. further investigation - I simplified the code to: $a_sel = [ ['template', 'downfile'], ['title|name|indexer', '%=', $a_terms] ]; $results = $pages->find($a_sel); So, there are 3 fields to search: "title", "name" and "indexer" (a textarea field). Still using $a_sel = "&hallo". It turns out, that the error occurs only if: "name" field is present and at least one more field is present The combination "title" with "indexer" works just fine. I have never filed an issue report, but this one could be worth it. Anyone who can duplicate this error?
  3. that extra sanitizer removes the error, Tracy reports $a_sel to be: So, for this case, the documentation seems to be wrong:
  4. well, that mixed lot of quotes makes the error disappear <scratchinghead>how did you come up with that?</scratchinghead>
  5. I have rearranged the code to use array syntax for the selector: $a_sel = [ ['sort', 'name'], ['limit', $limit_per_section], ['template', 'downfile'], ['title|name|indexer', '%=', $a_terms] ]; $results = $pages->find($a_sel); Now, if $a_terms contains search term "!hallo" then all is fine. Problem solved!? Well, not really. Searching for "&hallo" still crashes: I understand this should not happen, my debugging skills are a bit limited, though...
  6. @Autofahrn thanks for your input! Initially, I thought I am dealing with a general problem. Now, it seems more related to a special combination of details. @Zeka array syntax looks good - worth trying, I'd say! I'll report back once I find more...
  7. Okay, as I have multiple calls to find() on that page, I tried to narrow it down a bit and removed all but one. If the search is for, e.g., "hallo" then all is fine. However, if searching for "!hallo", that particular error (see above) occurs. The offending selector, as Tracy bd() reports: "sort=name,limit=50,template=downfile,title|name|indexer%="!hallo"" I can't see anything wrong with it...
  8. You are using "~=" while I'm prefering "%=" in this place - that's the only difference I can see right now. Should not make a difference, anyway? The error message, when admin, is like: Error: Exception: Unknown Selector operator: '%=!' -- was your selector value properly escaped? (in /home/abcdefg/public_html/wire/core/Selectors.php line 419) Other characters can also do such harm, for instance "?" or "," That site is running on PW 3.0.123, BTW
  9. I am setting up a front-end form to allow visitors to do a fulltext site search. When external input arrives at the system to be processed in database queries, security is a main issue. Therefore, all the (text) input for this form goes through a $sanitizer->text(), as a first step. Then, I thought using a $sanitizer->selectorValue() would be a good idea for building the selector: $results = $pages->find("template=contentpage,title|headline|body%={$sanitizer->selectorValue($search_term)}"); Unfortunately, it turned out to be quite easy to crash the whole thing, for instance by typing a single ! in the search which gives a 500 server error for the visitor. Obviously, there are a number of scenarios (including the ! char) which are not catched by the sanitizer, but need to be taken care of. Anyone who can share a list of forbidden chars or an algorithm to handle the filtering more securely in such a situation? Of course, the whole filtering should not be overly strict, so the visitor can still find a few things...
  10. Just had a similar problem after switching from PHP5.x to a PHP7.1.x system. Fatal error in admin (line 117 of /wire/core/PWPNG.php) while rebuilding a PNG thumbnail. Obviously, utf8_encode() is not necessarily part of core PHP functions (anymore). I fixed the problem by asking my server admin to install the missing PHP XML module. Though, I wonder if it would be a worth the effort to avoid use of utf8_encode() in the PW core altogether? It seems to be used rarely - I found two places only in V3.0.123. Would iconv() do the job?
  11. Website of a small technology business, currently based on Processwire 3 jQuery Magnific Popup Font Awesome Padloper with a fixed pixel width layout should get a new (more mobile friendly) skin, based on UIkit. Looking for help from a (front-end) developer, with good PW knowledge, to create a first mock-up with one typical page/template, including header/footer/menu components. No critical deadlines. Please PM for details. German would be nice, as well as English.
  12. @horst thanks for confirming! And: oughta check the modules directory more frequently. A horn of plenty!
  13. okay - seems I have to ask my site admin to install an additional PHP extension - "mbstring" I guess, during a PW install from scratch the presence of this extension is checked by the installer...
×
×
  • Create New...