| [ Index ] |
PHP Cross Reference of WordPress Trunk (Updated Daily) |
[Source view] [Print] [Project Stats]
WordPress core upgrade functionality.
| File Size: | 1765 lines (67 kb) |
| Included or required: | 1 time |
| Referenced: | 4 times |
| Includes or requires: | 1 file wp-admin/admin-footer.php |
| update_core( $from, $to ) X-Ref |
| Upgrades the core of WordPress. This will create a .maintenance file at the base of the WordPress directory to ensure that people can not access the website, when the files are being copied to their locations. The files in the `$_old_files` list will be removed and the new files copied from the zip file after the database is upgraded. The files in the `$_new_bundled_files` list will be added to the installation if the version is greater than or equal to the old version being upgraded. The steps for the upgrader for after the new release is downloaded and unzipped is: 1. Test unzipped location for select files to ensure that unzipped worked. 2. Create the .maintenance file in current WordPress base. 3. Copy new WordPress directory over old WordPress files. 4. Upgrade WordPress to new version. 4.1. Copy all files/folders other than wp-content 4.2. Copy any language files to WP_LANG_DIR (which may differ from WP_CONTENT_DIR 4.3. Copy any new bundled themes/plugins to their respective locations 5. Delete new WordPress directory path. 6. Delete .maintenance file. 7. Remove old files. 8. Delete 'update_core' option. There are several areas of failure. For instance if PHP times out before step 6, then you will not be able to access any portion of your site. Also, since the upgrade will not continue where it left off, you will not be able to automatically remove old files and remove the 'update_core' option. This isn't that bad. If the copy of the new WordPress over the old fails, then the worse is that the new WordPress directory will remain. If it is assumed that every file will be copied over, including plugins and themes, then if you edit the default theme, you should rename it, so that your changes remain. return: string|WP_Error New WordPress version on success, WP_Error on failure. param: string $from New release unzipped path. param: string $to Path to old WordPress installation. |
| _preload_old_requests_classes_and_interfaces( $to ) X-Ref |
| Preloads old Requests classes and interfaces. This function preloads the old Requests code into memory before the upgrade process deletes the files. Why? Requests code is loaded into memory via an autoloader, meaning when a class or interface is needed If a request is in process, Requests could attempt to access code. If the file is not there, a fatal error could occur. If the file was replaced, the new code is not compatible with the old, resulting in a fatal error. Preloading ensures the code is in memory before the code is updated. param: string $to Path to old WordPress installation. |
| _redirect_to_about_wordpress( $new_version ) X-Ref |
| Redirect to the About WordPress page after a successful upgrade. This function is only needed when the existing installation is older than 3.4.0. param: string $new_version |
| _upgrade_422_remove_genericons() X-Ref |
| Cleans up Genericons example files. |
| _upgrade_422_find_genericons_files_in_folder( $directory ) X-Ref |
| Recursively find Genericons example files in a given folder. return: array param: string $directory Directory path. Expects trailingslashed. |
| _upgrade_440_force_deactivate_incompatible_plugins() X-Ref |
| No description |
| _upgrade_core_deactivate_incompatible_plugins() X-Ref |
| Generated : Tue Apr 23 08:20:01 2024 | Cross-referenced by PHPXref |