Jump to content

Autofahrn

Members
  • Content Count

    290
  • Joined

  • Last visited

  • Days Won

    10

Autofahrn last won the day on May 14

Autofahrn had the most liked content!

Community Reputation

363 Excellent

1 Follower

About Autofahrn

  • Rank
    Sr. Member

Contact Methods

  • Website URL
    http://www.team-tofahrn.de/en/

Profile Information

  • Gender
    Male
  • Location
    Germany

Recent Profile Visitors

600 profile views
  1. maybe requested URL is wrong or does not handle the AJAX query in that case? ...only guessing, lack of knowledge about the inner workings...
  2. No instant solution, but did you check in dev tools both request and returned data? If the JSON parser complains the response starts with a <, it seems to receive some HTML.
  3. $sanitizer->selectorValue("*"); effectively returns an empty string. So searching for nothing obviously isn't intended, but probably correct to return everything...
  4. 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).
  5. yes, instantly! Probably because name is handled something special. Maybe worth triggering @ryan...
  6. 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.
  7. 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'" ]
  8. 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.
  9. neither me. Could you set $config->debug=true; in your site/config.php? Then there should be some more information in that error message.
  10. Seems like your $sanitizer->selectorValue() does not work at all for some reason. Could you check with Tracy? $search_term = '!'; $val = "template=contentpage,title|headline|body%={$sanitizer->selectorValue($search_term)}"; d($val); Should output: "template=contentpage,title|headline|body%="!"" (45)
  11. The search on that site can actually do both, depending if the search phrase starts with a ". No, it does not make a difference (just tried). Just logged my resulting $selector and saw the ! is encapsulated in ": 'text_index%="!", limit=16' Which version of PW are you running (I'm on 3.0.123)? Maybe there's a fix in $sanitizer->selectorValue(). (Edit: Ok, should read the last paragraph as well).
  12. @BillH, I'd probably go with a pretty different approach and manage a separate "RecentList" when updating entries instead for each view. If images are stored on individual pages, you simply maintain a repeater (on some hidden page) holding a page reference to each image. Whenever a new image is uploaded (i.e. use hook on page save), a link is added to that repeater. If it has too many items, the oldest are removed in that step. Since you are using multiple images per article, your repeater has to hold a reference to the article and the basename of the newly added image. On page view you simply load the repeater content (no search at all). To speed up things, you may add more fields to that repeater, like the title of the article, so there is no need for additional database queries. To ensure titles stay in sync, your page save hook needs to update the cached article titles as well.
  13. Does the error log tell you more about the 500 error? Just wondering since I basically do the same on the pwflex.team-tofahrn.de search: if($config->ajax && (($query = $input->get->q) != '')) { $query = $sanitizer->selectorValue($query); $search = "text_index~=$query"; $selector = "{$search}, limit=".($Limit+1); $matches = $pages->find($selector); Only difference may be, that my script requires three chars before it sends the query (makes no difference, just tried).
  14. @arjen quickly seeked the log and do not found anything wrong. In that log closing happens at 0.5s and opening at 2.7s so everything seems to work fine a the time between close and open indicates the time for zip operations to take place. You may give it a try and place the backups in some other location (i.e. next to the .../public folder or in .../public/backup), but I doubt this helps, since the logfiles are there. I can only guess that the $zip->close() fails for some reason, so please try changing that block to read: $zipLog->verbose("CLOSING ZIP: {$zipfile}"); $res = $zip->close(); if($res !== true) { $zipStatus = $zip->getStatusString(); $zipLog->verbose("CLOSE ZIP FAILED: {$zipStatus} in {$zipfile}"); throw new WireException("Unable to close ZIP ({$zipfile}): {$zipStatus}"); } $zipLog->verbose("OPENING ZIP: {$zipfile}"); Since I expect the close to fail I've read the complete log and saw, that it tries to zip temporary files generated by ProCache. So its probably worth to add an exclude for ProCache: %/ProCache-[^/]+$% # Ignore ProCache directory and maybe the pwpc directory as well: /site/assets/pwpc/ Edit: forgot that exclusion directories must be site-relative (so its /site/assets/pwpc/ not /pwpc/)
×
×
  • Create New...