timbonicus

Thanks Héctor, sorry to hijack the topic.

It appears that the “Post ID(s) to exclude” option is responsible for the mismatch. This gets applied in the outer where condition but not the sub-select. Some of the other exclusion conditions that get put into the where condition may be suspect as well (e.g. author).

I’m having a similar problem after the update to 3.2.0.

I have a widget set to show up to 5 posts from the last 30 days. It displayed 5 until the upgrade, now it only shows 3 posts.

The problem seems to be in wordpress-popular-posts.php, line 1652:

// ordered by views / avg
else {
  $from = "(SELECT postid, IFNULL(SUM(pageviews), 0) AS pageviews FROM {$prefix}summary WHERE last_viewed > DATE_SUB('{$now}', INTERVAL {$interval}) GROUP BY postid ORDER BY pageviews DESC {$limit}) v LEFT JOIN {$wpdb->posts} p ON v.postid = p.ID";

The sub-select has {$limit}, limiting the sub-select results to 5. Then the outer select only returns 3 from this 5. If I remove {$limit} from the sub-select and add it to the outer query, it works as expected.

I’m also interested in this change, Google PageSpeed recommends against content-blocking JavaScript (including scripts in the header).

A bit late to help Dominor I’m sure, but in case anyone else came across this post in a Google search like me…

The wp_posts post_date_gmt column is the scheduled date. It defaults to ‘0000-00-00 00:00:00’ which means ‘publish immediately’. If you have a draft with a scheduled date that you want to remove, update this column to the default:

update wp_posts set post_date_gmt='0000-00-00 00:00:00' where ID=<your post ID>

One way to find the post ID is to search by title:
select ID, post_date, post_date_gmt, post_title, post_status from wp_posts where post_title like '%Keyword%' and post_status='draft'

Where Keyword is something from your title.

Got it, the theme is using register_sidebar in functions.php and had an empty string for the before_widget/after_widget options. This overrides the default that adds an LI with a widget ID.

Sorry for the confusion!

I have some clues. The AJAX call works fine, but it’s trying to append the results to a jQuery object identified by $widget_id (‘#wpp-3’ in my case).

My theme renders widgets using the dynamic_sidebar function, which doesn’t seem to be setting widget IDs.

Thanks Hector, I think the Ajaxify setting will clear out the fake views. The sidebar widget doesn’t show anything with this enabled; I see it reported in this topic. Is the Ajaxify setting incompatible with the widget?

After some spelunking, I found that this was caused by a double-include of the Upgrader class in a theme file.

To be precise, Envato_WordPress_Theme_Upgrader from the envato-wordpress-toolkit-library was throwing an error “Cannot redeclare class Plugin_Upgrader”.

I switched to one of the default WordPress themes, performed the upgrade without any trouble, then switched back. Marking this as resolved.

Right, if the automated install had run into a snag halfway through I’d definitely be concerned about corrupt or incomplete files. It seems as though the process doesn’t even start with my installation.

Does the automatic installation produce a log file somewhere to record what it’s done? The wp-content/upgrade folder was created, but there’s nothing in there.

I’m trying to dig rather than give up and do a manual install; if there’s a genuine WordPress problem I’d like to uncover it to help other users. If it’s a problem with my environment I’d like to fix it rather than revert to manual installation for all future updates.