Working Integration with PostNuke

leason

Hi all, I posted a good while back talking about integration with 3rd party systems. The one in particular I am interested in is the PostNuke CMS. I know everyone here has mixed feelings about such systems, but they have a large audience and can make life easier if used properly, much like a condom. I am redesigning one of my postnuke sites and I absolutely hate the integrated forum solutions. I wanted to use Vanilla instead, and have it share user information with the CMS. Mark said to wait, but I decided to give it a shot anyway. So this morning I got it working. Right now if you register in the CMS you are automatically registered in the forum - you show up as a waiting user. So the admin still has to approve you. This could easily be tweaked though. The other thing I need to do is figure an easy way to share other user info like first and last name. Lastly, I need to make Lussumo use the CMS username and not allow people to udpate it. The good news is that so far the only file I've had to touch is the Vanilla.User.class.php file. If anyone here is interested in how to pull off such an endeavor, let me know and I'll share the steps. I know that Mark had mentioned an overhaul in the future that would make such integrations easier, but I needed something sooner unfortunately. Anyways, great job on the code structure Mark. It only took me about three hours to get it working. I'll post a URL once I get it skinned and the rest of the details worked out.

leason

By the way, the good news here is that after getting into the code I can see ways to abstract much of the hard coded settings and column mappings. So if you want me to try and pull that stuff out into a config file that would make such integrations easier (into any CMS, really) then let me know and I'll try to do that too. This way you could drop a vanilla install over any Mambo, Xoops, or PHPNuke installation and it would use the user table available rather than the Vanilla user table.

Mark

Yes, please do. I'd love to see how you did it.

leason

Okay, I'll try to clean it up and post up the code sometime today or tomorrow. I've run into a small issue and realized that the other classes don't use the User class... they also have hard coded references to the user table columns, so I may end up having to update the other main classes - definitely the discussion class at the minimum. From a high level though, basically what I did was add the lussumo user columns to my CMS user table (the names did not conflict). Next I brought in the rest of the lussomo tables, unchanged with the same LUM_ prefix. Next I went through the Users class and looked for references to the UserID column. Any place I found such a reference I modified the DB object and removed the table prefix. Then I updated table references and added the prefix back. Then I pointed the DB object at my CMS table (nuke_users) rather than the lussumo table (user). After I got all those references fixed, I basically did the same thing for the password column. PostNuke also uses md5 encryption, so that worked fine with no other modification. From this point I was able to register an account in PostNuke, log into Vanilla as admin and approve the new account, and then login and post on the forum with the PostNuke account. I also syncronized my postnuke admin and lussumo admin accounts, so they are one and the same. More details and code to follow.

Minisweeper

For everyones sake i'm just gonna double check now that you're working with one of the 0.9.3 versions?

Mark

I realized a week or so ago that I'm going to need to be able to specify a different name for the user table for precisely this purpose. I think I'll make that change before 1 comes out.

Mark

You're lucky that the vanilla user table's columns didn't conflict with your user table's columns. I wonder how is the best way to handle that in the future (in case there are conflicts)?

leason

minisweeper: Yes, this is 0.9.3 Mark: Yeah, I was very lucky! Otherwise I'd have to go through the whole app to point at the correct columns. The best way I have ever seen this type of thing handled is with a chat application called Chat Blazer. They have a rather large XML document that maps an internal name for tables and columns to a physical database name. So you have a parent node representing a table and then child nodes representing columns. Each node has two attributes: internal name and external name. The great thing about this setup was that with their system, you could map to any valid database object. So instead of mapping hte internal users object to a table, you could map to a view. This opens up a huge amount of possibility. It also completely unplugs your application from the data storage. It does add some overhead, but you can cache the information or even serialize it as a native PHP object. If you did that, it would only really add a tiny bit of overhead. To me, it would be worth the cost in resources to have the flexibility. So you'd have to rewrite your classes to use the abstracted layer. Instead of saying: $s->SetMainTable("User", "u"); you would do $s->SetMainTable($DB_Abstractor->GetTableName("User"), "u"); or something like that.

Minisweeper

deja vu.

leason

Has someone already done this mini?

Minisweeper

No. I just remember someone talking about using an xml go-between in the dim and distant past.

leason

Yeah, I think that was me... http://lussumo.com/community/discussion/1198/ But as an open source developer myself ( http://pnflashgames.com ) I figured maybe I could help out and see if it could actually work before I sent Mark on a wild goose chase.

Mark

Yeah, I remember talking about that with you before.

I still don't think I'd go the xml route. I might instead just add another appg file that contains an associative array of key -> column and key ->TableName pairs.

leason

Yeah, I think that would be more than sufficient. ChatBlazer went XML because it is a Java app and they did not really know what platform or environment the end user would be working in. For something like Vanilla, a PHP config file would both meet the need and minimize overhead.

Mark

I guess I'll do that while I wait for the guy doing xhtml to stop playing geometry wars.

leason

lol, here is the map I just made. Let me know if this structure will work for you. I decided to use two arrays rather than one big one. http://pnflashgames.dev.sourcekit.com:88/vanilla/appg/database.html Just save that as a PHP file.

leason

With that you basically use two functions to access your DB information: <code> function GetTableName($sInternalName){ return $_TABLES[$sInternalName]; } function GetColumnName($sInternalTable, $sInternalColumn){ return $_COLUMNS[$sInternalTable][$sInternalColumn]; } </code>

leason

Hey.. I'm taking a step back from this. I have another idea. With this current way of doing it what I think I'm going to do is update teh SQLBuilder classes. Im going to modify the methods such that whenever you add a field, add a join, set the main table, or do anything else, it is going to use the incoming argument to lookup the actual database name and use that in the query. This means I should just have to modfiy the sql builder and add in this config and it will work. I'll let you know how it goes. Btw, sorry to turn your forum into my own personal blog on this project.

Mark

haha - np.

I was thinking the exact same thing. The less work, the better.

leason

Wow, well I got something going here. I'm kindof amazed. Be aware, this is really early and I will need to do lots more before this is ready, but with a relatively small amount of changes I've got this thing working. Take a look at this page to see what is happening: http://pnflashgames.dev.sourcekit.com:88/vanilla/ What you see here is the original SQL from SQLBuilder printed out. Then it gets passed to a preprocessor function that pretty much does a find and replace to map internal names to external names. The neat trick here is that in order to pull this off I had to keep track of what tables were in use. I do that with an internal property on the SQLBuilder called AliasMappings - that is how I keep the thing from using the wrong column (in situations where two tables share column names).

leason

Btw, I have not updated the SearchBuilder class yet, so searches will not work yet.