acleach

My feed usually updates around 6:30pm daily, but I haven’t found where this is set or triggered.

Or at least, it did until yesterday, when that didn’t happen. A manual refresh today now shows “There are no items in this feed.”

Sigh. I guess Facebook has broken the plug-in again.

@noddemix No, it means they’ve just broken it again by putting an unapproved version live.

It should be possible to have a development process where a version is approved before being released for the community to use, but this “Still in development” seems to happen with depressing regularity.

Pity, because this plug-in does everything I want, except for this behaviour.

No: there are no further issues with Facebook videos. I should have returned to this and marked it as resolved (which I will do now).

Thank you for your attention here.

Thanks for the update.

I changed the option to “Do nothing” (which caused entries to do nothing) and then back to “Redirect to Facebook” and it appears to have worked: clicking the still image now opens a new tab for Facebook. Hopefully, now that it no longer uses the admin-ajax.php call it should also fix Google’s issues.

I’ll mark this as resolved once Google have confirmed all is well with their indexing.

I have found the “Reset cache” button which works and causes new posts to be collected from Facebook.

It would be really helpful to know how the plugin schedules its own refreshes.

If I can interrupt here again, I’ve done some investigation on my thread.

This is Facebook, not Instagram, and the library file is WDW_FFWD_Library.php.

The token issue appears to be caused by requesting the deprecated fields. I’ve removed all the deprecated fields from the request in WDFacebookFeed.php and I no longer have a #12 error, nor is the token invalidated after each request. Removing them one at a time caused the error message to change, referencing a different deprecated field until they were all removed. However, I can’t get refreshed data stored by the plugin, so the feed displayed in the widget remains out of date.

OK. I believe I’ve found what to do with $description and the other deprecated fields and it looks like this will fix the token issue (that is, trying to fetch deprecated fields caused the token error).

Removing the all deprecated fields from the request to Facebook no longer reports an error, nor does it invalidate the token.

I’ve amended how the deprecated fields like $description are set from the retrieved data, using the ['attachments'] array as described in the Facebook deprecation notice, and no errors are reported.

However, I still can’t get new data from Facebook — the wp_wd_fb_data table is not updated. Clicking Reset cache on the Options page shows “Success”, but nothing is stored. This may be because the Facebook type has fundamentally changed with the deprecation and how it is set at around line 817 of WDFacebookFeed.php needs to be reworked: it’s got more complicated.

• This reply was modified 3 years, 6 months ago by acleach. Reason: Found the deprecated fields in the plugin code

@kimabaghdasaryan You’ve asked elsewhere for someone to alter plugin code and check database values. I’m happy to do that if no-one else is confident to do so: but I’m using the Facebook feed and I don’t have framework\WDILibrary.php (I have WDW_FFWD_Library.php) nor an option “wdi_instagram_options” (all my options start “ffwd”).

However, it’s not just the Facebook authentication token which is the issue, but also the deprecation of the description field. This would appear to be defined in line 737 of WDFacebookFeed.php, and $description in line 884 needs to be extracted from the attachments array. Removing “description” from line 737 means the error is not reported, but of course without the Facebook token, data cannot be retrieved. I’m not familiar enough with the API or your code to work out how to extract the description from the attachments array, which I can see is included in the request.

@virtualtopia The plugin page https://www.ads-software.com/plugins/wd-facebook-feed/#description currently shows v1.1.34 was released three weeks ago. I would expect a new version to change that.

Link to affected site — the developer’s own: https://demo.10web.io/facebook-feed/ View the “Tablet” version.

It appears that the plugin is attempting to get the “description” field using v3.3 of the API. That field was deprecated two years ago, although the documentation implies it should still be available until August. A new version of the plugin would have been required then. It seems that Facebook have either brought the expiry forward or started to warn explicitly of its impending demise, and the message isn’t handled well. However, I gave up on trying to understand the Graph API ages ago, and now rely on plugin developers!

That doesn’t obviously explain why access tokens are also expiring immediately, though.

I’m very happy to add that prompt support has identified an issue with the theme(s) I’m using, so there’s no cause to dock a star at all. In fact I’d add one if I could for the support which is offered!

Many thanks for investigating!

The difference in behaviour between phone browsers (which don’t cause an unresponsive theme to respond) and desktop browsers (where it does) is a little surprising, but you’ve given me a steer as to what to look at. I’ll certainly consider adjusting the theme, but that will be a long-term project, I think.

The workaround of using a 35-day list in the mobile theme will do for the moment.

Intriguing. If I resize my desktop browser window, the calendar changes to a list. But on my mobile phone, I can’t trigger that when using “desktop” view. Either the browser is “intelligent” enough to preserve the layout, or my mobile screen is not small enough to trigger the change. I suspect that the browser is actually misreporting the screen size.

Using the mobile theme, the page does attempt to show the list rather the grid, because I get the “Hide past events” link. It must be a theme issue, and it seems likely that my mobile-friendly theme (which it is; Google likes it!) is conflicting with, or just can’t cope with, what’s going on with CSS in the plugin.

Thanks for looking quickly! You can run the mobile theme on a full-size screen and the desktop theme on a mobile-size screen by using the switcher icon at the bottom of the page. It sets the fdx_switcher querystring as shown in the links below.

These links should help, and will force the theme used, overriding the sniffing. Unfortunately there’s a <display:none> inserted from somewhere on the first link. However, link 2 (grid using desktop theme) should presumably degrade on a mobile device to the list view.

Grid view using mobile theme: https://eastbourneordinariate.org.uk/calendar-3-2?fdx_switcher=mobile
Grid view using desktop theme: https://eastbourneordinariate.org.uk/calendar-3-2?fdx_switcher=desktop

List view using mobile theme: https://eastbourneordinariate.org.uk/calendar-3-2-2?fdx_switcher=mobile
List view using desktop theme: https://eastbourneordinariate.org.uk/calendar-3-2-2?fdx_switcher=desktop