PW 3.0.201 – Core updates

[ryan]

This week we have ProcessWire 3.0.201 on the dev branch which includes a couple minor fixes but also a couple of useful additions:

There are new "Tab" field visibility options available for any field in the page editor. This makes the field display in its own page editor tab. It saves you from having to create a new/separate Tab field just to wrap around an existing field to make it display in a tab. So far I've found it particularly useful with ProFields (Combo, Table, Textareas, RepeaterMatrix) as well as the core Repeater, FieldsetPage and Images fields.

For instance, I have a Combo field labeled "SEO" that lets me edit browser_title, meta_description, canonical_url, etc., and now I can add that field to any template and pages using that template have their own "SEO" tab. Sure you could do this before by creating a separate tab field with an "SEO" label, but now it's a lot simpler/faster, as any field can now display as a tab on its own.

Like with the other visibility modes, also included are options to make the tab load dynamically on click with ajax or make the value non-editable. You can also optionally specify a label for the tab independently of the field label. This is because usually you want tab labels to be very short (1 word is best) whereas field labels have no such need. Please note that this new Tab option is exclusive to the page editor, and in order to work the field must not already be in a tab.

Also added this week is a new $page->getMultiple() method. This method works the same as the $page->get() method except that it lets you retrieve multiple page property/field values at once and returns them in an array. For example:

$a = $page->getMultiple([ 'foo', 'bar', 'baz' ]);
list($foo, $bar, $baz) = $a; 

It also accepts a CSV string:

$a = $page->getMultiple('foo,bar,baz');

By default it returns a regular PHP array, suitable for using in list() like the first example. But if you want it to return an associative array instead, then specify true as the 2nd argument:

$a = $page->getMultiple('foo,bar,baz', true);
echo $a['foo'];
echo $a['bar'];
echo $a['baz'];

I find this method useful in reducing the amount of code/lines necessary in many cases, and most often I use it in combination with a PHP list() call, i.e.

list($title,$subtitle,$body) = $page->getMultiple('title,subtitle,body');

That's all for this week. Thanks for reading and have a great weekend! 
 

[MateThemes]

@ryan Thanks for that great update!

[bernhard]

Hey @ryan thx for the tab update ? 

I've played a little with the getMultiple() method. Not sure if I'll use it a lot or not, but taken this example:

On 5/27/2022 at 7:16 PM, ryan said:

$a = $page->getMultiple([ 'foo', 'bar', 'baz' ]);
list($foo, $bar, $baz) = $a; 

I'd prefer this:

extract($page->getMultiple('foo,bar,baz', true));

So I was wondering if we could have something like this?

$page->extract("foo,bar,baz");
echo "$foo<br>$bar<br>$baz";

But I think that is not possible without the extract() call, is it?

Also I'm wondering if using list() is better than using extract()? 

[ryan]

@bernhard

Quote

But I think that is not possible without the extract() call, is it?

That's correct, a $page->extract() wouldn't be possible as the extract() function has a unique ability to create variables, as far as I understand it. 

Quote

Also I'm wondering if using list() is better than using extract()? 

The issue with extract() is that any variables it creates are unknown to your editor/IDE, and often times to the caller too. Whereas list() is defining variables in a visible manner that is readable and known to the IDE, clearly identified in the code as $variables. I rarely like extract() in code because it's too ambiguous, like tipping over a box of an unknown items and quantity. But there are times that's exactly what's intended, like in the TemplateFile class, where it has to pass an unknown set and quantity of variables to a php template file and make them directly accessible by $variables. This is fine because the php template file knows what variables to expect even if the class that provided them (TemplateFile) doesn't. So I think extract is good for cases like that, but otherwise I think it's preferable to have some kind of variable definition whether $name = 'value'; or list($name) = [ 'value' ]; etc.  

[cb2004]

Loving the tab feature, great addition. Can this be used within a combo field to group the subfields together?