This avoids the performance overhead of the function call every time `dirname( __FILE__ )` was used instead of `__DIR__`.
This commit also includes:
* Removing unnecessary parentheses from `include`/`require` statements. These are language constructs, not function calls.
* Replacing `include` statements for several files with `require_once`, for consistency:
* `wp-admin/admin-header.php`
* `wp-admin/admin-footer.php`
* `wp-includes/version.php`
Props ayeshrajans, desrosj, valentinbora, jrf, joostdevalk, netweb.
Fixes#48082.
git-svn-id: https://develop.svn.wordpress.org/trunk@47198 602fd350-edb4-49c9-b593-d223f7449a82
* Add missing translator comments.
* Fix placement of some translator comments. Translator comments should be on the line directly above the line containing the translation function call for optimal compatibility with various `.pot` file generation tools. The CS auto-fixing, which changed some inconsistent function calls to multi-line function calls, is part of the reason why this was no longer the case for a select group of translator comments.
Includes minor code layout fixes.
Polyglots, rejoice! All WordPress core files now have translator comments for all strings with placeholders!
Props jrf, subrataemfluence, GaryJ, webdados, Dency, swissspidy, alvarogois, marcomartins, mihaiiceyro, vladwtz, niq1982, flipkeijzer, michielatyoast, chandrapatel, thrijith, joshuanoyce, FesoVik, tessak22, bhaktirajdev, cleancoded, dhavalkasvala, garrett-eclipse, bibliofille, socalchristina, priyankkpatel, 5hel2l2y, adamsilverstein, JeffPaul, pierlo, SergeyBiryukov.
Fixes#44360.
git-svn-id: https://develop.svn.wordpress.org/trunk@45926 602fd350-edb4-49c9-b593-d223f7449a82
Prior to this change, resuming or activating a plugin or theme that is still broken would result in a redirect loop if in recovery mode. If outside recovery mode, it would cause the error template to be displayed.
Furthermore this applies to breaking a plugin or theme when editing from the backend.
Props aandrewdixon, azaozz, dhanukanuwan, henrywright, ocean90, ohiosierra, PandelisZ, xkon.
Fixes#46045, #46751.
git-svn-id: https://develop.svn.wordpress.org/trunk@45114 602fd350-edb4-49c9-b593-d223f7449a82
Using the new fatal handler introduced in [44962], an email is sent to the admin when a fatal error occurs. This email includes a secret link to enter recovery mode. When clicked, the link will be validated and on success a cookie will be placed on the client, enabling recovery mode for that user. This functionality is executed early before plugins and themes are loaded, in order to be unaffected by potential fatal errors these might be causing.
When in recovery mode, broken plugins and themes will be paused for that client, so that they are able to access the admin backend despite of these errors. They are notified about the broken extensions and the errors caused, and can then decide whether they would like to temporarily deactivate the extension or fix the problem and resume the extension.
A link in the admin bar allows the client to exit recovery mode.
Props timothyblynjacobs, afragen, flixos90, nerrad, miss_jwo, schlessera, spacedmonkey, swissspidy.
Fixes#46130, #44458.
git-svn-id: https://develop.svn.wordpress.org/trunk@44973 602fd350-edb4-49c9-b593-d223f7449a82
Due to the high number of follow-up tickets and associated security concerns, it was decided to reschedule the fatal error recovery feature for WordPress 5.2, in order to address these issues properly. The feature will continue to be developed, with iterations being merged into trunk early in the 5.2 release cycle.
Fixes#46141. See #44458, #45932, #45940, #46038, #46047, #46068.
git-svn-id: https://develop.svn.wordpress.org/trunk@44717 602fd350-edb4-49c9-b593-d223f7449a82
This changeset introduces a `WP_Shutdown_Handler` class that detects fatal errors and which extension (plugin or theme) causes them. Such an error is then recorded, and an error message is displayed. Subsequently, in certain protected areas, for example the admin, the broken extension will be paused, ensuring that the website is still usable in the respective area. The major benefit is that this mechanism allows site owners to still log in to their website, to fix the problem by either disabling the extension or solving the bug and then resuming the extension.
Extensions are only paused in certain designated areas. The frontend for example stays unaffected, as it is impossible to know what pausing the extension would cause to be missing, so it might be preferrable to clearly see that the website is temporarily not accessible instead.
The fatal error recovery is especially important in scope of encouraging the switch to a maintained PHP version, as not necessarily every WordPress extension is compatible with all PHP versions. If problems occur now, non-technical site owners that do not have immediate access to the codebase are not locked out of their site and can at least temporarily solve the problem quickly.
Websites that have custom requirements in that regard can implement their own shutdown handler by adding a `shutdown-handler.php` drop-in that returns the handler instance to use, which must be based on a class that inherits `WP_Shutdown_Handler`. That handler will then be used in place of the default one.
Websites that would like to modify specifically the error template displayed in the frontend can add a `php-error.php` drop-in that works similarly to the existing `db-error.php` drop-in.
Props afragen, bradleyt, flixos90, ocean90, schlessera, SergeyBiryukov, spacedmonkey.
Fixes#44458.
git-svn-id: https://develop.svn.wordpress.org/trunk@44524 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
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
- sets the modal content to `role="document"` to make screen readers switch back to browse mode
- standardizes the Themes screen and Customizer modals interaction
- Themes screen modal: sets initial focus on the modal overlay instead of the primary button, avoiding to "skip" content for keyboard and screen reader users
Fixes#42055.
git-svn-id: https://develop.svn.wordpress.org/trunk@41658 602fd350-edb4-49c9-b593-d223f7449a82
Unify the theme-browsing and theme-customization experiences by introducing a comprehensive theme browser and installer directly accessible in the customizer. Replaces the customizer theme switcher with a full-screen panel for discovering/browsing and installing themes available on WordPress.org. Themes can now be installed and previewed directly in the customizer without entering the wp-admin context. Also includes an extensible framework for browsing and installing themes from other sources.
Also includes CSS auto-prefixing added via `grunt precommit:css`.
For details, see: https://make.wordpress.org/core/2016/10/03/feature-proposal-a-new-experience-for-discovering-installing-and-previewing-themes-in-the-customizer/
Previously [38813] but reverted in [39140].
Fixes#37661, #34843, #38666.
Props celloexpressions, folletto, westonruter, karmatosed, melchoyce, afercia.
git-svn-id: https://develop.svn.wordpress.org/trunk@41648 602fd350-edb4-49c9-b593-d223f7449a82
This also standardises the `User-Agent` used when communicating with WordPress.org, allowing for more consistent version detection.
Fixes#42004.
git-svn-id: https://develop.svn.wordpress.org/trunk@41605 602fd350-edb4-49c9-b593-d223f7449a82
This is a great goal for core, and is close, but it is not in shape to be shipped for 4.7 and there is not enough time left in the development cycle to alter and polish sufficiently. There are bugs, but more than that, there are more fundamental questions around the use of existing UI, general UX, and how findable themes are (not) on the .org side.
see #37661.
git-svn-id: https://develop.svn.wordpress.org/trunk@39140 602fd350-edb4-49c9-b593-d223f7449a82
WordPress has supported custom page templates for over 12 years, allowing developers to create various layouts for specific pages.
While this feature is very helpful, it has always been limited to the 'page' post type and not was not available to other post types.
By opening up the page template functionality to all post types, we continue to improve the template hierarchy's flexibility.
In addition to the `Template Name` file header, the post types supported by a template can be specified using `Template Post Type: post, foo, bar`.
When at least one template exists for a post type, the 'Post Attributes' meta box will be displayed in the back end, without the need to add post type support for `'page-attributes'`. 'Post Attributes' can be customized per post type using the `'attributes'` label when registering a post type.
Props johnbillion, Mte90, dipesh.kakadiya, swissspidy.
Fixes#18375.
git-svn-id: https://develop.svn.wordpress.org/trunk@38951 602fd350-edb4-49c9-b593-d223f7449a82
This updates the list view to match the existing behaviour in the single theme modal.
Props tristangemus for initial patch.
Fixes#37774.
git-svn-id: https://develop.svn.wordpress.org/trunk@38788 602fd350-edb4-49c9-b593-d223f7449a82
By enabling the user to select their preferred locale when editing the profile, we allow for greater personalization of the WordPress admin and therefore a better user experience.
The back end will be displayed in the user's individual locale while the locale used on the front end equals the one set for the whole site. If the user didn't specify a locale, the site's locale will be used as a fallback. The new `locale` property of the `WP_User` class can be used to retrieve the user's locale setting.
Props ocean90, ipm-frommen, swissspidy.
Fixes#29783.
git-svn-id: https://develop.svn.wordpress.org/trunk@38705 602fd350-edb4-49c9-b593-d223f7449a82
Previously `ob_end_clean()` was only called when the previous condition was successful which led to unexpected results when another output buffering was involved, like PHPUnit's.
Fixes#37488.
git-svn-id: https://develop.svn.wordpress.org/trunk@38167 602fd350-edb4-49c9-b593-d223f7449a82
