C:/drupal/modules/update/update.compare.inc File Reference

Go to the source code of this file.


Functions

 update_get_projects ()
 _update_process_info_list (&$projects, $list, $project_type)
 update_get_project_name ($file)
 update_process_project_info (&$projects)
 update_calculate_project_data ($available)
 update_project_cache ($cid)


Detailed Description

Code required only when comparing available updates to existing data.

Definition in file update.compare.inc.


Function Documentation

_update_process_info_list ( &$  projects,
list,
project_type 
)

Populate an array of project data.

Definition at line 42 of file update.compare.inc.

References name, and update_get_project_name().

Referenced by update_get_projects().

Here is the call graph for this function:

update_calculate_project_data ( available  ) 

Given the installed projects and the available release data retrieved from remote servers, calculate the current status.

This function is the heart of the update status feature. It iterates over every currently installed project. For each one, it first checks if the project has been flagged with a special status like "unsupported" or "insecure", or if the project node itself has been unpublished. In any of those cases, the project is marked with an error and the next project is considered.

If the project itself is valid, the function decides what major release series to consider. The project defines what the currently supported major versions are for each version of core, so the first step is to make sure the current version is still supported. If so, that's the target version. If the current version is unsupported, the project maintainer's recommended major version is used. There's also a check to make sure that this function never recommends an earlier release than the currently installed major version.

Given a target major version, it scans the available releases looking for the specific release to recommend (avoiding beta releases and development snapshots if possible). This is complicated to describe, but an example will help clarify. For the target major version, find the highest patch level. If there is a release at that patch level with no extra ("beta", etc), then we recommend the release at that patch level with the most recent release date. If every release at that patch level has extra (only betas), then recommend the latest release from the previous patch level. For example:

1.6-bugfix <-- recommended version because 1.6 already exists. 1.6

or

1.6-beta 1.5 <-- recommended version because no 1.6 exists. 1.4

It also looks for the latest release from the same major version, even a beta release, to display to the user as the "Latest version" option. Additionally, it finds the latest official release from any higher major versions that have been released to provide a set of "Also available" options.

Finally, and most importantly, it keeps scanning the release history until it gets to the currently installed release, searching for anything marked as a security update. If any security updates have been found between the recommended release and the installed version, all of the releases that included a security fix are recorded so that the site administrator can be warned their site is insecure, and links pointing to the release notes for each security update can be included (which, in turn, will link to the official security announcements for each vulnerability).

This function relies on the fact that the .xml release history data comes sorted based on major version and patch level, then finally by release date if there are multiple releases such as betas from the same major.patch version (e.g. 5.x-1.5-beta1, 5.x-1.5-beta2, and 5.x-1.5). Development snapshots for a given major version are always listed last.

Parameters:
$available Array of data about available project releases.
See also:
update_get_available()

update_get_projects()

update_process_project_info()

Definition at line 234 of file update.compare.inc.

References cache_set(), drupal_alter(), t(), update_get_projects(), update_process_project_info(), and update_project_cache().

Referenced by update_status().

Here is the call graph for this function:

update_get_project_name ( file  ) 

Given a $file object (as returned by system_get_files_database()), figure out what project it belongs to.

See also:
system_get_files_database()

Definition at line 101 of file update.compare.inc.

References name.

Referenced by _update_process_info_list().

update_get_projects (  ) 

Fetch an array of installed and enabled projects.

This is only responsible for generating an array of projects (taking into account projects that include more than one module or theme). Other information like the specific version and install type (official release, dev snapshot, etc) is handled later in update_process_project_info() since that logic is only required when preparing the status report, not for fetching the available release data.

See also:
update_process_project_info()

update_calculate_project_data()

Definition at line 23 of file update.compare.inc.

References _update_process_info_list(), cache_set(), module_rebuild_cache(), and update_project_cache().

Referenced by _update_refresh(), and update_calculate_project_data().

Here is the call graph for this function:

update_process_project_info ( &$  projects  ) 

Process the list of projects on the system to figure out the currently installed versions, and other information that is required before we can compare against the available releases to produce the status report.

Parameters:
$projects Array of project information from update_get_projects().

Definition at line 125 of file update.compare.inc.

References t().

Referenced by update_calculate_project_data().

Here is the call graph for this function:

update_project_cache ( cid  ) 

Retrieve data from {cache_update} or empty the cache when necessary.

Two very expensive arrays computed by this module are the list of all installed modules and themes (and .info data, project associations, etc), and the current status of the site relative to the currently available releases. These two arrays are cached in the {cache_update} table and used whenever possible. The cache is cleared whenever the administrator visits the status report, available updates report, or the module or theme administration pages, since we should always recompute the most current values on any of those pages.

Parameters:
$cid The cache id of data to return from the cache. Valid options are 'update_project_data' and 'update_project_projects'.
Returns:
The cached value of the $projects array generated by update_calculate_project_data() or update_get_projects(), or an empty array when the cache is cleared.

Definition at line 580 of file update.compare.inc.

References cache_clear_all(), and cache_get().

Referenced by update_calculate_project_data(), and update_get_projects().

Here is the call graph for this function:


Generated on Mon Jun 2 15:08:32 2008 for SimpleTest by  1.5.5