Hi, krausing. Thanks for the feedback.
Could you provide some more information about the issue you’re having? That will help us investigate this further the issue.
To your 1st question, could you clarify what is meant by the “Facebook debugger” in this context?
Regarding your 2nd question, to clarify: are you saying you’re experiencing that hours after saving one of your WordPress posts and having it be published as an Instant Article to Facebook, that creating a post within Facebook with a link to your WordPress post generates a 404 error? Could you share a sample link?
Thanks again!
Hi again
I think it is solved now 🙂 But how come there is no content inside the two latest Instant Articles now? I have not changed any settings. If I look at the third last there is content inside it.
You can see two examples here: http://imgur.com/a/BRNRg
Aargh, and unfortunately I still have the problem that I have to debug each article through https://developers.facebook.com/tools/debug/og/object/ because it saids there are no content at the site before the URL is debugged 🙁
Paulo,
I’m having a similar issue. I submitted several posts to Facebook, and after reviewing them, I received a message that “all text is included in every article when compared to web” (see screenshot below).
View post on imgur.com
I assumed the Instant Articles for WP plugin would add the required tags to my posts.
John
I’m replying here because I’m having the same problem that krausing was describing at the beginning. I’ll try to explain it a little better: if we publish a post in WordPress, we find the corresponding instant article in our page publishing tools, and that’s ok. But then, trying to share a link to the article results in a 404.
After using the Facebook Open Graph Object debugger (https://developers.facebook.com/tools/debug) and fetching new scrape information everything works, but it’s very inconvenient.
Sorry about the double post, I’ll add this: it seems to me like the plugin is pushing the instant article to FB before the post is actually completely published, so that the Facebook scraper ends up with caching a 404 page. Hope this helps.
I had the same issues but when I updated to 2.9 and delete old articles in app queue the problems were resolved.
I’m using last version of WP, 2,9 WP Instant Articles, php 7.0
I’m already on 2.9, I’m going to try deleting old articles and see if that helps, thanks.
Meanwhile, I also noticed duplicated instant articles: one instance appears when the post is published on WP, the other on update. I looked them up in the Graph API and the first one is registered with a wrong canonical url. I still think the plugin is posting articles before WordPress is done publishing. I’ll let you know.
I can say the same, drafts on WP are also published. I test it some minute ago.
I am also seeing drafts being submitted to Facebook Instant Articles when using the feed at /feed/instant-articles.
I am seeing the same thing. post drafts are being submitted to Facebook before being published. Every article needs to be run through the debugger and re-scraped manually after being published.
I’ve been looking into this for a couple of weeks now. Today I found out the most probable reason for this: it’s the Instant Articles meta box in the post edit page.
I monitored my server’s access_log, looking for visits from the FB crawler. When you open a draft for editing, that meta box asks FB for the status of the final canonical URL of the post, and a visit from “facebookexternalhit” pops up; the post is still unpublished, though, so it ends up as a 404. I removed the meta box in my functions.php file like this:
remove_action( 'add_meta_boxes', array( 'Instant_Articles_Meta_Box', 'register_meta_box' ) );
remove_action( 'wp_ajax_instant_articles_meta_box', array( 'Instant_Articles_Meta_Box', 'render_meta_box' ) );
And the unwanted early visits have gone. I’ll let you know if this actually solves the problem.
The issue where “draft” articles were published to Facebook was resolved in v2.8
I suspect the earlier issues pointed out by @johnscotthaydon and @krausing were also related to similar problems where empty content was being published. Release v2.11 appears to have resolved all remaining cases were articles were unexpectedly published (with empty content).
Thanks for all your feedback. I’ll mark this thread as “resolved” since the initial issues appear to have been fixed in the latest version.
@aioros, your latest comment is interesting. Depending on what you find, perhaps open a new thread to bring focus to that particular case. And if/when you do, could you post a link to it here in this thread?
I’m still seeing this happen to all of our scheduled articles on version 2.11.
