Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 11/15/2024 in all areas

  1. This week most of the core dev branch commits are related to minor fixes and improvements. While last week we added a new $page->preload() method, I’m going to avoid more major additions or features so that we’re not creating more things that need lots of testing. For that reason, the commits over the next weeks or month will be similar to those from this week, so that we can get a new main/master version out as soon as possible. I was just looking at the date of our last master version (3.0.229) and see that it’s been more than a year! It feels like it’s been 3 months to me — time sure does fly! Seeing how long it’s been definitely motivates me to not wait too much longer on this next main version. The current dev branch fixes and adds quite a few things relative to 3.0.229 as well, so I think of it as being the more stable version at this point… a good sign it’s about time for a new release version. Thanks for reading and have a great weekend!
    9 points
  2. Big thumbs up for that idea. If the timing is right, I might even make it to both, since I'm planning to head across the pond and hike the John Muir Trail next summer. Love the preload method. I've got a shop solution built on PW with about 120k orders and 150k order positions by now, all as pages. Performance is becoming a bit of an issue in the backend with long range price change statistics and detailed Excel exports, and this seems like a perfect use case.
    2 points
  3. This week on the dev branch, we have a new $page->preload() method that enables you to preload multiple fields in one query (in this GitHub commit). This is kind of like what the autojoin option does (when configured with a field), or what the $pages->findJoin() method does, but with one big difference. Those options happen as part of the page loading process. Whereas $page->preload() can be applied to a page that has already loaded. Here’s one example where you might find this useful. Say you have a page living at /products/product/ and it has a hundred fields. At the top of your template file that renders the page, you could have a $page->preload(‘field1’, ‘field2’, ‘field3’); to preload all those fields before outputting them. This enables you to load field1, field2 and field3 in 1 query rather than 3. On your first call to $page->field1 it won’t trigger a load from the database and instead will return the value that has already been preloaded. You can also call $page->preload(); without any arguments, and it will preload ALL the supported fields for the page. In reality, ProcessWire is already pretty quick with loading fields, so you probably won’t benefit from preloading until the scale is quite large. While developing this, I was testing by iterating 500 pages and accessing 50 different fields from each. Without preload this took 12 seconds. With preload it took 6 seconds. So for this particular case, preloading cut the time in half. I’m not a query counter, as very often lots of simple DB queries are faster than a single big query, but I’ll mention that it also reduced the quantity of database queries by more than a factor of 10. For this large scale case, that meant more than 20000 queries down to well under 2000. Like with autojoin, there are some limitations with preloading. It supports primarily Fieldtypes that use the core loading mechanism. Some Fieldtypes (especially non-core) override this, and preload() skips over those fields. It also skips over most FieldtypeMulti (multi-row fields), but FieldtypePage is supported when used with Page fields that carry one value. Multi-value can be enabled for testing with an option you’ll find in the function $options, but like autojoin, is limited by MySQL’s group_concat limit. By default that limit is 1024, which supports 140-170 page reference values in a given page field. That's quite a lot, but I don't want to assume folks won't go over that, so it's disabled by default. I’m guessing that most won’t need the preload() function, but a few might really benefit from it, especially at larger scale. So I think it’s a worthwhile addition to the core, and another method that answers a need that may arise as an installation grows, further supporting ProcessWire’s ability to scale up as needs do. Though consider it experimental and "work in progress" at the moment, as we’ll need to do more testing to make sure it is fully stable in a broader range of situations, and further improvements are likely. Special thanks to @tuomassalo at Avoine who came up with the idea for preload() and helped me to get started developing it. Last week I told you how Pete, Jan and I met up in Holland. I also wanted to mention, a couple weeks ago, right before I left for Amsterdam, Oliver from @update AG (update.ch) in Zürich, Switzerland sent me a DM saying that he was in my neighborhood, so we got together for coffee near my house. They’ve been using ProcessWire at Update AG almost as long as PW has been open source, so it was good to meet another long time ProcessWire user, and a nice coincidence that he was in the neighborhood. It’s always great to meet ProcessWire users in person and I hope to meet more of you in the future as well. Thank you for reading and have a great weekend!
    1 point
  4. No worries at all, I always figure that if something gets posted in the forums it will end up helping someone!
    1 point
  5. @FireWiresorry, I totally did not see AsmSelect in the list albeit it being the very first item. Strange things happen sometimes...
    1 point
  6. @gebeer Was a good idea to double check, in the example documentation in the module it shows compatibility. I do see AsmSelect in the list of approved fields on that blog post. <?php /** * Page reference fields * * All Page reference Inputfields need to have at least the following * properties defined: * * - `derefAsPage` (int): Whether it single or multiple mode: * * - `0`: Multiple page (PageArray). * - `1`: Single Page or NULL when empty. * - `2`: Single Page or NullPage when empty. * * - `inputfield` (string): Which input class to use, can be any of the following. * You can specify the Inputfield class name or optionally omit the `Inputfield` * prefix, like the options below: * * - `select`: Select one via standard select. * - `selectMultiple`: Select multiple via multiline select. * - `radios`: Select one via radio buttons. * - `checkboxes`: Select multiple via checkboxes. * - `asmSelect`: Select multiple/sortable via asmSelect. * - `pageAutocomplete`: Autocomplete for single or multiple selection. * - `pageListSelect`: Select one page from tree. * - `pageListSelectMultiple`: Select multiple pages from tree. * - `textTags`: Select one or multiple via text tags input. * */ I also tested it in a vanilla repeater field and wasn't able to replicate the issue there. Using the field in a repeater applies a unique suffix: event_activities_select_repeater5720_activities[]
    1 point
  7. The list of currently supported inputfield types under heading "Possible values for “type”" at https://processwire.com/blog/posts/custom-fields-module/ does not list AsmSelect which you chose for your page field (multiple) based on the screenshots. Maybe this is the issue? Have you tried field type SelectMultiple instead of AsmSelect?
    1 point
  8. Just ran into this issue on a site and found this. Worked like a charm! If you have pages with a large amount of fields or a lot of data that may change, keep this tip in your back pocket. @elabx Many thanks 🙏
    1 point
  9. @TomPich Thanks, that was helpful, error found. I had a } error in schema.org in my prepand file. No idea why I didn't see that.
    1 point
  10. Yes, that would be great! Count me in (for Europe !) 😊
    1 point
  11. I find that the "number" input type is an enhancement for fields that are only to contain whole numbers. It lets you use the spinner arrows at the right of the input or your keyboard arrow keys to increment the number up and down, and it avoids invalid decimal or text values from being entered into the field. The PW admin uses number inputs for InputfieldInteger in some places but these are not used consistently and I regularly find myself trying and failing to increment values in an integer field that isn't using input type number. For example, in the "Rows" setting of a textarea field. With a simple hook in /site/ready.php you can ensure that all integer fields use input type number: $wire->addHookAfter('InputfieldInteger::renderReadyHook', function(HookEvent $event) { $event->return->type = 'number'; });
    1 point
  12. @bernhard Sorry, it's 2:40am here and I'm migrating servers. My brain is a little fried and I misread what you typed. I'll check it out when I can.
    0 points
×
×
  • Create New...