Hi Guy,
It seems I do not see the Facebook share button on the link you provided. So I proceeded to your EasyBlog backend to investigate.
However, in your EasyBlog backend, I am unable to click on any items in the menu. We suspect that this is due to a conflict with your cloudflare cache system. Is it possible for you to provide us with your Cloudflare access so we can investigate this? Thanks.
I also helped you move this ticket to EasyBlog>Technical Issues

Yes you're right. I've unchecked JS compression on CF. It should work now.
As far as the error is concerned, it appears to be something in the eb coding. Try duplicating the specific blog post and then delete the first block and you'll see it then works. At least it did for me.

If you still need access to CF let me know and I'll update my info under site details.

Cheers!

Hey Guy,

Try duplicating the specific blog post and then delete the first block and you'll see it then works.

If I'm not mistaken, do you mean after I duplicate and remove the first block in the post, I would not be able to share this duplicate blog post in FB(400 error)? If these are steps I need to take to replicate the 400 error, let me know so I can have confirmation.

I tried to edit a duplicate post to remove the blocks but unfortunately, cloudflare seems to be at play again as I am unable to click on the blocks and any button in the composer for that matter. Can you provide us your cloudflare access so we can investigate the issue more efficiently? Thanks.

Hi, CF is fixed. I've activated a copy and deleted the first block. As you can see from the screen dump it works. So what's causing it is in the first block so it can be fixed?
You'll also notice the text in the screen dump does not have spaces, the text runs into each other which needs to be fixed.

Cheers!
PS. I'm running the latest EB.

Screen dump

Hey Guy,
I think the cause of the issue comes from the alias of the duplicate post. It seems that when we duplicate a post, the new post will also use the same alias as the original post instead of changing its alias automatically. For example, /blog/post-1 to /blog/post-1 instead of /blog/post-1 to /blog/post-2
Since the alias of both the duplicate post and original post is the same, on the frontend, when we click the duplicate post, we are actually being brought to the original post because the system thought we are trying to access the original post.

In the case where the original post is unpublished, if we click the duplicate post in the frontend, we will hit the 404 error because the orignal post that we are being directed to is unpublished.
Now, as a super user, we won't hit this 404 error because super users are able to view unpublished post.
As a super user, inside the 'original post', when we click on the Share to FB button, Facebook will crawl the post.
While crawling the post to obtain post information, Facebook is acting as a guest user. Since guest users hit the 404 error because they can't view unpublished post, the same will happen to Facebook, thus we see the 400 error from the screenshot that you provided.

Now, the reason when you remove a block and save the post the error disappears is when we re-save a duplicate post, the alias of the post actually changes to create a unique alias. Since the alias is not the same as the original post, non super users and Facebook would be able to access the content of the duplicate content correctly.

Duplicating a post results in duplicating the alias as well instead of automatically changing them. This is a know issue and I will log this in our issue tracker so the devs can take a look at the issue.

In the meantime, whenever you duplicate a post, remember to re-save the post so that the alias gets changed.

As for Facebook og:description text formatting, unfortunately, there is nothing we can do about this. The opengraph protocol only crawls string text. It does not store html codes in it. You can refer to this link for reference.

Hi Raymond, Thanks for your explanations. I guess like you we're not happy with the text formatting that's submitted to Facebook. It simply does not make sense to present garbled hard to read text. There's no work around either so I guess the best alternative will be to switch share off in EasyBlog.
I'll investigate SourceCoast - opengraph - Facebook "Share"...

Now, the garbled text is also appears in the social stream and this of course has nothing to do with Facebook limitations.
Would you be so kind as to look at what can be done here.

Cheers!

Hey Guy,
The reason we strip html tags is because a truncation looks at a post in html view, which means including all html codes in the char/word count. Therefore, when truncating a post, 100 characters for example, the post will be cut off at the 100th character mark, html codes included, resulting in unclosed html tags which can cause potential issues.

It is actually possible to perform a hack to include html tags in the EasySocial stream, although I discourage this because future updates would revert the hack, requiring you re-hack the files.
Take a look at this screenshot and see if this is what you are looking for. This hack is not future proof, which means it could cause conflict with future releases of our products.
The post in the screenshot has a readmore tag, causing it to cut off at a certain part. A readmore tag is the only way to truncate posts if you use this hack because normal truncation methods have to be discarded as they strip html tags.
Also, your ES blog application Stream Settings>Content lengths to display in stream have to be set to 0 with this hack. Otherwise, post's html tags will be stripped.

Based on this information, let us know if you would like this hack to be done.

Hi Raymond, I'll need a few minutes to a hour or so to think through the consequences of what you've said here. In the meantime I'd just like to see we're actually on the same page and sure we know the extent of the issue.

I'll be back

Cheers!

Hi Raymond, You'll see from the screen dump that the Facebook Share does work. The stream works too. Okay the stream is not perfect but the text does not run into each other and much better and at a pinch acceptable. Albeit, I'd like to figure out and see truncating here.
The issue here lays clearly with the built in composer and has nothing to do with Facebook. Having said that I do understand it does have limited formatting. At least the screen dump shows it can be done.
You'll need to confer with Arlex as I don't wish to have you both work on the same issue unless you choose to of course
I did actually closed this ticket a while back but you answered anyway, which is course fine with me.

Cheers!

Thanks for your feedback, we will response you on another thread here.