In your first screenshot, you have all the paths set to publish to the uncategorized category. If you want to publish all posts to the same category you only need to create one Embeddable host record.
The Path Whitelist values that you have added to your Host entries might be causing problems. You can leave that value blank to publish all posts from your blog site that you’ve added the Discourse embed script to. If you want to set a specific path to publish to a Discourse category, the path should end with
/.*. For example
The double slash at the start of your
/t/newsletter-discussions/105 path may be a problem. Also, that looks like the path to a Discourse topic. If set, the path should be the path to a grouping of posts on your blog. The purpose of the Path Whitelist setting is to allow you to publish posts from a specific path on your blog to a specific Discourse category.
Ok thank you Simon, I appreciate it. I will give this a shot.
Like @codinghorror, I also use this DIscourse integration with Ghost using the stock configuration which uses the absolute URL as the
A week or so ago, I decided to change my Ghost blog’s routing so that posts with URLs like
https://engineerworkshop.com/2020/02/20/how-to-set-up-wireguard-on-a-raspberry-pi/ are redirected to
https://engineerworkshop.com/blog/how-to-set-up-wireguard-on-a-raspberry-pi/ being the new permalink.
You can probably anticipate the problem this creates: the discourseEmbedURL is set to the old URL and so when the embed script is called, which now has a different URL, a new comment post is created in Discourse.
Solution Attempt (Which Failed)
Now, prior to this, I had anticipated this problem, and so I thought I was being clever using a regex pattern with remap to fix the URLs:
While that did “sort of” work, wherever the URL was used in the original Discourse comment post, sadly, when I loaded the blog posts, new comment topics were created in Discourse.
Ultimately, I just reloaded every post on my site and transferred comments from the old topics to my new topics, deleting the originals (I know, I know). Obviously killing pages is bad for SEO, not to mention end-user experience.
I assume the reason my regex patch attempt didn’t work is because the Discourse topic is somehow keyed to the URL on the backend. (I readily admit to being ignorant of Discourse’s data structure). For future knowledge, and anyone else that may attempt to do the same in the future, is there a way to remap a DIscourse topic to a new blog post URL?
Thanks in advance!
7 posts were merged into an existing topic: WP Discourse Embed Plugin
I love this feature as I have many magazine-style content sites and I can auto generate the topics into our forums but is there a way to get the URL preview working like it does normally in Discourse?
So instead of this:
More like this:
If you have the link on a separate line by itself it should Onebox.
Then have your entire description line below, including the link, as you show in your first image. That will appear below the Oneboxed link.
Hmm… well that’s a bit of a problem as the page itself is what is being previewed. So putting a link at the very top of the page HTML or article text is kinda problematic. Here is the page in question:
Hi folks. I’ve almost got this working, but realised that the use case I had in mind looks like it may not be as straightforward as I had hoped, and I am not sure how much additional work is involved.
I’m hoping to use this feature to power discussions on a site that is based around user generated content. I have no issues with the embedding of comments, or getting SSO set up and ensuring my users automatically become members of my community with the same emails, usernames, etc.
What I was hoping is that, when a new piece of user content is created on my site, that the user who published it becomes the author of the related Discourse post, not a single user as defined in the “Username for topic creation” setting of the embed feature. I won’t be allowing signups outside of my current signup process so I can be 100% sure that the Discourse user will already exist or, at least, can be created at that time we create the new thread.
Hopefully it’s obvious why I’d want to do this. ie. the content creator would then be the discussion’s OP on my Discourse site and could be automatically subscribed to the thread and notified of replies, their posts highlighted so as to stand out from other comments, etc, etc.
Any suggestions on where to start?
Your use case is certainly not supported out of the box in Discourse and would require some custom development. I’d look at plugin development or hiring a consultant to help you implement it.
I would add to the Troubleshooting that if Discourse is not able to parse the content of your page/blog post in order to create a new thread, the embedding will fail (and no hint about it is given). Try embedding a specific topic first, then try to leverage the options for parsing your page.
This is great! The only hiccup I have on this is that I can’t determine how to use the correct CSS selector to pull the
meta-description in to use as the first post.
I have tried several iterations like this. Any suggestions?
If you are trying to pull in the content of the
meta tag from your site’s
head section, I don’t think it will be possible.
I am still lamenting that this won’t simply do a one box for the link provided in the embed vs. doing a more fancy import of text and potentially images.
Surely for sites with complex page data/layouts someone must have thought of a scenario where the topic was a placeholder for discussions and also a way to refer people to the remote site with the article/story?
So we are looking at implementing this on some blogs and articles on our main site and using the forum. When I was in a meeting this morning my marketing person said it was a bad idea because each post created on the forum would look like duplicate content with our blog because they have the same title and show the same first paragraph. He showed this with a google search from the example. Is there something built in that helps to show Google that these are not duplicates or could you put a no index on these posts?
Hmm, that’s interesting, because if we added
noindex then the comments wouldn’t be indexed either which is not ideal. Is there a way of telling google “this part of the page is a duplicate?”
We could apply that to the OP.
This was actually my concern when we discussed this. I don’t want to hurt the SEO value of the Blog however, I also don’t want to hide the forum Q&A because that is at times just as big of a draw as some of the blogs. I am not sure of a way to tell google index this part and not this part of a post.
Discourse has an
embed set canonical url site setting. When it’s enabled, the canonical URL for embedded topics is set to the embedded content’s URL. Would this help to improve the duplicate content issue?
It sounds like this would help with the issue. Any chance you know someone who is using this feature just so I can see and share an example?
Another option here would be to add “Comments on ______” to the beginning of the discussion title.
That’s a tricky one, because I can’t share details about our customer’s sites. There are some more details about this issue in this topic: Add option to set canonical_url to embed_url. I’ve asked in that topic to see if anyone wants to provide details about how enabling the setting has affected their SEO.