Plugin update info not fetched/Wrong code in $raw_response?

[greps]

Running 2.7rc1 (latest alpha) on DownTownHost.

For some reason the plugin update information is not fetched. That is, I know that half the plugins that I have installed (active or not) have been updated since I've installed them. In 2.6.* WP would alert me when the update was available and automatically install it if I choose to. Now, however, WP acts as if no updates are available and I have no idea how to force it to check for plugin updates.

Any ideas?

[DD32]

Visiting the plugins page will make a request if the data is out of date(by 12 hours).

are the RSS feeds still working for you?

[greps]

Replying to DD32:

Visiting the plugins page will make a request if the data is out of date(by 12 hours).

are the RSS feeds still working for you?

I've tried visiting the plugins page, refreshing it, deleting browser cache, etc, in 4 different browsers both on Windows and Mac with no luck, so it's definitely not computer-related.

The RSS feeds display just fine on the dashboard. The plugins I have now were installed using the new built-in plugin browser/installer a few weeks ago, but for reasons outlined above, I cannot update any of them.

I can also update my WP installation without problems through the core update tool.

[ericr23]

I just encountered this problem, too. In my two 2.6.5 installations, the dashboard conveniently indicated that a plugin needed updating and the plugins page allowed easy automatic updating. But in my 2.7RC1 installation, nothing -- not even on the plugins page.

This apparently was a problem in earlier 2.7 betas as well, because the plugin in question is actually now 2 updates behind the 2.6.5 sites.

[ryan]

Can you use phpymadmin or the like to look at the 'update_plugins' option in the options table? Cut-and-paste it here.

[pdreissen]

Ryan,

I just looked for this option but this option isn't available in the wp_options table.

FYI, i just installed the one-click plugin upgrade plugin, which detects the new versions perfect.

[pdreissen]

Oops... my bad it is there :)

O:8:"stdClass":3:{s:12:"last_checked";i:1228597986;s:7:"checked";a:45:{s:35:"adsense-manager/adsense-manager.php";s:6:"3.2.13";s:19:"akismet/akismet.php";s:5:"2.2.3";s:43:"all-in-one-seo-pack/all_in_one_seo_pack.php";s:8:"1.4.6.15";s:17:"blipit/bliptv.php";s:3:"1.1";s:43:"broken-link-checker/broken-link-checker.php";s:6:"0.4.10";s:50:"collapsible-archive-widget/collapsible-archive.php";s:7:"2.2.1.1";s:23:"customize/customize.php";s:5:"1.0.2";s:22:"dmsguestbook/admin.php";s:6:"1.12.1";s:23:"dmsguestbook/widget.php";s:4:"1.20";s:25:"easy-contact/econtact.php";s:12:"0.1.2 β";s:43:"get-recent-comments/get-recent-comments.php";s:5:"2.0.2";s:36:"google-sitemap-generator/sitemap.php";s:7:"3.1.0.1";s:9:"hello.php";s:3:"1.5";s:24:"lightbox-2/lightbox2.php";s:5:"2.8.0";s:19:"list_transports.php";s:3:"1.0";s:29:"nextgen-gallery/nggallery.php";s:9:"1.0.0-RC1";s:52:"one-click-plugin-updater/oneclick-plugin-updater.php";s:5:"2.4.4";s:17:"openid/openid.php";s:5:"3.1.4";s:21:"posttabs/postTabs.php";s:3:"2.7";s:27:"redirection/redirection.php";s:6:"2.0.11";s:21:"scissors/scissors.php";s:4:"0.93";s:37:"search-unleashed/search-unleashed.php";s:6:"0.2.24";s:33:"seo-automatic-links/seo-links.php";s:5:"1.7.2";s:30:"smart-youtube/smartyoutube.php";s:3:"2.6";s:21:"sociable/sociable.php";s:5:"2.9.5";s:47:"subscribe-to-comments/subscribe-to-comments.php";s:5:"2.1.2";s:37:"tinymce-advanced/tinymce-advanced.php";s:3:"3.1";s:17:"wassup/wassup.php";s:5:"1.6.3";s:15:"stats/stats.php";s:5:"1.3.5";s:21:"wp-cache/wp-cache.php";s:5:"2.1.3";s:27:"wp-crontrol/wp-crontrol.php";s:3:"1.0";s:41:"wp-downloadmanager/wp-downloadmanager.php";s:4:"1.31";s:48:"wp-downloadmanager/wp-downloadmanager-widget.php";s:4:"1.31";s:26:"highslide/wp-highslide.php";s:4:"1.28";s:27:"wp-pagenavi/wp-pagenavi.php";s:4:"2.31";s:21:"wp-polls/wp-polls.php";s:4:"2.31";s:28:"wp-polls/wp-polls-widget.php";s:4:"2.31";s:31:"wp-supercache-plus/wp-cache.php";s:5:"0.6.7";s:47:"wp-ajax-edit-comments/wp-ajax-edit-comments.php";s:7:"2.2.6.0";s:19:"wptouch/wptouch.php";s:3:"1.5";s:32:"wp-widget-cache/widget-cache.php";s:6:"0.25.1";s:27:"xrds-simple/xrds-simple.php";s:3:"1.0";s:42:"yet-another-related-posts-plugin/yarpp.php";s:5:"2.1.6";s:33:"breadcrumbs/yoast-breadcrumbs.php";s:5:"0.6.2";s:33:"wp-breadrum/yoast-breadcrumbs.php";s:3:"0.5";}s:8:"response";a:0:{}}

