Unless I'm misunderstanding what you're talking about you can already do that with the "Preview" tab seen here...

This leaves the image alone in the story but crops it whenever it's loaded as a preview.

Ours is still there.

Here's a video of this problem. We can replicate it across multiple computers but Town News support hasn't been able to replicate it.

Here's the issue...

It also happens on these sites across a variety of browsers:

richmond.com

galvnews.com

tulsaworld.com

lodinews.com

And I'd be willing to bet it happens on tons of other Zen sites. So do any of you have the same problem?

Nice! Thanks a lot!

So setting "Impressions: x; Per: y" does nothing but stop the ad for that time period once it reaches that number?

So if I have three ads and an average of 10,000 pageviews per day(just an example) and two ads each need 3,000 per day, one needs 4,000 the best way to do that is to set two ads for 30% and the other for 40% within that ad position, right? And each day do I just have to monitor the ads to make sure they're getting the impressions and adjust the percentages if one is straggling? That seems like a LOT of time spent making sure ads are delivered correctly.

We really need clarification on this because it's become a huge problem as our advertising department has moved toward impressions vs. exclusivity based on position. If we've got several ads in one position that run for several months and an ad that runs for a few days, what will ensure the limited ad gets all the impressions it needs and give the other ads less priority? Is it best to set the ads with the long duration to monthly impressions and the limited ad to daily impressions? Right now the system seems to struggle to give the limited ad enough impressions.

Basically, Facebook says that the first time someone shares the page, they may not see the image because of asynchronous loading (this may happen more frequently to newsrooms where they are often posting the content themselves and looking right away to make sure it worked).

This is likely the culprit, at least in our case, because it explains exactly what's happening with having to rescrape the page.

Maybe they could give us an option to display more than 25 results with the understanding that the search will be slower. This would alleviate the sting of having to batch edit and adding more than 25 child assets(or at least child assets spread out over multiple search pages).

That's been my experience too. 25 items at a time. Click next tab. Next 25 items. Next tab. etc.

You just have to make sure your blocks' query rules are set up to pull the new section tag.

I was told

Facebook will only update their cached image every 30 days. By submitting this to Facebook and telling them to rescrape the story, you're cutting out the default caching time.

But we're not talking about old stories. Unless Facebook scrapes it as soon as we post it but before we attach a child asset I don't know why it's cached the story without the correct image.

I just don't know why it's SO inconsistent.