[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
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
Boone Gorges
Sergey Biryukov
Gary Pendergast
Drew Jaynes
Scott Taylor
Dominik Schilling
Andrew Nacin
Mark Jaquith
Dion Hulse
Ryan Boren