The docs for `date_i18n()` and its filter now correctly state that the `$gmt` parameter is only taken into account if no timestamp is provided. Furthermore, a bug with that parameter is fixed, as it is now ensured that the timezone used with it is `UTC`.
Props Rarst.
Fixes#38771.
Built from https://develop.svn.wordpress.org/trunk@43389
git-svn-id: http://core.svn.wordpress.org/trunk@43217 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The functions `send_confirmation_on_profile_email()`, `_wp_privacy_send_request_confirmation_notification()`, `_wp_privacy_send_erasure_fulfillment_notification()`, and `wp_send_user_request()` all include a title and URL indicating the current site. However, so far they have dealt with those values inconsistently, sometimes using the site values, other times using the network values if in a multisite. This changeset ensures that only the current site is taken into account in all cases and that special characters in the site name are consistently decoded.
Props subrataemfluence, desrosj.
Fixes#44396.
Built from https://develop.svn.wordpress.org/trunk@43388
git-svn-id: http://core.svn.wordpress.org/trunk@43216 1a063a9b-81f0-0310-95a4-ce76da25c4cd
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.
Built from https://develop.svn.wordpress.org/trunk@43381
git-svn-id: http://core.svn.wordpress.org/trunk@43209 1a063a9b-81f0-0310-95a4-ce76da25c4cd
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.
Built from https://develop.svn.wordpress.org/trunk@43378
git-svn-id: http://core.svn.wordpress.org/trunk@43206 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`.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.
Built from https://develop.svn.wordpress.org/trunk@43348
git-svn-id: http://core.svn.wordpress.org/trunk@43176 1a063a9b-81f0-0310-95a4-ce76da25c4cd
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.
Built from https://develop.svn.wordpress.org/trunk@43347
git-svn-id: http://core.svn.wordpress.org/trunk@43175 1a063a9b-81f0-0310-95a4-ce76da25c4cd
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.
Built from https://develop.svn.wordpress.org/trunk@43329
git-svn-id: http://core.svn.wordpress.org/trunk@43157 1a063a9b-81f0-0310-95a4-ce76da25c4cd
When a term query using `fields=all_with_object_id` hits the cache, the
cached `stdClass` objects must be converted to `WP_Term` objects. This
was overlooked when `WP_Term_Query` was refactored to support object
queries in [38667].
Props dlh.
Fixes#44221.
Built from https://develop.svn.wordpress.org/trunk@43313
git-svn-id: http://core.svn.wordpress.org/trunk@43142 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Update the test infrastructure so that third party plugins, themes, and projects that use the core testing framework continue to operate from the `src` directory and do not require a build step.
Props mboynes, danielbachhuber, schlessera
See #43055
Built from https://develop.svn.wordpress.org/trunk@43311
git-svn-id: http://core.svn.wordpress.org/trunk@43140 1a063a9b-81f0-0310-95a4-ce76da25c4cd
And delete some left over cruft, only then shall we prevail.
There are some things easily missed, when using Git, which does not persist—
Empty directories, though that didn't derail—
Our Travis-based tests, which now must prevail.
Quoth Travis CI, “Build did fail.”
See #43055.
Built from https://develop.svn.wordpress.org/trunk@43310
git-svn-id: http://core.svn.wordpress.org/trunk@43139 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In many a strange and curious file of forgotten lore—
While I pondered, blaming Nacin, my notifications suddenly awakened,
As of someone quietly DMing;—DMing me, I can’t ignore.
“’Tis some contributor,” I muttered, “DMing me an idea or four—
Only this and nothing more.”
Ah, distinctly I remember, at WordCamp US, last December;
A mad proposal nearly laid me—down out cold—upon the floor.
Curious, I listened closely;—to a plan I agreed with, mostly—
A way to make our JavaScript—JavaScript which was a chore—
Maintainable, extendable, for the future, is what I saw.
Guten-ready for evermore.
Open here I switch to Slack, when, with many a patch and hack,
In there stepped Omar, a JavaScript developer hardcore;
Pronouncing all the changes fit; ready now to be commit;
“There’s nothing else for us to do,” DMing me, “It’s done!” he swore—
“No longer random guessing at which file need next be explored—
Let’s move on, we’re all aboard.”
Moved all together, grouped and managed, in folders all is packaged,
The code had all been cleaned and tidied, important parts moved to the fore,
“Though this change be useful here,” I said, “it is too large, I fear,
We couldn’t manage such a patch, we’ve done nothing like this before—
Tell me where doth go this change, change to make our codebase soar!”
Quoth Omar, “In WordPress Core.”
Props omarreis for shepherding this significant change.
Props adamsilverstein, aduth, atimmer, dingo_bastard, frank-klein, gziolo, herregroen, jaswrks, jeremyfelt, jipmoors, jorbin, netweb, ocean90, pento, tjnowell, and youknowriad for testing, feedback, discussion, encouragement, commiserations, etc.
I make no apologies for this commit message.
Fixes#43055.
Built from https://develop.svn.wordpress.org/trunk@43309
git-svn-id: http://core.svn.wordpress.org/trunk@43138 1a063a9b-81f0-0310-95a4-ce76da25c4cd
There doesn't appear to be any way for an attacker to introduce malicious input into the URL, unless a plugin is filtering the URL to add it, but it's better to be safe than sorry.
Props 1naveengiri, joyously.
Fixes#44115.
Built from https://develop.svn.wordpress.org/trunk@43290
git-svn-id: http://core.svn.wordpress.org/trunk@43119 1a063a9b-81f0-0310-95a4-ce76da25c4cd
A user is required to have the `manage_privacy_options` capability in order to determine which page is set as the privacy policy (the `wp_page_for_privacy_policy`). Given that, it doesn't make sense to allow users without that capability to edit or delete the page.
A similar situation exists with the `page_for_posts` and `page_on_front` options, but Editors are allowed to edit those pages. The reason that this situation is different is because it is more likely that an administrator will want to restrict modifications to the privacy policy, than it is that they will want to allow modifications. Modifications to the policy often require specialized knowledge of local laws, and can have implications for compliance with those laws.
Props dlh, desrosj.
Fixes#44079.
Built from https://develop.svn.wordpress.org/trunk@43286
git-svn-id: http://core.svn.wordpress.org/trunk@43115 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously, personal data exports were stored in `wp-content/uploads/exports`, which is generic enough that it's likely there are existing folders with that name, either created by plugins or manually by administrators. If that folder were reused by Core, then `wp_privacy_delete_old_export_files()` would delete all of the existing files inside it, which is almost certainly not what the site owner wants or expects.
To avoid that, the folder is being renamed to include a specific reference to Core, and a more verbose description of its purpose. With those factored in, it's very unlikely that there will be any conflicts with existing folders.
The `wp_privacy_exports_dir()` and `wp_privacy_exports_url()` functions were introduced to provide a canonical source for the location, and the `wp_privacy_exports_dir` and `wp_privacy_exports_url` filters were introduced to allow plugins to customize it.
Props johnjamesjacoby, allendav.
Fixes#44091.
Built from https://develop.svn.wordpress.org/trunk@43284
git-svn-id: http://core.svn.wordpress.org/trunk@43113 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously, the link used absolute positioning, in order to stick it at the bottom of the page. That was done in order to create visual separation between it and the "action" links, like "Lost Your Password?"
The absolute positioning can cause conflicts in some situations, though. For example, if extra text or error notices are added above the form, then the login link would be positioned on top of other elements.
Switching to relative positioning with extra margins avoids those issues, while maintaining the visual separation between the "action" links and the privacy policy link.
Props imath, melchoyce, desrosj, xkon, iandunn.
Fixes#44046.
Built from https://develop.svn.wordpress.org/trunk@43274
git-svn-id: http://core.svn.wordpress.org/trunk@43103 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Felix Arntz
John Blackbourn
atimmer
Sergey Biryukov
Andrew Ozz
K. Adam White
Gary Pendergast
jrf
Weston Ruter
Jeremy Felt
Boone Gorges
laurelfulford
iandunn
Dominik Schilling