Leaderboard

@Robin S @bernhard @teppo I would say it's less important to limit how many fields you create than it was before, but it's still worthwhile to make efficient use of fields for other reasons (at least for the way I work). But the technical reasons for doing so appear to be much less than before. If you look here at the performance numbers on a system with 1000 fields you can see that prior to lazy loading, it took 0.5167 ms (half second) to load the fields. This might sound reasonable, but note the fields were created with an automated script and not as diverse as they would be in a real environment, so I'd expect the numbers to be higher/slower in real life. After lazy loading that part of the boot process was reduce to 0.0062 ms. Even without lazy loading enabled, the field loading was reduced to 0.0322 ms (in that 1000 field environment) just due to the other optimizations made in support of lazy loading. So there's some question as to whether lazy loading is even necessary anymore now that everything else more optimized. But using less time and energy is always good thing, even if not felt on individual requests, small differences add up to significant numbers over thousands of requests. The way lazy loading works is that everything in the database table (for fields, templates, fieldgroups) still gets selected and loaded, but into an array rather than into objects. That data doesn't get loaded into and converted to actual Field (or Template, Fieldgroup) objects until that specific object is requested. TheTuningSpoon found that overhead came from actually creating and loading the objects rather than selecting them from the DB, and I was able to confirm that. But it also means that the more fields you have, the more memory they will consume. But the memory consumed by the raw field data is very little and I think you'd have to have many thousands of them for it to even be a consideration. Lazy loading fields don't change the way I use fields, at least. I like to have as few fields as necessary just because it's easier for me to keep track of, fewer things to remember when writing code, fewer things to manage during changes, etc. But if your workflow is like the one Bernhard describes above then that seems like a case where more fields would appear to be a benefit.

For me the opposite is true ? The main reason for that might be my workflows around RockMigrations and custom page classes. Having the fields defined in code directly in the page class is so much easier for me than any other approach I tried. So those additions where very welcome ones for me ? Need some new data for a boat? Go to the boat pageclass file and add a field there. Need a new field for every blog post? Go to the blog post pageclass file and add it... I'm only sharing fields across templates (page classes) when they really have the same purpose (eg a RockMatrix field for the pages content that has several content-blocks like headline, text, quote, etc that should be the same for templates home, basic-page and blog-item). So adding a new content block like "image" for example would make it available on all those templates immediately compared to having to update all templates one by one and adding the new image block to three different fields. For me it feels a lot better to have a single field for a single purpose. Sharing a field for different purposes by overriding settings in template context never felt good to me... I'm using template context a lot, but only to do simple modifications like tweaking the field's label (eg of the title field). One huge benefit of such an approach can be that you get reusable components that you can simply copy from one project to another. That's because the page classes do NOT share fields with other components of your site and therefore are self-contained parts that work on their own. That would not be possible if you shared fields from a central place. Or it would be a pain to reuse single parts of that website. I have been there. I don't want back ?

Wow, what an awesome list of improvements! @ryan, I have a question about the lazy-loading of fields. Do you think this change means that the previous recommendation to reuse fields, as in the "Making efficient use of fields in ProcessWire" blog post, is now no longer needed? Say I am using text fields in lots of different templates for different purposes, and if I create and name fields so they describe the use in each template I will have 50 text fields, or if named them generically and reused them I would have maybe 5 text fields. Is their any reason now to prefer the 5 fields option over the 50 fields option, given that in any one template I'll only have 5 text fields or less and so presumably only ~5 or less fields get fully loaded at a time?

I know this is not exactly what you were asking for, and it's based on an older version of PrivacyWire so there may be an easier way to do it now, but here's how I handled a similar need (just in case it's of use to you or someone else here): <script> window.cookieConsentUpdate = function(do_update) { do_update = typeof do_update === 'boolean' ? do_update : true; let privacywire_data = window.localStorage.getItem('privacywire') ? JSON.parse(window.localStorage.getItem('privacywire')) : ''; window.cookie_consent = { 'necessary': privacywire_data ? (Boolean(privacywire_data.necessary) ?? true) : true, 'functional': Boolean(privacywire_data.functional) ?? false, 'statistics': Boolean(privacywire_data.statistics) ?? false, 'marketing': Boolean(privacywire_data.marketing) ?? false, 'external_media': Boolean(privacywire_data.external_media) ?? false }; if (do_update) { // this is where you could send data to GA etc. } } window.cookieConsentUpdate(false); </script> Now just have this function run when cookie settings are changed; do_update will default to true, and any custom code in the if block will be triggered.

It's not often I stumble on parity like this, so grabbed this screenshot for posterity ?.

Congrats @ryan that's a really great achievement ? Also thx to @matjazp for all your help on the github issues - great work!

This new main/master version has more than 220 commits, resolves more than 80 issues, adds numerous new features, performance improvements and optimizations, and consumes HALF the disk space of our previous release— https://processwire.com/blog/posts/pw-3.0.200/ I've just merged the dev branch to the master branch so this new version is available now. I will add the 3.0.200 tag (which should trigger packagist and others) over this weekend or Monday.

If you want to pre-set the third option within the selectable pages: $wire->addHookAfter('Pages::added', function(HookEvent $event) { $page = $event->arguments(0); // Only for the booking template if($page->template != 'booking') return; // Get all the selectable pages for the field $selectable_pages = $page->getInputfield('booking_searchactivator_option')->getSelectablePages($page); // Get the third selectable page (the numbering is zero-based) $third_selectable_page = $selectable_pages->eq(2); // Set the third selectable page as the field value $page->setAndSave('booking_searchactivator_option', $third_selectable_page); });

Thx @skeltern could you please report your findings here: https://github.com/processwire/processwire-issues/issues/1341

Same here. I found out that fieldtype decimal is not ready for different locale settings. English with '.' separator works perfect. But. If you have for example installed the German lang pack or default lang is German the separator is now ',' and not a dot. Defined by correct locale 'de_DE.UTF-8' in language > translate > LanguageSupport.module. As German backend user already filled decimal fields are just showed and saved as blank. Plus you can't add correct data as German editor. It gets always cutted to integer without all digits. I was so pleased about this decimal feature. Unfortunately state today it's only safe usable by single language sites with '.' as language decimal seperator. Only one language with different decimal seperator could result in serious trouble and lost of field values by editing pages... I think this module multilang problem is fixable. Fieldtype float works in same language contexts correct. Maybe with a bug report.

Also curious about this one. Is lazy-loading enough to make number of fields a non-issue? Mostly just thinking out loud here, but I do see at least one benefit in sticking with fewer fields: your fields may remain more manageable, especially if the alternative is to have a lot of very specific fields. Consider having to make the same change to settings of 50 fields compared to 5 fields, for an example. (Of course assuming that they are identical enough for this to make sense in the first place.) On the other hand I guess that under some circumstances more fields could even be good for performance, considering that each field has a separate table. This seems unlikely to cause noticeable difference, though, unless we're talking about an absolutely massive scale ?

Nice work as always.