Prior to about 2013, many class methods lacked even access modifiers which made the `@access` notations that much more useful. Now that we've gotten to a point where the codebase is more mature from a maintenance perspective and we can finally remove these notations. Notable exceptions to this change include standalone functions notated as private as well as some classes still considered to represent "private" APIs.
See #41452.
Built from https://develop.svn.wordpress.org/trunk@41162
git-svn-id: http://core.svn.wordpress.org/trunk@41002 1a063a9b-81f0-0310-95a4-ce76da25c4cd
One thing fairly common to the cache groups is a block of code to look to see when the cache was last changed, and if there isn't one, to set it for the current microtime(). It appears in 8 different places in core. This adds a new helper `wp_cache_get_last_changed` to DRY things up a bit.
Since `wp-includes/cache.php` isn't guaranteed to be loaded, this new function is in `wp-includes/functions.php`
Props spacedmonkey, desrosj.
Fixes#37464.
Built from https://develop.svn.wordpress.org/trunk@38849
git-svn-id: http://core.svn.wordpress.org/trunk@38792 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The SQL query was built using the clauses compiled when querying for
top-level comments. But in cases where the top-level comment query
results are already in the cache, the SQL clauses are not built, and
so are unavailable for `fill_descendants()`. Instead, we call
`get_comments()`, using modified versions of the parameters passed
to the main `WP_Comment_Query` class.
Props Akeif, Rarst for testing.
Fixes#37696.
Built from https://develop.svn.wordpress.org/trunk@38446
git-svn-id: http://core.svn.wordpress.org/trunk@38387 1a063a9b-81f0-0310-95a4-ce76da25c4cd
When comment IDs are fetched from the cache rather than the database,
the subsequent `SELECT FOUND_ROWS()` query will not return the correct value.
To avoid unnecessary queries, we cache the results of the `found_comments`
query alongside the comment IDs.
Props spacedmonkey.
Fixes#37184.
Built from https://develop.svn.wordpress.org/trunk@38001
git-svn-id: http://core.svn.wordpress.org/trunk@37942 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Hierarchical comment queries work by first fetching the IDs of top-level
comments, and then filling the descendant tree one level at a time based on the
top-level results. When top-level comment IDs are found in the cache,
`WP_Comment_Query` does not generate the SQL used to fetch these comments. In
this case, the `fill_descendants()` query does not have enough information
to fill children. As a result, descendant comments were failing to be filled
in cases where the top-level comments were found in the cache.
This was a minor bug previously, because comment caches were not maintained
between pageloads. Since comment caches are now persistent [37613], the problem
becomes evident anywhere that a persistent object cache is in use.
The solution is to cache parent-child relationships, so that when top-level
comments are found in the cache, descendant comments should be found there as
well.
Fixes#36487.
Built from https://develop.svn.wordpress.org/trunk@37625
git-svn-id: http://core.svn.wordpress.org/trunk@37593 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Also use 'back-compat' in some inline comments where backward compatibility is the subject and shorthand feels more natural.
Note: 'backwards compatibility/compatibile' can also be considered correct, though it's primary seen in regular use in British English.
Props ocean90.
Fixes#36835.
Built from https://develop.svn.wordpress.org/trunk@37431
git-svn-id: http://core.svn.wordpress.org/trunk@37397 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The changes introduced in [36381], while logical and clearly awesome, introduce
the potential for much breakage. Those who want to query for comments with a
null `comment_post_ID` should use `'post_in' => array( 0 )` instead.
Reverts [36381], [36387].
See #35090.
Built from https://develop.svn.wordpress.org/trunk@36480
git-svn-id: http://core.svn.wordpress.org/trunk@36447 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously, this was not possible due to an overly broad `empty()` check.
Passing `null`, `false`, or `''` to 'post_id', or omitting 'post_id'
altogether, will continue to return comments regardless of `comment_post_ID`,
as before. Passing `0` or `'0'` will limit results to comments with no
associated post.
Props danielbachhuber.
Fixes#35090.
Built from https://develop.svn.wordpress.org/trunk@36381
git-svn-id: http://core.svn.wordpress.org/trunk@36348 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The refactor of `WP_Comment_Query`'s SQL generation in [34542] introduced a bug
that caused only the last post-related filter to be respected in comment
queries. In other words, if querying for comments using params
`post_status=draft&post_author=3`, only the last-processed of these params
would be respected. The current changeset fixes the logic so that these clauses
don't overwrite each other.
Props chriscct7.
Fixes#35478.
Built from https://develop.svn.wordpress.org/trunk@36326
git-svn-id: http://core.svn.wordpress.org/trunk@36293 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The descendant query in `WP_Comment_Query::fill_descendants()` uses the clauses
of the main `get_comment_ids()` query as a basis, discarding the `parent`,
`parent__in`, and `parent__not_in` clauses. As implemented in WP 4.4 [34546],
the WHERE clause was assembled in such a way that any modifications applied
using the `comments_clauses` filter were not inherited by `fill_descendants()`.
This resulted in descendant queries that did not always properly filter
results, and sometimes contained syntax errors.
The current changeset fixes the problem by using the post-filter WHERE clause
as the basis for the `fill_descendants()` query. This change requires a new
approach for eliminating the unneeded parent-related clauses: instead of
eliminating values in an associative array, we must use regular expressions.
Props boonebgorges, firebird75.
Fixes#35192.
Built from https://develop.svn.wordpress.org/trunk@36277
git-svn-id: http://core.svn.wordpress.org/trunk@36244 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This fixes a bug where widgets loaded in a preview or the Customizer are
rendered inside of a `wp_suspend_cache_addition()` block and thus could not
find comment objects in the cache.
Props rommelxcastro, stevehenty.
Fixes#34138.
Built from https://develop.svn.wordpress.org/trunk@35512
git-svn-id: http://core.svn.wordpress.org/trunk@35476 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`WP_Comment_Query::fill_descendants()` queries for a comment tree in a way that
minimizes database overhead, and places the located descendants with their
proper parents. However, it doesn't touch leaf nodes - comments with no
children - so future calls to `get_children()` on those comment objects
result in unnecessary database queries. To prevent this, `fill_descendants()`
now sets a `populated_children` flag on all located `WP_Comment` objects.
See #8071.
Built from https://develop.svn.wordpress.org/trunk@34730
git-svn-id: http://core.svn.wordpress.org/trunk@34694 1a063a9b-81f0-0310-95a4-ce76da25c4cd
[34583] modified comment queries so that all post fields are no longer loaded
by default. Instead, they are loaded only when requested on individual comment
objects. This changeset improves that flow:
* `WP_Comment` magic methods `__isset()` and `__get()` should only load the post when a post field is being requested.
* The new `update_comment_post_cache` argument for `WP_Comment_Query` allows developers to specify that, when comments are queried, all of the posts matching those comments should be loaded into cache with a single DB hit. This parameter defaults to false, since typical comment queries are linked to a single post.
Fixes#27571.
Built from https://develop.svn.wordpress.org/trunk@34599
git-svn-id: http://core.svn.wordpress.org/trunk@34563 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously, the 'page_comments' toggle allowed users to disable comment
pagination. This toggle was only superficial, however. Even with
'page_comments' turned on, `comments_template()` loaded all of a post's
comments into memory, and passed them to `wp_list_comments()` and
`Walker_Comment`, the latter of which produced markup for only the
current page of comments. In other words, it was possible to enable
'page_comments', thereby showing only a subset of a post's comments on a given
page, but all comments continued to be loaded in the background. This technique
scaled poorly. Posts with hundreds or thousands of comments would load slowly,
or not at all, even when the 'comments_per_page' setting was set to a
reasonable number.
Recent changesets have addressed this problem through more efficient tree-
walking, better descendant caching, and more selective queries for top-level
post comments. The current changeset completes the project by addressing the
root issue: that loading a post causes all of its comments to be loaded too.
Here's the breakdown:
* Comment pagination is now forced. Setting 'page_comments' to false leads to evil things when you have many comments. If you want to avoid pagination, set 'comments_per_page' to something high.
* The 'page_comments' setting has been expunged from options-discussion.php, and from places in the codebase where it was referenced. For plugins relying on 'page_comments', we now force the value to `true` with a `pre_option` filter.
* `comments_template()` now queries for an appropriately small number of comments. Usually, this means the `comments_per_page` value.
* To preserve the current (odd) behavior for comment pagination links, some unholy hacks have been inserted into `comments_template()`. The ugliness is insulated in this function for backward compatibility and to minimize collateral damage. A side-effect is that, for certain settings of 'default_comments_page', up to 2x the value of `comments_per_page` might be fetched at a time.
* In support of these changes, a `$format` parameter has been added to `WP_Comment::get_children()`. This param allows you to request a flattened array of comment children, suitable for feeding into `Walker_Comment`.
* `WP_Query` loops are now informed about total available comment counts and comment pages by the `WP_Comment_Query` (`found_comments`, `max_num_pages`), instead of by `Walker_Comment`.
Aside from radical performance improvements in the case of a post with many
comments, this changeset fixes a bug that caused the first page of comments to
be partial (`found_comments` % `comments_per_page`), rather than the last, as
you'd expect.
Props boonebgorges, wonderboymusic.
Fixes#8071.
Built from https://develop.svn.wordpress.org/trunk@34561
git-svn-id: http://core.svn.wordpress.org/trunk@34525 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Comments can be threaded. Now your query can be threaded too! Bonus: it's
not totally insane.
* The new `$hierarchical` parameter for `WP_Comment_Query` accepts three values:
* `false` - Default value, and equivalent to current behavior. No descendants are fetched for matched comments.
* `'flat'` - `WP_Comment_Query` will fetch the descendant tree for each comment matched by the query paramaters, and append them to the flat array of comments returned. Use this when you have a separate routine for constructing the tree - for example, when passing a list of comments to a `Walker` object.
* `'threaded'` - `WP_Comment_Query` will fetch the descendant tree for each comment, and return it in a tree structure located in the `children` property of the `WP_Comment` objects.
* `WP_Comment` now has a few utility methods for fetching the descendant tree (`get_children()`), fetching a single direct descendant comment (`get_child()`), and adding anothing `WP_Comment` object as a direct descendant (`add_child()`). Note that `add_child()` only modifies the comment object - it does not touch the database.
Props boonebgorges, wonderboymusic.
See #8071.
Built from https://develop.svn.wordpress.org/trunk@34546
git-svn-id: http://core.svn.wordpress.org/trunk@34510 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`WP_Comment_Query` will now report the total number of comments matching the
query params (`comments_found`), as well as the total number of pages required
to display these comments (`max_num_pages`). Because `SQL_CALC_FOUND_ROWS`
queries can introduce a lot of overhead in some cases, we disable the feature
by default. Pass `no_found_rows=false` to `WP_Comment_Query` to enable the
count. (We use the negative parameter name 'no_found_rows' for parity with
`WP_Query`.)
Props wonderboymusic, boonebgorges.
See #8071.
Built from https://develop.svn.wordpress.org/trunk@34544
git-svn-id: http://core.svn.wordpress.org/trunk@34508 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`WP_Comment_Query` now fetches comments in two stages: (1) a query to get the
IDs of comments matching the query vars, and (2) a query to populate the
objects corresponding to the matched IDs. The two queries are cached
separately, so that sites with persistent object caches will continue to have
complete cache coverage for normal comment queries.
Splitting the query allows our cache strategy to be more modest and precise, as
full comment data is only stored once per comment. It also makes it possible
to introduce logic for paginated threading, which is necessary to address
certain performance problems.
See #8071.
data is only stored once per comment, instead of along with
Built from https://develop.svn.wordpress.org/trunk@34310
git-svn-id: http://core.svn.wordpress.org/trunk@34274 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The new 'update_comment_meta_cache' parameter, which defaults to `true`, can
be used to disable this behavior.
`update_comment_cache()` has been updated to support an `$update_meta_cache`
parameter, which also updates to true; this matches the pattern we use for
priming post caches.
See #16894.
Built from https://develop.svn.wordpress.org/trunk@34268
git-svn-id: http://core.svn.wordpress.org/trunk@34232 1a063a9b-81f0-0310-95a4-ce76da25c4cd