Embedding without embedding?

khalwat

I ended up choosing VanillaForums for a client in part because it looked like it would embed nicely into the existing website. The website is using a CMS system (ExpressionEngine), so being able to embed it was attractive.

Unfortunately, using the "Embed Vanilla" in VF 2.0.18.10 causes a number of things not to function very well, including:

-- The Who's Online plugin count no longer seems to work
-- The Quotes plugin doesn't auto-scroll to the reply box when you click it
-- The CLEditor malfunctions badly with run-away resizing

...and so on and so forth. These problems go away if I go to the non-embedded URL for the forum, but then I lose the ability to integrate the forums visually with the CMS system and website.

So is there a way to embed the forums without embedding them in an iframe? I realize I can add whatever HTML I want to the header/footer, but that doesn't allow me to use the CMS system with it.

This has to be a pretty common scenario. Is there something I'm missing here?

meshugy

I tried embedding v 2.1b2 for a while and never had a problem with the Who's Online Plugin. But in the end, my developer decided to reskin the default theme to match my site as there were too many issues with embedding (a lot of problems with different sorts of links and other integration issues.)

khalwat

I wouldn't mind reskinning it -- we've customized both the main and the mobile themes quite a bit already.

The issue is that the rest of the site uses a templated CMS system to generate things like the header, menus, footer, etc. I don't see any way that could be dumped into a Vanilla Forums theme?

vrijvlinder

That is what I always recommend people to do. And it surely can be done. If you go to meshuguy's website you can't tell that the forum is another app.

I also made my forum and blog all have the same header and footer they look like the same place.

I do it for people all the time, it really is possible to make it match identical. It is much better than embedding it. You won't be sorry, just give it a try....

Roben

iframe problem is that it works with just a static domain! for example, the below places take one address in user browser, that is the address you've embedded your forum.

Signin, Registration, Activity, discussions...

@vrijvlinder said:
If you go to meshuguy's website

so, where is that? Is it this: http://www.djangobooks.com/forum/

I also made my forum and blog all have the same header and footer they look like the same place.

Link, please?

khalwat

@vrijvlinder said:
That is what I always recommend people to do. And it surely can be done. If you go to meshuguy's website you can't tell that the forum is another app.

>

I also made my forum and blog all have the same header and footer they look like the same place.

I do it for people all the time, it really is possible to make it match identical. It is much better than embedding it. You won't be sorry, just give it a try....

So just as an example, the CMS system handles people's logins (among other things). The login name appears in the menu at the top of the page, which, if I skin the forum as you're suggesting, I'd need to somehow roll my own and integrate into the CMS itself to obtain the logged in user's name.

That's a small example of the issues that lead me down the path to embedding it rather than attempting to skin it.

Thanks for any insight you have, I'd like to figure out a way to offer a better forums experience.

hgtonight

@khalwat

Every approach to meld two different systems will have its drawbacks.

Embedding is quick and easy, but you open a large can of worms that come in the form of potential 'odd behaviors'.

Skinning is more time intensive, but you keep the underlying code separate and save on some server crunching (don't need to initialize two frameworks on every page request). The biggest drawback is in you lose the ability to customize the header and footer from your CMS software.

As for your example, assuming your are using SSO, you already have the user's name on the vanilla side. Adding a link to the CMS user profile is pretty simple when you have that.

tl;dr in my experience embedding is seductive but rarely affords the experience one hopes for.

khalwat

Skinning is more time intensive, but you keep the underlying code separate and save on some server crunching (don't need to initialize two frameworks on every page request). The biggest drawback is in you lose the ability to customize the header and footer from your CMS software.

Well, it shouldn't be that bad, really. I can just grab the rendered HTML from the CMS, and with some modifications, use it on the forums skin. The only real conditionals are whether the user is logged in or not (we present different menus in that case.

As for your example, assuming your are using SSO, you already have the user's name on the vanilla side. Adding a link to the CMS user profile is pretty simple when you have that.

Right, I thought of that... if they aren't logged in at all, we don't want them accessing the forums at all, but I'm sure I could work around that as well.

tl;dr in my experience embedding is seductive but rarely affords the experience one hopes for.

Extremely well-said. I was seduced, but she's not marriage material, imo.

hgtonight

Don't get me wrong, I find Vanilla to be the easiest forum I have ever skinned.

Especially considering most people just want to change the header or footer.

khalwat

I took your advice and un-embedded the forums. So worth it. Many of the problems went away.

Thanks for the input!

chanh

I start to see something odd from time to time so I might end up doing the same.

khalwat

Tip for folks attempting the same... to get the logged in user's name to appear in your default.master.tpl file, use this Smarty variable:

{$User.Name}

The only thing I haven't quite figured out is a way to conditionally test whether they are logged in or not, and display different things in those cases.

But the benefits in terms of lack of weird problems, being able to use CLEditor, etc. far outweigh that.

hgtonight

@khalwat I'm going to just leave this here:

http://vanillawiki.homebrewforums.net/index.php/Using_Smarty_with_Vanilla

khalwat

So useful. Thank you!

chanh

PHP is the most efficient template in itself so I don't really understand why there is a need to use anything else and have to deal with caching issue and file permission, etc.

hgtonight

@chanh said:
PHP is the most efficient template in itself so I don't really understand why there is a need to use anything else and have to deal with caching issue and file permission, etc.

Separating out the template into a different language helps keep application logic out of your presentation templates. Then syntax is super simple for those only familiar with markup languages.

As far as being efficient, smarty compiles into PHP, so there is no performance hit after the first render.

That said, you aren't required to use smarty templates.

chanh

Thanks goodness for that!

chanh

Just a follow up on this Smarty issue.

This is the kind of issue that cache or Smarty will run into very often.

Smarty error: unable to write to $compile_dir 'c:\inetpub\wwwroot\Garden\cache\Smarty\compile'. Be sure $compile_dir is writable by the web server user.

hgtonight

@chanh_ong said:
Just a follow up on this Smarty issue.

This is the kind of issue that cache or Smarty will run into very often.

Smarty error: unable to write to $compile_dir 'c:\inetpub\wwwroot\Garden\cache\Smarty\compile'. Be sure $compile_dir is writable by the web server user.

I don't understand your hostility toward Smarty. It seems like you take issue with anything that manipulates files. Your configuration changes are also subject to file permission errors. Set up your folder permissions properly and it will never complain.

chanh

I am not "hostility", I am just point out that any form of file cache will likely to cause other problem and create many needless issue.

I see lot of people encounter "fatal" error issue due to file cache.

peregrine

@chanh_ong said:
I am not "hostility", I am just point out that any form of file cache will likely to cause other problem and create many needless issue.

I see lot of people encounter "fatal" error issue due to file cache.

but that could be resolved by a simple readme in the core installation. that lists folders that need special permission, and an explanation of how to resolve a bonk error. But then the forum wouldn't be so busy.