WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 3 years ago

#10615 closed defect (bug) (fixed)

Recent Comments Widget Should Use Comments API

Reported by: filosofo Owned by:
Priority: normal Milestone: 3.0
Component: Comments Version: 2.9
Severity: normal Keywords: has-patch dev-feedback needs-testing
Cc: westi, me@…

Description

Currently it makes a direct database query.

Patch calls get_comments() instead.

Attachments (6)

widget_comments_use_api.10615.diff (1.8 KB) - added by filosofo 4 years ago.
widget_comments_use_api.10615.no_limit.diff (2.1 KB) - added by filosofo 4 years ago.
widget_comments_use_api.10615.persistent_cache.diff (2.7 KB) - added by filosofo 4 years ago.
10615-4-no-output-buffering-updated.diff (3.1 KB) - added by blepoxp 3 years ago.
Refreshed. Doesn't use output buffering. Uses get_comments()
10615-4-no-output-buffering-updated-w-cache.diff (3.8 KB) - added by blepoxp 3 years ago.
This diff actually puts the $cache var into cache... removes limit label in GUI as well
get_comments.diff (482 bytes) - added by jshreve 3 years ago.
only show approved comments

Download all attachments as: .zip

Change History (27)

comment:1 westi4 years ago

Relates to #10612

comment:2 westi4 years ago

  • Cc westi added

Patch looks good.

I wonder if the old caching mech was trying to be clever for multiple widget instances so they all used the same cache hence always getting 15 comments

don't know if we want to preserve that behaviour.

It means that if you use the widget three times but with different comment counts its only one cache entry to store and invalidate.

comment:3 filosofo4 years ago

I think you're right about the intent. However, having multiple instances of the recent comments widget seems like too obscure a situation to justify the unnecessary queries.

I think that also explains why the max limit was set to 15. Without the caching cleverness, that limit is unnecessary, so I removed it from the second patch.

comment:4 follow-up: azaozz4 years ago

Why remove the explicit caching? That will force blogs with persistent cache to run the rest of the code on almost every page load.

comment:5 in reply to: ↑ 4 ; follow-up: filosofo4 years ago

Replying to azaozz:

Why remove the explicit caching? That will force blogs with persistent cache to run the rest of the code on almost every page load.

Ok, taking that into account, third patch does what the recent posts widget cache does: it uses the query API but caches the printed output.

Improvements:

  • Still using API instead of direct db calls
  • Likely to have to query less in most cases, as default 5 queried comments is less than previous 15 comments no matter what.
  • Persistent cache of output instead of serialized comment objects means we're caching a smaller amount of data but interrupting sooner, thereby reducing processing and memory use.

comment:6 ryan4 years ago

  • Keywords early added
  • Milestone changed from 2.9 to 3.0

comment:7 in reply to: ↑ 5 ; follow-up: westi3 years ago

Replying to filosofo:

Replying to azaozz:

Why remove the explicit caching? That will force blogs with persistent cache to run the rest of the code on almost every page load.

Ok, taking that into account, third patch does what the recent posts widget cache does: it uses the query API but caches the printed output.

Improvements:

  • Still using API instead of direct db calls
  • Likely to have to query less in most cases, as default 5 queried comments is less than previous 15 comments no matter what.
  • Persistent cache of output instead of serialized comment objects means we're caching a smaller amount of data but interrupting sooner, thereby reducing processing and memory use.

Looks good.

Do we really need to use output buffering and echos here?

Can we not just build up the html as a string and cache that?

comment:8 in reply to: ↑ 7 filosofo3 years ago

Replying to westi:

Do we really need to use output buffering and echos here?

No. I was desperately trying to get get_comments() in instead of querying the database directly, so to respond to the above criticism I just copied the recent posts widget almost exactly. (Recent posts, the calendar, and various chunks of the admin use the output buffering trick).

How about a patch that builds the HTML for recent comments as well as recent posts, so we're somewhat consistent?

comment:9 hakre3 years ago

Regarding Cache and multiple widgets please see this ticket which should contain a fix for the problem: #11580

comment:10 Denis-de-Bernardy3 years ago

  • Keywords needs-patch added; get_comments WP_Widget_Recent_Comments has-patch removed

widget_comments_use_api.10615.persistent_cache.diff is erroneous. the last call to wp_cache_add() is bogus (it's missing an argument), and it should be using wp_cache_set() instead.

comment:11 filosofo3 years ago

Whoops. However, aside from the missing argument it's the same as the recent posts widget. I'll see how the dust settles on that and imitate it for recent comments.

comment:12 rmccue3 years ago

  • Cc me@… added
  • Keywords needs-refresh added

No longer applies cleanly.

comment:13 nacin3 years ago

Just a thought -- custom comment types will show up in the widget, and plugins have no control over that currently unless they filter on the SQL itself. Using the API should allow for a plugin to filter that nicer.

blepoxp3 years ago

Refreshed. Doesn't use output buffering. Uses get_comments()

comment:14 blepoxp3 years ago

  • Keywords has-patch dev-feedback needs-testing added; needs-patch removed

This is basically the same patch as filosofo submitted but its built off of the current revision and it doesn't use output buffering. Comments / suggestions?

blepoxp3 years ago

This diff actually puts the $cache var into cache... removes limit label in GUI as well

comment:15 zeo3 years ago

relates to #12904. Probably need refresh.

comment:16 nacin3 years ago

  • Keywords needs-refresh removed

comment:17 blepoxp3 years ago

  • Keywords early removed

comment:18 westi3 years ago

Kicking the tires on this patch now.

comment:19 westi3 years ago

  • Resolution set to fixed
  • Status changed from new to closed

(In [14483]) Make the recent comments widget use the get_comments() api and cache the result. Fixes #10615 props filosofo and blepoxp.

comment:20 nacin3 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

jshreve3 years ago

only show approved comments

comment:21 nacin3 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

(In [14679]) Don't show unapproved comments in comments widget. props jshreve, fixes #10615.

Note: See TracTickets for help on using tickets.