Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 03/09/2021 in all areas

  1. This is a classical distributed systems problem: Your options are idempotency, reserving limited resources early and implementing compensation actions (e.g. compensating for missed payments by freeing the resource again). At some point it might even be useful to involve humans instead of trying to cater for each error case in code. The other part as @Jan Romero pointed out: Give whatever you sell identities. Instead of decrementing number of event tickets available create 100 tickets upfront and link them to orders. A ticket not linked is a ticket available. This is a more natural and easy to understand way of dealing with the domain. In the real world you also first print X tickets before they can be sold in retail. Same should apply to your spaces. Take that from someone having build a system similar to like you intended in a not so critical space (a handful of tickets more are not critical) and while not having completely regretted it I could soon see the problems of it.
    3 points
  2. There's a small but important difference between wire() and $anything->wire(). The first is the wire() function defined in Functions.php and documented here. The other is the Wire::wire() method you linked to. The first one just retrieves values but can't set them. So it's more of an inconsistency between those two than a bug.
    2 points
  3. Ticket vendors often temporarily reserve the space as soon as it’s added to the cart. You could use that to count towards the occupied spaces and remove the reservation if the transaction isn’t finalized in time. For example you could store the time of the reservation and to calculate availabilty subtract completed bookings as well as reservations younger than 15 minutes or so.
    2 points
  4. ProcessWire 3.0.173 adds several new requested features and this post focuses on one of my favorites: the ability to hook into and handle ProcessWire URLs, independent of pages— https://processwire.com/blog/posts/pw-3.0.173/
    1 point
  5. JL2 uses FastRoute to do what's being done here, although it obviously needs to hook into the 404 process in order to work. The reason I picked FastRoute was because, at the time, I simply didn't like the approach in current v1, and wanted something a little more robust, feature reach, and fast. JL2 could use this new feature (which is a great addition to PW), though some additional work would need to be done to make the URIs transform to the regex approach being used here, which is quite different. That aside, I'm afraid JL2 on hold, once again. Simply don't have the time to take it on right now, and doubtful that I will any time soon. In all honesty, I would be much happier if someone were to take the project over and give it new life. It's been in the pipeline for a long time now, and it's really come down to me making promises I uninentionally couldn't keep, much as I wanted to be able to. So, if anyone is able and willing to take it over, please feel free to pop me a DM.
    1 point
  6. https://github.com/processwire/processwire-issues/issues/1345
    1 point
  7. $this->rm()->migrate([ 'pages' => [ 'home' => [ 'title' => 'system', 'parent' => 0, 'template' => 'home' ] ] ]); This just changes the title, for simplicity. The original changed other fields and was part of a bigger migration. But running just this should highlight the issue.
    1 point
  8. Hi @teppo - thanks for the update. I was a bit confused about how to get the update to trigger. Turns out I had to visit the settings page for the ProcessChangelogHooks module and then I got the notice and the update worked as expected.
    1 point
  9. @adrian It's like an index for page URLs/paths. Usually PW has to join every page in a query in order to know its URL. So the PagePaths module provides a more direct and theoretically faster route. But in my experience, it's not really faster until the URLs get long (like in cases where PW would have to do lots of joins to determine the URL otherwise). The other thing it does is that it lets you perform $pages->find() partial text matching operations on the url/path, which you can't do otherwise. The only place where it adds overhead is if you change the name of a parent page, it then has to re-index all the URLs for everything below the parent. It's not installed automatically because most people don't need it, and it doesn't support multi-language URLs. But it's handy to have when it crosses over with your needs. I'm good to provide an option for findRaw to return an array of basic objects if one requests it in the $options. But for most I would suggest sticking to the array because it's good for it to be clearly different in syntax from a regular page. That's because it's all raw and unformatted data, so it's not going to be safe to swap between find() and findRaw() in most cases and good to maintain clear differentiation. For instance, when using something from findRaw() for output, you've got to be sure to entity encode anything you output, etc. Plus, one reason for findRaw() is to provide the lowest level path to the raw data, and I think a PHP array is probably the lowest level, least overhead way of doing that. But having an option/alternative for a std object seems fine to me.
    1 point
  10. If you use $myPage->render() you can use the options array: echo $myPage->render(['lol' => 'dongs']); /////// then on $myPage’s template ///////// echo $options['lol']; Or you could just add the property to the Page object: $myPage->set('lol', 'dongs'); echo $myPage->render(); /////// then on $myPage’s template ///////// echo $page->lol;
    1 point
  11. You can do that with hasChildren() just like you proposed, but you have to get the grandchild first. If you want to get the first child of $page and then the first child of that, and then check if that has children, you can do $page->child()->child()->hasChildren(). You can also put selector strings between each of the parentheses to only get specific children. Yeah, I’m pretty sure this should work: $pages->count("has_parent=$child, template=tops|tops2, projekt_top_vermietet=1") If you already know there aren’t any other templates under $child, you can just remove the template selector entirely.
    1 point
  12. That's what it says in the title of this request: "or maybe a findOneID()" ? I completely agree that getID works as it should. I think that perhaps has() is a confusing term given what it does - it's hard to know by its name whether it will work like a get or a find (ie with exclusions or not). But, we also clearly agree on that ? Request just posted: https://github.com/processwire/processwire-requests/issues/394
    1 point
  13. Just an observation, thanks to Tracy's Selector Queries (Debug Info panel), both the has() and getID() methods use the same query.
    1 point
  14. The following are a few links for you to check out: Wiremail Wiremail Class: https://processwire.com/api/ref/wire-mail/ Wiremail Related Modules https://processwire.com/modules/category/email/
    1 point
  15. Ok, I think I got this figured out. When you call something like $map->render($page, 'map', array('id' => 'jsMap',)); with the id option the wrapper MarkupGoogleMap js object is created with the same name as id provided. The google maps object is accessible as its map property, like this: jsMap.map; with all the good stuff from the API at your disposal.
    1 point
  16. One last attempt to suggest using the api, then I'm gone Instead of changing your source data, you can let the API create the pages for you when needed. So for a (simplified) table like this: Bibliography Type Document Title ----------------- ---------------------- Book Interesting Book 1 Book Interesting Book 2 Magazine Fascinating Magazine 1 .... you could use the following code, which automatically creates the pages for you function getBibliographyType($name) { $template = 'bibliography-type'; $parent = $pages->get('/bibliography-types/'); static $bibliographyTypes = array(); if (isset($bibliographyTypes[$name])) { return $bibliographyTypes[$name]; } else { // Create the bibliography-type page $p = new Page(); $p->template = $template; $p->parent = $parent; $p->name = wire('sanitizer')->pageName($name); $p->title = wire('sanitizer')->text($name); $p->save(); // Save bibliography type id for future calls, avoiding calls to the database $bibliographyTypes[$name] = $p; return $p; } } $f = $page->import_file->filename; $csvDelimiter = ','; $csvEnclosure = '"'; $templateName = 'Document'; $parent = $pages->get('/documents/'); while (($data = fgetcsv($f, 0, $csvDelimiter, $csvEnclosure)) !== false) { $bibliographyType = getBibliographyType($data[0]); $title = $data[1]; $p = new Page(); $p->template = $templateName; $p->parent = $parent; $p->name = $sanitizer->pageName($title); $p->title = $sanitizer->text($title); $p->bibliography_type = $bibliographyType; $p->save(); }
    1 point
×
×
  • Create New...