`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.
git-svn-id: https://develop.svn.wordpress.org/trunk@39005 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@38961 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@38899 602fd350-edb4-49c9-b593-d223f7449a82
`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.
git-svn-id: https://develop.svn.wordpress.org/trunk@38814 602fd350-edb4-49c9-b593-d223f7449a82
Restore `get_current_site()` to a multisite only function. Providing this in single site may be a possibility in the future, but should have a dedicated ticket and discussion.
See #37699.
git-svn-id: https://develop.svn.wordpress.org/trunk@38636 602fd350-edb4-49c9-b593-d223f7449a82
If a user is installing WordPress for the first time and has set `WP_DEBUG` to true, a PHP error during installation makes for a visually jarring experience.
Fixes#37358
git-svn-id: https://develop.svn.wordpress.org/trunk@38423 602fd350-edb4-49c9-b593-d223f7449a82
This fixes the paths in `wp-vendor/` that were including `src`. I want to drop this in so we can find out what else will break.
See #36335.
git-svn-id: https://develop.svn.wordpress.org/trunk@38411 602fd350-edb4-49c9-b593-d223f7449a82
The generated classmaps reference `/src/` files and operates in the assumption that the base directory is one level above `wp-settings.php`, which it isn't after our build processes are run.
See #36335
git-svn-id: https://develop.svn.wordpress.org/trunk@38402 602fd350-edb4-49c9-b593-d223f7449a82
* `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.
git-svn-id: https://develop.svn.wordpress.org/trunk@38399 602fd350-edb4-49c9-b593-d223f7449a82
There is a bug in PHP 5.2.6 - 5.2.17 (https://bugs.php.net/bug.php?id=44936, https://3v4l.org/IL0A2) which changes the access level of a setting to 63 after `ini_set()` was called.
To continue comparing the access value against `INI_ALL` and `INI_USER` use the bit operator `& 7`:
* `1 & 7 === 1` (INI_USER)
* `2 & 7 === 2` (INI_PERDIR)
* `4 & 7 === 4` (INI_SYSTEM)
* `7 & 7 === 7` (INI_ALL)
* `63 & 7 === 7` (INI_ALL)
See [38015].
See #32075.
git-svn-id: https://develop.svn.wordpress.org/trunk@38017 602fd350-edb4-49c9-b593-d223f7449a82
* 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.
git-svn-id: https://develop.svn.wordpress.org/trunk@38015 602fd350-edb4-49c9-b593-d223f7449a82
`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.
git-svn-id: https://develop.svn.wordpress.org/trunk@38012 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@37918 602fd350-edb4-49c9-b593-d223f7449a82
These adjustments improve the documentation for the filters and adjust the names make them more consistent with other filters already in core.
See #34936.
Props DrewAPicture, ocean90, jorbin
git-svn-id: https://develop.svn.wordpress.org/trunk@37690 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@37677 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@37670 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@37626 602fd350-edb4-49c9-b593-d223f7449a82
'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.
git-svn-id: https://develop.svn.wordpress.org/trunk@37613 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@37431 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@37342 602fd350-edb4-49c9-b593-d223f7449a82
Uses `wp_debug_mode()` to prevent response from being broken by debug errors. Matches similar behavior of the XML-RPC API.
Props rockwell15.
Fixes#34915.
git-svn-id: https://develop.svn.wordpress.org/trunk@36530 602fd350-edb4-49c9-b593-d223f7449a82
We do an early check for a mysql extension being loaded, but it fails if the `mysqlnd` extension is the only one present.
Props nexurium.
Fixes#33261.
git-svn-id: https://develop.svn.wordpress.org/trunk@36434 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@35688 602fd350-edb4-49c9-b593-d223f7449a82
Various functions in load.php need to check whether WP is in installation mode.
Let's let them.
Props adamsilverstein.
See #31130.
git-svn-id: https://develop.svn.wordpress.org/trunk@34896 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@34828 602fd350-edb4-49c9-b593-d223f7449a82
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
git-svn-id: https://develop.svn.wordpress.org/trunk@34291 602fd350-edb4-49c9-b593-d223f7449a82
This allows for the web server to generate the appropriate `Content-Length` header for the request, allowing for strict clients/proxies/servers to process the response.
Props swissspidy.
Fixes#33626
git-svn-id: https://develop.svn.wordpress.org/trunk@33935 602fd350-edb4-49c9-b593-d223f7449a82
