[Resolved] number_format() error when trying to add new plugins
This is seems to be similar to this issue: http://wordpress.org/support/topic/functionsphp-error-9?replies=7
I’m running 3.7.1 and see this error when trying to add new plugins by searching in the wordpress admin:
Warning: number_format() expects parameter 1 to be double, string given in /home/gbairway/public_html/wp-includes/functions.php on line 165 Warning: number_format() expects parameter 1 to be double, string given in /home/gbairway/public_html/wp-includes/functions.php on line 165 Warning: number_format() expects parameter 1 to be double, string given in /home/gbairway/public_html/wp-includes/functions.php on line 165 Warning: number_format() expects parameter 1 to be double, string given in /home/gbairway/public_html/wp-includes/functions.php on line 165 2 3 h P W w
I have tried deactivating all plugins and switching themes to default twentythirteen. Same error.
Anyone have any ideas? Thanks.
Was curious to why the above thread I posted was close
I closed that topic because it simply became too muddled to effectively help anyone. We do keep asking people to please post their own topics and not to tag onto someone else’s topic as similar symptoms may be caused by very different root problems.
Unless you are using the same version of WordPress on the same physical server hosted by the same hosts with the same plugins, theme & configurations as the original poster, do not post in someone else’s thread. Start your own topic.
However, it seems our requests are being ignored, thus reducing the chances of anyone you being helped effectively. If you wish to maximise the chances of getting an effective solution, post your own topic!
…in general, threads that have many people chiming in become unwieldy and confusing, so they may get closed for that reason.
I agree that sometimes those threads can become confusing so the reminder to start a new topic is okay. But sometimes it’s extremely helpful, especially when it starts to look like everyone is experiencing the exact same issues.
Thanks very much for opening a support ticket. I truly think there’s a larger WordPress issue happening here.
Let’s clarify a few things:
The number_format() message is a symptom, not the actual error. You’re getting this message here because you’re trying to get data from the WordPress.org servers, and failing.
In other words, the number_format() error on line 155 is because it’s trying to print something that isn’t actually a number.
Say you’re trying to get a list of popular plugins from WordPress.org. But for whatever reason, you can’t get that list and it gets some kind of error instead. Now, that number would be like “page 1 of whatever” normally, but because you don’t have any results, that “1” isn’t a valid number. That’s where the error comes from.
What you need to figure out is why your server cannot get results from api.wordpress.org. I just checked it, and it’s working fine, and I can get results from it fine, for all of popular and newest and also keyword searches.
Note that one of the changes in WordPress 3.7 was to make all interaction with the WordPress.org API servers happen via HTTPS only. By using secure connections, this can prevent man-in-the-middle attacks on your communications. If your webserver is not configured to have a method of performing outgoing HTTPS requests, then this could be a possible result. The quick fix to this would be to figure out how to install or enable php_curl on your webserver or hosting service.
However, that may not be the problem, and anything that interferes with communication could cause it. I’d recommend making a fresh test-install on your server, in a subdirectory, and seeing what its behavior is like. Might help to narrow down the issue.
especially when it starts to look like everyone is experiencing the exact same issues.
In this case, it has already been noted that people are NOT experiencing the same issues. The errors are pointing to completely different core scripts.
@otto, thank you. That was a helpful post.
I have CURL enabled and as previously stated, am running Litespeed Webserver. Other sites on this server are working fine so I can’t see that being the issue. Regardless, here are the curl settings:
cURL support enabled
cURL Information 7.24.0
Protocols dict, file, ftp, ftps, gopher, http, https, imap, imaps, pop3, pop3s, rtsp, smtp, smtps, telnet, tftp
SSL Version OpenSSL/1.0.0
ZLib Version 1.2.3
Any other thoughts? I get that the number_format() message is a symptom. I’m just curious though – how do we narrow it down if disabling all plugins, resetting the plugin folder, and using a default them all produce the same result? Like I said, Other sites running the same version of WP on the same host work okay. I would have to add all plugins back one by one and configure them exactly the same to test the way you’re asking. When you have plugins like WooCommerce running that is incredibly time consuming, if not impossible.
But all of that notwithstanding… why would a plugin or theme affect your framework’s ability to connect to its own server? This has to be an issue of WordPress not error checking somewhere when it’s not common across all sites on the same shared hosting environment.
@samuel if you have a site http://www..com and another http://www..com/dev and they are on the same server with the same version of WordPress with the same active plugins and the one in the subdirectory gets the error message and the core site does not, do you know what might cause that? Plus up until a few days ago both were functioning without error messages. I wouldn’t think a subdirectory would not be an issue and I think others on this thread are experiencing the problem on their core domains.
@linkhousemedia, @btlewand : As you probably understand, issues that are difficult to reproduce are difficult to solve. I can’t give you exact and specific solutions to problems that I cannot see myself. My sites and my test systems work fine.
We would need more information as to how to cause the problem in order to solve the problem, basically. Obviously, disabling plugins/themes is the first step to solving issues, in that it tends to narrow down the problem to a specific piece of code and/or make it reproducible.
I have no idea what the cause of the problems you’re experiencing are. Not a clue. I can’t see anything wrong on the WordPress.org side of things. And if it’s intermittent, then that suggests either a load issue (you might get blank/invalid responses from the api under heavy load), or an issue with your webserver’s connection (it can’t make an outgoing connection, or it times out, or something like that), or something else I know not of.
Clearly, there is an issue in the error handling there somewhere. That’s a core issue, but that also doesn’t really solve the problem, just make the failure case prettier and not show those error messages. If the data isn’t getting there, then the popular/newest/search lists would still be empty or have bad results in them.
I have had a small breakthrough. Here’s what I did:
- Cloned the site using WP Migrate DB Pro to dev zone
- Deleted plugin folders via FTP one by one, each time checking to see what happened on the plugin install page
- When I deleted the WooThemes Helper plugin I still saw the same errors on the plugin search page HOWEVER the other pages for installing plugins such as Featured, Popular, Newest, and Favorites all worked agian!
- Removed the rest of the plugin folders – same result
- Removed all themes and installed/activated twentythirteen – same result
- Removed all posts and pages (and removed from trash) – same result
- Checked with host – connections to wordpress API are not being firewalled, however there was one strange error in the php log this morning, but it occurred only once:
[03-Dec-2013 08:34:15 UTC] WordPress database error Lock wait timeout exceeded; try restarting transaction for query UPDATEwp_options
= '1386102804' WHEREoption_name
= '_site_transient_timeout_frm_autoupdate' made by do_action('admin_init'), call_user_func_array, wp_plugin_update_rows, get_site_transient, apply_filters('site_transient_update_plugins'), call_user_func_array, FrmUpdatesController->queue_update, set_site_transient, update_site_option, update_option
- Reset all wordpress and permalink settings – same result
My next step is to start removing database entries.
I have also reached out to WooThemes to see if they can shed any light on this.
My tech support at WiredTree went above and beyond trying to help me with this. They have confirmed there are no bad connection issues to report and dug as deep as they could into log files but turned up nothing other than what you see in my previous post.
Note that uninstalling the WooThemes helper also allows me to search for new plugins. The plugin tag cloud is still missing and replaced with the errors stated previously.
Same thing on your item #3 above. PHP warning and broken plugin tag cloud but you’re right the links for Featured, Popular, Newest, and Favorites all worked again when I deactivated WooThemes Helper 1.2.1.
The site I copied from to create my Dev site still has WooThemes Updater 1.1.3 and the Plugins>New functionality still works fine.
Deleted 1.2.1. from my test site and rolled back to 1.1.3 and that didn’t fix the problem. So whatever version 1.2.1 does when you install it jacks up WordPress somewhere (I guess the database) which results in the PHP warning. @linkhousemedia good luck on the database scrub. Hopefully there is a variable somewhere that creates a conflict. My guess is that the WooThemes updater is checking their database remotely for licenses which must be conflicting when you try to access WordPress.org remotely from the Add New Plugin.
@frank McClung – If you’re still checking in can you let us know if you are using a WooTheme theme or plugin as well. If you do this definitely is the common thread in the mystery.
fyi – I have opened up a support ticket at WooThemes as well.
Partial Breakthrough also on my end. When into PHPMyAdmin in cPanel and looked at the databases WooCommerce would add. Went into:
Field #10 is download count. Number in field is 0. Edited and changed to 1.
Refreshed the PlugIns AddNew screen and the tag cloud was back and php error is gone.
Only issue is the links for Popular, New, Favorites and Featured still don’t work but at least the error message is gone. Will need to see what WooThemes comes back with to fix the remainder.
fyi – if you’re able to roll back to the previous version of WooUpdater 1.1.3 for me. Everything in the New Plugin page works once you change the item above from 0 to 1 in the database.
Nice work @btlewand! Your case must be an isolated incident since I don’t have any table entries in wp_woocommerce_downloadable_product_permissions. Question: Do you have any downloadable products? I don’t in my store.
*Moderators, this is a great example of why a forum exists. So we can help each other. It would have saved some time if we didn’t have the pissing contest over the rules. I don’t say this to be cantankerous though – only to say maybe it’s worth seeing an exception to the rules or considering that the old way isn’t always the best way.
- The topic ‘[Resolved] number_format() error when trying to add new plugins’ is closed to new replies.