PW 3.0.117 – Core updates

[ryan]

Work continues on the new processwire.com website, while the core received several updates including support for Markup Regions "pw-optional" attributes, upgrades to WireArray that make it a lot more useful, and more.

https://processwire.com/blog/posts/processwire-3.0.117-core-updates/

[szabesz]

"Now WireArray can be used on its own with just about any data type. No longer is this base class limited to working with just Wire-derived objects."

I've been longing for this for quite a while. Sometimes dreams come true ? Thank you Ryan!

[Robin S]

Those are some sweet updates Ryan!

Seeing as you've been working on transferring the blog posts over to the new processwire.com site, do you think you could add a feature so that blog posts automatically get anchors on every <h3>? There could be an automatic table of contents from those anchors if you think that would be good, but having anchors is the main thing.

Because there is so much useful documentation of features within the blog I often want to save references to specific sections within a blog post, or provide a link to a section in a forum reply. Having heading anchors would make it possible to do this.

[bernhard]

Yes! And a prev/next link on each post ?

Great updates! Love them ?

[arjen]

Nice, "pw-optional". Right now I'm finally back in ProcessWire re-building some websites and Markup Regions is a breeze to work with. 

[Ralf]

Help...

After the update from 3.0.98 to 3.0.118 the complete page doesn't work anymore ? 

there is only one error message left:

Parse error: syntax error, unexpected 'new' (T_NEW) in /www/htdocs/xxxxxxx/wire/core/WireArray.php on line 2480

 

this is the code in WireArray.php

	/**
	 * Create a new WireArray instance of this type, optionally adding $items to it
	 * 
	 * This method call be called statically or non-statically, but is primarily useful as a static method call. 
	 * 
	 * ~~~~~~
	 * // Create new WireArray with a, b and c items
	 * $a = WireArray::new([ 'a', 'b', 'c' ]);
	 * 
	 * // This also works when called statically (array syntax can optionally be omitted)
	 * $a = WireArray::new('a', 'b', 'c');
	 * ~~~~~~
	 * 
	 * @param array|WireArray|mixed|null $items Items (or item) to add to new WireArray
	 * @return WireArray
	 * @since 3.0.117
	 * 
	 */
	public function ___new($items = null) {
		$a = self::new($items);
		$this->wire($a);
		return $a;
	}

 

Could anybody help?

Thanks Ralf

[adrian]

@Ralf - I would recommend installing 3.0.116 for the moment. It looks like this is not the only bug introduced in 3.0.117 - the Profields Table field is also throwing warnings that need attention.

Note that there is no 3.0.118 yet

[MrSnoozles]

@Ralf Which PHP version are you using? "self::new" is a syntax that threw an error prior to PHP 7. Since PW minimum requirements is PHP 5.3 it is a bug introduced in version 3.0.117. Like @adrian said, reverting to 3.0.116 or upgrading to PHP >=7.0 should fix it.

Anyway, I would also like to use this comment to continue a discussion that started in the comments sections of the blog post about the newly introduced WireArray::new() static method. I posted a pretty long comment about that which never got published. (As a side node, that is highly frustrating, taking into account I took quite some time researching background information to the comment I made. So here is going to be a shorter version of that post)

The discussion started with @teppo and @bernhard asking, why a new concept of WireArray::new() was introduced to initialise a new WireArray with data. More intuitive would be if you could just initialise it using new WireArray() and pass your data to the constructor. That's how it works for most other objects in ProcessWire too.

To that @ryan replied:

Quote

WireArray is a base class in PW for all different types of WireArray classes—PageArray, Fieldgroup, Selectors, Pagefiles, Notices, Fieldtypes, Modules, FieldsArray, FieldtypeArray, InputfieldArray, and on and on. Many of which have their own unique constructor arguments, specific to the purpose of each class (most of the time they are optional arguments). The benefit of the WireArray::new() is that is can be consistent on all of the WireArray types. That consistency wouldn't be possible if we were using the constructor. It's perfectly fine to create any WireArray type using "new AnyWireArrayType()" as always, but if you want to create one and add items to it at the same time, then the AnyWireArrayType::new() makes that possible, where the constructor wouldn't.

 

Now, I do understand why this is necessary, but just like Teppo and Bernhard I'm not 100% happy with it. It seems like a small thing we shouldn't care too much about, but I came to love ProcessWire because I usually do things I learned them using plain PHP and most of the time they just work the way I expect it. This new WireArray::new syntax is something I would intuitevly do wrong, then wonder why it doesn't work, then search the documentation, and finally ask myself, why I can't just use new WireArray(). And that's a workflow that's slowing me as a developer down, a workflow I'm accustomed to from Wordpress, not from ProcessWire.

So although it doesn't seem like a big thing, is there a chance we could make new WireArray() work for initialising WireArray objects with data? As far as I could see there are four classes derived from WireArray and implementing their own constructor. Would it be possible to refactor those?

 

 

[kixe]

new is a reserved word until PHP 5.6. Its not allowed to use it as a function name. PW 3.0.117 requires PHP 7.0.

@ryan

I strongly recommend to announce the change of the requirements. (even for the dev branch)

https://github.com/processwire/processwire-issues/issues/735

[LostKobrakai]

2 hours ago, kixe said:

I strongly recommend to announce the change of the requirements. (even for the dev branch)

Can we all please give ryan the benefit of the doubt and assume it might have just been a mistake. If this would be an intended change of requirements – which seems unlikely from prev. strongly held support down to even 5.3 – I'd expect ryan to announce it properly. Also this is the branch of active development in the end and while it has been super stable in the past without any major issues it's still a development branch. I see it similarly as with beta versions of other software. Things might go wrong sometimes. 

[bernhard]

Quote

It sounds like last week's version 3.0.117 additions to WireArray may have caused issues in PHP versions prior to 7.x. Sorry about that—it has been hopefully fixed on the dev branch. The culprit was a method that I added primarily for phpdoc purposes so that it would be picked up in the automatically generated ProcessWire API Reference site. It wasn't too important, and I simply removed it. Everything mentioned in last week's blog post still works. While I'm not yet bumping the core version number on the dev branch till next week, there are still several small updates and fixes on the dev branch this week, but I'll save the details on those, as well as some other nice additions in progress, for next week's blog post.

https://processwire.com/blog/posts/rebuilding-pw-website-part2/

[adrian]

I can confirm that today's updates have fixed the Profields Table field error I was getting. Not sure about the PHP <7 errors though as I am on 7.

[Robin S]

@ryan, I'm sure it's just a temporary glitch relating to the ongoing work you're doing on the docs, but I notice that many methods are showing "@since 3.0.110" when they have been around much longer than that.

Example: https://processwire.com/api/ref/inputfield/

[kixe]

It works again with PHP 5.6

@ryan Thanks for providing a quick solution.

ProfieldsTable is working as well. But it remains an inconsistence.
https://github.com/processwire/processwire-issues/issues/729#issuecomment-433594449