Invision Board + G2
|
Shadow_Wolf
Joined: 2004-04-03
Posts: 181 |
Posted: Fri, 2005-03-11 05:39
|
|
The original project for integration was a bridged version during G1 and IPB 1.3 here: Since then Gallery has been completely re-written with G2 and Invision Power Board rewrote their board with version 2.0.3. So none of the old bridging for the member database work anymore. So we're basically going to have to start from scratch. 1. Create a bridge between G2 member database and IPB member database. This is probably best done by just utilizing IPB's member registration for the creation of members. Then in the instances in G2 where it would normally call upon the g2 tables to instead point towards the IPB member tables. 2. Test the bridge, usergroups and membergroups to make sure no errors. This would result in multiple installations as well as testing of each feature to not only test G2 functionality but that alterations haven't affected G2 or IPB in some unforseen method. 3. Once there has been a bridge created and tested. Then the next step would be to create a layout/skin that would seemingly integrate G2 with IPB similar to how their own gallery system is integrated. Those are the main steps at goals of this project that I will try to undertake to the best of my ability. My understanding of G2 and the newer version of IPB 2.0.3 are still newer than most veterans. However an integration like this I believe is more possible with how G2 has been rewritten. Most of it should involve just rewriting or basically pointing items to look at a different table instead of where it would normally look. Let me know if I'm going about this in the wrong direction and if there is an easier method, please. I'm sort of going on logic and theory based on php and mySQL programming for the most part right now. From what I can tell in the mySQL table there are at least two tables which will need to be cross-referenced if I am understanding things. Permission for albums are obtained from g2_PermissionMap which matches the g_userid with the g2_user table and g_id of that member. Since all it is matching a userid that part should be comptable with IPB database since it also has its own id.
Gallery Tables Used:
g2_PermissionMap
- g_userid
g2_user
- g_id
- g_username
- g_fullname
- g_hashedpassword
- g_email
- g_language
IPB Tables Used:
ibf_members
- id
- name
- legacy_password
- email
In parts of G2 where it would normally check for g_id it would instead look at ibf_members at id. Then g_username instead look at ibf_members name field. The password I believe is g_hashedpassword which can match up with ibf_members legacy_password. And that leaves g_email to match with ibf_members email. I'm not sure though if g_language would effect anything since I really only care about the English aspect. However those fields could also just be added to the ibf_members table so in all areas where items would normally query or insert into g2_user, it would just put them into ibf_members. We would also probably have to add a g_fullname field to the ibf_members table since there isn't a matching field for that as well. A modification of this type would probably only be recommended on fresh installations of Gallery. Otherwise those gallery databases with member information could create an issue if bridged if the id's it looks for don't exist or someone else's member uses that id already. I'm tired since it is really late here for me but I figured I'd post my intial ideas. If any G2 gurus can let me know if I'm on the right track or idea and point me in the right direction to help out, let me know. Thank you. |
|
Posts: 32509
As you ask, let me tell you that we intended it a little differently.
If you follow the CMS Integration topic in the dev forum (IMO this IPB integration is a dev topic too), then you will see that there's a fundamental difference between what you describe here and where we have gone with G2 <-> [any application] integration.
In late summer/fall 2004, I did something similar what you describe with G2 and xaraya, let's call it tight coupling/integration. I replaced all SQL queries in G2 that had something to do with user/group tables. I translated most queries on-the-fly in the db abstraction layer of G2 and those queries that were incompatible with xaraya, were translated by hand and replaced in the user/group helper functions.
It worked, but it called for major changes and quite a lot of work for each new integration. I guess we elaborated more on this topic in the CMS topic.
Then we decided to examine a new approach where the two applications wouldn't be altered in their core functionality, where things were done with glue code and some hooking. We call this approach loose coupling/integration, leaving the core files of the two applications untouched. The difference to tight coupling is obvious.
In most cases, you want to integrate G2 into an existing website/solution. You want to integrate G2 in a CMS, or in a forum or a customized solution. So, the other application is assumed to be at least equally powerful concerning user/session management and has thus at least equal rights. Actually, G2 is the slave and the other application the master in this relationship.
Take a look at docs/EMBEDDING and embed.php (GalleryEmbed). What you do if you integrate G2 with another application is to replace the entry point of G2 (main.php) with a new file which you have to create. This new entry point is part of the other application. And a request goes like this:
1. Browser request index.php?module=gallery2 (just an example)
2. Other application handles session/auth management, parses GET/POST variables and redirects the request to the new G2 entry point.
3. The new G2 entry point includes embed.php from G2 (GalleryEmbed = embedding API, a G2 API subset).
4. You call GalleryEmbed::init(some configuration, activeUserId = ..., ...) to load/start G2
5. Call GalleryEmbed::handleRequest(); to handle the G2 request and receive the returned html for html body and head
6. Paste the returned html into templates of your application or print it out.
So much for the normal request. As you see, G2 doesn't start the communication. Your application always initiates the request because we assumed that calls for less requirements on the other application.
That's why user registration/login is disabled in G2 when embedded. You register/login in the other application. In step 4, the activeUserId is passed to G2. G2 knows that activeUserId is authenticated by the other application. All what G2 does is check the g2_externalIdMap table for a mapping of the externalUserId (activeUserId) with a registered G2 user. Then it loads this corresponding G2 user and from this point, everything works like a ordinary standalone G2 request.
The tricky part of this loose coupling apporach is the synchronization of users and user data. I said, that we deactivated login/register in G2. So, all we have to do is tell G2 when a user is created/updated/deleted in the other application. When a user gets created in the other map, G2 should get notified and passed the user data upon which G2 creates a corresponding G2 user and creates a mapping of the userId of the other application to the userId (entityId) of the corresponding G2 user. Update/delete are analogous. Central is the point, that G2 needs to be notified.
In very modern CMS, you can not only create modules, you can hook your functionality into core code/function. Core functions like "create user" of the CMS. This most often works by the use of events or hooks. Similar to G2, you can register your module as a listener to the "create user" events and every time a user registers/gets created, your code gets notified/activated. In this hooked function, you could call GalleryEmbed::init() and GalleryEmbed::createUser() each time you get notified of a new user and analogous functions, when when a user gets deleted /updated.
Advantages of loose coupled integration:
+ API level integration, no SQL required, no dependency on SQL level. Quite no projects guarantees backwards compatibility on the db schema level, there's a cause for APIs etc.
+ Files of G2 and the other applications stay untouched, no changes required to the vanilla distributions. Just get G2/the integration code/the other application and you're done. You can always upgrade to the newest version of G2 or the other application and or less dependent on a third party, the integration developers.
+ The integration developers don't have to "fork" G2 or the other project à la phpbb for *nuke CMS etc. There is far less code to write and to maintain.
We understand that this events/hooking isn't possible with a lot of other applications and we are on the search for solutions for these less powerful "partners". The simplest solution would be to just alter the core code, hack a call to your synchronization functions into these core functionality.
Solution for user creation for applications that don't feature events/hooks:
- Don't synchronize user creation at all.
- Just call GalleryEmbed::init(array(...,activeUserId => $ipbUserId)); as if you assumed that a corresponding user exists in G2. If no error is returned, this user exists in G2 and you can finish the G2 request with GalleryEmbed::handleRequest().
If an error is returned (missing object), you know that this user doesn't exist in G2. Then you first call GalleryEmbed::createUser() to create this user/mapping in G2, then you call GalleryEmbed::login() and finally you can handle the actual request by GalleryEmbed::handleRequest();
But what about user data creation / user deletion?
- Periodic synchronization executed as a cron command or manually executed.
- Hack the core code of the other app
- Open for your ideas
If you don't want to disable user registration / authentication (login) etc. in G2, then you don't have to. G2 issues events whenever a user gets created/modified/deleted and you could create a G2 module that listens to these events and synchronizes in the other way with another application.
Posts: 181
Ok I have been reading through CMS Integration topic for awhile now, definitely a lot to absorb. The more I read the better I am understanding things. Just to let you know though a lot of it is over my head, I can understand the concept but the actual implementation is different. It took me awhile to understand what CMS or API meant. LOL! Feel free to move this to Dev if you believe it to be more development than customization, I wasn't sure where I should post it entirely.
If I understand the process correctly. When modifying the database entry points and queries in both IPB and G2 it would be what is called a tight coupling. By utilizing the preferred method of just writing an entry point that calls upon both, without serious modification to code of G2/IPB we are using a loose coupling.
1. IPB database is imported into G2 database. Membergroups since both use permissions based off of membergroups as well as member ids is assigned. So that if G2 gallery becomes standalone, users, etc aren't lost although I won't personally have to worry about G2 becoming standalone it will stay integrated with IPB.
2. Registration is turned off in G2. Utilizing embed.php it calls upon IPB to authenticate/register members. IPB uses cookies so in essence it is checking for the cookie session, if value is 0 then it determines it as a guest giving guest permissions. If userid = something else then matches it in its database. So I need to increase the session timer to be twice as long as IPB so that while in G2 it won't time out.
The issue though is what to do when a new user is created/deleted. Since login/register is disabled in G2 and G2 systems still point to their databases, the G2 database doesn't receive the changes from the IPB database. It could be done with a Cron job but personally my server tends to have issues with Cron jobs. In most aspects one only needs to worry about user permission if that person is able to create album, delete photo, add photo (possibly need permission to make comments). Typically not all registered members would need the permission to create/delete photo/albums. So perhaps the best method would be to have a script that would query IPB database, check/verify with G2 database and then insert/update missing items. When the admin see's he needs to set access to a member that hasn't been created in G2 then he/she just runs script. The script would also be able to be called upon with a cron job for those that want it to run automatically.
But that brings up a question so maybe I'm not understanding the process entirely. How are changes made to member permissions by an admin? Disabling the register/login, doesn't that disable the admin panel or is that still functioning? Maybe I answered my own question, it would still have to be functioning then and since G2 functions haven't changed access is still assigned via that method.
Am I off base or at least understanding the basics?
Posts: 32509
You understand the everything good.
@Permissions:
G2 permissions are still managed in G2, even if it is embedded. Everything you can do as G2 admin in standalone mode, you can still do as admin in embedded mode. The only difference is, that you can disable the login/Register capabilities in G2 when embedded.
I'd handle permissions on group level as long as possible. Only use user level permissions in G2 if it is absolutely necessary.
The group "All Users" in G2 = all registered users = all IPB registered users is quite important as well as Everybody = Guests, registered users, admin, well everybody.
@Groups:
Keeping IPB and G2 users in sync' is quite straightforward. Synchronizing groups too, is sometimes a little tidious. Xaraya was special in this case, because there were some incompatibilities (i.e. subgroups of subgroups, ... tree vs. flat structure and admins are in the all users group in g2, but are not in the all users group in xaraya, ...).
So, i'd start with a basic project, just synchronizing users and embedding G2 visually. Then move on to groups, if necessary.
@Sync' user creation:
IMO the best solution for applications that don't have hooks/events is creating users on the first G2 request.
And delete/update users in G2 periodically if there are no hooks/events.
@Authentication/Sessions:
You don't have to code anything for this. The new G2 entry point / wrapper just has to be called in IPB at a point, where the user is athenticated. Just pass the IPB user id as activeUserId in the GalleryEmbed::init call to G2. And if it's the guest/anonymous user, pass a null as activeUserId to G2.
Take a look at the existing integrations, the xaraya one is the most complex and most complete integration to date.
Posts: 181
Where can I take a look at the programming done with Xaraya? Is that just by going through the CMS Integration post or is there someplace else I can find the information?
Posts: 32509
you know how to checkout gallery2 from cvs.
instead of checkout gallery2, write checkout integration and you will get most existing integrations.
Posts: 181
I have never been able to get access to sf.net cvs to work properly. I get to the point of key generation and it says to updated my public key in their maitenance page but there isn't a place to do it. I should have my linux system up in a couple days, I might have an easier time trying to access it via there instead of trying to go through WinCvs.
Posts: 32509
integration, from cvs attached.
Posts: 181
Ok I've slowly gone through the Xaraya integration, some of it I get and some of it is still over my head however I think I have a basic understanding of at least what needs to be done. Now getting it done properly is another story. LOL!
Initial Integration Outline:
1) Install IPB 2.0.3 as stand-alone.
2) Install Gallery 2 as stand-alone. Disable user registration and set G2's session timer to infinite.
3) Setup up user-groups in Gallery 2 to match the usergroups in IPB 2.0.3. In my test I will be having the following user groups.
4) Run database sychronization script. This queries IPB database, then creates members accordingly inserting them into G2 database.
Authentication/Sessions:
Sessions are set as infinite. We will be utilizing G2 through index2.php which is using embedding script. The user is authenticated and handle through IPB. When they go into G2 if they are logged in then the IPB user id is passed into G2 through the entry, if activeUserId then it determines permissions based on group/user id that were already set in G2. If it doesn't return an activeUserId it is treated as guest.
Sync' Groups and Users:
Users and group permissions are still handled through G2 and setup through G2 Site Admin. There are probably a couple way to sync users. The easiest would be through a script that queries IPB database, then inserts into G2 database however it would have to be run manually. You could use a cron job to do it automatically though not very effective. The best way would require modification of IPB files so whenever a user was created, deleted, password changed then that update would kick off script to insert data into G2. It could be setup inside IPB but trying to do the least amount of modifications to IPB files and rely more on a module or 3 group of files for interface.
Graphically I have completed and worked out a method for G2 to work with just IPB. Currently mine is working in conjunction with IPB and my Portal system though, however the skin that I'm designing to use with G2 will work outside of the Portal but simulate IPB's gallery looks like.
Unfortunately I don't see a method of integrating G2 without doing some modifications or editing to IPB files. Of course this means any updates or installations of IPB will require them to be done again. However most updates and modifications will most likely occur with G2 than IPB so having a method that requires no modifications to G2 is a must.
Is there a list of all G2 functions and their use, that a typical G2 user would have access too somewhere? I don't really have to worry about writing anything that would call upon things done in Site Admin since that can be done manually in G2, although at some point I'd like to make an interface to go directly into IPB's Control Panel.[/]
Posts: 32509
- really consider to not sync groups. syncing groups is tidous and doesn't have many advantages. what about syncing only users?
-
i don't really understand your intention. however, there's the G2 API docs, see the devel link on the bottom of the left side menu of this website.
Posts: 15
do you still have to pay for invisionboard 2?
Posts: 32509
see http://www.invisionboard.com/act.ips/download?subc=splash
Posts: 25
Any news on this intergration?
THe invision gallery is shocking.
I'm willing to donate to help this get along.
Posts: 25
is this dead?
Posts: 181
I have been moving everything over from my test site to my actual site. Other than user integration (which is being handled by someone else and should hopefully be completed soon) visually Gallery 2 was integrated into my portal/website.
Test Integration w/ portal/website
Gallery 2 Test
I upgraded to the latest release of Gallery in my move. I've noticed there were a few changes at least made to embed. So using the same files that I originally had no longer work. Currently you can see it is duplicating the gallery.
New Gallery
Here is what I have for my file in Gallery to handle the embed, called index2.php, Click Here
Here is what I have in my website/module to call upon Gallery, Click Here
Can someone take a look who is familar with the changes and let me know if there is something that needs to be updated in my code? Thank you.
Posts: 32509
see the last few pages for changes to the Embed API:
http://gallery.menalto.com/index.php?name=PNphpBB2&file=viewtopic&t=23957&start=90
// if anonymous user, set g2 activeUser to null $uid = null; // initiate G2 $ret = GalleryEmbed::init(array('embedUri' => 'index.php?ind=artgallery', 'relativeG2Path' => '../gallery', 'loginRedirect' => 'index.php', 'activeUserId' => $uid));should be
// if anonymous user, set g2 activeUser to null $uid = ''; // initiate G2 $ret = GalleryEmbed::init(array('embedUri' => 'index.php?ind=artgallery', 'embedPath' => see docs/EMBEDDING for the correct value 'relativeG2Path' => '../gallery', 'loginRedirect' => 'index.php', 'activeUserId' => $uid));GalleryCapabilities::set('showSidebar', false);should be
GalleryCapabilities::set('showSidebarBlocks', false);if (isset($g2moddata['sidebarHtml']) && !empty($g2moddata['sidebarHtml'])) { $data['sidebarHtml'] = $g2moddata['sidebarHtml']; }should be
if (isset($g2moddata['sidebarBlocksHtml']) && !empty($g2moddata['sidebarBlocksHtml'])) { $data['sidebarHtml'] = '<div id="gsSidebar" class="gcBorder1"> ' . join('', $g2moddata['sidebarBlocksHtml']) . ' </div>';Posts: 181
Now when I go to http://www.protoculturex.com/index.php?ind=artgallery I am now getting this error:
Parse error: parse error, unexpected $ in /home/protocul/public_html/mkportal/modules/artgallery/index.php on line 90I have checked that index.php and on line 90 we just have ?>.
Corrected Code: http://www.protoculturex.com/pastebin/pastebin.php?show=19
Corrected Code: http://www.protoculturex.com/pastebin/pastebin.php?show=18
According to embed docs it says to use "embedPath = URL path from document root to embedUri" so if I understood probably I have it set as:
$ret = GalleryEmbed::init(array('embedUri' => 'index.php?ind=artgallery', 'embedPath' => 'http://www.protoculturex.com/', 'relativeG2Path' => '../gallery', 'loginRedirect' => 'index.php', 'activeUserId' => $uid));Posts: 32509
nope, embedPath would just be '/' in this case.
your complete url should be.
$host . $embedPath . $embedUri
whereas $host is not needed as parameter, that we can detect ourselves.
as to your problem... maybe my code from the last post wasn't perfect, i guess you know how to debug... it must be in line 89 or 90.
Posts: 181
It looks like it was missing a }. That took care of the error but I am still getting the strange duplicate display of the gallery. One above the website, another inegrated within it.
http://www.protoculturex.com/index.php?ind=artgallery
Posts: 32509
Shadow_Wolf, then you're either printing twice or calling the whole thing twice.
Posts: 4
I've actually begun working on this, and I can attest, there is no printing/calling twice. o_O I've been looking through GalleryEmbed::init(), GalleryInitFirstPass(), GalleryInitSecondPass(), and GalleryMain (and _GalleryMain()) and don't really see the immediate reason this is happening.
Here's the start of the code:
function runGallery() { global $ibforums; require_once('/home/protocul/public_html/gallery/embed.php'); $data = array(); if($ibforums->member['id'] == 0) { $uid = null; } else { $uid = $ibforums->member['id']; } // initiate G2 $ret = GalleryEmbed::init( array( 'embedUri' => "index.php?ind=artgallery", 'embedPath' => "/", 'relativeG2Path' => "gallery", 'loginRedirect' => "/forum/index.php?act=login", 'activeUserId' => $uid, ) ); // user interface: disable sidebar in G2 and get it as separate HTML to put it into a block GalleryCapabilities::set('showSidebarBlocks', false); // handle the G2 request $g2moddata = GalleryEmbed::handleRequest(); // show error message if isDone is not defined if (!isset($g2moddata['isDone'])) { $data['bodyHtml'] = 'isDone is not defined, something very bad must have happened.'; return $data; } .....and so forthNow, if I just do this
function runGallery() { global $ibforums; require_once('/home/protocul/public_html/gallery/embed.php'); $data = array(); if($ibforums->member['id'] == 0) { $uid = null; } else { $uid = $ibforums->member['id']; } // initiate G2 $ret = GalleryEmbed::init( array( 'embedUri' => "index.php?ind=artgallery", 'embedPath' => "/", 'relativeG2Path' => "gallery", 'loginRedirect' => "/forum/index.php?act=login", 'activeUserId' => $uid, ) ); exit(); ....and so forthobviously ending the function, so there is no parser error, the content is outputted to the browser, just misformatted because there is no CSS being pulled in.
It seems that there is another file that is printing the data, but I'm having a heck of a time tracking it down.
Oh, btw Shadow Wolf...user integration for IPB working at /gallery/
Just login to the forums, then visit /gallery (or actually, the ind=artgallery is up now too) and you may need to refresh once (I think due to this dup printing issue) but it shows your correct username, etc. We'll talk more in email on what remains to be done.
But yeah, I'm actually here to inquire on the same thing, the duplicate printing...if I can get past this part, I can get a comple IPB integration (minus groups, at this point at least) done this week.
[EDIT]
To add on to this, in embed.php, if I exit immediately after the first line in init (the GalleryInitFirstPass()) content is being output to the browser. This is the content misformmated due to no CSS.
Ending as I described earlier kind of formats everything (the gallery logo image is a broken image) but content only outputs before the CMS wrapper, instead of inside it.
Still looking...
Posts: 4
Ok, I found that GalleryUtilities::isEmbedded() is not getting set. This is why it's being output, then the data is returned and output a second time.
In main.php
if (!GalleryUtilities::isEmbedded()) {
print "hello";exit();
hello is printed, though obviously it shouldn't be (I should think, based on the terminology of the call).
If/when I find why this isn't being set, I'll post back.
Posts: 4
Ok, resolved.
GalleryUtilities.class
Changed
function isEmbedded() { if (!GalleryDataCache::containsKey('G2_EMBED') || !GalleryDataCache::get('G2_EMBED')) { return false; } else { return true; } }to
function isEmbedded() { if (GalleryDataCache::containsKey('G2_EMBED') || GalleryDataCache::get('G2_EMBED')) { return true; } elseif(defined('G2_EMBED')) { return true; } else { return false; } }I tested from both our entry points, and it's working fine now (my integration previously, essentially I just didn't have to call handlerequest, and the data was still output directly from Gallery), plus accessing main.php still works fine.
Not sure if this is a bug, or something going on with this particular installation, but hey, whatever works right? Maybe this will help some others.
Posts: 32509
bfarber, your integration code must be very odd / something must be wrong.
it works for all existing integrations, so this is definitely not a bug of g2.
the G2_EMBED constant was removed a long time ago.
Posts: 4
What version was it removed in?
embed.php is still defining G2_EMBED first thing.
* @package GalleryMain * @version $Revision: 1.39 $ $Date: 2005/03/10 00:01:04 $ * @author Alan Harder <alan.harder@sun.com> */ define('G2_EMBED', 1); require(dirname(__FILE__) . '/main.php');As for the integration code, it's just the standard API calls. As my edits corrected the issue, I know that is the problem (it's looking for that constant in the GalleryDataCache). I don't know WHY it's a problem is the only thing.
Unless you can see some unforseen problem with this, everything else is working now, so I won't dwell on the issue. Problem fixed as far as I'm concerned. But if, for example, that changed in v 1.4 (embed says it's 1.39), then I'll know it's just a version variance somewhere.
Posts: 181
It looks like the Revision 1.39 is the older version. I renamed it to embed.old and uploaded the correct revision of embed 1.45.
<?php /* * $RCSfile: embed.php,v $ * * Gallery - a web based photo album viewer and editor * Copyright (C) 2000-2005 Bharat Mediratta * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or (at * your option) any later version. * * This program is distributed in the hope that it will be useful, but * WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ /** * Access point for external application in which Gallery is embedded. * See docs/EMBEDDING and modules/core/classes/GalleryEmbed.class for more details. * * @package GalleryMain * @version $Revision: 1.45 $ $Date: 2005/06/11 21:44:12 $ * @author Alan Harder <alan.harder@sun.com> */ /* Define G2_EMBED = 1 to remember to generate correct URLs and return the HTML, etc. */ require_once(dirname(__FILE__) . '/modules/core/classes/GalleryDataCache.class'); GalleryDataCache::put('G2_EMBED', 1, true); require(dirname(__FILE__) . '/main.php'); require(dirname(__FILE__) . '/modules/core/classes/GalleryEmbed.class'); ?>Posts: 25
Can't wait for this ShadowWolf - make sure you let us know when you think this is right to go and I will install it and let you know how I get on.
Posts: 25
Any update ShadwoWolf?
Have you got this working?
Posts: 13
Is this being tested with Invision 2.1? or the 2.0.4 code? Keep up the good work, and if you need someone to test this I am running 2.1 RC1 and also the 2.0.4 Final of Invision.
Posts: 13
Now that 2.1.0 Final is out, is there anyword on this? As G2 is far better than the Invision Gallery Software, not to mention its free.
Posts: 34
I am also interested with how to do this with 2.1. (I am a IPB noob).
Posts: 34
ops
Posts: 13
there is now an invision board sdk that might help.. too bad I am not skilled in the ways of PHP...
Posts: 1
Does anyone here know how to use the sdk to make it work with invisionboard 2.1?
Posts: 21
well I guess any progress on this is pretty well done for
oh well.
Posts: 48
BUMP ... any news on this topic?
Posts: 15
I have been working on this for my website and am finally getting somewhere. Mine is a little more complicated as the i have IPB 2.1 running on a server in LA and Gallery 2 running on a server in the UK! I have got the user sync working perfectly so when a user is registered on IPB, they are auto registered in Gallery2 on the other server. This is done using a secure custom XML feed called by the gallery server (feed can only be accessed by G2 server!) this sync is processed to sync 1 user at a time whenever that user registers/changes their profile or is deleted. Now step one is completed as the users can now access gallery.
My problem now is embedding G2 so they are auto logged in, having read through embed.php it appears that this is only possible if both apps are on the same server. (they have the same domain just diff subdomains) but are on different servers. Is it possible to create 1 login in this scenario, so i can disable logins in G2?
Thanks for any help.
Mike
Posts: 32509
different webservers is not that easy.
solving the subdomain issue would have been quite easy, but still requires a fix to g2.
@different webservers:
http://gallery.menalto.com/node/37002
Posts: 48
Mike,
that is very good news. Would you be willing to share a generic copy of your XML feed? I'd def be interested in that. that is really all i'm looking for .. smoething to sync the users .. they can login themself ;-)
Thanks,
--marco
Posts: 15
Thanks valiant, Ill have a look at that! I will share my XML code when its completly finished, shouldn't be long!
Mike
Posts: 15
ok read through that and am pretty confused! Basically this isnt going to be possible for someone who doesnt know a lot about php/cookies?
Posts: 32509
also from the same thread:
so it's not 100% obvious how it was solved, but a php coder could code a solution based on the description.
Posts: 25
mike I'm really keen to see this up and running.
Hopefully you can work out the login issue - if not i'd love you to share your current code and maybe we can all work something out. I have some guys doing some custom coding on my IPB2.1 install so maybe between us we can get this working.
Let us know if you want me to test anything otherwise please keep us updated with your progress and share the code
Posts: 15
I'll be working on it over the weekend so will hopefully have something positive soon
Posts: 15
Got a problem, In invision 2.1, passwords are hashed using md5 a salt and in gallery they are just md5, simply syncing the data in the databases isnt goint to work
Posts: 13
Any more progress on this? I am willing to give as little money to who ever can get his working. My main thing is jsut to make so that the user levels work = if you are a member of the board then you can view the images and upload to certain areas... if not then you dont see any of the albums.... there has got to be a way to bridge these.
Posts: 14
Hmm since this isn't out yet from what I understood, I have to rely on CMS+G2 integration for now. I just don't want to rely on the CMS+G2 coz my CMS' users rely on IPB and thus it'll appear as IPB2 users->CMS->G2 ~_~;;
Hope it'll be available this year 2006.
Posts: 1
hi
where can I finde IPB 1.3.1 + G2 intergration Mod? I've searched in Forum but didn't find anywhere
Posts: 1
does anyone have ipb 2.1 and G2 working together? I have 2.0.4 with reflections and would like to start using G2..
Posts: 25
Just bumping this thread - I'm offering to pay someone to code the gallery2 and the latest version of invision (IPB) intergration. It would be preferable if it was a modulear system in that gallery2 and IPB could be upgraded (in most cases) fairly easily.
Basically, a shared login/permissions/userdb is all I require.
The Invision Gallery is a piece of JUNK and I would really love to see Gallery2 and the forums working together.
Please post here or PM/Email me.
I'm happy to release the mod to the general public even though I'm paying for it.
Posts: 25
One thing I have found is this http://www.mkportal.it/support/showthread.php?t=9070&highlight=gallery2
It's a ported version of Gallery2 RC2 for MKportal which intergrated into IPB.
While the version is old - obviously the intergration work has pretty much been done - so maybe we can port some of the MKconfig and driver files that the index file is calling and make up our own standalone intergration.
Thoughts?