Views pager Unsupported operand types: int + string fatal error on PHP 8

[richardlampitt]

Description of the bug

A fatal error can happen when the pager attempts to add a string and int together:

TypeError: Unsupported operand types: int + string in views_plugin_pager_full->query() (line 265 of C:\wamp64\www\[...]\httpdocs\core\modules\views\plugins\views_plugin_pager_full.inc).

Steps To Reproduce

I'm not sure if this is completely reproduceable on a fresh system, but on our client's development installation, just opening /admin/structure/layouts/manage/default will cause the error.

To reproduce on a vanilla install of Backdrop:

1. Create a bunch of nodes (e.g. with Devel Generate, more than 10)
2. Create a simple View that shows nodes, with a pager (10 items e.g.)
3. Head to the Pager configuration of the View and remove the "0" under offset (leave that field blank).
4. Save the View and visit it. You'll see the same Fatal error

Actual behavior

A Fatal Error occurs.

Expected behavior

Layout admin interface loads.

Additional information

Add any other information that could help, such as:

• Backdrop CMS version: 1.31
• Web server and its version: apache 2.4.54
• PHP version: 8.0+ (tested with 8.0, 8.1, 8.2 and 8.3)
• Database sever (MySQL or MariaDB?) and its version: MariaDB Version: 10.11.11
• Operating System and its version: Windows NT 10.0 build 19045 (Windows 10) AMD64

The issue is in the query() function:

  function query() {
    if ( $this->items_per_page_exposed() && !empty($_GET['items_per_page']) ) {
      if ( is_numeric($_GET['items_per_page']) && $_GET['items_per_page'] > 0 ) {
        $this->options['items_per_page'] = $_GET['items_per_page'];
      }
      else if ( $_GET['items_per_page'] == 'All' && $this->options['expose']['items_per_page_options_all'] ) {
        $this->options['items_per_page'] = 0;
      }
    }
    if ( $this->offset_exposed() ) {
      if ( isset($_GET['offset']) && $_GET['offset'] >= 0 ) {
        $this->options['offset'] = $_GET['offset'];
      }
    }

    $limit  = $this->options['items_per_page'];
    $offset = $this->current_page * $this->options['items_per_page'] + $this->options['offset'];
    if ( !empty($this->options['total_pages']) ) {
      if ( $this->current_page >= $this->options['total_pages'] ) {
        $limit  = $this->options['items_per_page'];
        $offset = $this->options['total_pages'] * $this->options['items_per_page'];
      }
    }

    $this->view->query->set_limit($limit);
    $this->view->query->set_offset($offset);
  }

Adding typecasting to the $offset will fix the error:

    $offset = (int) $this->current_page * (int) $this->options['items_per_page'] + (int) $this->options['offset'];

[indigoxela]

Hi @richardlampitt, welcome to the Backdrop core issue queue!

Disadvantage of the typecasting is, that it hides the problem instead of solving it.

I'm not sure if this is completely reproduceable on a fresh system...

I'd assume, that a fresh install doesn't have broken views OOTB, no. 😉

Knowing more about the root cause on your site might help to find a more generic way (defensive coding, eventually).
Where does the string come from?

BTW: have you tried to reproduce it on Linux? Or just a different dev environment? Windows is (sort of) supported, but has several issues (WAMP).

[indigoxela]

Oh, BTW, I saw you opened another views related issue - is that the same (broken) view or a different one, @richardlampitt ?

[richardlampitt]

Knowing more about the root cause on your site might help to find a more generic way (defensive coding, eventually).
Where does the string come from?

This has cropped up as part of a D7 → Backdrop 1 migration for a client at my place of work. The site has a huge number of nodes (millions) and dozens (I think 60 or so?) views, so unfortunately not feasible to rebuild from a clean slate.

I have no idea where the string is coming from, unfortunately. I don't have a lot of wiggle room in the project's budget to spend digging too far. As far as I can tell, there's a number that's just being passed as a "string" rather than an int; I've not seen any odd maths since adding type-casting myself directly to get the site working as I migrate it.

Oh, BTW, I saw you opened another views related issue - is that the same (broken) view or a different one, @richardlampitt ?

It is not, that's a different issue - I managed to resolve that other problem but that bug remains. I'll add more information to that issue after this reply.

BTW: have you tried to reproduce it on Linux? Or just a different dev environment? Windows is (sort of) supported, but has several issues (WAMP).

