Known functions, classes, and methods are now auto-linked in Code Reference pages following #meta1483.
Note: Hook references are still linked via inline `@see` tags due to the unlikelihood of reliably matching for known hooks based on a RegEx pattern.
See #32246.
Built from https://develop.svn.wordpress.org/trunk@37342
git-svn-id: http://core.svn.wordpress.org/trunk@37308 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Percent signs are reserved characters in URIs. As such, it was impossible for
plugins to route requests to trashed posts, as happens in bbPress. The new
`__trashed` suffix should be sufficiently unique.
Also adds a test that demonstrates that the `__trashed` suffix can be
appended to slugs that contain the suffix somewhere other than the end of
the string.
Props netweb, ericlewis.
Fixes#11863.
Built from https://develop.svn.wordpress.org/trunk@37165
git-svn-id: http://core.svn.wordpress.org/trunk@37132 1a063a9b-81f0-0310-95a4-ce76da25c4cd
When determining a unique post slug, trashed posts are taken into account. Previously, new posts would add suffixes to their slugs (e.g. `about-2`) when a post in the trash had the desired slug (e.g. `about`).
To avoid this behavior, when a post is trashed its slug (i.e. `post_name`) is now suffixed with `-%trashed%`. The post's pre-trash slug is stored as post meta, and if the post is restored from trash, its desired slug is reapplied.
For existing trashed posts which don't have the `-%trashed%` suffix, the suffix is added when a post with its desired slug is created.
Props ocean90, boonebgorges, ryan, SergeyBiryukov, coffee2code, helen, williamsba1.
See #11863.
Built from https://develop.svn.wordpress.org/trunk@36607
git-svn-id: http://core.svn.wordpress.org/trunk@36574 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Comment and term meta lazyloading for `WP_Query` loops, introduced in 4.4,
depended on filter callback methods belonging to `WP_Query` objects. This meant
storing `WP_Query` objects in the `$wp_filter` global (via `add_filter()`),
requiring that PHP retain the objects in memory, even when the local variables
would typically be expunged during normal garbage collection. In cases where a
large number of `WP_Query` objects were instantiated on a single pageload,
and/or where the contents of the `WP_Query` objects were quite large, serious
performance issues could result.
We skirt this problem by moving metadata lazyloading out of `WP_Query`. The
new `WP_Metadata_Lazyloader` class acts as a lazyload queue. Query instances
register items whose metadata should be lazyloaded - such as post terms, or
comments - and a `WP_Metadata_Lazyloader` method will intercept comment and
term meta requests to perform the cache priming. Since `WP_Metadata_Lazyloader`
instances are far smaller than `WP_Query` (containing only object IDs), and
clean up after themselves far better than the previous `WP_Query` methods (bp
only running their callbacks a single time for a given set of queued objects),
the resource use is decreased dramatically.
See [36525] for an earlier step in this direction.
Props lpawlik, stevegrunwell, boonebgorges.
Fixes#35816.
Built from https://develop.svn.wordpress.org/trunk@36566
git-svn-id: http://core.svn.wordpress.org/trunk@36533 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously when updating a post using wp_insert_post(), post_name was
regenerated based on post_title every time if post_name was not passed in
explicitly. This irons out the expectation that properties not passed into the
function should not be modified.
Props jason_the_adams.
Fixes#34865.
Built from https://develop.svn.wordpress.org/trunk@35800
git-svn-id: http://core.svn.wordpress.org/trunk@35764 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Introduce `is_post_type_viewable( $post_type_object )`
* Separate the HTML bits from the translatable bits in the `post` messages array in `edit-form-advanced.php`
* Don't show certain UI pieces when a post is not viewable on the front end
When a custom post type item is not viewable on the front end, we don't want to show links to View it (on the front end) all over the admin. We also want to hide the Preview link, et al. We also want our admin messages to not contain said links.
Custom post types with `public_queryable` set to `false` are not viewable on the front end.
`'page'` is viewable on the front end, but `'page'` is a `_builtin` type, and `public_queryable` is set to `false` when it is registered - see `WP::parse_request()` for when `public_queryable` gets used.
This is confusing, but also somewhat straightforward: to determine if a post type is viewable on the front end, we can check one way for `_builtin => true` and another way for `_builtin => false`:
`$post_type->publicly_queryable || ( $post_type->_builtin && $post_type->public )`
If a post type is `publicly_queryable`, it's viewable. If that value is `false`, it is viewable if it's a `_builtin` type that is also `public`.
I am in search of edge cases, so this shall land.
Props wonderboymusic, DrewAPicture.
See #17609.
Built from https://develop.svn.wordpress.org/trunk@33666
git-svn-id: http://core.svn.wordpress.org/trunk@33633 1a063a9b-81f0-0310-95a4-ce76da25c4cd
If the post cache is not cleared at this point, the cache can become stale
for operations performed before the cache is cleared later in the function.
Specifically, the generation of a `guid` for new posts can use stale data,
resulting in non-unique values. [33262] introduced a call to `get_post()`
that introduced just such an invalidation problem.
Fixes#5305.
Built from https://develop.svn.wordpress.org/trunk@33630
git-svn-id: http://core.svn.wordpress.org/trunk@33597 1a063a9b-81f0-0310-95a4-ce76da25c4cd
