Weekly update – 24 May 2024

[ryan]

This week on the dev branch are a few updates to the core including the following:

Support for Inputfield header icon actions defined in PHP. If you recall, a couple weeks ago we released header actions for Inputfields via the JS Inputfield API. Robin S requested that the same be available from the PHP Inputfield API, and now it is. More details can be found in the phpdoc for the Inputfield::addHeaderAction() method here.

New link action was added to Inputfield header actions. This was also added by request and it's another type of header action that simply links to a URL. It can optionally be opened in a modal window. 

The $database API variable has been updated with a new $database->reset() method which resets the database connection. This is potentially useful after a "MySQL server has gone away" type error, to re-establish the connection. The $database->execute() method also now uses it to attempt to reestablish the connection (for a few tries) when appropriate. Though I've not yet been able to test this one with an actual lost connection. 

There were various other minor updates, optimizations and fixes this week as well.

In addition to the above core updates, we've got a new version of the UserActivity module (v8) posted in the ProDevTools support board. This version adds support for the PageEditChildren module and can properly identify which child pages are being edited alongside the parent. Previous versions only identify the page open in the page editor, and not the children open in PageEditChildren.

Thanks for reading, have a great weekend!

[Robin S]

1 hour ago, ryan said:

Support for Inputfield header icon actions defined in PHP.

Awesome, thanks @ryan!

[bernhard]

13 hours ago, ryan said:

It can optionally be opened in a modal window. 

Hey Ryan, thx for these additions! I'm wondering if there is a way to open a modal and then react/wait for something within that modal. For example we could maybe create an action for a page reference field to create a new page. When the page is successfully created in the modal and the modal is closed we could trigger the inputfield's reload event and the user could instantly select the newly created page.

[Jonathan Lahijani]

@ryan For PageEditChildren, would it be a stretch to have it support editing a children's children from the grandparent page as well?

I typically have an /options/ page, and under it I have my page-based options... for example "Colors", "Sizes", "Order Statuses", like this:

• Options (template is 'options')
  • Colors
    • Red
    • Green
    • Blue
  • Sizes
    • Small
    • Medium
    • Large
  • Order Statuses
    • Pending
    • Canceled
    • Complete

If I were to activate the 'options' template in PageEditChildren, I will be able to edit only the "Colors", "Sizes" and "Order Statuses" holder pages, not their children (from within the holder pages) which are the actual options themselves.  Is there a way to perhaps support this?  This is something I've been meaning to address more nicely in the past, but PageEditChildren would solve it with being able to edit grandchild pages.

[Robin S]

4 hours ago, Jonathan Lahijani said:

For PageEditChildren, would it be a stretch to have it support editing a children's children from the grandparent page as well?

Ryan said in the previous announcement that you can use a hook to set which pages become editable.

Quote

Another example is that it can edit any pages this way, not just children. For that reason, I put in a hook: ___getChildren($page) so that anyone can override what are the "children" for the page.

So you could use this to make the grandchildren editable, or the children and the grandchildren if you wanted the child pages to serve as a kind of visual divider between the categories of options.

Edit: example...

// Define custom "children" for PageEditChildren
$wire->addHookAfter('PageEditChildren::getChildren', function(HookEvent $event) {
	/** @var Page $page */
	$page = $event->arguments(0);
	if($page->template == 'blank') {
		$items = new PageArray();
		foreach($page->children as $child) {
			$items->add($child);
			foreach($child->children as $grandchild) {
				$items->add($grandchild);
			}
		}
		$event->return = $items;
	}
});

// Hook rendering of PageEditChildren "child" fieldsets
// to apply a data attribute for identifying the template
// It would be cool if PageEditChildren did this by default
$wire->addHookBefore('InputfieldFieldset::render', function(HookEvent $event) {
	/* @var $fieldset InputfieldFieldset */
	$fieldset = $event->object;
	$wrap_class = $fieldset->wrapClass();
	if($wrap_class !== 'PageEditChild') return;
	$attr = $fieldset->wrapAttr();
	if(!isset($attr['data-page'])) return;
	$p = $event->wire()->pages->get($attr['data-page']);
	if(!$p->id) return;
	$fieldset->wrapAttr('data-template', $p->template->name);
});

Custom admin SCSS:

li.PageEditChild[data-template="references"] {
	> .InputfieldHeader { background-color:#f0f3f7 !important; }
}

[Jonathan Lahijani]

@Robin S Thanks for that detailed example.  I actually did experiment with that hook before my post as well, and as your example demonstrates, you kind of have to hack it to show grandchildren in-line with their parents.  Sorting then becomes weird because they are technically at different depths.  This isn't the best UX.

Ideally, if you expanded/opened the "Colors" child page, then it would show it's children "contained" inside of it, in a way that's somewhat similar to nested repeaters without repeaters.  I was wondering if native support for the approach I described would be too much of a stretch given how PageEditChildren is currently programmed.

[Ivan Gretsky]

On 5/24/2024 at 11:51 PM, ryan said:

Support for Inputfield header icon actions defined in PHP. If you recall, a couple weeks ago we released header actions for Inputfields via the JS Inputfield API. Robin S requested that the same be available from the PHP Inputfield API, and now it is. More details can be found in the phpdoc for the Inputfield::addHeaderAction() method here.

Great stuff! Thanks for this @ryan! I think that another great thing to have would be custom repeater item actions. As far as I understand, we now cannot add any of these. But they could be as useful. Especially for repeater matrix based content builder setups.