| 1 |
OVERVIEW
|
| 2 |
========
|
| 3 |
|
| 4 |
The "update status" module queries drupal.org to see if there are new
|
| 5 |
versions of Drupal core and any modules that you are running. It
|
| 6 |
produces an available updates report at admin/logs/updates:
|
| 7 |
|
| 8 |
Administer >> Logs >> Available updates
|
| 9 |
|
| 10 |
Every module is part of a "project", which may have the same name as
|
| 11 |
the module or a different name. Some projects (for example, Drupal
|
| 12 |
core itself) include more than one module. The report shows every
|
| 13 |
project, the currently installed version, what modules are included,
|
| 14 |
and information about any newer releases that are available. Each
|
| 15 |
entry in the available updates report includes information about what
|
| 16 |
kind of release it is, the version, date, and links to the release
|
| 17 |
notes and download page. Releases marked as security updates are
|
| 18 |
flagged with extra urgency.
|
| 19 |
|
| 20 |
If update_status finds that any of your modules are out of date, the
|
| 21 |
row for the project containing the module will be colored red and
|
| 22 |
marked as an error. At the system modules page (admin/build/modules)
|
| 23 |
there will be a warning message displayed. Also, the site-wide status
|
| 24 |
report (admin/logs/status) will mark this as an error. You can
|
| 25 |
configured update_status to only consider missing security updates an
|
| 26 |
error, and all other newer releases are just considered a warning
|
| 27 |
(colored yellow on the available updates report and status report, and
|
| 28 |
the error message at the system modules page will not be shown).
|
| 29 |
|
| 30 |
By default, update_status checks once a day (assuming cron is
|
| 31 |
correctly enabled). You can also check manually when viewing the
|
| 32 |
available updates page or the site-wide status report.
|
| 33 |
|
| 34 |
|
| 35 |
REQUIREMENTS
|
| 36 |
============
|
| 37 |
|
| 38 |
This module requires that the web server process (for example, httpd)
|
| 39 |
is able to initiate outbound connections. This is usually possible,
|
| 40 |
but some hosting providers or server configurations forbid such
|
| 41 |
connections.
|
| 42 |
|
| 43 |
|
| 44 |
INSTALLING THIS MODULE
|
| 45 |
======================
|
| 46 |
|
| 47 |
Put the entire update_status directory into your 'modules' directory
|
| 48 |
or your 'sites/all/modules' directory and visit admin/build/modules:
|
| 49 |
|
| 50 |
Administer >> Site building >> Modules
|
| 51 |
|
| 52 |
Enable the "Update status" module like any other.
|
| 53 |
|
| 54 |
|
| 55 |
CONFIGURING THIS MODULE
|
| 56 |
=======================
|
| 57 |
|
| 58 |
The settings page for update_status is a tab off the available updates
|
| 59 |
report at admin/logs/updates/settings:
|
| 60 |
|
| 61 |
Administer >> Logs >> Available updates >> Settings
|
| 62 |
|
| 63 |
There are settings to control how often update_status will check for
|
| 64 |
newer releases and what kinds of available releases should be
|
| 65 |
considered an error.
|
| 66 |
|
| 67 |
You can configure update_status not to warn about a project being out
|
| 68 |
of date. For each project that it identifies as having an official
|
| 69 |
release on drupal.org, you may tell it to warn if a project has a new
|
| 70 |
version available 'always', 'not for the current version', or
|
| 71 |
'never'. If you select 'not for the current version' and a new version
|
| 72 |
is posted, the project will then show as having an available update.
|
| 73 |
Modules that are set to not warn if updates are available, or that
|
| 74 |
lack enough information to compare, are displayed in yellow.
|
| 75 |
|
| 76 |
|
| 77 |
REPORTING USAGE STATISTICS
|
| 78 |
==========================
|
| 79 |
|
| 80 |
Whenever update_status queries drupal.org to check for available
|
| 81 |
updates, it can also provide anonymous information about your
|
| 82 |
installed modules. This data is used to generate statistics about the
|
| 83 |
actual usage of each module, which helps to improve the quality of
|
| 84 |
Drupal contributions and will eventually help users find and use
|
| 85 |
projects that are better maintained and more well-used. No information
|
| 86 |
that can be used to identify your site is sent or recorded, so there
|
| 87 |
is no need to be concerned about security or privacy.
|
| 88 |
|
| 89 |
|
| 90 |
UPGRADING TO 6.x CORE
|
| 91 |
=====================
|
| 92 |
|
| 93 |
This module has been moved into Drupal core 6.x and renamed the
|
| 94 |
"update.module". See http://drupal.org/node/94154 for background.
|
| 95 |
Sites using the contributed update_status module in 5.x should disable
|
| 96 |
*and* uninstall the module *before* upgrading to 6.x core. This will
|
| 97 |
prevent any conflicts during the upgrade, and will ensure that no
|
| 98 |
stale variables are left in your database which are not used by the
|
| 99 |
6.x version in core.
|
| 100 |
|
| 101 |
Please note that the settings to ignore specific releases or specific
|
| 102 |
projects are not included in the update.module in core, and if you
|
| 103 |
make use of this functionality on your site, you should install the
|
| 104 |
contributed "Update status advanced settings" module:
|
| 105 |
|
| 106 |
http://drupal.org/project/update_advanced
|
| 107 |
|
| 108 |
|
| 109 |
DEPLOYING FROM CVS
|
| 110 |
==================
|
| 111 |
|
| 112 |
If you deploy your Drupal site directly from CVS, please see the CVS
|
| 113 |
deploy module:
|
| 114 |
|
| 115 |
http://drupal.org/project/cvs_deploy
|
| 116 |
|
| 117 |
If you enable both update_status and cvs_deploy, the available updates
|
| 118 |
report will be much more accurate for the modules you install from CVS.
|
| 119 |
|
| 120 |
|
| 121 |
AUTHORS
|
| 122 |
=======
|
| 123 |
|
| 124 |
The original version of this module (5.x-1.*) was written by Nedjo
|
| 125 |
Rogers and Earl Miles, and the back-end server code at drupal.org
|
| 126 |
(part of the project.module) was mostly by Nedjo, Earl and Derek Wright.
|
| 127 |
The current version (5.x-2.*) was a fairly fundamental re-write of the
|
| 128 |
original, based on lessons learned in practice. The back-end server
|
| 129 |
infrastructure and protocol for transfering data about available
|
| 130 |
updates was completely changed by Derek, and the client code was
|
| 131 |
overhauled by Earl and Derek.
|
| 132 |
|
| 133 |
Nedjo Rogers: http://drupal.org/user/4481 (nedjo)
|
| 134 |
Earl Miles: http://drupal.org/user/26979 (merlinofchaos)
|
| 135 |
Derek Wright: http://drupal.org/user/46549 (dww)
|
| 136 |
|
| 137 |
|
| 138 |
$Id: README.txt,v 1.7 2007/08/08 15:02:26 dww Exp $
|