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
* `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
[38058] changed `wp_mail()` so that it used PHPMailer's `setFrom()`
method rather than setting the From and FromName headers directly. See
behavior of setting the `Sender` field. This causes `mail` to be
called with the `-f` flag, which causes outgoing email to fail on some
server environments.
Props Clorith, iandunn, DrewAPicture.
Fixes#37736.
Built from https://develop.svn.wordpress.org/trunk@38286
git-svn-id: http://core.svn.wordpress.org/trunk@38227 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously, `wp_mail()` implemented Reply-To as a generic header, using
PHPMailer's `addCustomHeader()`. As such, the email address portion of
the header was being incorrectly encoded when the name portion
contained UTF-8 characters. Switching to PHPMailer's more specific
`addReplyTo()` method fixes the issue.
For greater readability, the handling of all address-related headers
(To, CC, BCC, Reply-To) has been standardized.
Props szepe.viktor, iandunn, bpetty, stephenharris.
Fixes#21659.
Built from https://develop.svn.wordpress.org/trunk@38058
git-svn-id: http://core.svn.wordpress.org/trunk@37999 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This new helper function is used by the pluggable functions `wp_get_current_user()` and `get_currentuserinfo()`, which was previously being called by the former before [36311]. Without it, infinite loops could be caused when plugins implement these functions, as they are now called the other way around.
Fixes#19615.
Built from https://develop.svn.wordpress.org/trunk@36651
git-svn-id: http://core.svn.wordpress.org/trunk@36618 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Introduces `wp_authenticate_email_password()` which is hooked into `authenticate` after `wp_authenticate_username_password()`.
Props Denis-de-Bernardy, ericlewis, vhomenko, MikeHansenMe, swissspidy, ocean90.
Fixes#9568.
Built from https://develop.svn.wordpress.org/trunk@36617
git-svn-id: http://core.svn.wordpress.org/trunk@36584 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Brings some love to this neglected screen:
* format `comment_content`, instead of escaping in one massive block of text
* only wrap the comment date in a link if the comment permalink exists
* include link to the Edit Comment screen at the bottom of the comment_content
* update the message styles to match other screens
* append `#wpbody-content` to the comment email message links for accessibility
Props johnbillion, rachelbaker, afercia, melchoyce, karmatosed.
Fixes#34133
Built from https://develop.svn.wordpress.org/trunk@36588
git-svn-id: http://core.svn.wordpress.org/trunk@36555 1a063a9b-81f0-0310-95a4-ce76da25c4cd
It encourages an ugly pattern like `global $userdata; get_currentuserinfo();` in plugins/themes. `wp_get_current_user()` should be used instead, e.g. `$current_user = wp_get_current_user();`.
Props scribu for initial patch.
Fixes#19615.
Built from https://develop.svn.wordpress.org/trunk@36311
git-svn-id: http://core.svn.wordpress.org/trunk@36278 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Hello, it's me again. A pluggable function named `wp_new_user_notification()`. A few months ago, after [33023], I have lost my second parameter `$plaintext_pass`. But thanks to [33620] I got a new one.
Bad idea - It hasn't had the same behavior as my previous parameter.
To solve that the second parameter got deprecated and reintroduced as the third parameter in [34116]. I was happy again, for a short time.
You remember my lost friend `$plaintext_pass`? No? Well, if its value was empty no notification was sent to the user. This behavior was still lost. And that's what this change is about: Don't notify a user if a plugin uses `wp_new_user_notification( $user_id )`.
You're asking if I'm happy now? Dunno, but maybe you have learned something about pluggable functions, have you?
Props danielbachhuber.
Fixes#34377.
Built from https://develop.svn.wordpress.org/trunk@35735
git-svn-id: http://core.svn.wordpress.org/trunk@35699 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The `notify_moderator` filter makes it possible to override the value for the `moderation_notify` option, which controls whether to send new comment emails to "site moderators", that is to say, the owner of the admin email for the site and the post author if they have the ability to modify the comment.
The `notify_post_author` filter likewise makes it possible to override the value for the `comments_notify` option, which controls whether to send new comment emails to the post author. If the post author is the comment author, default behavior is not to send the notification. Note: enabling or disabling notifications via this hook could also affect other recipients added via the 'comment_notification_recipients' filter in `wp_notify_postauthor()`, if hooked.
Passing a falsey value to either of the new filters will prevent notifications from being sent, regardless of their corresponding option values.
Adds tests.
Props coffee2code, adamsilverstein, DrewAPicture.
Fixes#761.
Built from https://develop.svn.wordpress.org/trunk@35339
git-svn-id: http://core.svn.wordpress.org/trunk@35305 1a063a9b-81f0-0310-95a4-ce76da25c4cd
