Clear All Cache causes Feed to stop displaying

Hi there, I just stumbled upon the same issue - is there any workaround in the meantime?

Hello, same issue here, clearing all caches doesn't work anymore. I tried on a fresh install, with a different instagram account, no feed either. I haven't found any workaround for now.

Confirmation. The same issue.

Same issue here.

For me, it's simply because the response returns to the redirect page (and not to the user page https://www.instagram.com/username/ --> https://www.instagram.com/accounts/login/) so there is nothing to display.

As it's probably due to a restriction from Instagram when the rate limit is exceeded scrapping their content I would recommend turning to an API oriented solution.

If you log yourself on Instagram on the machine using this module it should probably work back for a time. Using a proxy will also work.

But none of these solutions are long terms solutions.

The API limit should not be an issue if caching is enabled, because then the API is only called if the cache for cleared and you can control that with settings for the block.

However, we saw a related error end of last week, where the requests replied with a http code 500 which then brought down our whole Drupal site. The attached patch is preventing that from happening.

Rerolled the patch so that it also work even though the module is not compliant with coding standards, e.g. white space in the original code.

I agree with your caching analysis. The issue is when your IP got blacklisted from instagram (because I think that's what happening here), then there is no way back (at least I don't know for how long they blacklist you)...

Also if you have a VPS it makes it easier to be blacklisted.

Re-rolled the patch again because the return type needs to be array and not bool, see also #3105915: InstagramWithoutApi::build() needs to return array

One option might be to add some JavaScript that would fetch the data client-side in this scenario.

#9 applied fine, but nothing shows up in the block :-(

I'd suggest the following addition to the code:

1. In PHP, if the response from Instagram doesn't include anything useful, add the relevant info in Drupal.settings, and a JS file
2. In the JS file, make the request and populate the block

I observed this on a site hosted on GoDaddy, so the IP address is probably on a blacklist.

Because it's being done client-side, it's unlikely that the browser would be on the blacklist.

If I get time, I'll work on a patch for this, but if anyone else can work on it, that would be great.

Same issue here. Local environment works fine. Production environment suddenly stopped displaying the IG feed. I can think of nothing else then IG blocking scrapers after a while.

The provided patches are not related to this topic, but still thank you. You might want to open another issue for the exception catching.

Here's a patch for the Drupal 7 version that adds the client-side behaviour suggested in #12

This issue is resolved in the 3.x rewrite as part of #3250550: Placed Block does not render any HTML

The original crash was caused by the strpos/string-slicing approach used to extract window._sharedData from Instagram's HTML. When Instagram returned a redirect or login page instead of profile data, the parsing produced undefined or garbage output and the block broke entirely.

The 3.x branch addresses this in several ways:

• Graceful failure — build() now returns a translatable error message rather than crashing when Instagram is unreachable or returns unexpected data.
• More resilient data fetching — the module now uses Instagram's web_profile_info JSON endpoint as the primary source, with the HTML scrape kept as a fallback. This is less prone to being redirected.
• Persistent local image cache — images are downloaded to public://instagram_without_api/ on the filesystem. A Drupal cache clear only triggers a fresh Instagram API call, not a re-download of every image.
• Configurable cache lifetime — the block respects its #cache['max_age'] setting (default 24 hours), so Instagram is not hit on every page load.

The one scenario that remains outside the module's control is Instagram temporarily blocking a server IP due to rate limiting. In that case the block will display a "Could not retrieve Instagram posts" message until the restriction is lifted — a clean degradation rather than a fatal error.

If you are on the 3.x branch and still seeing this behaviour please open a new issue with details.