The intention of `wp_get_environment_type()` is to provide a consistent means of identifying the environment type, not of identifying a specific environment.
Actual environments should fit within one of the existing types: `local`, `development`, `staging`, or `production`. That should cover the types that plugins and themes might be concerned about when toggling functionality.
Props johnbillion, joostdevalk, TimothyBlynJacobs, jeremyfelt, batmoo, claytoncollie, Clorith, markjaquith, garrett-eclipse, GaryJ, elrae.
Fixes#50992.
Built from https://develop.svn.wordpress.org/trunk@48894
git-svn-id: http://core.svn.wordpress.org/trunk@48656 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This gives developers a better control over their existing development workflow and ensures that `local` is not the exact same as `development` if it does not need to be.
Props claytoncollie, johnbillion, jeremyfelt, kreppar, dushakov, TimothyBlynJacobs, Ipstenu, khag7, knutsp, Clorith, markjaquith, joostdevalk, SergeyBiryukov.
Fixes#51064.
Built from https://develop.svn.wordpress.org/trunk@48856
git-svn-id: http://core.svn.wordpress.org/trunk@48618 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Since `wp_get_environment_type()` runs too early for plugins to hook these filters, and the result is then cached in a static variable and cannot be changed later, the filters are not that useful.
The `WP_ENVIRONMENT_TYPES` and `WP_ENVIRONMENT_TYPE` constants and environment variables should be enough for now.
Follow-up to [47919], [48188], [48372].
Props Clorith, SergeyBiryukov.
Fixes#33161.
Built from https://develop.svn.wordpress.org/trunk@48662
git-svn-id: http://core.svn.wordpress.org/trunk@48424 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Rename the `wp_approved_environment_types` filter to `wp_environment_types`.
* Introduce `WP_ENVIRONMENT_TYPES` system variable and constant to complement the filter.
* Correct the argument type for the `wp_environment_types` filter.
* Cache the result in a static variable to ensure consistent return value.
* Rename the `stage` type to `staging`.
Follow-up to [47919].
Props dlh, dd32, TimothyBlynJacobs, johnbillion, pbiron.
See #33161.
Built from https://develop.svn.wordpress.org/trunk@48188
git-svn-id: http://core.svn.wordpress.org/trunk@47957 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Partially reverts [48059] as there's no full consensus on the removal of the text prefix. Further actions should be taken to improve consistency and accessibility of the admin notices. Keeps some improvements to the translatable strings from [48059].
Fixes#47656.
Built from https://develop.svn.wordpress.org/trunk@48115
git-svn-id: http://core.svn.wordpress.org/trunk@47884 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The tag was supported in phpDocumentor 1.x, but is no longer supported in 2.x and 3.x.
Usage of static variables is considered an internal implementation detail and has no information value for someone reading the docs.
Props alishanvr, jrf.
Fixes#50426.
Built from https://develop.svn.wordpress.org/trunk@48109
git-svn-id: http://core.svn.wordpress.org/trunk@47878 1a063a9b-81f0-0310-95a4-ce76da25c4cd
For a number of years, most of the WordPress error messages have been prefixed with "Error:". However, these messages appear in a context where it's already clear an error occurred. Whether it's an error, a warning, or any other classification, that's not so relevant for users. The content of the message is the relevant part. The "Error:" prefix doesn't add great value while it does add unnecessary complexity for the message readability.
Also, revises some of these messages to improve clarity and removes HTML from translatable strings.
Props garrett-eclipse, ramiy, SergeyBiryukov, afercia, sabernhardt, quadthemes, audrasjb.
See #47003, #43037, #42945, #15887.
Fixes#47656.
Built from https://develop.svn.wordpress.org/trunk@48059
git-svn-id: http://core.svn.wordpress.org/trunk@47826 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Many caching backend have support for multiple gets in a single request. This brings that support to core, with a compatability fallback that will loop over requests if needed.
Fixes: #20875.
Props: nacin, tollmanz, wonderboymusic, ryan, jeremyfelt, spacedmonkey, boonebgorges, dd32, rmccue, ocean90, jipmoors, johnjamesjacoby, tillkruess, donmhico, davidbaumwald, SergeyBiryukov, whyisjake.
Built from https://develop.svn.wordpress.org/trunk@47938
git-svn-id: http://core.svn.wordpress.org/trunk@47711 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The type can be set via the `WP_ENVIRONMENT_TYPE` global system variable, a constant of the same name, or the `wp_get_environment_type` filter.
Possible values include `development`, `stage`, `production'. If not set, the type defaults to `production`.
Props Clorith, krogsgard, joostdevalk, frank-klein, Maelacuna, nathanrice, grierson, jchristopher, davidvee, jackfungi, johnbillion, tabrisrp, knutsp, ev3rywh3re, Rastaban, danielbachhuber, pfefferle, audrasjb, SergeyBiryukov.
Fixes#33161.
Built from https://develop.svn.wordpress.org/trunk@47919
git-svn-id: http://core.svn.wordpress.org/trunk@47693 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The `register_globals` directive in PHP was deprecated in version 5.3 and removed entirely in 5.4.
Now that WordPress only supports PHP 5.6.20 and newer, the `wp_unregister_GLOBALS()` function can be deprecated.
Props ayeshrajans, desrosj, SergeyBiryukov.
Fixes#49938.
Built from https://develop.svn.wordpress.org/trunk@47612
git-svn-id: http://core.svn.wordpress.org/trunk@47387 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This avoids the performance overhead of the function call every time `dirname( __FILE__ )` was used instead of `__DIR__`.
This commit also includes:
* Removing unnecessary parentheses from `include`/`require` statements. These are language constructs, not function calls.
* Replacing `include` statements for several files with `require_once`, for consistency:
* `wp-admin/admin-header.php`
* `wp-admin/admin-footer.php`
* `wp-includes/version.php`
Props ayeshrajans, desrosj, valentinbora, jrf, joostdevalk, netweb.
Fixes#48082.
Built from https://develop.svn.wordpress.org/trunk@47198
git-svn-id: http://core.svn.wordpress.org/trunk@46998 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously, `wp_favicon_request()` was introduced in [13205] to avoid a performance hit of serving a full 404 page on every favicon request.
While working as intended, that implementation did not provide a way for theme or plugin authors to manage the behavior of favicon requests.
This changeset implements the following logic (only applied if WordPress is installed in the root directory):
* If there is a Site Icon set in Customizer, redirect `/favicon.ico` requests to that icon.
* Otherwise, use the WordPress logo as a default icon.
* If a physical `/favicon.ico` file exists, do nothing, let the server handle the request.
Handling `/favicon.ico` is now more consistent with handling `/robots.txt` requests.
New functions and hooks:
* Introduce `is_favicon()` conditional tag to complement `is_robots()`.
* Introduce `do_favicon` action to complement `do_robots` and use it in template loader.
* Introduce `do_favicon()` function, hooked to the above action by default, to complement `do_robots()`.
* Introduce `do_faviconico` action to complement `do_robotstxt`, for plugins to override the default behavior.
* Mark `wp_favicon_request()` as deprecated in favor of `do_favicon()`.
Props jonoaldersonwp, birgire, joostdevalk, mukesh27, SergeyBiryukov.
Fixes#47398.
Built from https://develop.svn.wordpress.org/trunk@47018
git-svn-id: http://core.svn.wordpress.org/trunk@46818 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Fix typo in `is_blog_admin()` description.
* Capitalize PHP correctly in `enable_wp_debug_mode_checks` filter description.
* Capitalize XML correctly in `wp_is_xml_request()` return value description.
Props stevegrunwell.
Fixes#48771.
Built from https://develop.svn.wordpress.org/trunk@46759
git-svn-id: http://core.svn.wordpress.org/trunk@46559 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The path to magic quote sanity took a fun and exciting turn: PHP core removed it and WordPress updated the minimum version.
For the formally external pclzip, the code is commented out to make investigating easier and in case we ever need to merge upstream (if that still exists) changes.
Props ayeshrajans, jrf, jorbin.
See #47783.
Fixes#18322.
Built from https://develop.svn.wordpress.org/trunk@46105
git-svn-id: http://core.svn.wordpress.org/trunk@45917 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Add missing translator comments.
* Fix placement of some translator comments. Translator comments should be on the line directly above the line containing the translation function call for optimal compatibility with various `.pot` file generation tools. The CS auto-fixing, which changed some inconsistent function calls to multi-line function calls, is part of the reason why this was no longer the case for a select group of translator comments.
Includes minor code layout fixes.
Polyglots, rejoice! All WordPress core files now have translator comments for all strings with placeholders!
Props jrf, subrataemfluence, GaryJ, webdados, Dency, swissspidy, alvarogois, marcomartins, mihaiiceyro, vladwtz, niq1982, flipkeijzer, michielatyoast, chandrapatel, thrijith, joshuanoyce, FesoVik, tessak22, bhaktirajdev, cleancoded, dhavalkasvala, garrett-eclipse, bibliofille, socalchristina, priyankkpatel, 5hel2l2y, adamsilverstein, JeffPaul, pierlo, SergeyBiryukov.
Fixes#44360.
Built from https://develop.svn.wordpress.org/trunk@45926
git-svn-id: http://core.svn.wordpress.org/trunk@45737 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Noteable changes:
- The `magic_quotes_runtime` and `magic_quotes_sybase` settings were removed in PHP 5.4, so no longer need to be set.
- Some functions that use external libraries can generate errors that can't be tested for, so are globally allowed to silence errors.
- Quite a few functions would cause errors if `safe_mode` was set. This setting was removed in PHP 5.4.
- Only a handful of `header()` calls needed corresponding `headers_sent()` checks for unit tests to pass, but more may need to be added as the nightlies builds are tested.
See #46732.
Built from https://develop.svn.wordpress.org/trunk@45611
git-svn-id: http://core.svn.wordpress.org/trunk@45422 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Prior to this change, resuming or activating a plugin or theme that is still broken would result in a redirect loop if in recovery mode. If outside recovery mode, it would cause the error template to be displayed.
Furthermore this applies to breaking a plugin or theme when editing from the backend.
Props aandrewdixon, azaozz, dhanukanuwan, henrywright, ocean90, ohiosierra, PandelisZ, xkon.
Fixes#46045, #46751.
Built from https://develop.svn.wordpress.org/trunk@45114
git-svn-id: http://core.svn.wordpress.org/trunk@44923 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Using the new fatal handler introduced in [44962], an email is sent to the admin when a fatal error occurs. This email includes a secret link to enter recovery mode. When clicked, the link will be validated and on success a cookie will be placed on the client, enabling recovery mode for that user. This functionality is executed early before plugins and themes are loaded, in order to be unaffected by potential fatal errors these might be causing.
When in recovery mode, broken plugins and themes will be paused for that client, so that they are able to access the admin backend despite of these errors. They are notified about the broken extensions and the errors caused, and can then decide whether they would like to temporarily deactivate the extension or fix the problem and resume the extension.
A link in the admin bar allows the client to exit recovery mode.
Props timothyblynjacobs, afragen, flixos90, nerrad, miss_jwo, schlessera, spacedmonkey, swissspidy.
Fixes#46130, #44458.
Built from https://develop.svn.wordpress.org/trunk@44973
git-svn-id: http://core.svn.wordpress.org/trunk@44804 1a063a9b-81f0-0310-95a4-ce76da25c4cd
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
