Prior to this change, `date_i18n()` only supported the `timezone_string` option, causing incorrect timezones to appear in formatted dates on sites that still rely on the `gmt_offset` option.
Props Rarst.
Fixes#34835.
git-svn-id: https://develop.svn.wordpress.org/trunk@43387 602fd350-edb4-49c9-b593-d223f7449a82
This utility function allows for easy detection whether terms for a taxonomy are considered publicly viewable.
Props andizer.
Fixes#44466.
git-svn-id: https://develop.svn.wordpress.org/trunk@43386 602fd350-edb4-49c9-b593-d223f7449a82
Erasing timezone with a regular expression is redundant, the date could be just formatted in the respective format instead.
Props Rarst.
Fixes#42542.
git-svn-id: https://develop.svn.wordpress.org/trunk@43384 602fd350-edb4-49c9-b593-d223f7449a82
Despite historical function name, the output does not conform to RFC3339 format, which must contain timezone.
Props Rarst.
See #42542.
git-svn-id: https://develop.svn.wordpress.org/trunk@43383 602fd350-edb4-49c9-b593-d223f7449a82
This brings the name in line with user-facing language and similar names of existing related capabilities. Since the capability has not been part of any WordPress release, it can be renamed without any backward-compatibility implications.
Also missing props benhuberman for [43006].
Fixes#44457.
git-svn-id: https://develop.svn.wordpress.org/trunk@43381 602fd350-edb4-49c9-b593-d223f7449a82
Despite previously being labeled as a Unix timestamp, in reality it's a sum of Unix timestamp and timezone offset in seconds.
Props Rarst.
See #38771.
git-svn-id: https://develop.svn.wordpress.org/trunk@43380 602fd350-edb4-49c9-b593-d223f7449a82
Introduce an `object_subtype` argument to the args array for `register_meta()` which can be used to limit meta registration to a single subtype (e.g. a custom post type or taxonomy, vs all posts or taxonomies).
Introduce `register_post_meta()` and `register_term_meta()` wrapper methods for `register_meta` to provide a convenient interface for the common case of registering meta for a specific taxonomy or post type. These methods work the way plugin developers have often expected `register_meta` to function, and should be used in place of direct `register_meta` where possible.
Props flixos90, tharsheblows, spacedmonkey.
Fixes#38323.
git-svn-id: https://develop.svn.wordpress.org/trunk@43378 602fd350-edb4-49c9-b593-d223f7449a82
This can be used in phpunit.xml:
{{{
<php>
<const name="WP_TESTS_CONFIG_FILE_PATH" value="/path/to/wp-tests-config.php" />
</php>
}}}
Props clarinetlord
Fixes#39734
git-svn-id: https://develop.svn.wordpress.org/trunk@43369 602fd350-edb4-49c9-b593-d223f7449a82
Add a `_doing_it_wrong()` message describing the correct usage of the function.
Props kraftbj, azaozz, SergeyBiryukov, YuriV.
Fixes#44142.
git-svn-id: https://develop.svn.wordpress.org/trunk@43361 602fd350-edb4-49c9-b593-d223f7449a82
The line was copied from the emails that get sent when an email address changes, without considering if it made sense in the new context.
Props iandunn, ianbelanger, desrosj.
Fixes#44030.
git-svn-id: https://develop.svn.wordpress.org/trunk@43353 602fd350-edb4-49c9-b593-d223f7449a82
`.gitignore` + `svn:ignore`:
* Add the typical filenames of overloaded PHPCS configs to `.gitignore`.
Composer:
* Use the `develop` (Packagist `dev-master`) version of WPCS as it contains lots of bugfixes.
* Remove the PHPCS dependency. This is a dependency of WPCS, not of WP Core itself. This will also make sure that the PHPCS version used is always one which is supported by WPCS.
* Refreshed the `composer.lock` file.
PHPCS ruleset:
* Removed a reference to a sniff which doesn't exist in WPCS yet.
* Use the PHPCS 3.x `basepath` option to clean up the file paths PHPCS shows in the reports.
* Use the PHPCS 3.x `parallel` option to enable parallel scanning whenever possible to speed up the scans.
* Whitelist the `wp-includes/l10n.php` file from issues being reported by the `WordPress.WP.I18n` sniff.
Fixes#44366.
git-svn-id: https://develop.svn.wordpress.org/trunk@43348 602fd350-edb4-49c9-b593-d223f7449a82
These annotations make it clear to the reader of a JavaScript source
where the build process outputs to. These annotations can later be
integrated in a webpack configuration. This way there is one source of
truth.
The `build` folder is omitted from the paths, because a single JS file
shouldn't not be responsible of knowing where outputs in general will
end up at. A file only knows its output location relative to the
project.
Props adamsilverstein, herregroen, omarreiss, pento.
Fixes#44361.
git-svn-id: https://develop.svn.wordpress.org/trunk@43347 602fd350-edb4-49c9-b593-d223f7449a82
Use `grunt watch --phpunit --group={testgroup}` to start `grunt watch` with a specific test group so that PHP file changes trigger a limited number of tests.
Props jeremyfelt, birgire for testing.
Fixes#44240.
git-svn-id: https://develop.svn.wordpress.org/trunk@43335 602fd350-edb4-49c9-b593-d223f7449a82
Historically, `grunt build` has copied all files from the `src` directory to the `build` directory. This is usually fine, but can be super slow when there are lots of custom plugins or themes in the `src` directory.
To rectify this, we now only copy Core plugins and themes to `build`.
Props adamsilverstein, pento, johnbillion.
Fixes#44256.
git-svn-id: https://develop.svn.wordpress.org/trunk@43329 602fd350-edb4-49c9-b593-d223f7449a82