[ryan]

That looks like it successfully checked seven hours previously and api.wordpress.org reported no updates.

[ryan]

Related thread:

​http://comox.textdrive.com/pipermail/wp-hackers/2008-December/022963.html

A buggy http transport could cause this. The following plugin will list the transports your blog is using below the admin footer.

​http://trac.wordpress.org/attachment/ticket/8086/list_transports.php

[pdreissen]

Available transports: Curl Streams Fopen Fsockopen

[greps]

The content of my update_plugins:

O:8:"stdClass":1:{s:12:"last_checked";i:1228647989;}

That's using 2.7-RC1-10073

Found another strange thing. see for yourself:

​http://i35.tinypic.com/2je8od1.jpg >
​http://i33.tinypic.com/34ss80n.jpg >
​http://i33.tinypic.com/f1gj89.jpg

So despite the fact that I am using an outdated version (1.3.2), when I browse to the plugin installation page using the plugin installer still reports that I have the latest version, even though it clearly says that the current version (1.3.5) is greater than mine.

[greps]

Replying to ryan:

Related thread:

​http://comox.textdrive.com/pipermail/wp-hackers/2008-December/022963.html

A buggy http transport could cause this. The following plugin will list the transports your blog is using below the admin footer.

​http://trac.wordpress.org/attachment/ticket/8086/list_transports.php

Installed:

Available transports: Curl Streams Fopen Fsockopen

[DD32]

Found another strange thing. see for yourself:

The Installer bases the upgrade notice on the update_plugins option, Its the only piece of data which can definitively (well, closest possible) a filename => Plugin name. It(installer) has no other way of knowing that "Plugin XYZ" on your WordPress install is the same as "Plugin XYZ" from the .org database, However the update checker API does extra checks based on plugin metadata to determine which is the correct plugin.

O:8:"stdClass":1:{s:12:"last_checked";i:1228647989;}

That looks like the HTTP API has hit a bug and hasn't returned valid data to me. (I'll leave someone else to debug that one for now)

[scribu]

Here's what I'm getting, using 2.7-RC1-10073.

Available transports:  Curl Streams Fopen Fsockopen

$raw_response:
Array
(
    [headers] => Array
        (
        )

    [body] => a:1:{s:43:"custom-field-images/custom-field-images.php";O:8:"stdClass":5:{s:2:"id";s:4:"3174";s:4:"slug";s:19:"custom-field-images";s:11:"new_version";s:7:"1.6.0.1";s:3:"url";s:56:"http://wordpress.org/extend/plugins/custom-field-images/";s:7:"package";s:61:"http://downloads.wordpress.org/plugin/custom-field-images.zip";}}
    [response] => Array
        (
            [code] => id
            [message] => #249
        )

)

