thetuningspoon

Members
  • Content count

    594
  • Joined

  • Last visited

  • Days Won

    2

thetuningspoon last won the day on May 8 2015

thetuningspoon had the most liked content!

Community Reputation

442 Excellent

3 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,715 profile views
  1. thetuningspoon

    @netcarver Thanks for chiming in. I just submitted a pull request on GitHub. Looks like I had submitted a bug report at the time, which this pull request resolves. I also added a password config option, and made some change to the read() method (but I don't remember what it's doing exactly).
  2. thetuningspoon

    An update on this for others: Using Redis for sessions solved the problem for me. I had to make some changes to the module to get it to work right (if anyone wants my code, let me know). Today I happened to try migrating my project from using ProcessWire's default MyISAM database engine to using InnoDB (had to convert all tables and set $config->dbEngine in site/config.php). I was playing around with the demo version of my system (which is not using Redis). And interestingly enough, I THINK this (in combination with SessionHandlerDB) actually resolved the issue with simultaneous ajax calls! Perhaps this is because InnoDB has row-level locking instead of table-level locking?
  3. thetuningspoon

    You should be fine using the native $_SESSION, although PW also provides the $session api variable if you want to use it (store vars using $session->myVar = $myValue and retrieve with $session->myVar). I am suspicious that something else is causing your problem.
  4. thetuningspoon

    Eyup, good point. Which is why this can come in handy.
  5. thetuningspoon

    What I meant was whether PW was using the same basic flow: Converting a selector to an SQL select statement, getting the IDs of the matching pages, and then calling getById() to load the actual pages into a PageArray. I spent this morning doing a deep dive into the core and have confirmed that this is how it's working. I was also able to simplify the example by @LostKobrakai to the following: $pf = $this->pages->getPageFinder(); $query = $pf->find($selector, ['returnQuery' => true]); # Show sql //$query->getQuery(); # Modify query //$query->where($sql); $statement = $query->execute(); $statement->execute(); # Load the pages $ids = array(); while($row = $statement->fetch()) $ids[] = $row[0]; $myPages = $this->pages->getById($ids); I haven't solved the pagination side of things yet. Unfortunately PagesLoader::find() is doing quite a bit of work that we're not able to take advantage of due to the fact that we have to bypass it completely and go straight to PagesLoader::find() in order to get the DatabaseQuerySelect() object. I'm not sure if this problem can be solved without modifying the core or duplicating a lot of its code. For future reference, this is the basic flow of a Pages::find() call (sans various options and some intermediary methods): Pages::find() Does nothing on its own. Delegates to PagesLoader::find() PagesLoader::find() Checks for page in runtime cache, returns cached page if it's in memory Creates a selector object from your selector string (PageFinder::find() can also do this, as I discovered) PageFinder::find() Turns selector object/string into a ProcessWire DatabaseQuerySelect object (via PageFinder::getQuery()) Turns DatabaseQuerySelect into an SQL select statement and queries the database Returns a multidimensional array with the ID, parent ID, and template ID of each matching page (OR a ProcessWire DatabaseQuerySelect object if the $returnQuery option is true) PagesLoader::getById() Takes an array of IDs Creates a page object for each ID and populates it with fields from the database (an additional database query). This is where any autojoin fields are pulled from the database. PagesLoader::find() Sorts pages by template (?) Sets up pagination Returns final PageArray
  6. thetuningspoon

    This seems to do it: $pf = $this->pages->getPageFinder(); $selector = new Selectors($selector); $query = $pf->find($selector, ['returnVerbose' => true, 'returnQuery' => true]); $statement = $query->execute(); $statement->execute(); $ids = array(); while($row = $statement->fetch()) $ids[] = $row[0]; $myPages = $this->pages->getById($ids); Is this how PW constructs the PageArray during a regular $pages->find()? So even if you were autojoining all your fields, it is still doing one query to find the matching pages and then another separate query for each page to load the desired fields?
  7. thetuningspoon

    Yes, I understand. I meant how does it work under the hood. I guess path is a dynamic page property, so it requires constructing the page object to get it? You mean with a $pages->get()? Wouldn't that mean going back to the database again to build each page? Anyway, thank you for explaining further. At this point I am wondering if you can provide any insight to my original question, which was how I can modify the sql of a regular $pages->find() and then return the results as a PageArray.
  8. thetuningspoon

    @bernhard How does the closure thing work? Is it creating a page object for each result? Can you give an example of when the closure would be required? Thanks
  9. thetuningspoon

    @bernhard This looks very cool, but I am not totally clear on what it does and how it does it. Can you give me a semi-technical explanation of how your module works (inputs and outputs) and where it plugs into the core? What exactly does a call to RockFinder return? Is there a way to get page objects from the results if I don't need the scalability features of the module and just want a normal page array in the end? Can I still use pagination with the results? Also, as cool as your module looks (and it looks very cool), if what I'm wanting to do can be achieved easily with just the core, I'd prefer to keep it simple.
  10. thetuningspoon

    @LostKobrakai I've been playing around with your example here and it's really neat. I've been looking for a way to add or modify a selector with custom SQL. It looks like your onto something here. However, I can't figure out what to do after running the query. How to I convert the results into a PageArray? Also, I noticed in studying the core a bit that this technique bypasses some of what would normally occur in a $pages->find(), including (I think) setting up the pagination and the loadOptions. In my particular use case I have a selector that does exactly what I want, but need to add a custom ORDER_BY for a more complex sort than PW allows.
  11. thetuningspoon

    I get that, but if everyone is using their own helper libraries and different frameworks, you lose the great jQuery ecosystem and all the plugins and libraries built on top of it. You could end up having to include a bunch of code from different libraries that are doing the same thing in order to use the existing solutions you want. That feels like a step backward to me. I don't see why jQuery can't just be retooled so that it's using newer, faster technology under the hood, with the same compact, standardized api on the front end. Maybe have a legacy jQuery and a new, slimmer jQuery for those that don't need old browser support. Regarding jQuery and more advanced JS applications, I don't think jQuery should be thought of as competing against vue or react. It's at a lower level in the stack. It doesn't impose structure on your application, but that doesn't mean it prevents you from creating your own structure. Disclaimer: These are just my feelings as a developer who is still trying to build my applications largely server-side, where my ajax calls usually return blocks of html encoded within JSON instead of pure data structures. This keeps all rendering and business logic server side in order to keep the application code simple and DRY. Not sure if I really know enough about what I'm talking about when it comes to the new client-side development paradigm. I feel like both are reasonable approaches to development (depending on the application's requirements). It's when you don't choose one or the other that things really get messy and WET.
  12. thetuningspoon

    Sorry to say, whenever I see the vanilla JS alternatives to jQuery, it reminds me why I still use jQuery
  13. thetuningspoon

    @mel47 Thanks. I just pushed another release so the module will only load in the admin, as it was before. But it is still no longer limited to specific admin processes.
  14. thetuningspoon

    Just released an update on GitHub: -Added support for repeaters using the new InputfieldPage::renderReadyHook method (Will fall back to hooking into render if using on an older version of PW) -Specifying processes is no longer required (I'm not sure why I limited the modules use to just specific admin pages before, but there may have been a reason. Let me know if you see any problems with this) I looked into the possibility of making the modal optional, but it's not such a simple task with the way the JS is currently structured. I would like to do some refactoring, but not sure if/when I'll have the time.
  15. thetuningspoon

    @Kiwi Chris Did you try this? https://processwire.com/talk/topic/9857-module-page-field-edit-links/