"Be more discrete." declared matt in [3155], and since then, "Silence is Golden" has been the calling card of placeholder index files. Historically, these have been php files, but [43012] changed that and added index.html files for privacy export generated folders.
The php silence files produce no visible content. This adds consistency with these new html files in that there will be no visible content. Silence will fall when the question is asked.
Fixes#44195.
Props audrasjb, rafsuntaskin, Ov3rfly, johnbillion, pento
Built from https://develop.svn.wordpress.org/trunk@43446
git-svn-id: http://core.svn.wordpress.org/trunk@43273 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
Whenever an admin initiates a download or email of a personal data export, a fresh copy of the file is generated. Previously, a new filename was used each time, which could lead to situations where a URL that was emailed to a data subject is broken.
That can be avoided by reusing the same filename when building fresh archives.
Props desrosj, tz-media, allendav.
Fixes#43905.
Built from https://develop.svn.wordpress.org/trunk@43180
git-svn-id: http://core.svn.wordpress.org/trunk@43009 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The personal data export and erasure tools allow plugins to register their own callbacks, in order to add additional data to the export and erasure processes. Previously, these were registered without specifying a constant identifier in the array of callbacks. Using mutable integers makes it difficult for plugins to modify the callbacks of other plugins, though.
Using associative array keys instead provides a covenient and reliable way to identify and interact with another plugin's callbacks.
Props desrosj, allendav, ocean90.
Fixes#43931.
Built from https://develop.svn.wordpress.org/trunk@43154
git-svn-id: http://core.svn.wordpress.org/trunk@42983 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This runs immediately after the data export file has been successfully created, allowing plugins to introduce some workflow customizations. For example, a plugin could password-protect the export file, for peace of mind, even though the CSPRN in the filename makes brute force attacks nearly impossible.
See #43546.
Built from https://develop.svn.wordpress.org/trunk@43047
git-svn-id: http://core.svn.wordpress.org/trunk@42876 1a063a9b-81f0-0310-95a4-ce76da25c4cd
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.
Built from https://develop.svn.wordpress.org/trunk@43046
git-svn-id: http://core.svn.wordpress.org/trunk@42875 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`rand()` is deterministic and therefore offers much less protection in this context. `wp_generate_password()` is a convenient wrapper around `wp_rand()`, which uses `random_int()` to generate cryptographically-secure psuedorandom numbers.
See #43546.
Built from https://develop.svn.wordpress.org/trunk@43045
git-svn-id: http://core.svn.wordpress.org/trunk@42874 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The error response body size is limited to 1 KB by default to avoid taking up too much memory. The size can be increased using `download_url_error_max_body_size` filter.
Props soulseekah, campusboy1987, mihdan, SergeyBiryukov.
Fixes#43329.
Built from https://develop.svn.wordpress.org/trunk@42773
git-svn-id: http://core.svn.wordpress.org/trunk@42603 1a063a9b-81f0-0310-95a4-ce76da25c4cd
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.
Built from https://develop.svn.wordpress.org/trunk@42648
git-svn-id: http://core.svn.wordpress.org/trunk@42477 1a063a9b-81f0-0310-95a4-ce76da25c4cd
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.
Built from https://develop.svn.wordpress.org/trunk@42217
git-svn-id: http://core.svn.wordpress.org/trunk@42046 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Prevent edits to 2-level deep theme files from returning a `disallowed_theme_file` error when attempting to save an edit. Aligns logic for gathering `$allowed_files` in `theme-editor.php` for listing files with the validation logic in `wp_edit_theme_plugin_file()`.
Amends [41806].
See #6531.
Fixes#42425.
Built from https://develop.svn.wordpress.org/trunk@42112
git-svn-id: http://core.svn.wordpress.org/trunk@41941 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This now treats files containing `./` as valid, and also treats files containing a trailing `../` as valid due to widespread use of this pattern in theme and plugin zip files.
Adds tests.
Props Ipstenu, borgesbruno, DavidAnderson, philipjohn, birgire
Fixes#42016, #36170
Built from https://develop.svn.wordpress.org/trunk@42011
git-svn-id: http://core.svn.wordpress.org/trunk@41845 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The theme and plugin editors now list all files in the selected theme or plugin, recursing through subdirectories as necessary.
Props WraithKenny, schlessera, chsxf, MikeHansenMe, Daedalon, valendesigns, westonruter, pento.
Fixes#6531.
Built from https://develop.svn.wordpress.org/trunk@41806
git-svn-id: http://core.svn.wordpress.org/trunk@41640 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Increase PHP execution time limit prior to issuing loopback requests where are themselves given timeouts to ensure PHP file can be reverted.
* Output scrape messages on success and failure so that absence of either can also be flagged as an error condition.
* Forward browser's HTTP Basic Auth credentials in loopback requests to admin and home URL.
* Display more helpful message when loopback request fails.
Amends [41721].
See #21622.
Fixes#42102.
Built from https://develop.svn.wordpress.org/trunk@41805
git-svn-id: http://core.svn.wordpress.org/trunk@41639 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Edits to active plugins which cause PHP fatal errors will no longer auto-deactivate the plugin. Supersedes #39766.
* Introduce sandboxed PHP file edits for active themes, preventing accidental whitescreening of a user's site when introducing a fatal error.
* After writing a change to a PHP file for an active theme or plugin, perform loopback requests on the file editor admin screens and the homepage to check for fatal errors. If a fatal error is encountered, roll back the edited file and display the error to the user to fix and try again.
* Introduce a secure way to scrape PHP fatal errors from a site via `wp_start_scraping_edited_file_errors()` and `wp_finalize_scraping_edited_file_errors()`.
* Moves file modifications from `theme-editor.php` and `plugin-editor.php` to common `wp_edit_theme_plugin_file()` function.
* Refactor themes and plugin editors to submit file changes via Ajax instead of doing full page refreshes when JS is available.
* Use `get` method for theme/plugin dropdowns.
* Improve styling of plugin editors, including width of plugin/theme dropdowns.
* Improve notices API for theme/plugin editor JS component.
* Strip common base directory from plugin file list. See #24048.
* Factor out functions to list editable file types in `wp_get_theme_file_editable_extensions()` and `wp_get_plugin_file_editable_extensions()`.
* Scroll to line in editor that has linting error when attempting to save. See #41886.
* Add checkbox to dismiss lint errors to proceed with saving. See #41887.
* Only style the Update File button as disabled instead of actually disabling it for accessibility reasons.
* Ensure that value from CodeMirror is used instead of `textarea` when CodeMirror is present.
* Add "Are you sure?" check when leaving editor when there are unsaved changes.
Supersedes [41560].
See #39766, #24048, #41886.
Props westonruter, Clorith, melchoyce, johnbillion, jjj, jdgrimes, azaozz.
Fixes#21622, #41887.
Built from https://develop.svn.wordpress.org/trunk@41721
git-svn-id: http://core.svn.wordpress.org/trunk@41555 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Passing a non-null value to the filter will prevent the uploaded file from being moved to the uploads directory for any of the functions leveraging `_wp_handle_upload()`, such as `wp_handle_upload()` or `wp_handle_sideload()`.
Error reporting related to the file being moved will also be skipped.
Props ryan, Mte90.
Fixes#24603.
Built from https://develop.svn.wordpress.org/trunk@41258
git-svn-id: http://core.svn.wordpress.org/trunk@41098 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Introduces some consistency in the usage of the button CSS classes, fixes the
focus style for accessibility and responsiveness of the buttons.
- Adds the `button` class to all primary buttons make them responsive
- Removes all `secondary-button` classes and replaces it with button when needed. `button-secondary` shouldn't be used and exists just for backward compatibility reasons
- Replaces classes inside `submit_button()` with a shorthand for some buttons, and use an empty string for the default `button` class. Passing `button` is unnecessary
- Adjusts `get_submit_button()` to remove empty items
Props iseulde, dimchik, chris_d2d, mhowell, afercia.
Fixes#27314, #37138, #37448.
Built from https://develop.svn.wordpress.org/trunk@38672
git-svn-id: http://core.svn.wordpress.org/trunk@38615 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
The default error handler `wp_handle_upload_error()` expects a reference for the first parameter but `call_user_func()` doesn't pass parameters by reference. The current code didn't produce any issues until now. PHP 7.0.9 (and PHP 7.1) is now stricter and prevents calling the error handler with a warning:
> PHP Warning: Parameter 1 to wp_handle_upload_error() expected to be a reference, value given.
To restore the error handler `_wp_handle_upload()` now uses `call_user_func_array()`.
Props jbrinley.
Props jorbin for review.
Fixes#37570.
Built from https://develop.svn.wordpress.org/trunk@38235
git-svn-id: http://core.svn.wordpress.org/trunk@38176 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Under certain conditions upgrades on Windows may fail because `wp_tempnam()` gets called in a loop.
This can happen when `wp_tempnam()` is called with `\.maintenance` for the `$filename` parameter. The function strips the extension, in this case `.maintenance`, which results in an empty filename. Because it's empty, `wp_tempnam()` calls itself with `dirname( '\.maintenance' )`. On *nix systems this would be `"/"` which allows `wp_tempnam()` to fall back on `time()`. But on Windows it's `"\"`.
This change adds the backslash to the list of characters which allow `wp_tempnam()` to fall back on `time()`.
See [32322], [31936].
Fixes#33999.
Built from https://develop.svn.wordpress.org/trunk@38151
git-svn-id: http://core.svn.wordpress.org/trunk@38092 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`$context` is a full path to the directory that is tested for being writable. A path shouldn't be a boolean value.
This also updates `WP_Upgrader_Skin::request_filesystem_credentials()` and `Automatic_Upgrader_Skin::request_filesystem_credentials()` and adds missing docs.
Props DrewAPicture, ocean90.
Fixes#37412.
Built from https://develop.svn.wordpress.org/trunk@38138
git-svn-id: http://core.svn.wordpress.org/trunk@38079 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Don't lower memory limit if the current limit is greater than `WP_MAX_MEMORY_LIMIT`.
* Set `WP_MEMORY_LIMIT` and `WP_MAX_MEMORY_LIMIT` to current limit if the `memory_limit` setting can't be changed at runtime.
* Use `wp_convert_hr_to_bytes()` when parsing the value of the `memory_limit` setting because it can be a shorthand or an integer value.
* Introduce `wp_raise_memory_limit( $context )` to raise the PHP memory limit for memory intensive processes. This DRYs up some logic and includes the existing `admin_memory_limit` and `image_memory_limit` filters. The function can also be used for custom contexts, the `{$context}_memory_limit` filter allows to customize the limit.
* Introduce `wp_is_ini_value_changeable( $setting )` to determine whether a PHP ini value is changeable at runtime.
* Remove a `function_exists( 'memory_get_usage' )` check. Since PHP 5.2.1 support for memory limit is always enabled.
Related commits: [38011-38013]
Props jrf, A5hleyRich, swissspidy, ocean90.
Fixes#32075.
Built from https://develop.svn.wordpress.org/trunk@38015
git-svn-id: http://core.svn.wordpress.org/trunk@37956 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Twelve years later, after no fewer than three themes have intentionally implemented popup comments in their functionality, before being abandoned for at least the last six years, we've reached a time where we can put this era behind us. A time when we can remove comment popup functionality from WordPress.
If this breaks the internet, I'll eat my hat.
Fixes#28617
Built from https://develop.svn.wordpress.org/trunk@35848
git-svn-id: http://core.svn.wordpress.org/trunk@35812 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Keeping myhacks support is a small price to pay for not breaking people's sites. Even if it is very very very few sites, breaking sites isn't something that should be encouraged. Even with 10 years of deprecation notices.
https://core.trac.wordpress.org/ticket/33741#comment:18 outlines all the ways that the hack_file and my-hacks options can be setup and thus all the ways that the removal of those options could break sites.
Fixes#33741.
Built from https://develop.svn.wordpress.org/trunk@35688
git-svn-id: http://core.svn.wordpress.org/trunk@35652 1a063a9b-81f0-0310-95a4-ce76da25c4cd
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.
Built from https://develop.svn.wordpress.org/trunk@34828
git-svn-id: http://core.svn.wordpress.org/trunk@34793 1a063a9b-81f0-0310-95a4-ce76da25c4cd
For the last 10 years, my-hacks has been deprecated and has been throwing a deprecation notice. For the last six years, you haven't been able to enable my-hacks.php in the admin UI. That should be enough time to give developers notice. Plugins and themes seem like they might have staying power.
Fixes#33741
Props bobbingwide
Built from https://develop.svn.wordpress.org/trunk@34291
git-svn-id: http://core.svn.wordpress.org/trunk@34255 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Numerous changes to make the FTP modal experience a good one. These include:
* Update HTML used by both the form here and the form on the standalone screen
* Allow users to cancel FTP install
* Focus locking in the modal
* Focus on modal form on load
* ARIA Attributes
* Style Enhancements
* Add low screen height (such as phone and some tablets) friendly experience for entering credentials
Props ericlewis, afercia
Fixes#31608
Built from https://develop.svn.wordpress.org/trunk@31949
git-svn-id: http://core.svn.wordpress.org/trunk@31928 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This is a restoration of [31749] which was reverted in [31755].
It includes a number of enhancements from the original version. Namely:
* Not doing a credential check in src/wp-includes/script-loader.php
* Add new function `wp_print_request_filesystem_credentials_modal`
* update the version number in the list table when a plugin is updated
UI still needs further work, but this basic version should enable more testing
Props ericlewis, jorbin
See #31528
Built from https://develop.svn.wordpress.org/trunk@31811
git-svn-id: http://core.svn.wordpress.org/trunk@31793 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Affects DocBlocks for the following core elements:
* Remove HTML tag from parameter description in `comment_form()`
* Remove HTML tag from a summary for the `comment_form_top` hook
* Markdown-indent a code snippet in the description for `get_linkobjectsbyname()`
* Markdown-indent a code snippet and format an unordered list in the description for `get_linkobjects()`
* Backtick-escape some inline code in the description for `clean_pre()`
* Remove HTML tag from the summary for the `rss_tag_pre` hook
* Various formatting fixes in the descriptions for `get_filesystem_method()` and `request_filesystem_credentials()`
Props rarst for the initial patch.
See #30473.
Built from https://develop.svn.wordpress.org/trunk@30538
git-svn-id: http://core.svn.wordpress.org/trunk@30527 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This is only enabled when new files will not be installed during the update (as indicated by the WordPress.org API), and does not apply to Plugin/Theme/Translation Background Updates.
Additionally, the code to determine if the 'direct' filesystem transport should be used has been tweaked for wider support (where getmyuid() was unavailalbe) which fixes#10424
See #10205, #30245
Built from https://develop.svn.wordpress.org/trunk@30384
git-svn-id: http://core.svn.wordpress.org/trunk@30381 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Per our inline documentation standards, no further use of the `@uses` tag is recommended as used and used-by relationships can be derived through other means. This removes most uses of the tag in core documentation, with remaining tags to be converted to `@global` or `@see` as they apply.
Fixes#30191.
Built from https://develop.svn.wordpress.org/trunk@30105
git-svn-id: http://core.svn.wordpress.org/trunk@30105 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* In `wp_handle_upload()` and `wp_handle_sideload()`, `$ext` gets conditionally reset... and then is never used.
* In `request_filesystem_credentials()`, `$password` is initialized as an empty string. The variable is never used.
See #27882.
Built from https://develop.svn.wordpress.org/trunk@28268
git-svn-id: http://core.svn.wordpress.org/trunk@28096 1a063a9b-81f0-0310-95a4-ce76da25c4cd
- Add a "Update Translations" stand-alone button to the updates page
- Shift Language feedback to before update process completion action links & limit the verbosity of output (name + success/errors)
- Simplify/combine the language update descriptive string to only include a plugin/theme name
- Properly handle cache clearing after language updates to prevent langs being repeditively updated
- Display a "All items up to date" string when there's nothing to do
- Reduce the 'Connection Information' from a <h2> to a <h3> to remove duplicate h2's and screen icons from update screens
- Fix the Direct filesystem method not being used for Language updates because WP_LANG_DIR doesn't exist (check it's parent for writable instead)
See #18200, #22704
Built from https://develop.svn.wordpress.org/trunk@25806
git-svn-id: http://core.svn.wordpress.org/trunk@25718 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The exceptions to this are update_post_meta() and add_post_meta() which are often used by plugins in POST handlers and will continue accepting slashed data for now.
Introduce wp_upate_post_meta() and wp_add_post_meta() as unslashed alternatives to update_post_meta() and add_post_meta(). These functions could become methods in WP_Post so don't use them too heavily yet.
Remove all escape() calls from wp_xmlrpc_server. Now that core expects unslashed data this is no longer needed.
Remove addslashes(), addslashes_gpc(), add_magic_quotes() calls on data being prepared for handoff to core functions that until now expected slashed data. Adding slashes in no longer necessary.
Introduce wp_unslash() and use to it remove slashes from GPCS data before using it in core API. Almost every instance of stripslashes() in core should now be wp_unslash(). In the future (a release or three) when GPCS is no longer slashed, wp_unslash() will stop stripping slashes and simply return what is passed. At this point wp_unslash() calls can be removed from core.
Introduce wp_slash() for slashing GPCS data. This will also turn into a noop once GPCS is no longer slashed. wp_slash() should almost never be used. It is mainly of use in unit tests.
Plugins should use wp_unslash() on data being passed to core API.
Plugins should no longer slash data being passed to core. So when you get_post() and then wp_insert_post() the post data from get_post() no longer needs addslashes(). Most plugins were not bothering with this. They will magically start doing the right thing. Unfortunately, those few souls who did it properly will now have to avoid calling addslashes() for 3.6 and newer.
Use wp_kses_post() and wp_kses_data(), which expect unslashed data, instead of wp_filter_post_kses() and wp_filter_kses(), which expect slashed data. Filters are no longer passed slashed data.
Remove many no longer necessary calls to $wpdb->escape() and esc_sql().
In wp_get_referer() and wp_get_original_referer(), return unslashed data.
Remove old stripslashes() calls from WP_Widget::update() handlers. These haven't been necessary since WP_Widget.
Switch several queries over to prepare().
Expect something to break.
Props alexkingorg
see #21767
git-svn-id: http://core.svn.wordpress.org/trunk@23416 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This code stops wp_handle_upload() from reporting errors when the upload couldn't be moved to its final local and it was a non-JS fallback that is unused.
git-svn-id: http://svn.automattic.com/wordpress/trunk@20019 1a063a9b-81f0-0310-95a4-ce76da25c4cd
