Error fetching album tree

I was able to track down the problem to a G2 method and it looks like a G2 bug to me. I will discuss the issue with some G2 devs to find a solution ...

The problem exists with the latest version of G2 as well. Some more background ...
For gallery menu generation we need the whole album tree from G2. To achieve this we are calling fetchAlbumTree() which takes 3 parameters: root album id, depth and user to check permission. I asked on irc #gallery how I can fetch the whole tree and not only the partial tree visible to the current user, the answer was to pass in the admin user id to fetchAlbumTree(). This works perfectly nice in most cases, but not for anonymous users (and if no other user is logged in). Here is why: fetchAlbumTree() makes sure that the current user has access to the root album (default album) by calling hasItemPermission(). However for guest users the userId is assumed 0 which obviously results in an access denied although 'everybody' is granted access to the root album. If I add three lines to this method to use the anonymous user id (instead of 0) everything works as expected.

Replace

if (!isset($userId)) {
  $userId = $gallery->getActiveUserId();
}

with

if (!isset($userId)) {
  $userId = $gallery->getActiveUserId();
  if (!$userId) {
    list($ret, $userId) = GalleryCoreApi::getPluginParameter('module', 'core', 'id.anonymousUser');
    if ($ret) {
      return array($ret, null);
    }
  }
}

in GalleryUserHelper_simple.class (modules/core/classes/helpers), hasItemPermission() line 60 to try what I mean.

I have crossposted this on gmc and the G2 issue queue (after discussion on IRC). In my experience it can take some time for someone to look at the issues. It's unlikely to see this fixed before Gallery 2.3 ...

However you can safely comment line 243 gallery_base.inc to suppress the message generated/logged by gallery_error(). Actually I'm thinking about a temporary solution until this is solved in G2 for the final release of 5.x-2.x.

I've just committed an update to the 5--2 branch which cleans up the init() calls for G2. We have to ensure a certain init sequence to get this right ... Marking the issue fixed and hoping for you to confirm ;) Thanks.

Can you please try the latest 5.x-2.x-dev version, the fixes for this error went in after beta4 was released! This is very tricky stuff, but after discussion with one of the main devs of G2 I thought we finally solved the problem ...

There seems to be a problem when you try to use "Enable URL Rewrite mode" for the gallery_menu.module. When you are logged in there is no problem, but for anonymous (not logged) users each link is wrong, there is this string appended to the URL (that is right...but with this parameter it doesn't work) :
%3Fg2_GALLERYSID%3DTMP_SESSION_ID_DI_NOISSES_PMT
Now if I remove this from the URL I get to the right location and links inside the gallery works (they are right).

But it isn't just that, the tree structure isn't used for the menu generated by gallery_menu.module for anonymous users, but as soon as you're logged everything works fine.

There's another issue I noticed while testing this, when I'm browsing the gallery as anonymous, and I try to login it just redirects me to the same page but doesn't log me in, maybe it's not related and it should be noticed in another issue.

Thanks in advance.

Instead of removing the %3Fg2_GALLERYSID%3DTMP_SESSION_ID_DI_NOISSES_PMT part completely it also work if you manually decode the string to ?g2_GALLERYSID=TMP_SESSION_ID_DI_NOISSES_PMT. But its actually the Drupal menu system that encodes this piece and therefore prevents it from working correctly. So here is a patch that simply strips off this stuff, so that it doesnt show up in the url at all. I will need to check this limitation for Drupal 6, but for D5 I think we have to use this kind of workaround.

Applied the patch and it works fine, stripping an not just decoding it is the right move in my opinon, it wouldn't look much like a "clean" URL with this parameter (withouth thinkin what it would do in terms of SEO) ;)

It also fix the hierarchy issue (so I guess Drupal uses path to build the hierarchy in this case).

The last issue (login issue) I reported is also fixed, so I guess I was right about thinking the issue was related to the same problem.

Thanks for this quick fix !

Patch committed. Thanks for testing.