Jer Clarke

I’ve created a GitHub report for the plugin authors about this issue:

https://github.com/Automattic/facebook-instant-articles-wp/issues/878

Please reply there if you are experiencing it also.

Re-scraping shouldn’t have any effect. It controls Facebook’s cache of Open Graph metadata. That data controls how facebook shares look (the cover image, the title, the excerpt) but has nothing to do with Instant Articles.

(I did try rescraping the post I’m testing, but it had no effect on the out of date Instant Article version, as expected)

(I also tried unpublishing and republishing the post, also to no effect)

Instant Article data is sent to FB when the post is published, and stored in a different location from the OG data as far as I can tell.

Previously, whenever a post was re-saved, the data was re-sent, so all you had to do to update an Instant Article was save the post with new content.

For me this is NOT working right now. Nothing I do is causing the data to be re-sent, it’s stuck in whatever format was there when I first published.

This is terrible, and most users won’t even notice that their content is totally out of date, because they won’t check the Instant Article format (which is a pain to do for an old post even if you think of it).

Anyone else having this problem all of a sudden?

• This reply was modified 7 years, 1 month ago by Jer Clarke.

Thanks!

@wordpressme2 If you edit a plugin it can still be updated! The problem is just that your changes might dissappear.

So in a case like this, where the plugin is broken for everyone (which was clear from the forum) you can safely make the patch with the expectation that when the plugin DOES update, the fix will be included and you won’t have to re-add it.

If your change is to add a feature that the developer hasn’t agreed to add to the main branch (a situation I’m often in) that’s when you need to be cautious and re-do your changes after every update.

Thank you!

Okay, this seems to be the ticket to follow, seeing as it has a fix present. Definitely having the same problem. Also found at least two other threads by people with the same problem.

Can confirm it’s not 4.8, my 4.7.5 site has same problem.

NOTE: This shouldn’t affect the COLLECTION of data in GA, just the DISPLAY of the data in WP admin dashboard. If you are happy to just visit Google Analytics itself to view your data, you can happily skip the hassle of updating the plugin with the hack above/below.

Here’s my version of the code fix in case it helps anyone find the right spot in google-analytics-summary-widget.php / GoogleAnalyticsSummary->getSiteUsage():

	# Get the metrics needed to build the usage table
	/**
	 * HACK! Replace ga:timeOnSite with ga:sessionDuration to fix API 
	 * @SEE: https://www.ads-software.com/support/topic/not-working-with-latest-wp-2/
	 */
//	$stats     = $this->api->getMetrics('ga:visits,ga:bounces,ga:entrances,ga:pageviews,ga:timeOnSite,ga:newVisits',  $this->date_before, $this->date_yesterday);
	$stats     = $this->api->getMetrics('ga:visits,ga:bounces,ga:entrances,ga:pageviews,ga:sessionDuration,ga:newVisits',  $this->date_before, $this->date_yesterday);

Fixing the line starting with $stats = ... makes the box work again.

It’s worth noting that this still leaves the actual <b>Avg. time on site</b> statistic broken inside the box. For a full fix you also need to edit the <td> that displays the info.

The line you need to edit is in the same method as the fix above (GoogleAnalyticsSummary->getSiteUsage()) It looks like this to start (note it has ga:timeOnSite):

<td><strong><?php echo $this->sec2Time($stats->totalsForAllResults['ga:timeOnSite'] / $stats->totalsForAllResults['ga:visits']); ?></strong></td>

Fix is the same as above, replace ‘ga:timeOnSite’ with ‘ga:sessionDuration’:

<td><strong><?php echo $this->sec2Time($stats->totalsForAllResults['ga:sessionDuration'] / $stats->totalsForAllResults['ga:visits']); ?></strong></td>

DEVS PLEASE FIX THIS ASAP! Obviously it’s freaking people out and dramatically reducing the value this plugin offers ??

This was a known bug that should have been fixed already:

6.5.1

Fix depricated classname constructors.
Fix issue with being unable to deactivate and reset from settings screen.

If you haven’t updated try updating then resetting everything.

Sounds like this ticket is a duplicate of https://www.ads-software.com/support/topic/not-working-with-latest-wp-2/

Please reply there if the solution in replies doesn’t work for you. We’re all waiting for the plugin devs to fix it.

This ticket is a duplicate of https://www.ads-software.com/support/topic/not-working-with-latest-wp-2/

Please reply there if the solution in replies doesn’t work for you. We’re all waiting for the plugin devs to fix it.

I’m pretty sure one of the “clear” buttons in the old plugin did this, it’s very important!

When someone tells me they are stuck, I need a button to push to make them able to log in, without diagnosing their IP etc.

I don’t care about releasing any other locks. When there’s a false positive it’s vital that any admin can quickly reset the locks.

Here’s an example of what we see in our logs:

PHP Fatal error:  Uncaught Error: Class 'InvisibleReCaptcha\Modules\WordPress\GoodByeCaptcha' not found in /[...]/invisible-recaptcha/engine/Modules/WordPress/WordPressPublicModule.php:172

I just added my own fresh solution to stack overflow and the github for this plugin:

https://github.com/Automattic/facebook-instant-articles-wp/issues/321

Unfortunately I don’t think it’s something they can fix on the plugin side, you need to look at those solutions and create your own code to paste in the plugin setting for analytics code.

I just added my own fresh solution to stack overflow and the github for this plugin:

https://github.com/Automattic/facebook-instant-articles-wp/issues/321

Unfortunately I don’t think it’s something they can fix on the plugin side, you need to look at those solutions and create your own code to paste in the plugin setting for analytics code.

Here’s a PHP solution:

/**
 * Filter for Facebook Instant Articles that disables the featured image 
 * as "cover image" for all instant articles.
 *
 * By default FB uses the WP featured image as the "Cover Image" for ia, 
 * which shows above the headline.  * FB forbids having that image repeat
 * in the post, and especially when it's at the top of the post, it looks
 * terrible to have two copies in a row. 
 * 
 * This code disables the Cover Image entirely, and is useful if you 
 * usually have the featured image inserted at thetop of your posts so you
 * don't need the cover image. 
 * 
 * Note: This has no effect on the FB share display, which is driven by
 * the Open Graph og:image tag and not iA. 
 *
 * @param array $image_data
 *
 * @return array
 */
function 57_filter_instant_articles_remove_featured_image($image_data) {
	return array(
		'src' => '',
		'caption' => '',
	);
}
add_filter('instant_articles_featured_image', '57_filter_instant_articles_remove_featured_image');

• This reply was modified 8 years, 1 month ago by Jer Clarke.

FYI this github ticket (no feedback from plugin author) poses the question of how to disable the Featured Image->Cover Image relationship entirely:

https://github.com/Automattic/facebook-instant-articles-wp/issues/57

So far, I’m coming to the conclusion that if we want a “solution” to this problem, then that is what we are looking for, a simple way to disable the header Cover Image entirely (because you rely on images at the top of a post), or a more complex solution that removes them only when the featured image is the first thing in the post content.