Seeing PHP errors with PHP 7.2

[gmclelland]

Short description of the issue

If I navigate to the modules page, I see the following errors:

1x | PHP Warning: count(): Parameter must be an array or an object that implements Countable in .../Inputfield/InputfieldFile/InputfieldFile.module:637
--
1× | PHP Warning: count(): Parameter must be an array or an object that implements Countable in .../Inputfield/InputfieldFile/InputfieldFile.module:229

Expected behavior

No errors will be shown.

Actual behavior

Errors are shown.

Optional: Suggestion for a possible fix

@adrianbj suggested "Looks like we need to explicitly do an is_array() check before count() now."

Steps to reproduce the issue

1. Go to the modules page
2. View error with TracyDebugger shown in the backend

Setup/Environment

Apache/2.4.28 (Unix) PHP/7.2.0beta3

• ProcessWire version:
  3.0.79

[adrianbj]

@adrianbj suggested "Looks like we need to explicitly do an is_array() check before count() now."

Just to clarify, is_array() if an array is expected, or if it's an object, then you need to check if it implements countable

[szabeszg]

more on this: https://wiki.php.net/rfc/counting_non_countables

[adrianbj]

Maybe also worth a read: https://blog.martinhujer.cz/php-7-2-is-due-in-november-whats-new/ in case there might be other things that need attention.

[ryancramerdesign]

This isn't consistent with the PHP count() documentation. It states that the argument can be mixed, so you can pass anything into it. It also outlines what the return value behavior is:

When the parameter is neither an array nor an object with implemented Countable interface, 1 will be returned. There is one exception, if array_or_countable is NULL, 0 will be returned.

The page even includes examples of using it with null and false, and it's the null version that I use quite often since PW often uses null for values known not yet populated, and blank array for populated but empty. We expect count() to return 0 for either, as it states. We also rely on count() to return 1 for Wire derived objects that aren't WireArray, since they represent a single item that can be stored in a WireArray... because it's "1" item. Short term will stick to the documentation until they change it. But it sounds like this less useful version of count() may end up in the final PHP 7.2, so we'll have to add a wireCount() function that duplicates the currently documented behavior of count(). Either that or wrap every count() call with multiple if() and else statements... but I think wireCount sounds better to me.

[adrianbj]

Did you also see this: http://php.net/manual/en/migration72.incompatible.php

I am dealing with this at the moment and it's not always a simple solution - I have relied on count() in different ways and there isn't a stock approach that can be applied, at least in my experience so far.

The thing I was almost tempted to do was to cast the variable inside the count() as an array, eg: count((array)$var). I feel like that would probably always work, but it seems wrong/dirty and actually avoids the reason they have made this change in the first place - detection of hidden bugs by relying on count to do something that semantically it shouldn't be able to do.

I am curious how see wireCount() handling wireCount('string'); - will it return 1 as per the current behavior, or false?

[ryancramerdesign]

I can't say I've ever had an issue with bugs and using count(), and actually find the behavior handy. It's like they've changed the purpose of the function. I don't agree that semantically count() should only be able to count certain types. I mean, if you give me 1 apple in the real world, then I've got 1 apple, whether you gave it to me in a bag that can hold a dozen apples, or you just gave me an apple. If you give me nothing (null) then I've got nothing (0).

I am curious how see wireCount() handling wireCount('string'); - will it return 1 as per the current behavior, or false?

I'm not sure I understand why it would ever return false? :) If we're asking for a count() we're asking for an integer. So if you give me one "string", then I've got 1 string (return value 1). I've never perceived PHP's count() to be something like Javascript.length property, where it can return the length of a string or the count of an array/object. That would be a whole different function I'd think, like a mashup of strlen() and count().

Here's a potential implementation of wireCount():

/**
 * Return the count of item(s) present in the given value
 * 
 * Duplicates behavior of PHP count() function prior to PHP 7.2, which states:
 * Returns the number of elements in $value. When the parameter is neither an array nor an 
 * object with implemented Countable interface, 1 will be returned. There is one exception, 
 * if $value is NULL, 0 will be returned.
 * 
 * @param mixed $value
 * @return int
 * 
 */
function wireCount($value) {
	if($value === null) return 0; 
	if(is_array($value)) return count($value); 
	if(is_object($value) && $value instanceof \Countable) return count($value);
	return 1;
}

[adrianbj]

actually find the behavior handy

I agree it's handy and I also rely on it quite often. Whether it is semantic or not I guess is up to interpretation - I agree that with a real world analogy it sounds fine, but not sure if that translates to code or not.

Interesting quote in one of those links:

I really like this change, because no one writes such code intentionally, but rather as a bug that needs fixing.

While I don't agree that no ones writes such code intentionally, I do agree that the change can help to identify bugs if you pass in a $str mistakenly thinking it is an array. Before it would have returned 1 and you wouldn't know things were not as expected. Yes the new behavior requires things to be more explicit and it's a bit of a pain, but it might actually be better in the end and also create more understandable code. Maybe? - I don't know :)

[teppokoivula]

... but it might actually be better if the end and also create more understandable code. Maybe? - I don't know :)

At least it makes one thing more obvious: without reading the docs I actually would've expected count() to behave like .length when used on strings.

In my humble opinion returning 1 for a string value of any length (or any given number, including 0, for that matter) may be handy once you know it, but still feels a bit weird :)

[ryancramerdesign]

At least it makes one thing more obvious: without reading the docs I actually would've expected count() to behave like .length when used on strings.

It's the opposite for me, but I was also using PHP for years before I knew any Javascript. I think it just depends what you get used to. For me count() is a handy function that behaves exactly how I'd like it to (prior to PHP 7.2 anyway). It just simply returns a count of how many items you give it, whether it's 1 string (which is 1 item), 1 boolean (1 item), 1 non-Countable object (1 item), an array of 5 integers (5 items), a Countable with 10 pages (10 items), or the one handy exception: null (no items).

[gmclelland]

FYI... Just reporting that I noticed the new commits lately, so I tried out ProcessWire 3.0.80, but I still see the same errors when I visit the modules page.

[adrianbj]

FYI... Just reporting that I noticed the new commits lately, so I tried out ProcessWire 3.0.80, but I still see the same errors when I visit the modules page.

Ryan added the new wireCount() function, but hasn't yet applied it to any of the core code - assuming that will come with time - probably as he edits various scripts containing regular count()

[adrianbj]

Just a reminder that php 7.2 was made the current stable a week ago :)