[wp-trac] [WordPress Trac] #20379: dashboard_incoming_links fails to update when 'home' changes, so google rss is wrong
WordPress Trac
wp-trac at lists.automattic.com
Fri Apr 6 16:04:00 UTC 2012
#20379: dashboard_incoming_links fails to update when 'home' changes, so google rss
is wrong
--------------------------+-----------------------------
Reporter: kitchin | Owner:
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Feeds | Version: 3.3.1
Severity: normal | Keywords:
--------------------------+-----------------------------
When the user changes 'home', the wp_option 'dashboard_widget_options' is
updated. But WP fails to update it completely, so the default Google RSS
syndication URL is broken.
The borked value is:
dashboard_widget_options: dashboard_incoming_links: url
which is of the form
http://blogsearch.google.com/blogsearch_feeds?scoring=d&ie=utf-8&num=10&output=rss&partner=wordpress&q=link:http://example.com/
The string at the end, example.com, is supposed to change but it does not.
Here is the problem.
(Trunk has the same code as the current ver. 3.3.1.)
http://core.trac.wordpress.org/browser/trunk/wp-
admin/includes/dashboard.php#L59
constructs 'url' as follows, expanded for readability:
{{{
'url' => isset($widget_options['dashboard_incoming_links']['url'])
? apply_filters(
'dashboard_incoming_links_feed',
$widget_options['dashboard_incoming_links']['url']
)
: apply_filters(
'dashboard_incoming_links_feed',
'http://blogsearch.google.com/blogsearch_feeds?scoring=d&ie=utf-8&num=' .
$num_items . '&output=rss&partner=wordpress&q=link:' . trailingslashit(
get_option('home') )
),
}}}
Since 'url' is already set, it never changes! The value of
get_option('home') is not used.
This code block is only reached when 'home' has changed, or on initial
setup, so it does not make much sense to ignore 'home'.
I'm not sure if there is any reason to keep the tertiary. Solution 1 below
is the simple fix.
Solution 2 is a heuristic fix to handle the case where a plugin or theme
has updated the database, instead of using the filter. It mimics the
current (possibly wrong) behavior in that case.
Solution 1:
{{{
$widget_options['dashboard_incoming_links'] = array(
...
'url' => apply_filters( 'dashboard_incoming_links_feed',
'http://blogsearch.google.com/blogsearch_feeds?scoring=d&ie=utf-8&num=' .
$num_items . '&output=rss&partner=wordpress&q=link:' . trailingslashit(
get_option('home') ) ),
}}}
Solution 2:
{{{
$url_prefix =
'http://blogsearch.google.com/blogsearch_feeds?scoring=d&ie=utf-8&num=' .
$num_items . '&output=rss&partner=wordpress&q=link:';
$url = $url_prefix . trailingslashit( get_option( 'home' ) );
if ( isset ( $widget_options['dashboard_incoming_links']['url'] ) ) {
if ( 0 !== strpos(
$widget_options['dashboard_incoming_links']['url'], $url_prefix ) ) {
$url = $widget_options['dashboard_incoming_links']['url'];
}
}
$widget_options['dashboard_incoming_links'] = array(
...
'url' => apply_filters( 'dashboard_incoming_links_feed', $url ),
}}}
The importance of this bug is twofold:
1. No clear workaround for the user, even with basic PHPMyAdmin skills.
The incorrect value is in a serialized array in the table 'wp_options'.
2. Users may not realize the feed is borked, since there is no Dashboard
UI. I think there used to be. The WP forums have several 5-year old
threads about it.
By the way, $num_items never changes by default. It could only be updated
by plugins or themes, and Solution 2 assumes they know what they are doing
there too.
--
Ticket URL: <http://core.trac.wordpress.org/ticket/20379>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list