Opened 20 years ago
Closed 18 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)
Change History (15)
#3
@
20 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?
#4
@
20 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.
#6
@
20 years ago
rss-functions.php, line 567-569:
if ( !defined('MAGPIE_CACHE_ON') ) {
define('MAGPIE_CACHE_ON', 1);
}
:|
#7
@
20 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:-)
#8
@
20 years ago
- Resolution changed from 10 to 90
- Status changed from assigned to closed
Caching to the FS is not an option
#9
@
20 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"...
#10
@
20 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.
#11
@
20 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.
Magpie has a cache for such things, but the relevant code in wordpress seems both disabled and broken
See: wp-includes/rss-functions.php