Hi all,
I was using gallery 1.4 on my PHP-Nuke powered portal and it works fantastic. But I came to a point where I needed to use my portal groups to control access in side gallery. I learned that this feature is in gallery2. I downloaded and installed gallery2 and it works great. I was able to import my albums from 1.4 and all. It also appears as a link in the "modules" block in PHP-Nuke. Clicking the link to the module, however, takes me outside PHP-Nuke and directly to the gallery. How do I integrate gallery2 with PHP-Nuke?
Thanks all.
Posts: 7994
We have not yet written a G2 integration for any CMS' yet. We'll do one for PHP-Nuke when we get the chance, but it probably won't happen for another couple of months. If you can find a developer resource who wants to work on this, point him or her our way!
Posts: 32509
Does phpnuke(7.3) really lack of user groups?
I've installed phpnuke to see how difficult it would be to integrate.
It has something called user groups, but there's no user<->group mapping table. But each group and each user has a "points" field. I guess you'll become a member of a group automatically when you've reached the points level of the group, right?
So we could use the user and group table of phpnuke and use the user_group table of G2.
Perhaps the developer of the Gallery 1.x phpnuke integration / the guy(s) from http://www.nukedgallery.net could write the phpnuke module for G2.
What's the plan, write a general integration module + plugins or write for each portal/CMS/... a specific one?
Posts: 7994
I'll point Dari at this thread and see if he has any input.
My feeling is that we should start with the simplest integration first and work our way up to the harder ones. We've got time and we can continue to restructure things as much as we need to, so let's not tackle too much complexity at first.
I don't know whether it makes sense to write one module or many, so I think we need to do a few by hand quickly (hardcoding whatever changes you need to right into the code) to get an idea of the scope of the changes involved before we throw together a framework.
Posts: 32509
How do we handle cross module db queries?
All modules are allowed to query data from the g2_user, g2_group and g2_usergroupmap table.
Now what if a CMS we want to integrate with doesn't have the same architecture?
i.e. xaraya doesn't store the prefered language in the "user table" but in other tables.
i.e. xaraya doesn't have a user and a group table, it has a roles table with a column "type". all users in the roles table have type=0, all groups have type=1.
For the integration, we can derive the classes GalleryUser, GalleryGroup or GalleryUserGroupMap and create our own queries, so all G2 API calls to get user/group information will work.
if there are direct db queries from other files than GalleryUser, GalleryGroup or GalleryUserGroupMap, i.e. from other modules that rely on such a query, what do we do?
DatabaseStorage.class translates every db query. we could parse if the user/group table is involved and make the query a little more complicated on the fly.
same for the language field. if the user.language is involved, we must a) translate the query and b) translate the returned value for language, as the CMS uses other language codes.
does this sound too complicated?
an easier solution:
lang problem: - add a column "g2_lang" to the roles table of xaraya. i guess i'll do that anyway.
user/group: - use the roles table only for users and use g2_group and g2_usergroupmap for everything else. not very satisfying...
but the databasestorage layer should have a value translator anyway as different CMS surely store the prefered language in the user table in a different format.
Posts: 7994
For joining against the user, group and the user<-->group tie table I think we should be ok with most CMS's since they almost definitely have some table with a primary key for those two tables, and they should have something similar to the user<-->group tie table. If they have something more complex as it sounds like Xaraya has then we can either beef up the query translator as you mentioned, or we can try to create and synchronize our own tie table. If Xaraya has an event model somewhere that we can tap into so that we can synchronize our copy of the group table whenever they make changes to it then we might be ok.
Either way, we can extend GalleryUser to make XarayaUser and override the load method so that we read the entire object from the Xaraya tables instead of the G2 ones. We may need to do multiple lookups to get all the information we need if, for example, the language information is stored in some other table. As long as we're overriding the load method, we can do whatever database operations we want in order to get the data. We can do all of that without even using the DatabaseStorage layer since we can use the Xaraya database object, or their API or whatever means they make available to us to get info from their data store. Does that make sense?