Your comments
Thanks, Kevin. I had the same thought about the Trim for Web.
Robert —
https://www.24liveblog.com/ has a pretty good free live blog service. Just grab the embed code, drop it in an HTML or article asset and you're ready to rock. Forget playing with flags for creating a live blog experience. Just grab the iframe code from a live blog platform.
CoverItLive used to be my go-to but their pricing structure just doesn't work for me given that I only live blog on occasion.
Doing it how I'm suggesting gets around issues of caching.
Best
HML
That sounds like a good plan. We look forward to getting this type of control in place.
I'm going to upvote this. We use pannellum to embed via iframe 360 photos we published one today and that worked just fine. Having support for that would be great, being able to upload the photo in blox, as opposed to imgur or similar host. It doesn't kill my efforts to do these things if it's not in blox, but it sure helps. My 360-degree videos are hosted on youtube and I create youtube assets which work just fine.
Thanks, Christine.
Please let me know if your team has explored this. What it seems to me the problem is that there is a discrepancy between what we are passing to Facebook through the og:url tag and separately through the data-href property. And that the solution would be to pass the same information in both places, giving Facebook a clear relationship between how we are identifying the page and the comments data, which we are currently identifying as different entities.
If I got to a random page on my site: http://www.santafenewmexican.com/opinion/local_columns/skandera-snow-day-both-all-wet/article_fcfc74e3-f717-504d-85a9-ee4b6de4b559.html
The og:url property is:
| <meta property="og:url" content="http://www.santafenewmexican.com/opinion/local_columns/skandera-snow-day-both-all-wet/article_fcfc74e3-f717-504d-85a9-ee4b6de4b559.html" /> |
I can go in to Facebook debugger and verify it as such. Meanwhile the comments box identifies the same page using the permanent url: http://www.santafenewmexican.com/tncms/asset/editorial/fcfc74e3-f717-504d-85a9-ee4b6de4b559/ It seems to me that it's a case of mistaken identity and FB can't match the pages. I take your point about the name-in-url function. So, it seems to me what we want to do is output the exact same information in the og:url property as the data-href property with a different construction. To eliminate the changing variable of the title, we don't output it in this instance. The url construction for data-href and og:url should be [domain.com]+[article id]+[.html] instead of [domain.com]+[category]+[subcategory]+[articleid]+[html] In this protocol you could change your title as often as you like and it wouldn't matter since the og:url and data-href wouldn't be affected since the title doesn't appear. This doesn't change your canonical url for google and it still allows for Google to read the title via the <title> tag while allowing Facebook to read og:title for its purposes. I'm of course assuming that the Blox CMS can output a custom url for the asset. This would then identify the instance of the page and the instance of the comments box are the same. That would fill the gap in FB's identification. Right? Let me know your thoughts. HML |
Thanks, Christine.
Please let me know if your team has explored this. What it seems to me the problem is that there is a discrepancy between what we are passing to Facebook through the og:url tag and separately through the data-href property. And that the solution would be to pass the same information in both places, giving Facebook a clear relationship between how we are identifying the page and the comments data, which we are currently identifying as different entities.
If I got to a random page on my site: http://www.santafenewmexican.com/opinion/local_columns/skandera-snow-day-both-all-wet/article_fcfc74e3-f717-504d-85a9-ee4b6de4b559.html
The og:url property is:
| <meta property="og:url" content="http://www.santafenewmexican.com/opinion/local_columns/skandera-snow-day-both-all-wet/article_fcfc74e3-f717-504d-85a9-ee4b6de4b559.html" /> |
I can go in to Facebook debugger and verify it as such. Meanwhile the comments box identifies the same page using the permanent url: http://www.santafenewmexican.com/tncms/asset/editorial/fcfc74e3-f717-504d-85a9-ee4b6de4b559/ It seems to me that it's a case of mistaken identity and FB can't match the pages. I take your point about the name-in-url function. So, it seems to me what we want to do is output the exact same information in the og:url property as the data-href property with a different construction. To eliminate the changing variable of the title, we don't output it in this instance. The url construction for data-href and og:url should be [domain.com]+[article id]+[.html] instead of [domain.com]+[category]+[subcategory]+[articleid]+[html] In this protocol you could change your title as often as you like and it wouldn't matter since the og:url and data-href wouldn't be affected since the title doesn't appear. This doesn't change your canonical url for google and it still allows for Google to read the title via the <title> tag while allowing Facebook to read og:title for its purposes. I'm of course assuming that the Blox CMS can output a custom url for the asset. This would then identify the instance of the page and the instance of the comments box are the same. That would fill the gap in FB's identification. Right? Let me know your thoughts. HML |
Thank you Christine. I appreciate the response. I hope we can figure out something in this instance. I think we all appreciate the potential in being able to have the conversation happening in multiple places.
If I can be of help, let me know. I'm glad to see that we're on the same path regarding the urls.
Michael and Nick, if you fellas have any insight, please do share.
One question for Christine. By what mechanism is the permanent url currently being passed to FB. When I look at the source code, I don't see references to the "permanent" url there (unless I missed it of course.)
—HML
Customer support service by UserEcho
I hear what you're saying. I hope you might then make this a site-enabled feature wherein we can opt-in. This really is one of those features that any modern CMS should have, especially in a collaborative environment. I'd really appreciate you giving this serious consideration.