Weekly update – New blog: field and template scalability upgrades

[ryan]

This week we have some great performance and scalability improvements in the core that enable lazy-loading of fields, templates and fieldgroups, thanks to @thetuningspoon — 

https://processwire.com/blog/posts/field-and-template-scalability-improvements/

[pwired]

I feel real good about this scalability and speed tuning with the fields and templates.
Big thanks fly out to the tuning spoon and ryan.

[kongondo]

@thetuningspoon, massive thanks for the POC!

@ryan

1. If I am editing a page with lots of repeaters on it (hundreds), would the new lazy loading improve (ProcessPageEdit) performance? This is aside from the current ajax-loading of repeater fields.
2. Are you able to share (a gist maybe?) the script you used to automate the creation of fields, templates and fieldgroups please? It might help others quickly replicate your test install in order to help with testing this new feature. 

Thanks.

[ryan]

@kongondo

Quote

If I am editing a page with lots of repeaters on it (hundreds), would the new lazy loading improve (ProcessPageEdit) performance? This is aside from the current ajax-loading of repeater fields.

It could but I would guess your bottleneck is quantity of pages, not fields or templates (?). So unless you literally mean hundreds-of-repeater-fields, for your case I think you'd want to enable the ajax loading features of the repeater (if not already) as that would make a big difference. 

Quote

Are you able to share (a gist maybe?) the script you used to automate the creation of fields, templates and fieldgroups please? It might help others quickly replicate your test install in order to help with testing this new feature. 

It was a one-off thing that I used and deleted. Writing in the browser so it may need adjustment, but here's something similar (though a bit simpler than what I used): 

$fieldtype = $modules->get('FieldtypeText');
$title = $fields->get('title');

for($n = 0; $n < 1000; $n++) {
  $field = new Field();
  $field->type = $fieldtype;
  $field->name = "test_$n";
  $field->label = "Test field $n";
  $fields->save($field);

  $fieldgroup = new Fieldgroup();
  $fieldgroup->name = "test-$n";
  $fieldgroup->add($title);
  $fieldgroup->add($field);
  $fieldgroups->save($fieldgroup);

  $template = new Template();
  $template->name = "test-$n";
  $template->label = "Test template $n";
  $template->fieldgroup = $fieldgroup;
  $templates->save($template);
}

@ErikMH

Quote

I’ve been running 3.0.184 for a while now, so it’s possible that new errors that I’m seeing are due to an intervening change, but with 3.0.193 I’m getting lots of NullPage errors when dealing with parent pages (and, I’m guessing, other related pages) in methods defined in custom page classes.

I'm not aware of any recent changes that would affect pages in that manner. But for your code, I would drop the $me = wire($this); there is no $me, there is only $this. ?  And rather than referring to $me->parent; refer to $this->parent(); with the parenthesis, so that it is a method call rather than a direct access property. Since you are "inside" of the Page class here, the interface is a little lower level than if you are outside of it. Usually it doesn't matter but in this case of things like "parent" I think it might be safer to method calls rather than properties, because these things are dynamically loaded and so accessing the method ensures that happens. 

[kongondo]

@ErikMH. As requested, I have split the posts relating to your NullPage errors into its own thread ?. @bernhard, @adrian just tagging your for FYI. Thanks.

 

Edited March 27, 2022 by kongondo