Welcome to Geeklog, Anonymous Sunday, September 01 2024 @ 12:37 am EDT
Geeklog Forums
G2 - Gallery Integration with Geeklog ?
Page navigation
Status: offline
knuff
Forum User
Full Member
Registered: 12/17/04
Posts: 340
Location:Sweden
Hi,
Looking at the current status of Gallery we are soon going to the new Gallery 2 RC as G2 is getting very stable beta versions.
Integration with Geeklog is however not yet available
Any great developers outhere that are willing to start the integration ?
I did a search both here and at gallery, but couldn´t find any hint to someone already working on it.
The integration thread is here.
It currently lists a lot of the competitors CMS systems, and I hope someone here could pick up the integration part ...
If I can assist on it, let me know, but I am far from a developer.
Greetz,
Boris
Vanrillaer.com - our Family Portal
Looking at the current status of Gallery we are soon going to the new Gallery 2 RC as G2 is getting very stable beta versions.
Integration with Geeklog is however not yet available
![Mr. Green Mr. Green](http://www.geeklog.net/images/smiles/icon_mrgreen.gif)
Any great developers outhere that are willing to start the integration ?
I did a search both here and at gallery, but couldn´t find any hint to someone already working on it.
The integration thread is here.
It currently lists a lot of the competitors CMS systems, and I hope someone here could pick up the integration part ...
If I can assist on it, let me know, but I am far from a developer.
Greetz,
Boris
Vanrillaer.com - our Family Portal
32
25
Quote
Status: offline
knuff
Forum User
Full Member
Registered: 12/17/04
Posts: 340
Location:Sweden
Andy,
Whenever you need someone to test some stuff ... let me know.
Playing around with G2 to get a good grip on it and having played quite a lot with G1 and GL1
Keep us posted, will ye
Thanks again for looking into it !
Boris
Vanrillaer.com - our Family Portal
Whenever you need someone to test some stuff ... let me know.
Playing around with G2 to get a good grip on it and having played quite a lot with G1 and GL1
Keep us posted, will ye
![Mr. Green Mr. Green](http://www.geeklog.net/images/smiles/icon_mrgreen.gif)
Thanks again for looking into it !
Boris
Vanrillaer.com - our Family Portal
28
24
Quote
Status: offline
asmaloney
Forum User
Full Member
Registered: 02/08/04
Posts: 214
Hello everyone.
G2 integration is done quite differently to the way it was done with G1. The main reason is that G2 now uses an SQL db instead of its own files, so it maintains its own user lists which have to be kept in sync with GL's. These means mapping users and groups from GL into G2.
I have a plugin which installs and allows anonymous access to G2, but does not map any users. It does not have any prefs and does not show the sidebar in a block yet - it simply shows the gallery. Once I get the user portion done, I'll consider getting some people to test it. I haven't looked at the groups yet because I haven't had the time, but, to be honest, mucking with GL's db frightens me a bit because of lack of documentation
- Andy
G2 integration is done quite differently to the way it was done with G1. The main reason is that G2 now uses an SQL db instead of its own files, so it maintains its own user lists which have to be kept in sync with GL's. These means mapping users and groups from GL into G2.
I have a plugin which installs and allows anonymous access to G2, but does not map any users. It does not have any prefs and does not show the sidebar in a block yet - it simply shows the gallery. Once I get the user portion done, I'll consider getting some people to test it. I haven't looked at the groups yet because I haven't had the time, but, to be honest, mucking with GL's db frightens me a bit because of lack of documentation
![Shocked Shocked](http://www.geeklog.net/images/smiles/icon_eek.gif)
- Andy
24
29
Quote
Status: offline
knuff
Forum User
Full Member
Registered: 12/17/04
Posts: 340
Location:Sweden
Hi Andy,
I am pretty sure you read it, but there is some global talk about how the "loose" integration concept is supposed to be handled.
From what I understand, by calling the two different API´s G2 stays in sync as a slave, without the need of getting involved with the G2 db and all user access is handled by the master.
Just in case you missed the reference, here
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.
Some other really worth reading literature on the topic.
CMS Integration 18 pages, kind of long, but some interesting bids
And last but not least, the docs/EMBEDDING
in embed.php provides APIs to assist in processing G2 requests and keeping sessions,
user logins and user/group data in sync between G2 and the embedding application.
In this document "embedding application" is shortened to emApp.
This document contains instructions for:
A) Embedding G2 in another application using existing integration code
B) Writing the integration code to embed G2 in another PHP application
___ Embedding G2 in another application using existing integration code ___
___________________________________________________________________/
1) Install (separately) G2 and the app in which G2 will be embedded.
2) Obtain and install the G2 integration code written specifically for the emApp.
This may be a module or plugin if the emApp supports them, or a simple php file.
3) Follow instructions with the integration code to initially synchronize users and groups.
This may be done as part of module/plugin installation or via special php files.
4) Login to G2 as a site administrator:
a) Make sure the registration module is deactivated or not installed
b) Set the G2 session lifetime to at least twice the lifetime of sessions in the emApp.
This is because a user may visit G2 and then continue to use the emApp but not visit
G2 pages.. a longer G2 session timeout will help ensure their session sticks around
until they do visit a G2 page again. Note that if the G2 session does timeout and
the user returns then a new session will be created with the correct user logged in.
Other data from the old session is lost but the user login is restored.
5) Test the integration
6) Once everything is working you can choose to disable direct access to G2 and only
allow access via the emApp. To do this set the embedOnly flag in your config.php.
___ Writing the integration code to embed G2 in another PHP application ___
___________________________________________________________________/
First install (separately) G2 and the app in which G2 will be embedded.
Next you need an entry point in the emApp for all G2 requests, (similar to
main.php in G2 standalone). This may be a module or plugin if the application
supports these, or a plain php file. Determine the URI/path for your access
point and the G2 base directory, relative to your webserver document root.
Examples: __ access point __ __ G2 base dir __
a) appdir/gallery2.php appdir/gallery2
b) appdir/plugins/gallery2.php appdir/lib/gallery2
c) appdir/index.php?module=gallery2 gallery2
d) index.php?page=gallery albums
Use these to determine the following values:
embedURI = Filename (and any query parameters, but NO path) for access point
embedPath = URL path from document root to embedUri
relativeG2Path = Path from directory for access point to G2 base directory
For the above examples these settings are:
__ embedURI __ __ embedPath __ __ relativeG2Path __
a) gallery2.php /appdir gallery2
b) gallery2.php /appdir lib/gallery2
c) index.php?module=gallery2 /appdir ../gallery2
d) index.php?page=gallery / albums
You'll also need a URI for a login page or main page of the app; G2 will
redirect here for access attempts without proper permissions.
Examples: / or /appdir/login.php
The code in the access point to handle a G2 request looks something like this:
require_once(dirname(__FILE__) . 'relative/path/to/gallery2/embed.php');
$ret = GalleryEmbed::init(array(
'embedUri' => {value}, embedPath => {value}, 'relativeG2Path' => {value},
'loginRedirect' => {value}, 'activeUserId' => {value}));
if ($ret->isError()) {
// $ret->getAsHtml() has error details..
exit;
}
$g2data = GalleryEmbed::handleRequest();
if ($g2data['isDone']) {
exit; // G2 has already sent output (redirect or binary data)
}
// Use $g2data['headHtml'] and $g2data['bodyHtml']
// to display G2 content inside embedding application
// if you don't want to use $g2data['headHtml'] directly, you can get the css,
// javascript and page title separately by calling...
if (isset($g2moddata['headHtml'])) {
list($title, $css, $javascript) = GalleryEmbed::parseHead($g2moddata['headHtml']);
}
The 'activeUserId' value passed to init() enables session synchronization by
making sure the active user in G2 matches the emApp user. The value is the
active emApp user id. Pass in an empty string for anonymous/guest user
(NOT the user id of the emApp's anonymous user if it has an id).
To complete session sync add a hook/callback/event-handler for the logout
operation in the emApp:
require_once(dirname(__FILE__) . 'relative/path/to/gallery2/embed.php');
$ret = GalleryEmbed::logout();
This hook is not required, but it resets the G2 session at logout so a session for
a logged-in user isn't left on the server.
Next decide if you want to support cookieless browsing. Some extra steps are
required if G2 can't count on cookies to track its session id. The emApp must
be able to provide a key=value string for its own session key and id, and have
an available API to store additional data in the session.
Here are the extra steps:
1) The input array for the GalleryEmbed::init() call must also contain:
'embedSessionString' => {key=value}, 'gallerySessionId' => {value}
(omit gallerySessionId when the value is not yet known)
2) After the init() call:
$gallerySessionId = GallerEmbed::getSessionId();
{store value in emApp's session}
Other optional tasks:
1) Prior to the handleRequest() call set GalleryCapabilities.
Check modules/core/classes/GalleryCapabilities.class for available settings;
also see the settings made by default in GalleryEmbed::init().
Example: GalleryCapabilities::set('showSidebar', false);
2) Check for 'sidebarHtml' in content returned from handleRequest().
If the example GalleryCapabilities setting shown above is used then handleRequest()
may return 'sidebarHtml' (when a core.ShowItem page is being viewed). You can include
this content in a block on the emApp sidebar.
Next add hooks to keep users in sync between G2 and the emApp.
The code in each case will look like this:
require_once(dirname(__FILE__) . 'relative/path/to/gallery2/embed.php');
$ret = GalleryEmbed::init();
if ($ret->isError()) {
// $ret->getAsHtml() has error details..
}
// Call GalleryEmbed as required..
// ..
$ret = GalleryEmbed::done();
if ($ret->isError()) {
// $ret->getAsHtml() has error details..
}
You'll need hooks to call GalleryEmbed::createUser(), ::updateUser() and ::deleteUser()
for user creation, updates and deletes, respectively. There may be two create hooks
if the emApp supports both new user registration and an admin function to create new
users directly.
If the emApp supports user groups then add hooks to keep groups in sync. Synchronizing
groups is optional, even if the emApp supports groups. The process is the same as above,
using GalleryEmbed::createGroup, ::updateGroup, ::deleteGroup(), ::addUserToGroup() and
::removeUserFromGroup(). Note that G2 does not support nested groups.. if the emApp does
then the hooks will have to expand the groups into the list of users and update the G2
groups accordingly.
Euhhh, I know you read it, but just wanted to make sure you didn´t miss anything ...
Sounds heavy, but I am convinced you can DO it
Vanrillaer.com - our Family Portal
I am pretty sure you read it, but there is some global talk about how the "loose" integration concept is supposed to be handled.
From what I understand, by calling the two different API´s G2 stays in sync as a slave, without the need of getting involved with the G2 db and all user access is handled by the master.
Just in case you missed the reference, here
Text Formatted Code
... 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.
Some other really worth reading literature on the topic.
CMS Integration 18 pages, kind of long, but some interesting bids
And last but not least, the docs/EMBEDDING
Text Formatted Code
Gallery2 is designed to be easily embedded in other applications. The GalleryEmbed classin embed.php provides APIs to assist in processing G2 requests and keeping sessions,
user logins and user/group data in sync between G2 and the embedding application.
In this document "embedding application" is shortened to emApp.
This document contains instructions for:
A) Embedding G2 in another application using existing integration code
B) Writing the integration code to embed G2 in another PHP application
___ Embedding G2 in another application using existing integration code ___
___________________________________________________________________/
1) Install (separately) G2 and the app in which G2 will be embedded.
2) Obtain and install the G2 integration code written specifically for the emApp.
This may be a module or plugin if the emApp supports them, or a simple php file.
3) Follow instructions with the integration code to initially synchronize users and groups.
This may be done as part of module/plugin installation or via special php files.
4) Login to G2 as a site administrator:
a) Make sure the registration module is deactivated or not installed
b) Set the G2 session lifetime to at least twice the lifetime of sessions in the emApp.
This is because a user may visit G2 and then continue to use the emApp but not visit
G2 pages.. a longer G2 session timeout will help ensure their session sticks around
until they do visit a G2 page again. Note that if the G2 session does timeout and
the user returns then a new session will be created with the correct user logged in.
Other data from the old session is lost but the user login is restored.
5) Test the integration
6) Once everything is working you can choose to disable direct access to G2 and only
allow access via the emApp. To do this set the embedOnly flag in your config.php.
___ Writing the integration code to embed G2 in another PHP application ___
___________________________________________________________________/
First install (separately) G2 and the app in which G2 will be embedded.
Next you need an entry point in the emApp for all G2 requests, (similar to
main.php in G2 standalone). This may be a module or plugin if the application
supports these, or a plain php file. Determine the URI/path for your access
point and the G2 base directory, relative to your webserver document root.
Examples: __ access point __ __ G2 base dir __
a) appdir/gallery2.php appdir/gallery2
b) appdir/plugins/gallery2.php appdir/lib/gallery2
c) appdir/index.php?module=gallery2 gallery2
d) index.php?page=gallery albums
Use these to determine the following values:
embedURI = Filename (and any query parameters, but NO path) for access point
embedPath = URL path from document root to embedUri
relativeG2Path = Path from directory for access point to G2 base directory
For the above examples these settings are:
__ embedURI __ __ embedPath __ __ relativeG2Path __
a) gallery2.php /appdir gallery2
b) gallery2.php /appdir lib/gallery2
c) index.php?module=gallery2 /appdir ../gallery2
d) index.php?page=gallery / albums
You'll also need a URI for a login page or main page of the app; G2 will
redirect here for access attempts without proper permissions.
Examples: / or /appdir/login.php
The code in the access point to handle a G2 request looks something like this:
require_once(dirname(__FILE__) . 'relative/path/to/gallery2/embed.php');
$ret = GalleryEmbed::init(array(
'embedUri' => {value}, embedPath => {value}, 'relativeG2Path' => {value},
'loginRedirect' => {value}, 'activeUserId' => {value}));
if ($ret->isError()) {
// $ret->getAsHtml() has error details..
exit;
}
$g2data = GalleryEmbed::handleRequest();
if ($g2data['isDone']) {
exit; // G2 has already sent output (redirect or binary data)
}
// Use $g2data['headHtml'] and $g2data['bodyHtml']
// to display G2 content inside embedding application
// if you don't want to use $g2data['headHtml'] directly, you can get the css,
// javascript and page title separately by calling...
if (isset($g2moddata['headHtml'])) {
list($title, $css, $javascript) = GalleryEmbed::parseHead($g2moddata['headHtml']);
}
The 'activeUserId' value passed to init() enables session synchronization by
making sure the active user in G2 matches the emApp user. The value is the
active emApp user id. Pass in an empty string for anonymous/guest user
(NOT the user id of the emApp's anonymous user if it has an id).
To complete session sync add a hook/callback/event-handler for the logout
operation in the emApp:
require_once(dirname(__FILE__) . 'relative/path/to/gallery2/embed.php');
$ret = GalleryEmbed::logout();
This hook is not required, but it resets the G2 session at logout so a session for
a logged-in user isn't left on the server.
Next decide if you want to support cookieless browsing. Some extra steps are
required if G2 can't count on cookies to track its session id. The emApp must
be able to provide a key=value string for its own session key and id, and have
an available API to store additional data in the session.
Here are the extra steps:
1) The input array for the GalleryEmbed::init() call must also contain:
'embedSessionString' => {key=value}, 'gallerySessionId' => {value}
(omit gallerySessionId when the value is not yet known)
2) After the init() call:
$gallerySessionId = GallerEmbed::getSessionId();
{store value in emApp's session}
Other optional tasks:
1) Prior to the handleRequest() call set GalleryCapabilities.
Check modules/core/classes/GalleryCapabilities.class for available settings;
also see the settings made by default in GalleryEmbed::init().
Example: GalleryCapabilities::set('showSidebar', false);
2) Check for 'sidebarHtml' in content returned from handleRequest().
If the example GalleryCapabilities setting shown above is used then handleRequest()
may return 'sidebarHtml' (when a core.ShowItem page is being viewed). You can include
this content in a block on the emApp sidebar.
Next add hooks to keep users in sync between G2 and the emApp.
The code in each case will look like this:
require_once(dirname(__FILE__) . 'relative/path/to/gallery2/embed.php');
$ret = GalleryEmbed::init();
if ($ret->isError()) {
// $ret->getAsHtml() has error details..
}
// Call GalleryEmbed as required..
// ..
$ret = GalleryEmbed::done();
if ($ret->isError()) {
// $ret->getAsHtml() has error details..
}
You'll need hooks to call GalleryEmbed::createUser(), ::updateUser() and ::deleteUser()
for user creation, updates and deletes, respectively. There may be two create hooks
if the emApp supports both new user registration and an admin function to create new
users directly.
If the emApp supports user groups then add hooks to keep groups in sync. Synchronizing
groups is optional, even if the emApp supports groups. The process is the same as above,
using GalleryEmbed::createGroup, ::updateGroup, ::deleteGroup(), ::addUserToGroup() and
::removeUserFromGroup(). Note that G2 does not support nested groups.. if the emApp does
then the hooks will have to expand the groups into the list of users and update the G2
groups accordingly.
Euhhh, I know you read it, but just wanted to make sure you didn´t miss anything ...
![Mr. Green Mr. Green](http://www.geeklog.net/images/smiles/icon_mrgreen.gif)
Sounds heavy, but I am convinced you can DO it
![Leaves me speechless Leaves me speechless](http://www.geeklog.net/images/smiles/speechless.gif)
Vanrillaer.com - our Family Portal
26
39
Quote
Status: offline
asmaloney
Forum User
Full Member
Registered: 02/08/04
Posts: 214
Thought I'd post a quick update. "I'm not dead - I'm getting better."
I have a pre-pre-alpha version out with a couple of people to try. Extremely basic integration at the moment.
Don't know how much time I'll have to spend on this one though. If the testers find what I gave them actually useful, I might just clean that up and release it in the meantime.
- Andy
I have a pre-pre-alpha version out with a couple of people to try. Extremely basic integration at the moment.
Don't know how much time I'll have to spend on this one though. If the testers find what I gave them actually useful, I might just clean that up and release it in the meantime.
- Andy
32
24
Quote
Status: offline
asmaloney
Forum User
Full Member
Registered: 02/08/04
Posts: 214
Great! [no pressure]
[Users who don't already have a gallery installation should take a look at machinari's Inmemoriam Media Gallery which is made specifically for geeklog.]
My integration now grabs the theme and javascript from G2 and I've made the config simpler. Haven't looked at creating a block for it yet either. It's coming along though.
I could use one or two more people who have test servers set up to try this out. Beware it may completely destroy your computer, your TV, and your home [though, to the best of my knowledge, none of these have happend to ajzz yet - at least due to my Gallery2 integration]. If that doesn't scare you, email me with your conifguration info and we'll give it a try.
- Andy
[Users who don't already have a gallery installation should take a look at machinari's Inmemoriam Media Gallery which is made specifically for geeklog.]
My integration now grabs the theme and javascript from G2 and I've made the config simpler. Haven't looked at creating a block for it yet either. It's coming along though.
I could use one or two more people who have test servers set up to try this out. Beware it may completely destroy your computer, your TV, and your home [though, to the best of my knowledge, none of these have happend to ajzz yet - at least due to my Gallery2 integration]. If that doesn't scare you, email me with your conifguration info and we'll give it a try.
- Andy
19
30
Quote
Status: offline
ajzz
Forum User
Regular Poster
Registered: 01/19/05
Posts: 113
Great - now i have to upgrade G2 within a week of installing the last one!
but G2 has one of the slickest installs - its almost a pleasure.
Yes indeed most of my belongings are still unaffected by Andy's G2 integration
The templates can now be set from within G2 and all the G2 administrative functions including url-rewriting seem to work well. The ultra-curious may e-mail-request a link to the test site (its not ready for those web-crawlers yet).
Andy, is integration with GL-search planned for this version?
(With G2 released, we need more testers for the plugin to be released soon - please heed asmaloney's request above if you will/already have a test-rig)
Cheers!
Ajay
![Doh! - that was a mistake Doh! - that was a mistake](http://www.geeklog.net/images/smiles/doh.gif)
Yes indeed most of my belongings are still unaffected by Andy's G2 integration
![Big Celebration Big Celebration](http://www.geeklog.net/images/smiles/banana.gif)
Andy, is integration with GL-search planned for this version?
(With G2 released, we need more testers for the plugin to be released soon - please heed asmaloney's request above if you will/already have a test-rig)
Cheers!
Ajay
32
31
Quote
Status: offline
surgeon
Forum User
Newbie
Registered: 01/31/05
Posts: 8
Location:Poland
Quote by asmaloney:I could use one or two more people who have test servers set up to try this out.
Ready for tests.
--
Pozdrawiam (Regards)
surgeon
http://galeria.lubin.pl/
30
22
Quote
Status: offline
asmaloney
Forum User
Full Member
Registered: 02/08/04
Posts: 214
An update is in order...
I have enough testers for now.
Coincidentally, just after my note, Ajay's drive got fried by a power outage. He assures me it had nothing to do with my plugin.
The plugin: I have the sidebar showing up in a GL block, so you can put random photos, search boxes, and all sorts of stuff there through the G2 admin interface.
Remaining: admin page, docs, cleanups and fix a couple of outstanding issues.
It's coming along...
- Andy
I have enough testers for now.
Coincidentally, just after my note, Ajay's drive got fried by a power outage. He assures me it had nothing to do with my plugin.
The plugin: I have the sidebar showing up in a GL block, so you can put random photos, search boxes, and all sorts of stuff there through the G2 admin interface.
Remaining: admin page, docs, cleanups and fix a couple of outstanding issues.
It's coming along...
- Andy
24
29
Quote
Status: Banned
machinari
Forum User
Full Member
Registered: 03/22/04
Posts: 1512
Quote by mpursley:...and to move to a database driven system!
if it is only the database driven aspect of Gallery that is enticing you, Inmemoriam offers you this feature if you wanna check it out.
25
29
Quote
Status: offline
asmaloney
Forum User
Full Member
Registered: 02/08/04
Posts: 214
Quote by machinari:
Quote by mpursley:...and to move to a database driven system!
if it is only the database driven aspect of Gallery that is enticing you, Inmemoriam offers you this feature if you wanna check it out.Poacher!
![Very Happy Very Happy](http://www.geeklog.net/images/smiles/icon_biggrin.gif)
Seriously, for those of you who aren't already 'invested' in gallery or really don't need some of gallery's esoteric features, you should check out machinari's Inmemoriam. It was written specifically for Geeklog.
- Andy
21
22
Quote
Page navigation
All times are EDT. The time is now 12:37 am.
- Normal Topic
- Sticky Topic
- Locked Topic
- New Post
- Sticky Topic W/ New Post
- Locked Topic W/ New Post
- View Anonymous Posts
- Able to post
- Filtered HTML Allowed
- Censored Content