WordPress.org

Make WordPress Core

Opened 9 years ago

Closed 7 years ago

#1103 closed defect (bug) (fixed)

Move RSS feed update for dashboard to pseudo cron

Reported by: anonymousbugger Owned by: matt
Milestone: 2.1 Priority: normal
Severity: trivial Version: 2.0.1
Component: General Keywords: has-patch
Focuses: Cc:

Description

It's quite annoying to goto my admin, login, and then wait anywhere from 1 second to 2 minutes while Magpie takes its sweet time updating the RSS feed for the dashboard.

It would be prudent to optimize this behaviour or move it to a shutdown hook or *something*.

  • Jeff Minard

Attachments (1)

crude_rss_cache_fix.patch (3.8 KB) - added by anonymousbugger 9 years ago.

Download all attachments as: .zip

Change History (15)

comment:1 anonymousbugger9 years ago

  • Patch set to No

comment:2 idanso9 years ago

Magpie has a cache for such things, but the relevant code in wordpress seems both disabled and broken

See: wp-includes/rss-functions.php

comment:3 anonymousbugger9 years ago

I use Feed On Feeds as my news reader (it utilizes Magpie), and even with caching on, it can still take a while to parse a few feeds. I just don't think people should be left waiting after hitting the "login" button.

Perhaps the update could be run once every hour via a shutdown hook that tracks the "last updated" time.

And actually, the caching funcionality is on, by default, but there is no "cache" folder in the wp-includes directory for it to take advantage of.

Not to mention that fact that Magpie is at v0.71, and the included one is 0.51 - I wonder what the reason for that is - can't be an oversight, right?

comment:4 idanso9 years ago

And actually, the caching funcionality is on, by default, but there is no "cache" folder in the wp-includes directory for it to take advantage of.

It is not - MAGPIE_CACHE_ON constant is not defined, thus the cache is disabled.

Even if it will be set to on, I still had to port some up-to-date code from recent Magpie to actually make it working.

comment:5 ryan9 years ago

  • Owner changed from anonymous to matt
  • Status changed from new to assigned

comment:6 anonymousbugger9 years ago

rss-functions.php, line 567-569:

if ( !defined('MAGPIE_CACHE_ON') ) {

define('MAGPIE_CACHE_ON', 1);

}

:|

comment:7 idanso9 years ago

rss-functions.php, line 567-569:

Correct:-)

In addition, it appears that the caching system itself was not crippled, but It used the DB(specificly, the options table, except that it doesn't seem it was designed for that purpose) to store the cache data.

My patch actually makes it work on a file-system cache once again, which has it trade-offs:-)

comment:8 matt9 years ago

  • Resolution changed from 10 to 90
  • Status changed from assigned to closed

Caching to the FS is not an option

comment:9 anonymousbugger9 years ago

  • Resolution changed from 90 to 30
  • Status changed from closed to assigned

Woah, wait a sec - not closed yet.

The orginal idea was not "to FS, or not to FS" it was, "remove the > 10 seconds login lag"

Would it be innapropriate to move this to the shutdown hook or find some other way to keep the feeds up-to-date? Perhaps having the main blog shutdown hook check the feeds every 3-6 hours?

So, back to the "login lag"...

comment:10 MC_incubus9 years ago

I use Magpie to grab the latest entry from everyone on my blogroll and display it in my sidebar. At first I used Magpie's caching... but felt bad for the sorry visitor who triggered the downloading and parsing of the feeds and was treated to a 20s load time. So what I did was write a function to manually refresh the cache (there isn't a function in Magpie to do that), and have it run on Cron every X minutes. Then, when setting up Magpie, I tell it to grab new feeds that are older than 2*X minutes... that way Magpie will never trigger an auto-refresh, because the cache will always be refreshed by the cron process and will never get old enough for an auto-refresh.

If we built a manual feed refresh function (it's not hard, it's some copy-pasting and removing of some if() stuff), we could have it run on the publish_post action. That already takes time, due to Pingback (and Trackback if you're sending them), so that might be a better place to make the user wait. Then we could set Magpie's cache's expiration to something big like 5 days, so the user would only trigger an auto-update at the Dashboard if they haven't posted in 5 days.

The fact is: downloading and parsing a feed takes time. Unless you set it up as a cron job (and let's face it, few people know how to do that, and not everyone's host supports it), you can't get around the fact that someone is going to have to sit there at some point and wait for the feed to download. I just think that doing it at a time when the user is expecting a delay anyway makes more sense than the delay they currently get when they log in.

comment:11 jminard9 years ago

It could be moved to the "shutdown" hook which utilizes the php function <a href="http://us3.php.net/manual/en/function.register-shutdown-function.php">register_shutdown_function()</a> function. These calls happen after the script is done sending data to the client. However, the only issue with doing it this way is that the data on that page will not be updated until the next page load. Not such a big deal IMO though as most people aren't sitting on the edge of their seats waiting to read what's going on.

comment:12 markjaquith8 years ago

  • Milestone set to 2.1
  • Summary changed from Move RSS feed update for dashboard to shutdown hook to Move RSS feed update for dashboard to pseudo cron
  • Version changed from 1.5 to 2.0.1

comment:13 rgovostes8 years ago

  • Keywords has-patch added

comment:14 matt7 years ago

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

This should be addressed by the new AJAX loading.

Note: See TracTickets for help on using tickets.