A static variable contains an integer that is incremented with each call. This number is returned with the optional prefix.
As such the returned value is not universally unique, but it is unique across the life of the PHP process.
Props westonruter, dlh.
See #44883.
git-svn-id: https://develop.svn.wordpress.org/trunk@43658 602fd350-edb4-49c9-b593-d223f7449a82
* Add a `human_readable_duration` function including tests.
* Add 'pixels' after image width/height.
* Add screen reader text for durations.
Props Presskopp, kiranpotphode, milindmore22, stormrockwell, afercia.
Fixes#39667.
git-svn-id: https://develop.svn.wordpress.org/trunk@43633 602fd350-edb4-49c9-b593-d223f7449a82
Previously, UTC context was implied, but could be unreliable due to being affected by plugins.
Props Rarst, rahulsprajapati, marco.marsala.
Fixes#37440.
git-svn-id: https://develop.svn.wordpress.org/trunk@43594 602fd350-edb4-49c9-b593-d223f7449a82
`$function`, `$message`, and `$version` have historically been passed to the `doing_it_wrong_run` action. It makes sense to pass those to the filter as well, so that one can conditionally determine the filter value to return.
Fixes#34183.
git-svn-id: https://develop.svn.wordpress.org/trunk@43587 602fd350-edb4-49c9-b593-d223f7449a82
WPCS 1.0.0 includes a bunch of new auto-fixers, which drops the number of coding standards issues across WordPress significantly. Prior to running the auto-fixers, there were 15,312 issues detected. With this commit, we now drop to 4,769 issues.
This change includes three notable additions:
- Multiline function calls must now put each parameter on a new line.
- Auto-formatting files is now part of the `grunt precommit` script.
- Auto-fixable coding standards issues will now cause Travis failures.
Fixes#44600.
git-svn-id: https://develop.svn.wordpress.org/trunk@43571 602fd350-edb4-49c9-b593-d223f7449a82
Some versions of PHP appear to have a memory leak that is occasionally triggered by calling `stream_get_wrappers()`. In order to avoid calling this, we can return early from `wp_is_stream()` when `$path` doesn't contain `://`.
Props pbiron, JPry, dontstealmyfish.
Fixes#44532.
git-svn-id: https://develop.svn.wordpress.org/trunk@43466 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@43389 602fd350-edb4-49c9-b593-d223f7449a82
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
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
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
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@43284 602fd350-edb4-49c9-b593-d223f7449a82
Previously, when a plugin updated its suggested privacy policy text, an admin notice was shown on all screens in the Administration Panels. That was done in order to make sure that administrators were aware of it, so that they could update their policy if needed. That was a very heavy-handed and intrusive approach, though, which leads to a poor user experience, and notice fatigue.
An alternative approach is to use bubble notifications in the menu, similar to when plugins have updates that need to be installed. That still makes it obvious that something needs the administrator's attention, but is not as distracting as a notice.
The notice will still appear on the Privacy page, though, since it is relevant to that screen, and provides an explanation of why the bubble is appearing.
Props azaozz, xkon, iandunn.
Fixes#43954. See #43953.
git-svn-id: https://develop.svn.wordpress.org/trunk@43223 602fd350-edb4-49c9-b593-d223f7449a82
r43046 introduced `wp_schedule_delete_old_privacy_export_files()` to schedule the `wp_privacy_delete_old_export_files` cron job, but it did not check to make sure it wasn't running in the context of the install process. When it did run in that context, it created a database error, because the necessary database tables don't exist at that point.
Checking the current context and returning early during the installation phase avoids that issue.
Props helen, timothyblynjacobs, iandunn.
Fixes#43952.
git-svn-id: https://develop.svn.wordpress.org/trunk@43162 602fd350-edb4-49c9-b593-d223f7449a82
`list_files()` is defined in `wp-admin/includes/file.php`, which is not included by `wp-cron.php`, so it needs to be included by the caller in order to avoid a fatal PHP error.
This bug was not detected during testing because the file _is_ included when executing jobs via `wp cron event run`.
Props mikejolley, iandunn.
See #43546.
See https://wordpress.slack.com/archives/C9695RJBW/p1525190405000860.
git-svn-id: https://develop.svn.wordpress.org/trunk@43059 602fd350-edb4-49c9-b593-d223f7449a82
The primary means of protecting the files is the CSPRN appended to the filename, but there is no reason to keep the files after the data subject has downloaded them, so deleting them provides an additional layer of protection. Previously this was done from `wp_privacy_generate_personal_data_export_file()`, but that does not guarantee that it will be run regularly, and on smaller sites that could result in export files being exposed for much longer than necessary.
`wp_privacy_delete_old_export_files()` was moved to a front end file, so that it can be called from `cron.php`.
This introduces the `wp_privacy_export_expiration` filter, which allows plugins to customize how long the exports are kept before being deleted.
`index.html` was added to the `$exclusions` parameter of `list_files()` to make sure that it isn't deleted. If it were, then poorly-configured servers would allow the directory to be traversed, exposing all of the exported files.
Props iandunn, desrosj.
See #43546.
git-svn-id: https://develop.svn.wordpress.org/trunk@43046 602fd350-edb4-49c9-b593-d223f7449a82
A new global multisite table `wp_blogmeta` is added to the database schema, and a set of `*_site_meta()` API functions are introduced.
The implementation fails gracefully when the new table is not yet available, which may happen especially shortly after the core update, before the network has been upgraded to the new database schema. The presence of the table is detected once and stored as a global setting on the main network.
Core does not yet use site metadata, but there are several use-cases to be implemented or explored in the near future, and it allows plugins to extend sites with arbitrary data, which will come in particularly handy with the upcoming REST API endpoint for sites.
Props spacedmonkey, johnjamesjacoby, jeremyfelt, flixos90.
Fixes#37923.
git-svn-id: https://develop.svn.wordpress.org/trunk@42836 602fd350-edb4-49c9-b593-d223f7449a82
While intended as a playful error message, `Cheatin’ uh?` can be interpreted as insulting or accusatory in an already stressful situation. This replaces Cheatin’ with more meaningful error messages, depending on the error that occurs.
Props ElectricFeet, EricMeyer, karmatosed, dd32, BandonRandon, melchoyce for language; dmsnell for original patch; peterwilsoncc.
Fixes#38332.
git-svn-id: https://develop.svn.wordpress.org/trunk@42648 602fd350-edb4-49c9-b593-d223f7449a82
WordPress' code just... wasn't.
This is now dealt with.
Props jrf, pento, netweb, GaryJ, jdgrimes, westonruter, Greg Sherwood from PHPCS, and everyone who's ever contributed to WPCS and PHPCS.
Fixes#41057.
git-svn-id: https://develop.svn.wordpress.org/trunk@42343 602fd350-edb4-49c9-b593-d223f7449a82
The WPCS `WordPress.WhiteSpace.PrecisionAlignment` rule throws warnings for a bunch of code that will likely cause issues for `wpcbf`. Fixing these manually beforehand gives us better auto-fixed results later.
See #41057.
git-svn-id: https://develop.svn.wordpress.org/trunk@42228 602fd350-edb4-49c9-b593-d223f7449a82
This pattern occurs a handful of times across the codebase:
`<div class="foo<?php if ( $bar ) { echo ' baz'; } ?>">`
Unfortunately, it doesn't really play nicely with `phpcbf`, so all instances need to be removed in preperation for auto code formatting.
See #41057.
git-svn-id: https://develop.svn.wordpress.org/trunk@42217 602fd350-edb4-49c9-b593-d223f7449a82
