Jump to content

All Activity

This stream auto-updates     

  1. Today
  2. Hey @gregg! If possible, please try updating the module to the latest version (0.12.0). This should resolve your issue. For the record, Fields::delete() expects an object implementing the Saveable interface as its first argument – so the correct syntax would be something along the lines of $fields->delete($fields->get('thefield')). Since you cannot use this method to delete a field that has been added to one or more fieldgroups (via templates), that might still fail though
  3. Well, there's a plethora of PW sanitizer methods: https://processwire.com/api/ref/sanitizer/ A good combo might be: https://processwire.com/api/ref/sanitizer/chars/ https://processwire.com/api/ref/sanitizer/min-length/ And of course native PHP has many methods you can use in addition to the PW API functions (some of them are just wrappers or combinations of native methods).
  4. 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...
  5. Oh, don't worry, I always do that, in addition to all sorts of user-input sanitation/validation. I was rather just speaking theoretically. Thankfully, PW code in the site profiles has plenty of useful examples with comments, which will hopefully prevent newbies to omit such checks. After all, we can't expect PW to handle everything for us; it's always up to the developer to take care of security and best practice.
  6. Using %= means your value will be escaped and wrapped in "%$value%". Using that with LIKE in sql means you'll get all results returned for an empty string value. Both – returning an empty or a full resultset – can be valid expected results for a filtering operation so it's best to align with the default sql behavior and not adding special cases, which is at least the less surprising option. If you don't want to allow searches for empty string is ultimately a business decision you have to take care for on your own. If that's a concern I'm wondering if you don't set limit on your query. Limit (and in extension pagination) makes the problem of an empty string not filtering the results a non-issue.
  7. I strongly disagree. An empty string is useless. (maybe "correct" in a strictly SQL / theoretical / technical view, but not in the context discussed here) It's funny that * returns empty string, but ? or ! return ""?"" and ""!"". I'm really surprised (knowing how important security is for @ryan). Does that mean that a malicious attacker could potentially bring a server to its knees by searching with wildcard automatically x times per second?
  8. $sanitizer->selectorValue("*"); effectively returns an empty string. So searching for nothing obviously isn't intended, but probably correct to return everything...
  9. I found some other strange stuff (only tested in Tracy): $q = "*"; $query = $sanitizer->selectorValue($q); $pgs = $pages->find("parent=1041, include=all, vertec|title|name|remarks%=$query"); d($pgs); This returns everything. Every single page inside parent id 1041. ! returns a seemingly random amount of results (74 out of 1061) - completely wrong. ? does the same, but returns 73 instead of 74. So, I guess you'd have to manually sanitize the query yourself: Check if minimum string length is 3. Remove charactes such as ! & *. And of course, make it a habit to narrow results down (according to template, parent, not in trash, etc.). I would expect PW to throw some sort of error if a search string is less than 3 characters. Maybe the results may differ if I actually used it in a template (outside Tracy) and not logged in as superuser, or with debug off. But still, this behavior truly puzzles me.
  10. Finally fixed @arjen's issue, culprit was a non-readable file within the pwpc directory which wasn't excluded since I forgot exclusion paths need to be site relative (/site/assets/pwpc/ for all ProCache users).
  11. Due to the tooltip problem, the only safe way to copy anything from the forum is to quote the message and then copy from the message composing area.
  12. yes, instantly! Probably because name is handled something special. Maybe worth triggering @ryan...
  13. 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?
  14. that extra sanitizer removes the error, Tracy reports $a_sel to be: So, for this case, the documentation seems to be wrong:
  15. @HerTha Just curious is this code fails? $a_sel = [ ['sort', 'name'], ['limit', $limit_per_section], ['template', 'downfile'], ['title|name|indexer', '%=', $sanitizer->selectorValue($a_terms)] ]; $results = $pages->find($a_sel);
  16. Hi. I'm getting this error 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 '.id FROM `pages` JOIN field_banner_categories AS field_banner_categories O' at line 7 with this selector $this->wire('pages')->find("banner_position=sidebar, (banner_categories|banner_sections=$page), (banner_custom_pages=$page)"); banner_position - Select Options field banner_categories, banner_sections, banner_custom_pages - Page reference fields. This selector produces such SQL queries: banner_categories|banner_sections=1057 ---------------------------- SELECT SQL_NO_CACHE pages.id FROM `pages` LEFT JOIN field_banner_categories AS field_banner_categories ON field_banner_categories.pages_id=pages.id AND ((((field_banner_categories.data='1057') ) )) LEFT JOIN field_banner_sections AS field_banner_sections ON field_banner_sections.pages_id=pages.id AND ((((field_banner_sections.data='1057') ) )) WHERE ((((field_banner_categories.data='1057') ) ) OR (((field_banner_sections.data='1057') ) ) ) banner_custom_pages=1057 ---------------------------- SELECT SQL_NO_CACHE pages.id FROM `pages` JOIN field_banner_custom_pages AS field_banner_custom_pages ON field_banner_custom_pages.pages_id=pages.id AND ((((field_banner_custom_pages.data='1057') ) )) banner_position=sidebar, =(banner_categories|banner_sections=1057), =(banner_custom_pages=1057), status<1024 ---------------------------- SELECT SQL_NO_CACHE pages.id,pages.parent_id,pages.templates_id FROM `pages` JOIN field_banner_position AS field_banner_position ON field_banner_position.pages_id=pages.id AND (((field_banner_position.data='1' ) )) WHERE (pages.status<1024) AND ( pages.id IN ( SELECT SQL_NO_CACHE pages.id FROM `pages` LEFT JOIN field_banner_categories AS field_banner_categories ON field_banner_categories.pages_id=pages.id AND ((((field_banner_categories.data='1057') ) )) LEFT JOIN field_banner_sections AS field_banner_sections ON field_banner_sections.pages_id=pages.id AND ((((field_banner_sections.data='1057') ) )) WHERE ((((field_banner_categories.data='1057') ) ) OR (((field_banner_sections.data='1057') ) ) ) ) OR pages.id IN ( SELECT SQL_NO_CACHE pages.id FROM `pages` JOIN field_banner_custom_pages AS field_banner_custom_pages ON field_banner_custom_pages.pages_id=pages.id AND ((((field_banner_custom_pages.data='1057') ) )) ) ) GROUP BY pages.id I thought that it can be relative to "OR" selector banner_categories|banner_sections=$page So I tried $this->wire('pages')->find("banner_position=sidebar, (banner_sections=$page), (banner_custom_pages=$page)"); It also produces the same error. Any thought? Thanks.
  17. Yesterday
  18. It's just manually enforcing the string is escaped in quotes, but single quotes this time. Since I guess that double quotes are removed somewhere, you may try with this one as well: ['title|name|indexer', '%=', '"'.$a_terms.'"' ] In both cases you really need to ensure the search term does not contain quotes itself, searching for "it's" will fail now. That's normally something $sanitizer->selectorValue() takes care of.
  19. Doh! < slaps forehead > of course!! I will also look into that PW database interaction stuff. I should be doing it that way, but for some reason have resisted learning the wire framework.
  20. well, that mixed lot of quotes makes the error disappear <scratchinghead>how did you come up with that?</scratchinghead>
  21. Thanks for the pointer, searching for "&something" does not work with AjaxSearch either, since it sends the field unescaped through a get request, so "something" effectively gets a second parameter and the search string is empty (does not contain the ampersand). But that's another story. Could you try this line (or better run $a_terms through $sanitizer->selectorValue()): ['title|name|indexer', '%=', "'$a_terms'" ]
  22. 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...
  23. @SoccerGuy3 Glad that it helped. The name of your button is not 'submit', but 'submit_name', but in your initial code you check '$this->input->post->submit'. $f->attr('name', 'submit_save'); Also if you want to make your code more PWish you can rewrite it with https://processwire.com/api/ref/wire-database-p-d-o/
  24. Did you check for bad characters? Had this sometimes with copy&paste code from the forum. Modified the script a little to hopefully display a reasonable error message.
  25. Beautiful!! That was it exactly. Still have some other logic/syntax problems to work out, but they are of the php/mysql variety and I can (hopefully) handle that part! Now the big question, can you tell me or point in the direction of WHY that code change you suggested was the solution? What I had before is working in another module I did last year (far simpler and writing to a table within the PW database).
  26. @AutofahrnDanke for your hard work on this. I really appreciate it. I've excluded both pwpc and added the regex to the config. No luck. I then changed the "Absolute path of the directory where packages are saved." to the ../public folder. No luck either. Funny thing is though that the log says it still wants to save in the "default" folder. When I add your code I'm getting a "Parse error: syntax error, unexpected '$res' (T_VARIABLE)". I've double check the syntax, but it seems to be okay. Not sure what is going on there as well. I also removed all filecompiler files and let it recompile again. No luck.
  27. Hi I have some difficulties with customize the lay-out. I have a custom calendar and want to put the month with navigation on top of it (in place of 05 = month may). Is there an API call $recurme->month()->next ? Is there an api call $recurme->month()->prev ?
  1. Load more activity
×
×
  • Create New...