Due to the high number of follow-up tickets and associated security concerns, it was decided to reschedule the fatal error recovery feature for WordPress 5.2, in order to address these issues properly. The feature will continue to be developed, with iterations being merged into trunk early in the 5.2 release cycle.
Fixes#46141. See #44458, #45932, #45940, #46038, #46047, #46068.
Built from https://develop.svn.wordpress.org/trunk@44717
git-svn-id: http://core.svn.wordpress.org/trunk@44548 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This changeset introduces a `WP_Shutdown_Handler` class that detects fatal errors and which extension (plugin or theme) causes them. Such an error is then recorded, and an error message is displayed. Subsequently, in certain protected areas, for example the admin, the broken extension will be paused, ensuring that the website is still usable in the respective area. The major benefit is that this mechanism allows site owners to still log in to their website, to fix the problem by either disabling the extension or solving the bug and then resuming the extension.
Extensions are only paused in certain designated areas. The frontend for example stays unaffected, as it is impossible to know what pausing the extension would cause to be missing, so it might be preferrable to clearly see that the website is temporarily not accessible instead.
The fatal error recovery is especially important in scope of encouraging the switch to a maintained PHP version, as not necessarily every WordPress extension is compatible with all PHP versions. If problems occur now, non-technical site owners that do not have immediate access to the codebase are not locked out of their site and can at least temporarily solve the problem quickly.
Websites that have custom requirements in that regard can implement their own shutdown handler by adding a `shutdown-handler.php` drop-in that returns the handler instance to use, which must be based on a class that inherits `WP_Shutdown_Handler`. That handler will then be used in place of the default one.
Websites that would like to modify specifically the error template displayed in the frontend can add a `php-error.php` drop-in that works similarly to the existing `db-error.php` drop-in.
Props afragen, bradleyt, flixos90, ocean90, schlessera, SergeyBiryukov, spacedmonkey.
Fixes#44458.
Built from https://develop.svn.wordpress.org/trunk@44524
git-svn-id: http://core.svn.wordpress.org/trunk@44355 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Because WP REST API requests aren't identified until `parse_request`, it's impractical to reference the `REST_REQUEST` constant in `wp_debug_mode()`. Instead, it's more helpful to assume that a request wanting a JSON response probably doesn't want PHP errors breaking the response.
Merges [43730] to trunk.
Props chrisl27, duanestorey, earnjam.
Fixes#44534.
Built from https://develop.svn.wordpress.org/trunk@43983
git-svn-id: http://core.svn.wordpress.org/trunk@43815 1a063a9b-81f0-0310-95a4-ce76da25c4cd
WPCS 1.0.0 includes a bunch of new auto-fixers, which drops the number of coding standards issues across WordPress significantly. Prior to running the auto-fixers, there were 15,312 issues detected. With this commit, we now drop to 4,769 issues.
This change includes three notable additions:
- Multiline function calls must now put each parameter on a new line.
- Auto-formatting files is now part of the `grunt precommit` script.
- Auto-fixable coding standards issues will now cause Travis failures.
Fixes#44600.
Built from https://develop.svn.wordpress.org/trunk@43571
git-svn-id: http://core.svn.wordpress.org/trunk@43400 1a063a9b-81f0-0310-95a4-ce76da25c4cd
A new global multisite table `wp_blogmeta` is added to the database schema, and a set of `*_site_meta()` API functions are introduced.
The implementation fails gracefully when the new table is not yet available, which may happen especially shortly after the core update, before the network has been upgraded to the new database schema. The presence of the table is detected once and stored as a global setting on the main network.
Core does not yet use site metadata, but there are several use-cases to be implemented or explored in the near future, and it allows plugins to extend sites with arbitrary data, which will come in particularly handy with the upcoming REST API endpoint for sites.
Props spacedmonkey, johnjamesjacoby, jeremyfelt, flixos90.
Fixes#37923.
Built from https://develop.svn.wordpress.org/trunk@42836
git-svn-id: http://core.svn.wordpress.org/trunk@42666 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Rework logic for how external object caches are detected, so that if
an external cache does not define a `wp_cache_init()`, the built-in
object cache will be used.
Object caches can now wrap their entire contents in logic checks. So a
Redis caching backend could make sure that the `Redis` PHP class is
available before defining all the caching functions. And if Redis is
not available, the site doesn't break or throw errors or think it is
using caching when it isn't. This is particularly useful for doing
local development, where you might want to develop on a site without
running Memcache or Redis like you are in production.
* Accounts for multisite, which may re-initialize the object cache
multiple times.
* Accounts for object caches that may include `object-cache.php` during
`advanced-cache.php` (before WP loads it).
Props jtsternberg, markjaquith.
Fixes#22661.
Built from https://develop.svn.wordpress.org/trunk@42723
git-svn-id: http://core.svn.wordpress.org/trunk@42553 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This pattern occurs a handful of times across the codebase:
`<div class="foo<?php if ( $bar ) { echo ' baz'; } ?>">`
Unfortunately, it doesn't really play nicely with `phpcbf`, so all instances need to be removed in preperation for auto code formatting.
See #41057.
Built from https://develop.svn.wordpress.org/trunk@42217
git-svn-id: http://core.svn.wordpress.org/trunk@42046 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Increase PHP execution time limit prior to issuing loopback requests where are themselves given timeouts to ensure PHP file can be reverted.
* Output scrape messages on success and failure so that absence of either can also be flagged as an error condition.
* Forward browser's HTTP Basic Auth credentials in loopback requests to admin and home URL.
* Display more helpful message when loopback request fails.
Amends [41721].
See #21622.
Fixes#42102.
Built from https://develop.svn.wordpress.org/trunk@41805
git-svn-id: http://core.svn.wordpress.org/trunk@41639 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Edits to active plugins which cause PHP fatal errors will no longer auto-deactivate the plugin. Supersedes #39766.
* Introduce sandboxed PHP file edits for active themes, preventing accidental whitescreening of a user's site when introducing a fatal error.
* After writing a change to a PHP file for an active theme or plugin, perform loopback requests on the file editor admin screens and the homepage to check for fatal errors. If a fatal error is encountered, roll back the edited file and display the error to the user to fix and try again.
* Introduce a secure way to scrape PHP fatal errors from a site via `wp_start_scraping_edited_file_errors()` and `wp_finalize_scraping_edited_file_errors()`.
* Moves file modifications from `theme-editor.php` and `plugin-editor.php` to common `wp_edit_theme_plugin_file()` function.
* Refactor themes and plugin editors to submit file changes via Ajax instead of doing full page refreshes when JS is available.
* Use `get` method for theme/plugin dropdowns.
* Improve styling of plugin editors, including width of plugin/theme dropdowns.
* Improve notices API for theme/plugin editor JS component.
* Strip common base directory from plugin file list. See #24048.
* Factor out functions to list editable file types in `wp_get_theme_file_editable_extensions()` and `wp_get_plugin_file_editable_extensions()`.
* Scroll to line in editor that has linting error when attempting to save. See #41886.
* Add checkbox to dismiss lint errors to proceed with saving. See #41887.
* Only style the Update File button as disabled instead of actually disabling it for accessibility reasons.
* Ensure that value from CodeMirror is used instead of `textarea` when CodeMirror is present.
* Add "Are you sure?" check when leaving editor when there are unsaved changes.
Supersedes [41560].
See #39766, #24048, #41886.
Props westonruter, Clorith, melchoyce, johnbillion, jjj, jdgrimes, azaozz.
Fixes#21622, #41887.
Built from https://develop.svn.wordpress.org/trunk@41721
git-svn-id: http://core.svn.wordpress.org/trunk@41555 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`wp_load_translations_early()` is used when WordPress isn't fully initialized. Therefore using the `WP_Locale_Switcher` with `get_locale()`/`get_user_locale()` can cause PHP fatal errors.
This reverts [38976] and [38977], and instead removes `WP_Locale_Switcher` from `wp_load_translations_early()`.
See #29783.
Fixes#38535.
Built from https://develop.svn.wordpress.org/trunk@39005
git-svn-id: http://core.svn.wordpress.org/trunk@38947 1a063a9b-81f0-0310-95a4-ce76da25c4cd
With the introduction of user-specific languages in [38705] it's necessary to be able to switch translations on the fly. For example emails should be sent in the language of the recipient and not the one of the current user.
This introduces a new `WP_Locale_Switcher` class which is used for switching locales and translations. It holds the stack of locales whenever `switch_to_locale( $locale )` is called. With `restore_previous_locale()` you can restore the previous locale. `restore_current_locale()` empties the stack and sets the locale back to the initial value.
`switch_to_locale()` is added to most of core's email functions, either with the value of `get_locale()` (site language) or `get_user_locale()` (user language with fallback to site language).
Props yoavf, tfrommen, swissspidy, pbearne, ocean90.
See #29783.
Fixes#26511.
Built from https://develop.svn.wordpress.org/trunk@38961
git-svn-id: http://core.svn.wordpress.org/trunk@38904 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously we ensured that the entry points to WordPress were parsable by PHP4 in order to display a friendly not-supported-php error message.
However, for the last two years the main entry points have not actually parsed, and we've only added extra parse errors since it last worked in 3.9, so it's time we just remove this 'feature'.
The PHP version checks are still there for PHP 5.0/5.1, and so it's inplace when we eventually drop PHP 5.2 support.
See #29489.
Built from https://develop.svn.wordpress.org/trunk@38899
git-svn-id: http://core.svn.wordpress.org/trunk@38842 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`get_network()` falls back to the current network when called without any arguments. Between this and `get_current_network_id()`, we can replace almost all instances of the global `$current_site` and all instances of `get_current_site()`.
This effectively deprecates `get_current_site()`, something that we'll do in a future ticket.
Props flixos90.
Fixes#37414.
Built from https://develop.svn.wordpress.org/trunk@38814
git-svn-id: http://core.svn.wordpress.org/trunk@38757 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* `wp-admin` and `wp-includes` are scanned for classes to autoload
* Several 3rd-party and Ryan McCue-shaped libraries are excluded when the classmap is generated, see `composer.json`: `autoload.exclude-from-classmap`
* `wp-vendor/autoload_52.php` is included at the top of `wp-settings.php` - no changes need to be made to unit tests to include the autoloader
* An avalanche of `require()` and `require_once()` calls that loaded class files have been removed from the codebase.
The following files have been added to `svn:ignore` - they are not 5.2-compatible and fail during pre-commit:
* src/wp-vendor/autoload.php
* src/wp-vendor/composer/autoload_real.php
* src/wp-vendor/composer/autoload_static.php
* src/wp-vendor/composer/ClassLoader.php
We favor these files instead:
* src/wp-vendor/autoload_52.php
* src/wp-vendor/composer/autoload_real_52.php
* src/wp-vendor/composer/ClassLoader52.php
When new PHP classes are added to the codebase, simply run `composer install` or `composer update` from the project root to update the autoloader.
The future is now.
See #36335.
Built from https://develop.svn.wordpress.org/trunk@38399
git-svn-id: http://core.svn.wordpress.org/trunk@38340 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Don't lower memory limit if the current limit is greater than `WP_MAX_MEMORY_LIMIT`.
* Set `WP_MEMORY_LIMIT` and `WP_MAX_MEMORY_LIMIT` to current limit if the `memory_limit` setting can't be changed at runtime.
* Use `wp_convert_hr_to_bytes()` when parsing the value of the `memory_limit` setting because it can be a shorthand or an integer value.
* Introduce `wp_raise_memory_limit( $context )` to raise the PHP memory limit for memory intensive processes. This DRYs up some logic and includes the existing `admin_memory_limit` and `image_memory_limit` filters. The function can also be used for custom contexts, the `{$context}_memory_limit` filter allows to customize the limit.
* Introduce `wp_is_ini_value_changeable( $setting )` to determine whether a PHP ini value is changeable at runtime.
* Remove a `function_exists( 'memory_get_usage' )` check. Since PHP 5.2.1 support for memory limit is always enabled.
Related commits: [38011-38013]
Props jrf, A5hleyRich, swissspidy, ocean90.
Fixes#32075.
Built from https://develop.svn.wordpress.org/trunk@38015
git-svn-id: http://core.svn.wordpress.org/trunk@37956 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`wp_convert_hr_to_bytes()` was previously defined in wp-includes/media.php because it's only used by `wp_max_upload_size()` in the same file.
Moving this function to load.php allows us to improve core's memory limit handling.
See #32075.
Built from https://develop.svn.wordpress.org/trunk@38012
git-svn-id: http://core.svn.wordpress.org/trunk@37953 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In the past, `get_blog_details()` has been used to retrieve the `home`, `siteurl`, `blogname`, and `post_count` options for a site. By lazy loading properties in a `WP_Site` object, we can avoid having to use `get_blog_details()` and instead provide the properties as needed.
This introduces the global `site-details` cache group in which standard objects representing the site are stored. This will one day be a replacement for the `blog-details` cache group that is currently used in `get_blog_details()`.
This relies on the `ms_loaded` action introduced in [37916] as properties are not available via `get_option()` until multisite has been fully loaded.
Props flixos90.
Fixes#36935.
Built from https://develop.svn.wordpress.org/trunk@37918
git-svn-id: http://core.svn.wordpress.org/trunk@37859 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Moving to load.php introduces parity with other commonly evaluated `is_*()` functions such as `is_admin()` or `is_multisite()`. It also makes `is_ssl()` available much earlier in the loading process, such as for use in drop-ins like advanced-cache.php.
Props johnjamesjacoby.
Fixes#35844.
Built from https://develop.svn.wordpress.org/trunk@37677
git-svn-id: http://core.svn.wordpress.org/trunk@37643 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Similar to `get_current_blog_id`, this can be used to get the ID of the `$current_site` global. If not available, it will fallback to the main network ID. In single site, this will return 1.
Props spacedmonkey, flixos90.
Fixes#33900.
Built from https://develop.svn.wordpress.org/trunk@37670
git-svn-id: http://core.svn.wordpress.org/trunk@37636 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Non web interfaces with WordPress (such as wp-cli) need to be able to bypass certain checks in the bootstrap process. This introduces three new filters to allow for those checks to be skipped.
1. Provides a way of forcefully bypassing wp_maintenance().
2. Provides a way of forcefully bypassing wp_debug_mode(). See https://github.com/wp-cli/wp-cli/issues/177
3. Provide a way of forcefully skipping loading wp-content/advance-cache.php. See https://github.com/wp-cli/wp-cli/pull/164
These filters should not be used by plugins (in fact, they run before plugins are loaded, so they can't be used by plugins). In general, they should only be used in non-web interactions with WordPress.
See #34936.
Props jorbin, DrewAPicture.
Built from https://develop.svn.wordpress.org/trunk@37626
git-svn-id: http://core.svn.wordpress.org/trunk@37594 1a063a9b-81f0-0310-95a4-ce76da25c4cd
'comment' was made non-persistent in [7986], to address the difficulty of
reliable cache invalidation. Since then, the comment system has improved such
that we can be more confident that caches are being busted as needed.
Props spacedmonkey.
Fixes#36906.
Built from https://develop.svn.wordpress.org/trunk@37613
git-svn-id: http://core.svn.wordpress.org/trunk@37581 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Also use 'back-compat' in some inline comments where backward compatibility is the subject and shorthand feels more natural.
Note: 'backwards compatibility/compatibile' can also be considered correct, though it's primary seen in regular use in British English.
Props ocean90.
Fixes#36835.
Built from https://develop.svn.wordpress.org/trunk@37431
git-svn-id: http://core.svn.wordpress.org/trunk@37397 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Known functions, classes, and methods are now auto-linked in Code Reference pages following #meta1483.
Note: Hook references are still linked via inline `@see` tags due to the unlikelihood of reliably matching for known hooks based on a RegEx pattern.
See #32246.
Built from https://develop.svn.wordpress.org/trunk@37342
git-svn-id: http://core.svn.wordpress.org/trunk@37308 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Keeping myhacks support is a small price to pay for not breaking people's sites. Even if it is very very very few sites, breaking sites isn't something that should be encouraged. Even with 10 years of deprecation notices.
https://core.trac.wordpress.org/ticket/33741#comment:18 outlines all the ways that the hack_file and my-hacks options can be setup and thus all the ways that the removal of those options could break sites.
Fixes#33741.
Built from https://develop.svn.wordpress.org/trunk@35688
git-svn-id: http://core.svn.wordpress.org/trunk@35652 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The `WP_INSTALLING` constant is a flag that WordPress sets in a number of
places, telling the system that options should be fetched directly from the
database instead of from the cache, that WP should not ping wordpress.org for
updates, that the normal "not installed" checks should be bypassed, and so on.
A constant is generally necessary for this purpose, because the flag is
typically set before the WP bootstrap, meaning that WP functions are not yet
available. However, it is possible - notably, during `wpmu_create_blog()` -
for the "installing" flag to be set after WP has already loaded. In these
cases, `WP_INSTALLING` would be set for the remainder of the process, since
there's no way to change a constant once it's defined. This, in turn, polluted
later function calls that ought to have been outside the scope of site
creation, particularly the non-caching of option data. The problem was
particularly evident in the case of the automated tests, where `WP_INSTALLING`
was set the first time a site was created, and remained set for the rest of the
suite.
The new `wp_installing()` function allows developers to fetch the current
installation status (when called without any arguments) or to set the
installation status (when called with a boolean `true` or `false`). Use of
the `WP_INSTALLING` constant is still supported; `wp_installing()` will default
to `true` if the constant is defined during the bootstrap.
Props boonebgorges, jeremyfelt.
See #31130.
Built from https://develop.svn.wordpress.org/trunk@34828
git-svn-id: http://core.svn.wordpress.org/trunk@34793 1a063a9b-81f0-0310-95a4-ce76da25c4cd
For the last 10 years, my-hacks has been deprecated and has been throwing a deprecation notice. For the last six years, you haven't been able to enable my-hacks.php in the admin UI. That should be enough time to give developers notice. Plugins and themes seem like they might have staying power.
Fixes#33741
Props bobbingwide
Built from https://develop.svn.wordpress.org/trunk@34291
git-svn-id: http://core.svn.wordpress.org/trunk@34255 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The check is true for `wp-admin/plugin-install.php` and `wp-admin/theme-install.php` too. This will end in a redirect to `/wp-admin/upgrade.php` or a screen with a bunch of errors.
The `WP_INSTALLING` constant was added in WordPress 1.5.1 to `wp-admin/install.php` which makes the check for "install.php" redundant.
props joemcgill.
fixes#29694.
Built from https://develop.svn.wordpress.org/trunk@30581
git-svn-id: http://core.svn.wordpress.org/trunk@30571 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Felix Arntz
Gary Pendergast
Jeremy Felt
Sergey Biryukov
John Blackbourn
Dominik Schilling
Mark Jaquith
Drew Jaynes
Weston Ruter
Pascal Birchler
Dion Hulse
Scott Taylor
Aaron Jorbin
Boone Gorges
Rachel Baker
Eric Lewis
Andrew Nacin