When I tried this yesterday, the message was #175.

[scribu]

a plugin that outputs $raw_response and available transports

[greps]

Replying to scribu:

Here's what I'm getting, using 2.7-RC1-10073.

Available transports:  Curl Streams Fopen Fsockopen

$raw_response:
Array
(
    [headers] => Array
        (
        )

    [body] => a:1:{s:43:"custom-field-images/custom-field-images.php";O:8:"stdClass":5:{s:2:"id";s:4:"3174";s:4:"slug";s:19:"custom-field-images";s:11:"new_version";s:7:"1.6.0.1";s:3:"url";s:56:"http://wordpress.org/extend/plugins/custom-field-images/";s:7:"package";s:61:"http://downloads.wordpress.org/plugin/custom-field-images.zip";}}
    [response] => Array
        (
            [code] => id
            [message] => #249
        )

)

When I tried this yesterday, the message was #175.

I'm getting this with your plugin installed:

Available transports: Curl Streams Fopen Fsockopen $raw_response: Array ( [headers] => Array ( ) [body] => a:1:{s:15:"stats/stats.php";O:8:"stdClass":5:{s:2:"id";s:3:"626";s:4:"slug";s:5:"stats";s:11:"new_version";s:5:"1.3.5";s:3:"url";s:42:"http://wordpress.org/extend/plugins/stats/";s:7:"package";s:53:"http://downloads.wordpress.org/plugin/stats.1.3.5.zip";}} [response] => Array ( [code] => id [message] => #96 ) )

...and now for whatever reason update info has actually been fetched: There is a new version of WordPress.com Stats available. View version 1.3.5 Details or upgrade automatically.

[greps]

After updating the plugin I saw this: ​http://i36.tinypic.com/ejtwfq.jpg

And the message in the footer changed to this: Available transports: Curl Streams Fopen Fsockopen $raw_response: Array ( [headers] => Array ( ) [body] => a:0:{} [response] => Array ( [code] => id [message] => #96 ) )

[scribu]

Replying to greps:

...and now for whatever reason update info has actually been fetched: There is a new version of WordPress.com Stats available. View version 1.3.5 Details or upgrade automatically.

That's because the plugin doesn't check if the response code is 200.

You should not leave it enabled, tho, because it makes a request to the WP api on every admin page load.

[jacobsantos]

What version of PHP are you using? I checked the cURL code and it appears to be correct. I mean it works for me and I'm using PHP 5.2.6. Could also be the Streams transport.

[scribu]

I'm using PHP 5.2.5

[kpdesign]

I am now experiencing this issue with 2.7 on ​Eleven2 on two different servers (Alpha and Bravo). I changed the version number for both Akismet and Hello Dolly and, after 15 hours, there was still no notice that they needed to be updated in the 2.7 installs on either server.

Earlier versions of 2.7 did return the upgrade notices for plugins - this seems to have stopped working for me in the past 7 days.

Here are my results after installing the List Transports plugin:

Alpha server:

PHP version: 5.2.4

Available transports: Curl Streams Fopen Fsockopen

Options table:

update_plugins: O:8:"stdClass":1:{s:12:"last_checked";i:1228637756;}

update_themes: O:8:"stdClass":1:{s:12:"last_checked";i:1228636439;}

Bravo server:

PHP version: 5.2.4

Available transports: Curl Streams Fopen Fsockopen

Options table:

update_plugins: O:8:"stdClass":1:{s:12:"last_checked";i:1228650914;}

update_themes: O:8:"stdClass":1:{s:12:"last_checked";i:1228609966;}

(Note: I've listed the results for update_themes on both servers, as it seems to be returning the same type of results as update_plugins - not sure if it is relevant or not.)

I changed the version number of a plugin on a 2.6.5 install on Bravo server and immediately went back to the Plugins page. I already had the notice that the plugin needed to be upgraded, so the notices work fine in 2.6.5, but not 2.7.

I've also encountered a new issue with the WordPress core update process on both servers starting this AM. It has worked fine up to and including rev 10073. I did the core upgrade this AM, it says that it upgraded everything successfully, but I am stuck at rev10073. Here's the results from the options table on both servers:

Alpha server - update_core:
O:8:"stdClass":3:{s:7:"updates";a:1:{i:0;O:8:"stdClass":5:{s:8:"response";s:11:"development";s:3:"url";s:34:"http://wordpress.org/download/svn/";s:7:"package";s:56:"http://wordpress.org/nightly-builds/wordpress-latest.zip";s:7:"current";s:5:"2.6.5";s:6:"locale";s:5:"en_US";}}s:12:"last_checked";i:1228651001;s:15:"version_checked";s:13:"2.7-RC1-10073";}

Bravo server - update_core: O:8:"stdClass":3:{s:7:"updates";a:1:{i:0;O:8:"stdClass":5:{s:8:"response";s:11:"development";s:3:"url";s:34:"http://wordpress.org/download/svn/";s:7:"package";s:56:"http://wordpress.org/nightly-builds/wordpress-latest.zip";s:7:"current";s:5:"2.6.5";s:6:"locale";s:5:"en_US";}}s:12:"last_checked";i:1228651001;s:15:"version_checked";s:13:"2.7-RC1-10073";}

The footer still says "You are using a development version (2.7-RC1-10073)." and the dashboard says "You are using WordPress 2.7-RC1-10073."

This is happening on both the Alpha and Bravo servers. It was also mentioned on the wp-testers list this AM, so it seems I'm not the only one having this issue with the core update not returning the correct version number after the bump in changeset 10096.

[jacobsantos]

Add this plugin or the code to the current plugin.

<?php
/*
Plugin Name: Disable cURL
Description: Isolate trouble transport.
Version: 1.0
*/

function mad_dog_disable_curl($isEnabled)
{
    return false;
}

add_filter('use_curl_transport', 'mad_dog_disable_curl');

[jacobsantos]

Can you try the patch and see if it works for you without the mad_dog plugin.

[scribu]

I've patched http.php and nothing changed. Then I added mad_dog and I still see cURL in the available transports list.

I'm still using 2.7-RC1-10073.

I also have the latest svn revision on localhost and both plugin_update and mad_dog work.

[jacobsantos]

I've realized that cURL is not used for the plugin_update version checker because it can not be used to send POST data. Only Streams, HTTP Extension, and fsockopen can do that.

Since you don't have the HTTP extension, that means that it is actually the Streams transport that is FUBAR.

An error must being returned at some point. Need to isolate it and var_dump it. New patch is coming.

[jacobsantos]

debugging

[jacobsantos]

New patch adds debugging to Streams. If you can submit what comes back, it should be helpful to finding a fix.

[scribu]

array(2) {

headers?=>
array(6) {

[0]=>
string(15) "HTTP/1.1 200 OK"
[1]=>
string(39) "Content-Type: text/plain; charset=utf-8"
[2]=>
string(17) "Content-Length: 6"
[3]=>
string(35) "Date: Sun, 07 Dec 2008 17:07:47 GMT"
[4]=>
string(17) "Server: LiteSpeed"
[5]=>
string(17) "Connection: close"

}
readbuf?=>
resource(249) of type (stream)

}

[jacobsantos]

Actual fix.

[jacobsantos]

New patch should (hopefully) fix problem, maybe.

[scribu]

That seems to work:

$raw_response:
Array
(
    [headers] => Array
        (
            [content-type] => text/plain; charset=utf-8
            [content-length] => 6
            [date] => Sun, 07 Dec 2008 17:33:01 GMT
            [server] => LiteSpeed
            [connection] => close
        )

    [body] => a:0:{}
    [response] => Array
        (
            [code] => 200
            [message] => OK
        )

)

[greps]

Replying to jacobsantos:

New patch should (hopefully) fix problem, maybe.

I hereby confirm that this patch does, in fact, work. Thanks!

[greps]

Also confirming that applying the patch above will screw up searching for plugins through the admin interface ("An unknown error has occured")

[scribu]

Replying to greps:

Also confirming that applying the patch above will screw up searching for plugins through the admin interface ("An unknown error has occured")

Same here. It's interesting that if I do a search that I did before the patch ('deviant'), it works.

[kpdesign]

Replying to jacobsantos:
I've tested the patch on both my servers and can confirm that it does work for me as well.

I am also getting the same error, however, when trying to install new plugins. Go to Install New, and the tags are missing from the bottom of the page. Type a keyword into the search box and get "An unknown error has occured" message.

This happens whether the debug plugin is active or disabled.

[jacobsantos]

More debugging

[jacobsantos]

Back to the drawing board

[kpdesign]

Applied the latest patch with debug plugin still enabled. Navigate to Install Plugins and see the following where the tags should be:

array(2) {
response?=> array(2) { code?=> string(3) "200" message?=> string(2) "OK" } headers?=> array(5) { content-type?=> string(24) "text/html; charset=UTF-8" transfer-encoding?=> string(7) "chunked" date?=> string(29) "Sun, 07 Dec 2008 19:31:25 GMT" server?=> string(9) "LiteSpeed" connection?=> string(5) "close" } }

This is what is at the bottom of the page:

Available transports: Curl Streams Fopen Fsockopenarray(2) { response?=> array(2) { code?=> string(3) "200" message?=> string(2) "OK" } headers?=> array(5) { content-type?=> string(25) "text/plain; charset=utf-8" content-length?=> string(1) "6" date?=> string(29) "Sun, 07 Dec 2008 19:31:27 GMT" server?=> string(9) "LiteSpeed" connection?=> string(5) "close" } } $raw_response: Array ( [headers] => Array ( [content-type] => text/plain; charset=utf-8 [content-length] => 6 [date] => Sun, 07 Dec 2008 19:31:27 GMT [server] => LiteSpeed [connection] => close ) [body] => a:0:{} [response] => Array ( [code] => 200 [message] => OK ) )

Search for 'deviant' returns 3 results. The following appears between the links and the search results:

array(2) { response?=> array(2) { code?=> string(3) "200" message?=> string(2) "OK" } headers?=> array(5) { content-type?=> string(24) "text/html; charset=UTF-8" content-length?=> string(4) "1187" date?=> string(29) "Sun, 07 Dec 2008 19:32:57 GMT" server?=> string(9) "LiteSpeed" connection?=> string(5) "close" } }

At bottom of page:

Available transports: Curl Streams Fopen Fsockopenarray(2) { response?=> array(2) { code?=> string(3) "200" message?=> string(2) "OK" } headers?=> array(5) { content-type?=> string(25) "text/plain; charset=utf-8" content-length?=> string(1) "6" date?=> string(29) "Sun, 07 Dec 2008 19:32:58 GMT" server?=> string(9) "LiteSpeed" connection?=> string(5) "close" } } $raw_response: Array ( [headers] => Array ( [content-type] => text/plain; charset=utf-8 [content-length] => 6 [date] => Sun, 07 Dec 2008 19:32:58 GMT [server] => LiteSpeed [connection] => close ) [body] => a:0:{} [response] => Array ( [code] => 200 [message] => OK ) )

[jacobsantos]

Debugging of the returned body.

[kpdesign]

After applying 8476.5.diff, I'm getting a parse error:

Parse error: syntax error, unexpected T_STRING, expecting ',' or ';' in /home/xxxxxx/public_html/wordpress/wp27/wp-includes/http.php on line 801

[jacobsantos]

Fix missing semi-colon

[scribu]

Applied 8476.5.diff and both plugin updates and plugin search work.

[jacobsantos]

Hopefully final patch with debugging removed.

[ryan]

(In [10117]) Fix raw_response code in Streams transport. Props jacobsantos. fixes #8476

[firewings.2010]

Nothing.