Adds context to one string used in two different contexts for the new user and new site signup email notification.
More to come.
See #38882
git-svn-id: https://develop.svn.wordpress.org/trunk@39323 602fd350-edb4-49c9-b593-d223f7449a82
[38961] added a `$user = get_user_by( 'login', $user );` call which was overriding the `$user` string variable for the login name. The change to `$user_login` makes this clear.
Props johnjamesjacoby.
Fixes#38763.
git-svn-id: https://develop.svn.wordpress.org/trunk@39203 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
`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
An empty string in `WPLANG` is used to define the site language as `en_US`. The `! empty()` check didn't catch this case so that `wpmu_create_blog()` fell back to the network setting.
Fixes#36918.
git-svn-id: https://develop.svn.wordpress.org/trunk@38655 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
Defer to the new `get_sites()` replacement, offering fresh (...or cached) `WP_Site` objects via the new `WP_Site_Query`.
Props flixos90.
Fixes#36994.
git-svn-id: https://develop.svn.wordpress.org/trunk@37653 602fd350-edb4-49c9-b593-d223f7449a82
Full `WP_Site` objects should be expected from `get_site()` rather than arrays.
In the single (soon to be deprecated) use of arrays for this in core, we can cast the result to `(array)` for back-compat.
See #35791.
git-svn-id: https://develop.svn.wordpress.org/trunk@37652 602fd350-edb4-49c9-b593-d223f7449a82
`get_sites()` is now used in:
* `domain_exists()`
* `wp_update_network_site_counts()`
* `get_blog_id_from_url()`
Props spacedmonkey, jeremyfelt.
See #35791.
git-svn-id: https://develop.svn.wordpress.org/trunk@37620 602fd350-edb4-49c9-b593-d223f7449a82
When a site is added, updated, or deleted, the `site_ids` cache for a query will no longer be reliable. Bumping `last_changed` will force a new query for site IDs.
See #35791.
git-svn-id: https://develop.svn.wordpress.org/trunk@37618 602fd350-edb4-49c9-b593-d223f7449a82
`get_sites()` should be considered a replacement for `wp_get_sites()`. Backward compatibility is maintained in the meantime by using `get_site()` to populate the return data with associative arrays rather than `WP_Site` objects.
Props spacedmonkey, flixos90.
See #35791.
git-svn-id: https://develop.svn.wordpress.org/trunk@37617 602fd350-edb4-49c9-b593-d223f7449a82
Applying these specially-crafted `@see` tags allows the Code Reference parser to recognize and link these elements as actions and filters.
See #36921.
git-svn-id: https://develop.svn.wordpress.org/trunk@37540 602fd350-edb4-49c9-b593-d223f7449a82
Also removes two error strings that were likely never being triggered anyway due to the stricter character matching higher up.
Props atomicjack, bjornjohansen, DrewAPicture.
Fixes#33336.
git-svn-id: https://develop.svn.wordpress.org/trunk@35142 602fd350-edb4-49c9-b593-d223f7449a82
This better aligns with expectations and matches the structure used by `_blog_option()`. The `_site_option()` functions remain as an appropriate method for working with the current network.
See #28290.
git-svn-id: https://develop.svn.wordpress.org/trunk@35024 602fd350-edb4-49c9-b593-d223f7449a82
Previously, an value matching `empty()` would have been bypassed in favor of the default setting for 100MB.
Related #19538, r19639, r19652, where we saw the bug, fixed the bug, and then unfixed the bug so that it was not a surprise in a point release.
See #34037.
git-svn-id: https://develop.svn.wordpress.org/trunk@35016 602fd350-edb4-49c9-b593-d223f7449a82
The `_network_option()` parameter order will be changing to accept `$network_id` first. The `_site_option()` functions will remain in use throughout core as our way of retrieving a network option for the current network.
See #28290.
git-svn-id: https://develop.svn.wordpress.org/trunk@34912 602fd350-edb4-49c9-b593-d223f7449a82
The function encapsulates the existing `subdirectory_reserved_names` filter and reduces the maintenance burden of keeping the value of (currently) two instances of the same hook in sync.
See #33615.
git-svn-id: https://develop.svn.wordpress.org/trunk@34854 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
Replaces all uses of `*_site_option()` with the corresponding "network" function.
This excludes one usage in `wp-admin/admin-footer.php` that needs more investigation.
Props spacedmonkey.
See #28290.
git-svn-id: https://develop.svn.wordpress.org/trunk@34778 602fd350-edb4-49c9-b593-d223f7449a82
