Previously, `wp_favicon_request()` was introduced in [13205] to avoid a performance hit of serving a full 404 page on every favicon request.
While working as intended, that implementation did not provide a way for theme or plugin authors to manage the behavior of favicon requests.
This changeset implements the following logic (only applied if WordPress is installed in the root directory):
* If there is a Site Icon set in Customizer, redirect `/favicon.ico` requests to that icon.
* Otherwise, use the WordPress logo as a default icon.
* If a physical `/favicon.ico` file exists, do nothing, let the server handle the request.
Handling `/favicon.ico` is now more consistent with handling `/robots.txt` requests.
New functions and hooks:
* Introduce `is_favicon()` conditional tag to complement `is_robots()`.
* Introduce `do_favicon` action to complement `do_robots` and use it in template loader.
* Introduce `do_favicon()` function, hooked to the above action by default, to complement `do_robots()`.
* Introduce `do_faviconico` action to complement `do_robotstxt`, for plugins to override the default behavior.
* Mark `wp_favicon_request()` as deprecated in favor of `do_favicon()`.
Props jonoaldersonwp, birgire, joostdevalk, mukesh27, SergeyBiryukov.
Fixes#47398.
Built from https://develop.svn.wordpress.org/trunk@47018
git-svn-id: http://core.svn.wordpress.org/trunk@46818 1a063a9b-81f0-0310-95a4-ce76da25c4cd
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.
Built from https://develop.svn.wordpress.org/trunk@44524
git-svn-id: http://core.svn.wordpress.org/trunk@44355 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The position of this template within the hierarchy is of so little use that zero themes in the WordPress.org theme directory make use of it. It's second only to `index.php` in the hierarchy, meaning that any archive template such as `category.php` or `archive.php` will be chosen before it.
Fixes#38162
Props ryankienstra for initial patch
Built from https://develop.svn.wordpress.org/trunk@38755
git-svn-id: http://core.svn.wordpress.org/trunk@38698 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This allows themes to directly override the default template. The order in which the template is retrieved is as follows: `embed-$post_type-$post_format.php` -> `embed-$post_type.php` -> `embed.php`.
The `embed_template` filter gets replaced by the dynamic `{$type}_template` filter in `get_query_template()`.
Props ChriCo, swissspidy.
See #34561. Fixes#34278.
Built from https://develop.svn.wordpress.org/trunk@36876
git-svn-id: http://core.svn.wordpress.org/trunk@36843 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Splits wp-includes/embed-template.php, introduced in 4.4, into five new templates that can be individually overridden by themes:
* embed.php
* embed-404.php
* embed-content.php
* header-embed.php
* footer-embed.php
Also introduces a new template tag for outputting the site title, `the_embed_site_title()`.
The five new templates live in theme-compat, allowing for graceful fallbacks should themes prefer not to override any or all of them.
Props swissspidy, imath, ocean90, DrewAPicture.
See #34561.
Built from https://develop.svn.wordpress.org/trunk@36693
git-svn-id: http://core.svn.wordpress.org/trunk@36660 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In [36338], a template loading error was shown only to users with the `install_themes` capability. This is now displayed users with the `switch_themes` capability, as users with this cap can at least switch to a different theme. Also, this will now show for site administrators in multisite, whereas `install_themes` is limited to superadmins.
Props dd32.
See #21931.
Built from https://develop.svn.wordpress.org/trunk@36344
git-svn-id: http://core.svn.wordpress.org/trunk@36311 1a063a9b-81f0-0310-95a4-ce76da25c4cd
After [36335], if a template file is not loaded, an error is displayed
to logged-in users. As logged-in users may have no capabilities,
this check is insubstantial. Limit the display of this error to users
with the `install_themes` capability, i.e. someone who has the capacity
to deal with the error.
See #21931.
Built from https://develop.svn.wordpress.org/trunk@36338
git-svn-id: http://core.svn.wordpress.org/trunk@36305 1a063a9b-81f0-0310-95a4-ce76da25c4cd
On the off-chance the active theme folder is renamed or deleted, a "white screen
of death" was displayed to the user. Instead, the user is shown a useful error
screen displaying any errors the theme has (e.g. if the theme can't be found).
Props MikeHansenMe, SergeyBiryukov.
See #21931.
Built from https://develop.svn.wordpress.org/trunk@36335
git-svn-id: http://core.svn.wordpress.org/trunk@36302 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
For the past 6 years, WordPress has operated as an oEmbed consumer, allowing users to easily embed content from other sites. By adding oEmbed provider support, this allows any oEmbed consumer to embed posts from WordPress sites.
In addition to creating an oEmbed provider, WordPress' oEmbed consumer code has been enhanced to work with any site that provides oEmbed data (as long as it matches some strict security rules), and provides a preview from within the post editor.
For security, embeds appear within a sandboxed iframe - the iframe content is a template that can be styled or replaced entirely by the theme on the provider site.
Props swissspidy, pento, melchoyce, netweb, pfefferle, johnbillion, extendwings, davidbinda, danielbachhuber, SergeyBiryukov, afercia
Fixes#32522.
Built from https://develop.svn.wordpress.org/trunk@34903
git-svn-id: http://core.svn.wordpress.org/trunk@34868 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Content doesn't make sense for HEAD requests
* Saves wear and tear on the server
* Introduces a filter: exit_on_http_head (we send TRUE through it)
fixes#14348. props mbijon, mitchoyoshitaka.
git-svn-id: http://core.svn.wordpress.org/trunk@22347 1a063a9b-81f0-0310-95a4-ce76da25c4cd
