Maybe I’m not forming the question well because I got nothing useful using search for some reason. Sorry if this is common knowledge that I’m not aware of. I don’t wish to multiply menus or menu types. I want the blog seamlessly integrated so as to appear a natural part of the Discourse experience.
I would like a Permalink next to the About that would reveal the WordPress Blog in Discourse clothing. Some hack that pulls the automagically generated WP Pages and populates a submenu like that of the About.
Make some provision for WP Catagories, and Tags? And Discourse entirely replacing WordPress Comments on Posts. The WordPress Admin would remain the same.
One other related design issue is my intention to create a multi-step registration using a WP Forms plugin. Again I don’t want anyone aware they are in WP, and later when logging in or out I was to lock the login to either just Discourse or just WP and hide the other login not in use.
We strongly recommend against this type of heavy use of iframes. They are intended for ephemeral snippets of content, nothing more. You’ll get into SEO issues and all sorts of other problems if you abuse iframes like this.
For visual cohesion you are much better off re-styling your Discourse navigation to match that of your WordPress blog: Brand header theme component
Not to play out the threadbare “Argumentative,” i.e., Angry Black Woman trope (again), but define “heavy-handed”? Would this require more than a single iFrame? If this is a sin then why, or is this like the church where I my questions are far from appreciated and I get answers that are uninformative criticisms?
Since proactive SEO tuning has zero currency in our application, can move on to point me at the Discourse Man. section that expands in detail on “abuse” of iFrames? I am problem-oriented, so if and when, a technical inhibition restricts the employ of sound design principles, I am more accustomed to addressing that as an engineering challenge.
Complexity beyond utility. I didn’t toss my proposal out for comment without research and deliberation. Introducing a second navigation tool to accommodate the ‘temporary’ use of WordPress and then replicating that model to other Federation community sites is not a road I intend to go down.
I need a solution that does not depart from the clean simplicity of the Discourse UI/UX design.
I have a user perspective on this. Unless I have misunderstood what you are trying to do, I expect that I would hate to have to use what you are proposing.
Any blog that I find useful will always entice me to follow the trails to other useful material (blog posts or links) and then I will find stuff that I want to share with others. The iFrame solution is only really suitable for small “snippets” that I will never want to navigate from or link to.
I lose too much basic functionality and utility every time a developer has the “great” idea of putting a website in an iFrame. It is usually done for expediency while discounting the impact on the user experience.
I appreciate that you are trying to be helpful. However, a single person’s anecdotal experience doesn’t contradict hard data on how people experience and use interfaces.
Trying to make the case that adding a second menu that behaves differently in form but essentially is accomplishing the same task to address a page that visually should not appear any different than the “About” is not a design logic you want to champion.
To aid in providing context, I find this to be an excellent quick explanation; your results may vary.
make that two, or consider me as not anecdotal because my opinion is based on documentation. Even if you work out CORS issues, there’s more to consider
… Because each embedded browsing content created by <iframe> is itself a complete document environment, every use of <iframe> within a page can cause substantial increases in the amount of memory and other computing resources required by the document overall … you should keep the potential for performance issues in mind. …
Accessibility concerns
People navigating with the aid of assistive technology such as a screen reader can use the value of a title attribute declared on an iframe to determine what embedded content it contains. … Without this description, they may have to navigate into the iframe and browse around to determine what the embedded content is. This context shifting can be a confusing and time-consuming process …
IMHO as long as there is unifying header navigation, common color palette, common fonts, you don’t need to strive for “identical looking” only “associated looking”.
In fact it could be argued that you are doing visitors a favor by having subtle differences. Just enough so they’ll know “I’m at the same site, but a different part of it, the UI will be this here”.
@Muiren, I feel your pain. You’re in trouble here for two reasons:
Reason 1: technical
From a UX perspective, separating a community web site from its discussion system is an aberration. In a bright future, web sites and discussion platforms will be accessible as components, which you can mix together to design an integrated experience. But we are far from this at the moment. Your web site is probably a monolithic pile of spaghetti code (did I hear Wordpress?) and Discourse is a monolithic platform.
You are suggesting using iframes to combine them. It is technically possible. In fact, lately, I have spent quite some time doing precisely this. But, like others have mentioned, it is very difficult, because iframes have not been designed for that purpose.
Reason 2: political
People here won’t help you with this. Possible reasons are:
They see no possible positive outcome (because of the technical challenge I’ve mentioned) and think it’s a waste of time.
They have “made a virtue of necessity” and will defend the monolithic approach.
Discourse is a commercial product whose source code is open. To charm “serious customers” despite the “open source” label, Discourse marketing strategy is to promote an “opiniated” approach. A direct consequence is that alternative use and experimentation are discouraged.
I don’t entirely agree. Opinionated, yes; stifling experimentation, no. There are many people here experimenting with Discourse in all sorts of ways (just browse the plugin category!) Certainly the Discourse team themselves will focus work on what actual customers want, but I don’t get the impression they dissuade experimentation.
In this case I think this is more likely:
Hasn’t come up in this topic yet so worth mentioning — there’s already a great WordPress plugin, WP Discourse, built specifically for connecting the two platforms. It’s used by many many sites and a ton of time has already been spent making that plugin work to solve not only SSO but things like:
See:
I think the main takeaway is that 99.99% of the time it doesn’t make sense to reinvent the wheel (whether by shunting a whole WP site into an iframe on Discourse, or something else) when there’s already a very good way to connect the two in a more robust way via this plugin and SSO.
Sure it may be technically possible to do it another way, but what Erlend’s getting at is that there are already much simpler solutions that are well established and battle tested by many sites. Doing it a totally different way would mean spending lots of time building a custom solution, with not much obvious benefit.
If someone doesn’t yet have an established WP site or just really doesn’t want to deal with configuring integration between multiple platforms, another possible way to go would be to just use Discourse itself to fulfill the function of a blog platform. People have definitely tried that too and discussed on Meta; one example here: How to enable your community to use Discourse as a (micro) blogging platform
@Muiren You are welcome to use Discourse as you like – @erlend_sh was simply giving you advice. We do that if we think someone is making a mistake because we want all Discourse communities to succeed if possible. I agree with his advice.
@jack2 Your take is a little strange and completely incorrect. We define our product roadmap based on common feature requests. Feature requests from our hosted customers get more priority but they don’t change the roadmap in any other way.
Our intervention isn’t required here. You are welcome to hack your own Discourse instances in any way you see fit. Note that if we have advised against it, we won’t support you to fix it when it breaks.
