Support » Networking WordPress » Illegal string offset 'total_users'

  • Resolved cogmios



    Direct after upgrading to 3.4 I noticed Illegal string offset ‘total_users’ in update.php on line 75.

    On line 55 it requests

    $user_count = get_user_count( );

    I echo this value and it is an integer (2) so not an array

    on line 73 however it requests


    (so an array….. ) this is where it fails on my WP multisite install.

    So im thinking what could be wrong since my get_user_count() does not return an array but just “2” (so an integer)

    (but obviously this should be an array since it has been an array for always)

Viewing 15 replies - 1 through 15 (of 23 total)
  • Where are you getting the error? On the list users page in the network dash or …?

    not on any of the normal blog admin pages but on all network admin pages.

    I echo “$user_count” and it returns 2

    so the only thing i can think of is that there is somewhere a (new) filter on site_option_user_count that changes the value from an array to an integer.

    so… im downloading (now) the complete site and plugins to my local disk to serach for something that could do that

    im not sure though


    ms-functions does :

    $count = $wpdb->get_var( $wpdb->prepare("SELECT COUNT(ID) as c FROM $wpdb->users WHERE spam = '0' AND deleted = '0'") );
    	update_site_option( 'user_count', $count );

    and get_site_option in option.php called by get_user_count in ms-function.php all treat $user_count as an integer

    So … where DOES it get converted to an array so that in update.php it can actually request $user_count[‘total_users’],


    (for non multisite it gets to be an array in count_users in user.php)

    I echo “$user_count” and it returns 2

    Yeah, that’s where you’re losing me 😉

    Where/why/how are you doing that?

    not on any of the normal blog admin pages but on all network admin pages.

    Do you mean on every single network admin page, you get that error?

    a. yes on every single network admin page
    b. open “\wp-includes\update.php
    c. look at line 55 (3.4) it reads “$user_count = get_user_count( );”
    d. so… $user_count is an integer e.g. 2
    e. now look at line 73 it reads “$user_count[‘total_users’]”
    f. how can that be? requesting an array value “total users” from an integer?

    I’m ignoring b through f for a reason, so bear with me. 🙂

    The error:

    Warning: Illegal string offset ‘total_users’ in /opt/htdocs/html/wp-includes/update.php on line 75

    There’s no reason for you to be mucking around in core, and since WP works just fine, no errors, for pretty much everyone else with this, it’s something you ‘did’ 🙂

    The update.php file is for “Check WordPress version against the newest version.” You can really totally ignore that. I know that’s what the error says, it’s not what it means.

    So. Manually reinstall 3.4 before we go anywhere else.

    “no errors, for pretty much everyone else with this,”

    are you sure about that?
    What happens when you turn “show errors” on with

    error_reporting(E_ALL & ~E_STRICT);

    ? Do you now see it?


    But if that was the only way you were able to produce those errors, we have a new track to run down.

    What version of PHP are you using? (5.3.13 for me right now, soon to be .14)

    5.4.3. … ah… you want me to upgrade to 5.4.4. ? Let me try that. Im also creating a second (clean) multisite on the same (Amazon Linux) server to test, takes some time.

    I don’t think that 5.4.4 eould really matter, honestly, but it very well could be a PHP issue.

    Have you done a manual reinstall of WP yet?

    ‘Have you done a manual reinstall of WP yet? ‘

    yep i did a svn export –-force . in the root of the site and the first thing i see after logging in is

    *Warning: Illegal string offset ‘total_users’ in /opt/htdocs/html/wp-includes/update.php on line 73* 🙂

    hey… the file was edited its now 2 lines higher up 🙂

    (and 5.4.4 @ ./configure –prefix=/opt/php –with-config-file-path=P/opt/php/etc –with-config-file-scan-dir=/opt/php/etc/php.d –enable-fpm –with-curl –with-mysql=mysqlnd –with-mysqli=mysqlnd –with-pdo-mysql=mysqlnd –with-zlib –with-openssl –with-mcrypt –enable-mbstring –enable-mbregex –with-gd –with-jpeg-dir –with-png-dir –with-xmlrpc -disable-cgi)

    p.s. running nginx and phpfpm also

    I just checked the logic, and it does look (at least from here) like you’ve found an issue.

    The call to get_user_count() on a Multisite installation does in fact return an integer. The return of this function is assumed to be an array (stored in $user_count) and is referenced as such farther down in the update script.

    A couple of us are looking in to what exactly changed and whether or not this is actually a bug …

    Thanks 🙂

    for reference: i checked back some versions but it seems to be there for some time, even when it was

    $url = "$wp_version&php=$php_version&locale=$locale&mysql=$mysql_version&local_package=$local_package&blogs=$num_blogs&users={$user_count['total_users']}&multisite_enabled=$multisite_enabled";

    instead. So I would expect that would have noticed on the other end that when during a year all requests from multisite installations would be bad concerning user_count someone would notice….?

    That is why i am / was doubting.

    But if it is really a bug it is good to know that really nothing is done with all that data *GRIN*

    When the variables are set. In multisite, we use get_user_count() (a cached
    array), while in single site, we call count_users() (a direct count).

    Not sure it is a bug, if that’s related.

Viewing 15 replies - 1 through 15 (of 23 total)
  • The topic ‘Illegal string offset 'total_users'’ is closed to new replies.