I've not had the chance yet to test on a *nix install, but ultimately it will be sitting on an ubuntu LAMP box - again, the project's budget doesn't stretch far enough to warrant testing it so. My WAMP install seems to be behaving grand in general, I've had no issues working on other Backdrop sites, or any of the Drupal 10 or WordPress sites we also look after here.

[indigoxela]

I've had no issues working on other Backdrop sites, or any of the Drupal 10 or WordPress sites we also look after here.

So, let's assume, the problem's not caused by the dev environment.

I have no idea where the string is coming from...

I guess, we can figure that out, though.

One of the 3 options seems to be a string, so we should inspect $this->options. Do you know, which of the 60+ views is causing it, or is that also unknown?

Leave in the typecasting, and try debug($this->options);, or - as it's about "int + string" - try debug($this->options['offset']);.
If you're not familiar with debug() - to see the output directly, you should turn on error display (on admin/config/development/logging).

If you know which view it is - can you edit it via admin UI? Does that view show any "broken handler" nagging?
If you open the pager's offset setting of that view (that's a dialog) and save it - does the error go away?

[indigoxela]

To clarify: this is the pager's offset setting - obviously a number FormAPI field, so it's really odd, that you get a string... (and saving that once, and then the view could fix the problem).

[richardlampitt]

To clarify: this is the pager's offset setting - obviously a number FormAPI field, so it's really odd, that you get a string... (and saving that once, and then the view could fix the problem).

[huge image that's not really needed for this quote]

I'll have a quick search through my config for anything that's saved as a string here - give me a moment.

[richardlampitt]

Can confirm that there is a mixture of strings and ints in my config for all of these values.

And in code, in case it's needed:

                "pager": {
                    "type": "some",
                    "options": {
                        "items_per_page": "5"
                    }
                },

                "pager": {
                    "type": "none",
                    "options": {
                        "offset": "0"
                    }
                },

                "pager": {
                    "type": "some",
                    "options": {
                        "items_per_page": 5
                    }
                },

[indigoxela]

So, you're able to figure out the problematic views by their json...? Alright, and if you save those via admin UI (again, the dialog and then the view) - do those errors go away? (You'd have to revert your local hacks, of course, to see the result.)

[richardlampitt]

Regarding typecasting, I think that in this instance it would be a good idea regardless - developers may change config values manually and use a string for this. I certainly wouldn't expect to cause a bug using a numeric string rather than an int for a value. Certainly, if I see a numeric string value in a JSON file I'm going to be extremely adverse to changing its type just because it contains a digit.

Regarding how these values came to be in the first instance, as this config is part of a migration from D7 → Backdrop 1, it would be worth ensuring that these values are in the correct type during both import and saving.

[richardlampitt]

So, you're able to figure out the problematic views by their json...? Alright, and if you save those via admin UI (again, the dialog and then the view) - do those errors go away? (You'd have to revert your local hacks, of course, to see the result.)

I'll give this a crack, give me a moment.

[indigoxela]

Out of curiosity I did a quick check on a site upgraded recently from D7 - their offset are string and that site runs without any problem on PHP 8.1.

However, I'd still recommend to save your problematic views once via UI, just to make sure, the views per se are alright.

[richardlampitt]

Re-saving the view through the UI made no difference:

                "pager": {
                    "type": "full",
                    "options": {
                        "items_per_page": "20",
                        "offset": "0",
                        "id": "0",
                        "expose": {
                            "items_per_page_options_all": 0
                        }
                    }
                },

It seems that the system will maintain the scalar type on save.

During the my sitewide search, it seems that many contrib modules provide these values as strings by default, strengthening the case for type-casting or similar mitigation on arthmetic to prevent unnecessary errors on PHP 8.

[argiepiano]

Not sure if I'm missing something in this discussion, but this "8" + 1 is valid in PHP and will not throw an error. "8" is automatically typecast to int, no need to add typecasting. So, having numbers as a string will not cause this problem. The problem only happens in situations when you do "wrong" + 1 or "" + 1, where the string can't be typecast. So the idea of using typecasting will not solve anything here, unless you do this to an empty string. So I would search your json files for an empty string in offset.

EDIT: I was somewhat wrong above. Actually typecasting something like (int) "wrong" + 2 will avoid the error and will result in 2. So, yes, I'd search offset looking for a string that's not a number, or I would look for an empty string.