| [ Index ] |
PHP Cross Reference of Drupal 6 (yi-drupal) |
[Source view] [Print] [Project Stats]
(no description)
| File Size: | 701 lines (31 kb) |
| Included or required: | 0 times |
| Referenced: | 0 times |
| Includes or requires: | 0 files |
| update_get_projects() X-Ref |
| 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. This array is fairly expensive to construct, since it involves a lot of disk I/O, so we cache the results into the {cache_update} table using the 'update_project_projects' cache ID. However, since this is not the data about available updates fetched from the network, it is ok to invalidate it somewhat quickly. If we keep this data for very long, site administrators are more likely to see incorrect results if they upgrade to a newer version of a module or theme but do not visit certain pages that automatically clear this cache. |
| _update_process_info_list(&$projects, $list, $project_type) X-Ref |
| Populate an array of project data. |
| update_get_project_name($file) X-Ref |
| Given a $file object (as returned by system_get_files_database()), figure out what project it belongs to. |
| update_process_project_info(&$projects) X-Ref |
| 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. param: $projects |
| update_calculate_project_data($available) X-Ref |
| 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. The results of this function are expensive to compute, especially on sites with lots of modules or themes, since it involves a lot of comparisons and other operations. Therefore, we cache the results into the {cache_update} table using the 'update_project_data' cache ID. However, since this is not the data about available updates fetched from the network, it is ok to invalidate it somewhat quickly. If we keep this data for very long, site administrators are more likely to see incorrect results if they upgrade to a newer version of a module or theme but do not visit certain pages that automatically clear this cache. param: $available |
| update_project_cache($cid) X-Ref |
| 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. Note: while both of these arrays are expensive to compute (in terms of disk I/O and some fairly heavy CPU processing), neither of these is the actual data about available updates that we have to fetch over the network from updates.drupal.org. That information is stored with the 'update_available_releases' cache ID -- it needs to persist longer than 1 hour and never get invalidated just by visiting a page on the site. param: $cid return: |
| update_filter_project_info($info) X-Ref |
| Filter the project .info data to only save attributes we need. param: array $info return: |
| Generated: Mon Jul 9 18:01:44 2012 | Cross-referenced by PHPXref 0.7 |