By Road Runner on
The other day upgraded from 7.20 to 7.21 version number didn't change on the report so I ignored it. Today upgraded whatever I am running to 7.22 and it appeared to work i.e. database actually was updated but still the version number as reported remains at 7.20
Update: The status report shows correctly version 7.22 but the available updates report shows 7.20
Comments
@Road Runner - Interesting! I
@Road Runner - Interesting! I have yet to have that happen on my site...do you have any page caching? It might be good after the upgrade to just clear your site cache and see if that makes any difference. Did you do anything custom during the upgrade?
Nothing different, updated as
Nothing different, updated as I always do and the database was updated. I did not put the site into maintenance mode however. I do run Domain Access and Boost. I don't use caching since Boost is installed. I cleared the caches anyway. Status report says the right version number but the update available report says still running v2.2
Update data is stored in db
Update data is stored in db table cache_update. It may not be deleted on a normal cache clear http://api.drupal.org/api/drupal/modules!update!update.module/group/upda.... Re-checking for updates (manually or by running cron) should clear it. You could always try truncating the table manually then rerunning the update check. As ever, messing with the database is best done on a test site not the live site.
I seem to recall also that the status showing the wrong version of core is one of the side-effects of starting with a Drupal distribution, then (incorrectly) attempting to to update in the ordinary way using the standard distro.
Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors
Something is screwy when I
Something is screwy when I check manually I get following error message.
Failed to get available update data for 72 projects.
Now it would appear when I check for updates it can't access them. Any help or ideas appreciated. This is production system.
Either your server is not
There are two usual causes. Either your server is not connecting to the drupal.org server (which sometimes is down), or you are suffering from a queue table in the database which is not getting cleared. If it is the latter, the solution is to truncate the queue table. You can empty that table in phpmyadmin, use command line, or use drush to do so. Do not delete the table!
Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors
Drupal version number still
Drupal version number still in error. I tried the queue truncation no joy. What rebuilds this table - it is now empty even thought I ran cron, ran update.php etc. Where does the report update generator get its information? This is annoying as it is core we are speaking about here - I am connected to the server just fine. Any ideas most appreciated.
Sorry I must have been tired
Sorry I must have been tired when I wrote that. It is cache_update where the version number is, and clearing caches in the normal way does not clear it. You should maybe truncate it manually.
Truncating queue is the usually effective cure to a different problem, when update checks keep cycling and do not repeat.
Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors
cache update returns an empty
cache update returns an empty result set. Could Boost have anything to do with this?
On the cache
On the cache see
http://api.drupal.org/api/drupal/modules%21update%21update.compare.inc/f...
My understanding (and I am not a core expert) is that the version number is read from modules/system/system.info file into the system table. The cache_update data is collected from the system table. The table should not be empty if you have run a check for available updates or visited status page. You can check you have the right file at modules/system/system.info, check the version number in system and cache_update. However they do not have their own table field, they are stored as variables in the database.
Assuming you haver the correct version number in the file, you could always open the database in phpmyadmin and search for all the tables where the incorrect version number appears....
Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors