millennial1

@jeherve – Thanks! That took care of the issue right away. If anything, regretfully that also removes image optimizations such as the top post’s typical square crop, but that’s something I can perfectly live with for now. I appreciate the help. Have a good one, guys.

Are the images in the staging site sourced from the live site’s domain? If so, that’s why the image CDN is pulling them from there.

If the functioning image in the ‘Top Posts & Pages (JetPack)’ Widget on the live site is, say:
https://i0.wp.com/millennialdiyer.com/wp1/wp-content/uploads/2019/01/Kawasaki-Ninja-300-Upgrades-List-Title-Thumbnail.jpg?resize=150%2C150&ssl=1

In the staging site JetPack assumes the image is at:
https://i0.wp.com/stagingsite.millennialdiyer.com/wp1/wp-content/uploads/2019/01/Kawasaki-Ninja-300-Upgrades-List-Title-Thumbnail.jpg?resize=150%2C150&ssl=1
Since JetPack hasn’t cached the images for the staging subdomain, those images are broken links. JetPack is on ‘Safe Mode’, but I suppose it’s still getting the sites URL from wp-config.php (which gets changed to the staging site url). In any case the images don’t display properly, and it doesn’t appear as if the CDN will simply index them later if given time.

Since what that specific JetPack widget displays is out of one’s control, I’m not exactly sure what approach would work to fix it from the user’s side, if any. I imagine I’m not the only one who has had this type of issue with a staging site, so I was hoping someone might point me in the right direction as far as what to look into to address it.

Thanks for the insight. At least now I know it’s not worth spending any time thinking about. Great plugin, by the way. Have a good one.

+1 from this. I was just doing a search, being in the same exact situation. I also found the same job in WP Crontrol.

I think the OP’s question is pretty much if it’s a superfluous/obsolete cron job that can be safely deleted, or if it’s there for a reason? Given that the action is empty, it doesn’t look like it’s doing anything even when it does run, so there isn’t any point to running it on a schedule. And it’s set to run once a day. I suppose that there’s little harm in leaving it as is, but things could get crowded or inefficient if too many plugins create cron jobs with no purpose. On the other hand it may just be the plugin not detecting the cron job correctly, and the job is indeed doing something. Anyway, it might be something worth giving a cursory glance to, just to see if it’s necessary to have it or not.

Just wanted to chime in and say the RC version of the update “broke” my site, too. Installing v1.7.1. fixed it, thankfully. I just finished going through a hosting migration so I thought the restoration was at fault. I’ve been sweating bullets for the last hour trying to find the broken code. I guess I feel a little better now knowing it isn’t anything worse than an unlucky buggy update.

I definitely thank you and appreciate the update! Nonetheless, fingers crossed this can get solved soon.

I’d be curious about this, too.

Hi @lizkarkoski

Thanks for the input. I had sent a CS email about this question I believe. Yeah, I saw that but didn’t think it would be a worthwhile solution here.

It would mean that if I had 100 pages and wanted to add related Posts to three pages, I’d have to enable Related Posts on all 100, and selectively disable one by one Related Posts on 97 of them just to get it to appear on three. As well as all future pages. It’s a lot more trouble than it’s worth.

It isn’t really worth the hassle if that’s the way it would have to be done. Thanks for the help though.

Hi there,

MillennialDIYer.com

Though I don’t see why that would be needed. It’s not so much a question about my site as much as a question regarding the snippet above (or whatever Jetpack officially endorses). Basically I’m just looking for what Jetpack suggests for removing related posts, but just for Top Posts.

Thanks @shazahm1! Regardless I appreciate the answer.

Yeah, I was aware of manually creating them. It’s just that that wouldn’t serve the usage scenario. Namely certain posts where you know you might need an anchor link in the future, but you don’t need it now and you don’t know which. In such case creating them all manually just in case doesn’t make much sense.

To be honest, it seems like a wasted opportunity for WordPress to not implement them automatically with headings. The internet would be so much nicer is people linked more often to the exact section in question rather than post a link and expecting you to find whatever they’re referring to.

Anyway, have a good day.

Thanks for the quick response.

@utz119 thanks. I guess that’s probably the generic answer I was looking for. Doesn’t seem ideal regarding user experience and image sizes, but it is what I was expecting.

@anevins I was curious about “default operation”, as in what would be the fallback method, so to speak. Like I said above, I’d be curious is WP’s default operation using a simple theme like twenty-seventeen.

Basically, I’m just trying to understand the underlying rationality in order to best pick image resolution and file sizes.

Thanks Andrew! That looks like it works great!

After playing around with it a little longer, I finally confirmed it was JetPack’s fault, as it was overriding the default box-shadow code:

.entry-content a img, .comment-content a img, .widget a img {
    -webkit-box-shadow: 0 0 0 8px #fff;
    box-shadow: 0 0 0 8px #fff;
}

I found that I could also solve it assigning it the !important tag, but I guess that’s just lazy coding. I imagine your solution is more “correct”.

Anyway, I really appreciate it. I’ll sleep better tonight thanks to you ??

Thanks @joemanna (I hope that’s how you quote a user here). I didn’t get notified of the response. I guess that kinda means that for the moment, there isn’t. Hopefully that Gutenburg build bridges the gap.

Do you have any link at hand where the functionality is shown or explained? I’d guess that would help give me an idea if it’s worth waiting for or if I should try to find another solution.