thetuningspoon

Members
  • Content count

    572
  • Joined

  • Last visited

  • Days Won

    2

thetuningspoon last won the day on May 8 2015

thetuningspoon had the most liked content!

Community Reputation

394 Excellent

2 Followers

About thetuningspoon

  • Rank
    Hero Member
  • Birthday 11/03/1986

Contact Methods

  • Website URL
    http://www.solutioninnovators.com

Profile Information

  • Gender
    Male
  • Location
    CT, USA
  • Interests
    Design, Programming, Tiny Houses

Recent Profile Visitors

11,350 profile views
  1. We are putting PW through its paces on one of our projects. Currently we have 3.5 million pages and counting. Everything has been scaling well and is running great, except for some of our selectors that use subfields. Our project involves physical units (represented by PW pages) that transmit their status to our application each day, resulting in a new page for each transmission. We are using a page field on the unit to store a reference to its latest transmission. We then need to filter the units by their last transmission date, so we are using the following selector: $pages->find('template=unit, last_transmission.date_field<-1 day, last_transmission.date_field>=-7 day, sort=created, limit=10'); Once we had several thousand unit pages in the system, this selector began to fail. After doing some debugging to see what SQL PW was actually producing, we discovered that the problem was that the selector was generating three separate sql queries. One returned the ids of all of the units that had a last_transmission date greater than a given timestamp, one returned the ids of all the units that had a date less than a given timestamp, and the last took the results of the other two queries and applied any remaining selectors. Since there were several thousand units, the first two queries caused a memory error. We resolved this issue by using the created date instead of a custom date field on the last transmission, so the selector changed to: $pages->find('template=unit, last_transmission.created<-1 day, last_transmission.created>=-7 day, sort=created, limit=10'); For some reason PW was able to combine this into a single SQL query, whereas it was unable to do so with the custom field. Not sure if this is the intended behavior or not, but it looks like this is an area of PW core that might be improved upon. Has anyone else come across this issue and are there any other workarounds I might not be aware of?
  2. @kongondo Correct, I only want Page and not Child 1. Though it doesn't matter if Child 1 is matched too, because it has a different template from Page and I can exclude it by specifying the template in the selector. @tpr I tried your suggestion yesterday after seeing your post. The example I gave in my initial post was oversimplified. My selector is actually more like children.children.pageField=123 So that didn't work. Any ideas? I restructured the page tree to get things working for now (the pages I'm referencing in the selector are now direct children), but this may not be ideal in the long run.
  3. Just ran into a requirement on one of my sites which I don't think PW supports yet. I'm trying to match all pages that have a certain child, but the child is not an immediate child of the page. It is two levels down: Page -- Child 1 ---- Sub-child 1 ---- Sub-child 2 < I only want to select the parent Page if this one exists -- Child 2 This would be similar to the has_parent selector, but in the opposite direction. I searched the forums but didn't find any discussion of this feature/request. I seem to recall seeing it brought up at some point in the past, though.
  4. https://github.com/processwire/processwire-issues/issues/379
  5. @bernhard This looks amazing! I developed a CRM for a customer using ListerPro with some custom enhancements, but this is another level up! Must have been a LOT of work. Hope you were paid well
  6. @Robin S No, I am using ID. It works fine when editing the user in ProcessPageEdit (or from Access/Users), but not ProcessProfile.
  7. I just ran into this same issue. I tried to make a field dependent on one of the roles and it broke the profile, even though neither the roles field or the dependent field were visible in the profile at all. I created a copy of the ProcessProfile module under /site/modules/ and replaced this: if(count($form->getErrors())) { $this->error($this->_("Profile not saved")); return; } With this: $errors = $form->getErrors(); if(count($errors)) { if(count($errors) == 1 && strpos($errors[0], 'showIf') !== false) { // Everything is okay } else { $this->error(implode('; ', $errors)); // Show the actual errors instead of just a generic message return; } } This way if there is only one error message and it is related to a 'showIf' field dependency, the form will save anyway.
  8. I did try turning off SessionHandlerDB and using php's session_write_close() and that didn't seem to help either. I think I also tried $session->close() (which just calls php's function). Moreover, there are a couple ajax requests which do need to be able to write to the session, so a blanket session_write_close if $config->ajax is true wouldn't solve my issue Edit: I am going to try Redis. Will let you know how it goes.
  9. I am having trouble with executing multiple AJAX requests at the same time. The response is very slow and seems to be synchronous instead of asynchronous. I am using jQuery's ajax() function, so I don't think there's any issue on the client side. I think it is an issue with Session locking/blocking. I read somewhere that SessionHandlerDB would resolve this issue, but enabling it has not improved the situation any. I just want to confirm whether or not SessionHandlerDB is designed to handle concurrent requests efficiently, so I know what to rule out.
  10. @ukyo Is it possible to send each email individually, as with the base WireMail class? I tried the following, but it still includes all recipients in the email headers of each email that gets sent: foreach($recipients as $recipient) { $m->to(null); $m->to($recipient); $m->send(); }
  11. How are you calling WireMail? If you are using "$mail = new WireMail()" then I don't think it knows to use the WireMailPHPMailer module and will use the default WireMail() instead. Use "$mail = wireMail()" instead.
  12. Coming back to this... I just remembered that that this is what selector arrays were created for.
  13. @gebeer Thanks for that simple and effective solution! Note if you are using PW3 with namespaces you must use catch(\Exception $e) instead. The redirect at the end is optional. For my forms I only redirect on success.
  14. Just ran into this issue today. It seems like the subfield should disregard access settings since you are not actually getting the subfield, but are only checking for its relationship to the page you are getting. I see that there is still a todo note about this in FieldtypePage.module
  15. Thanks for that. I've read it over a few times now but I'm not quite getting it. How is this unnecessary? How else would one determine where each permission is applicable? Does he mean you could create a separate permission for each template, e.g. page-edit-home page-edit-basic-page, etc.? Yes, yes, yes... THIS sounds like the type of solution I would expect from ProcessWire. Simple, powerful, and un-opinionated. What became of this?