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.
git-svn-id: https://develop.svn.wordpress.org/trunk@36566 602fd350-edb4-49c9-b593-d223f7449a82
With the false indentation in place, the parser for the Code Reference incorrectly interprets it as a block quote.
Fixes#35019.
git-svn-id: https://develop.svn.wordpress.org/trunk@35868 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@35800 602fd350-edb4-49c9-b593-d223f7449a82
`post-template.php` loads after `post.php` in `wp-settings.php`. It could probably also be loaded in `post.php`, but avoiding that for the moment.
See #33413.
git-svn-id: https://develop.svn.wordpress.org/trunk@34109 602fd350-edb4-49c9-b593-d223f7449a82
Creates:
`class-wp-post.php`
`post-functions.php`
`post.php` contains only top-level code. Class file only contains the class. Functions file only contains functions.
See #33413.
git-svn-id: https://develop.svn.wordpress.org/trunk@33759 602fd350-edb4-49c9-b593-d223f7449a82
* 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.
git-svn-id: https://develop.svn.wordpress.org/trunk@33666 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@33630 602fd350-edb4-49c9-b593-d223f7449a82
The documentation should make it clear that the function does not modify the
post object in the database, but only fires hooks related to the transition.
Props AramZS.
Fixes#33014.
git-svn-id: https://develop.svn.wordpress.org/trunk@33296 602fd350-edb4-49c9-b593-d223f7449a82
This prevents existing posts with numeric slugs from having their permalinks
changed on update.
Fixes#5305.
git-svn-id: https://develop.svn.wordpress.org/trunk@33262 602fd350-edb4-49c9-b593-d223f7449a82
Pages are static content, for which comments are not expected out of the box.
Props valendesigns, rachelbaker.
Fixes#31168.
git-svn-id: https://develop.svn.wordpress.org/trunk@33041 602fd350-edb4-49c9-b593-d223f7449a82
Update docs for `WP_Post` constructor to indicate that `WP_Post|object` can be the supplied param, as opposed to just `WP_Post`.
props westonruter.
fixes#32632.
git-svn-id: https://develop.svn.wordpress.org/trunk@32762 602fd350-edb4-49c9-b593-d223f7449a82
On certain permalink structures, a numeric post slug will result in a post
permalink that conflicts with a date archive URL. For example, with permastruct
`/%year%/%monthnum%/%postname%/`, a post published in May 2015 with slug
`'15'` will result in a URL (`/2015/05/15/`) that conflicts with the archive
for May 15, 2015.
To avoid this problem, `wp_unique_post_slug()` rejects a requested slug when it
would generate a conflict of this type. Thus, in our example, `'15'` would
become `'15-2'`.
Props valendesigns, boonebgorges, Denis-de-Bernardy, loushou.
See #5305.
git-svn-id: https://develop.svn.wordpress.org/trunk@32647 602fd350-edb4-49c9-b593-d223f7449a82
Clarify `@return` values where necessary.
In `wp_delete_post_revision()`, `wp_delete_post()` doesn't return `WP_Error`, so that check can be removed.
`wp_revisions_to_keep()` always returns an `int`, so `wp_revisions_enabled()` can use strict comparison.
See #32444.
git-svn-id: https://develop.svn.wordpress.org/trunk@32621 602fd350-edb4-49c9-b593-d223f7449a82
Clarify some existing values for `@param` and `@return`.
Some functions do not need to set a variable before immediately returning it.
See #32444.
git-svn-id: https://develop.svn.wordpress.org/trunk@32619 602fd350-edb4-49c9-b593-d223f7449a82
