It is possible to delegate pingback processing to a service function outside of WordPress itself. All other calls in default themes (and likely other themes) uses `bloginfo` which automatically adds the filter argument of "display". This adds consistency.
Props dshanske.
Fixes#34633.
Built from https://develop.svn.wordpress.org/trunk@38671
git-svn-id: http://core.svn.wordpress.org/trunk@38614 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This private query var allows the hierarchical page query on the Pages listing screen to query for `wp_posts.ID, wp_posts.post_parent` instead of `wp_posts.*`. This introduces large memory and time savings when the site contains a large number of Pages. Combined with the processing time savings introduced in [31730] this makes the Pages listing screen considerably more performant.
Fixes#34982
Props rodrigosprimo
Built from https://develop.svn.wordpress.org/trunk@38451
git-svn-id: http://core.svn.wordpress.org/trunk@38392 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The rewrite rule matching code in WP::parse_request() used an unclear variable `$request` to represent the requested path (e.g. "2016/05/03") as well as a deceptively named variable `$request_uri`, which actually represents the requested file when an install used PATHINFO links.
Those variables are replaced with `$requested_path` and `$requested_file` respectively for clarity.
Fixes#36674.
Built from https://develop.svn.wordpress.org/trunk@37356
git-svn-id: http://core.svn.wordpress.org/trunk@37322 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
[34247] made the 'public' paramater of `register_taxonomy()` work by blocking
requests for non-public taxonomy archives during `parse_request()`. Blocking
taxonomy archive requests this late means that it's impossible to register an
independent query var that matches the slug of a non-public taxonomy. By
moving the block to `register_taxonomy()` - not allowing these taxonomies to
register their query vars in the first place - we free up the slug for other
use. In addition, we free up a bit of processing (no need to look for the query
var in `parse_request()` and better parallel the way non-public post types
work. See `register_post_type()`.
Non-public taxonomy archives that are requested using `?taxonomy=tax_name` are
still blocked during `parse_request`. It's only custom query vars -
`?tax_name=term` - that are affected by this change.
Props mboynes.
Fixes#21949.
Built from https://develop.svn.wordpress.org/trunk@35333
git-svn-id: http://core.svn.wordpress.org/trunk@35299 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
Awesome rewrite bug: the `page` query var was being set to `'/4'` in `$wp`. When cast to `int`, it returns `0` (Bless you, PHP). `WP_Query` calls `trim( $page, '/' )` when setting its own query var. The few places that were checking `page` before posts were queried now have sanity checks, so that these changes work without flushing rewrites.
Adds/updates unit tests.
Props wonderboymusic, dd32.
See #11694.
Built from https://develop.svn.wordpress.org/trunk@34492
git-svn-id: http://core.svn.wordpress.org/trunk@34456 1a063a9b-81f0-0310-95a4-ce76da25c4cd
[13216] introduced the 'public' argument for `register_taxonomy()`. This param
was used to set defaults for 'show_ui' and a number of other params, but it
never did anything itself.
With this changeset, taxonomies registered with `public=false` will no longer
be queryable on the front end, ie via taxonomy archive queries.
Props wpsmith, ocean90, nacin, ericlewis, boonebgorges.
Fixes#21949.
Built from https://develop.svn.wordpress.org/trunk@34247
git-svn-id: http://core.svn.wordpress.org/trunk@34211 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Add a query var, `title`, that allows you to query posts by `post_title`. To accomplish this now, you have to do something like:
{{{
$tacos = get_posts( [
'post_type' => 'taco',
's' => $name,
'exact' => true,
'sentence' => true,
'post_status' => 'publish',
'fields' => 'ids',
'posts_per_page' => 1
] );
}}}
Adds unit tests.
Fixes#33074.
Built from https://develop.svn.wordpress.org/trunk@33706
git-svn-id: http://core.svn.wordpress.org/trunk@33673 1a063a9b-81f0-0310-95a4-ce76da25c4cd
A URL like `example.com/2015/05/15/` generally resolves to the May 15, 2015 date
archive. But in certain cases, it could also be the permalink of a post with
the slug `'2015'`. When a conflict of this sort is detected, resolve to the post
instead of the archive.
URL conflicts of this sort should no longer occur for new posts; see [32647].
Props valendesigns, boonebgorges, Denis-de-Bernardy.
Fixes#5305.
Built from https://develop.svn.wordpress.org/trunk@32648
git-svn-id: http://core.svn.wordpress.org/trunk@32618 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Exactly one method was made private in [28516], and is only used internally.
* 2 properties were made private, but they just store variables passed to the constructor.
* Instances of this class are never created in core. `WP_MatchesMapRegex::apply()` is called statically in `WP->parse_request()` and `url_to_postid()`.
The chances that:
1) this class is used as an instance somewhere and
2) the properties that have always been marked `@access private` and begin with `_` were used publicly
...is extremely low.
Remove the magic methods, I should not have added them.
While we're at it, use the PHP5-style `__construct()` instead of the class name.
See #30891.
Built from https://develop.svn.wordpress.org/trunk@31136
git-svn-id: http://core.svn.wordpress.org/trunk@31117 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
