System for embedding Phorum in other applications (early preview)

You're right about deleting users Wendy. If that has to be done, it should be done from the master application's user registration. It cannot be done from the connector class, since there on-the-fly synchronization is only done if the user himself is coming by. As a matter of fact, all synchronization tasks could of course be done from the master application's registration process, so the on-the-fly trick is not a mandatory part of the connector. Whether that can be done depends on how much you can change the master application's software (e.g. through hacking the software or by writing plugins).

What you could also do is send active=0 for the user that is deleted. That deactivates the user within Phorum. But what I will do is add some functionality to the usersycn lib for deleting users.

For groups, I think it does make sense to be able to send a list of groupnames along with the synchronized user. For easy of use, this does not have to be a separate function. My view on this is that it can simply be a list of groupnames that is put in the userdata that is sent using embed_phorum_syncuser(). Does that sound like a good solution?

---

Maurice Makaay
Phorum Development Team
my blog linkedin profile secret sauce

Deactivating may be a better option if a user has some posts rather than actually deleting them from the database (same sort of problems as with changing a user name).

It really shouldn't make too much of a difference if group membership is controlled by syncuser or a separate function. Whichever is easier (it sounds like syncuser would be and it keeps everything together).

sync group is a good thing to have.

how would phorum know if the user in the master app is no longer there?

Unless phorum has a function call that allow the plugin in the master app to call phorum to deactivate user when user account was remove or unless the embed mod do a complete user account sync each time but that will not be efficient if the user list is huge.

In any rate, it really does not matter whether the user in embed phorum need to be deactivate or not because phorum does not take the user login directly to phorum any way so it really make no different.

[opensourceCMS.com]
[ongetc.com]
Chanh Ong

The master application can load the right files to be able to call the Phorum API calls for deactivating and/or deleting users (the same kind of tricks that are used in run_phorum.php can be used for that). I can add some code to the usersync lib to make it easier to use the lib directly from the master application.

chanh mentions one important issue here and that is that not allowing a user to login into the master application (by deactivating or deleting the user there) automatically prevents the user from accessing Phorum. However, you might want to deactivate the user in Phorum, to disable profile viewing for that user. And a reason for deleting users in Phorum might be to allow usernames to be recycled in the master application.

Some thoughts in general on this

Looking at it, the whole user management thing comes down to the following two possible synchronization methods:

1) From the connector class when a user logs in, you can add/update a user from the user_get_id() method.

2) From the master application, where you can add/update/deactivate/delete a user.

Option (2) was what I had in mind for my own site, but then I realized that option (1) was cool too. Whether you need options (2) at all depends on your own user management policies. Implementation of option (2) means that either the master application must have a plugin system of its own that makes this possible or you have to hack its code to add the Phorum calls. Implementation of option (1) should always be a clean solution.

---

Maurice Makaay
Phorum Development Team
my blog linkedin profile secret sauce

edit user, disable or remove from phorum while it is running as an embed phorum could be done but it will require maintenance. For a busy site it might not be feasible!

[opensourceCMS.com]
[ongetc.com]
Chanh Ong

Quote
kevwit

Quote
chanh
Now we are in business! I am wonder how could I go about customizing the template.

Where could I find some resources on tips to do that?
What is the entry point of your embed template?

Thanks

Browse over to the templates forum. Check out dissurion's martha_with_settings template. [www.dissurion.com] Basically almost every page has an html template. Phorum's template stucture is very powerful (uses {VAR} syntax so no php needed - similar idea as some php cms systems) and the only disadvantage that I see is there is so many template pages.

A big key to making things go smoothly for you is using the css.tpl file to setup css. Also settings.tpl. This is why I recommend you compare dissurion's version to the default template.

Keep in mind that the header.tpl and footer.tpl simplify things a little because they are constant on every page.

I believe one of the dev team has started a documentation file for templates. It is located under the development section (wiki).

Thanks for the tips! This will help me get start.

When I view the post it push my right column out since it is bigger then the center column should be. Which tpl should I look at and how do I make it smaller or not to push my right side out.

Thanks again!

[opensourceCMS.com]
[ongetc.com]
Chanh Ong



Edited 1 time(s). Last edit at 02/12/2006 08:42PM by chanh.

I'm in the process of building a completely new template, because I have the same problem as you and because I want to have a template that holds up in limited space. The right column being pushed out isn't something that is easily fixed in one spot. There are more pages that do this. What might work is limiting the width of the <div> that is around the whole Phorum code (in header.tpl, something like PDDiv), but I never tried that.

If you like what you see at [mambo.gitaar.net] then you can wait for my template too.

---

Maurice Makaay
Phorum Development Team
my blog linkedin profile secret sauce

Dear Maurice,

I'm a developer from the Gallery 2 project (http://gallery.menalto.com) and I've designed the embedding approach for Gallery 2 in the past 1.5 years.

I'm glad to see that to see that you've chosen a similar approach (loose integration) and I like the concept of having the integrators only implement a single Connector class plus the actual page.
We have a synchronization api ready for the initial user synchroniation which works the same way (single class to implement), but our main embedding approach just offers an API which can be used by the integrators. Principally the same approach as your Connector class.

Do I interpret your integration correctly that you do all synchronization on-the-fly? We offer this as a low-tech fallback solution.
But since more and more CMS / frameworks and even blogs offer events / hooks, our preferred / high-tech solution is event-based synchronization. Users are created, updated, deleted, logged in, in Gallery 2 right when it happens in the master application.
Maybe that's something you also want to look in to. I'm about to document our event-based loose-coupled integration. I wanted to do that 1.5 years ago, but never found the time to do it.

Some concepts of your integration approach are definitely something we want to offer in Gallery 2 too. Some of them are used by plogger and other applications, and I think they make sense. E.g. integration by simple function calls.

Brian Moon contacted Gallery to discuss about general interoperability in September 2005, we have answered immediately but never heard something back.
Is this embeddeding module of yours the result of this initiative? Is there something else going on?

Kind regards,
Andy Staudacher - G2 development team

This embedding module that I'm writing is not a result of this initiative. I started the project mainly, because I wanted to run Phorum embedded in my own website. I figured that it would be very useful if I could come up with a solution that was more widely usable than only on my own website. Brian's initiative had more to do with authentication I think, but maybe he can fill in the blanks here.

The fact that you are seeing on-the-fly user synchronization in the two example connectors so far (gitaar.net and Mambo) does not mean that is is the preferred method for it. It would only be the preferred way for systems that do not offer event-based synchronization features. For other systems, event-based synchronization would be best (it saves some database calls, which is always good and you have better synchronization because deleted and deactivated users can be sent to Phorum right away). So I think that our ideas on this are the same (I feel very comfortable with the low-tech / high-tech terminology that you use to describe this ;-).

For gitaar.net, I will eventually put the synchronization in my website framework and the on-the-fly syncing will be stripped from the connector class. It's mainly in there now because I wanted to try out if this was a possible way of handling synchronization. See also this message where I outlined some syncing options.

The API for syncing users from master application events to Phorum will also be in the syncuser.php library. That library is not specific for writing on-the-fly synchronization from the connector class.

---

Maurice Makaay
Phorum Development Team
my blog linkedin profile secret sauce

Thanks for your answers.
I hope we can establish this approach of event-based loose-coupled integration for integrating web applications and thus get more and more CMS / frameworks to add events / hooks to their application and thus are ready for integration with dedicated applications like phorum or G2.