WordPress.org

Make WordPress Core

Opened 9 years ago

Last modified 14 months ago

#20854 reopened defect (bug)

PHP warning caused by missing 'spam' and 'deleted' fields in a custom user table

Reported by: leondari Owned by: Nikolaos Raftopoulos
Milestone: Future Release Priority: normal
Severity: normal Version: 3.3.2
Component: Users Keywords: needs-testing needs-patch
Focuses: multisite Cc:

Description

In my network dashboard I get the following error message :

Warning: number_format() expects parameter 1 to be double, string given in /home/tklighth/public_html/wp-includes/functions.php on line 155

Attachments (2)

20854.diff (753 bytes) - added by kobenland 9 years ago.
Wraps $count in absint()
20854.2.diff (758 bytes) - added by jeremyfelt 8 years ago.

Download all attachments as: .zip

Change History (16)

#1 @scribu
9 years ago

  • Keywords reporter-feedback added; needs-codex needs-testing removed

Install this in your mu-plugins folder to get more information about the error:

https://raw.github.com/gist/625769/e26b3eb9b5ccaeeda75dc266fdbd6f8e36da51f5/backtrace-errors.php

#3 @kobenland
9 years ago

I have the same warning in my 3.3.2 (and prior) install, but I can't seem to reproduce it in 3.4-RC2.

The number of users are stored in a site option, which is fed by a query returning a string:

//in wp-includes/ms-functions.php line 1980
$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 );

@kobenland
9 years ago

Wraps $count in absint()

#4 @SergeyBiryukov
9 years ago

I can reproduce in 3.4.1 with a custom user table which doesn't contain spam and deleted fields.
wp_update_network_counts() then fails to update user_count site meta value:

SELECT COUNT(ID) as c FROM wp_users WHERE spam = '0' AND deleted = '0'
Unknown column 'spam' in 'where clause'

user_count ends up being an empty string, which leads to the notice.

@jeremyfelt
8 years ago

#5 @jeremyfelt
8 years ago

  • Keywords has-patch added; reporter-feedback removed
  • Milestone changed from Awaiting Review to 3.7

20854.2.diff is a refresh against trunk. Wraps blog and user counts in absint() before setting the options.

#6 follow-up: @nacin
8 years ago

I'm not sure what this does. When the option comes back out of the table, it'll again be a string.

If the issue is to paper over an issue where a custom user table is missing the spam and deleted fields, that sounds like a much larger issue, and we shouldn't be papering over it with an int cast in this one situation.

#7 in reply to: ↑ 6 @SergeyBiryukov
8 years ago

  • Milestone 3.7 deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Replying to nacin:

If the issue is to paper over an issue where a custom user table is missing the spam and deleted fields, that sounds like a much larger issue, and we shouldn't be papering over it with an int cast in this one situation.

Indeed.

#8 @nacin
8 years ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

I don't think this means it is a wontfix right away — we should audit core to see what happens when these fields are missing.

#9 @SergeyBiryukov
8 years ago

  • Milestone set to Awaiting Review

#10 @jeremyfelt
8 years ago

  • Component changed from Multisite to Users
  • Focuses multisite added

#11 @SergeyBiryukov
7 years ago

#27972 was marked as a duplicate.

#12 @SergeyBiryukov
7 years ago

  • Summary changed from functions.php on line 155 ? to PHP warning caused by missing 'spam' and 'deleted' fields in a custom user table

#13 @chriscct7
6 years ago

  • Keywords needs-testing added

#14 @desrosj
14 months ago

  • Keywords needs-patch added; has-patch removed
  • Milestone set to Future Release

Did some investigating on this today. Here are the steps I took:

  • Create a new database table using CREATE TABLE custom_user_table2 AS SELECT * FROM wp_users
  • Run ALTER TABLE custom_user_table DROP COLUMN deleted, DROP COLUMN spam
  • Define the CUSTOM_USER_TABLE constant to a value of custom_user_table.

After taking these steps, I navigated around the Network admin and site admin screens, but I was unable to trigger the error described above.

However, I was able to find a few issues:

  • If you head to the Network > Add New screen, you will be unable to create new users (the Cannot add user. error is displayed). Though, this is could be the preferred behavior to alert an admin of an issue, the message could be more informative.
  • If you head to a single site admin Users > Add New, enter a new user, check "Add the user without sending an email that requires their confirmation", click Add New User, the screen shows "User has been added to your site". This is not the case, no user is added to the database.
  • Follow the same steps as the previous item but don't click the confirmation checkbox. The user is correctly added to the wp_signups table and sent an email. When the activation link is clicked in the email, "An error occurred during the activation" heading is displayed with "Could not create user".

It seems that there are currently no PHP notices or warnings displayed, but there are probably some more less than desirable outcomes somewhere in the code base. I think only the second one really needs to be fixed. An administrator should not be displayed a success notice when the user is not actually added.

Note: See TracTickets for help on using tickets.