G2 embed works! but can't access block settings now

I have G2 successfully embedded into my Drupal 5.2 installation. Details:

------------
GALLERY:
<code>
Gallery version = 2.2.1 core 1.2.0.1
PHP version = 4.4.7 cgi
Webserver = Apache/2.0.54 (Unix) PHP/4.4.7 mod_ssl/2.0.54 OpenSSL/0.9.7e mod_fastcgi/2.4.2 DAV/2 SVN/1.4.2
Database = mysqlt 5.0.24a-standard-log, lock.system=flock
Toolkits = ArchiveUpload, Exif, Thumbnail, Getid3, ImageMagick, LinkItemToolkit, Ffmpeg
Acceleration = none, none
Operating system = Linux amp 2.6.18.1-grsec+e+f6b+gr219+opt+c4a+gr2b-grsec #1 SMP Thu Oct 19 12:50:29 PDT 2006 i686
Default theme = pauls
gettext = enabled
Locale = en_US
Browser = Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en) AppleWebKit/419 (KHTML, like Gecko) Safari/419.3
Rows in GalleryAccessMap table = 351
Rows in GalleryAccessSubscriberMap table = 4413
Rows in GalleryUser table = 11
Rows in GalleryItem table = 4391
Rows in GalleryAlbumItem table = 128
Rows in GalleryCacheMap table = 0 </code>

DRUPAL:
Drupal 5.2, 2007-07-26

DRUPAL - G2 EMBED SETTINGS
Directory Settings
- URI of Gallery2: /pics/
- Location of Gallery2 (Autodetected value):
/home/pathtomysite/pics/
- Embed URI (Autodetected value):
/index.php?q=gallery
Embedded URL Rewrite settings
- Embedded setup...absolute path:
/home/pathtomysite/
- Url of my environment:
/
------------
Everything works great.
I have the Gallery standalone located at /pics
The embedded is at /gallery
Clean URLS are working
Users are all synced up

PROBLEM:
Gallery shows up in sidebar block on all the pages EXCEPT all nodes in /portfolio because I changed the block settings to hide the gallery block while developing the portfolio section.

When I went into the blocks to turn it back on, I get the dreaded:
"Unable to initialize embedded Gallery. You need to configure your embedded Gallery." error printed 4x

However, the gallery still works fine in the rest of the site.

I'm afraid to change any of the settings in the gallery settings config since it was a nightmare to get it all setup in the first place!

Affected pages:
/admin/build/block
/admin/build/block/configure/gallery/2
/admin/build/block/configure/gallery/0
/admin/settings/gallery

Thanks for the reply. Yes, I'm using 5.x-1.0 since the newer version said it wasn't stable yet.

I checked my logs and found the following:

Location	/admin/build/block/configure/gallery/2
Referrer	/admin/build/block
Message	Unable to initialize embedded Gallery. You need to configure your embedded Gallery.
Error (ERROR_STORAGE_FAILURE)

    * in modules/core/classes/GalleryStorage/GalleryStorageExtras.class at line 1001 (gallerycoreapi::error)
    * in modules/core/classes/GalleryStorage.class at line 505 (gallerystorageextras::addmapentry)
    * in modules/core/classes/GalleryCoreApi.class at line 2833 (mysqlstorage::addmapentry)
    * in modules/core/classes/GalleryEmbed.class at line 846 (gallerycoreapi::addmapentry)
    * in /home/pathtomysite/sites/all/modules/gallery/gallery_base.inc at line 89 (galleryembed::addexternalidmapentry)
    * in /home/pathtomysite/sites/all/modules/gallery/gallery_block.inc at line 42
    * in /home/pathtomysite/sites/all/modules/gallery/gallery.module at line 197
    * in ??? at line 0
    * in /home/pathtomysite/includes/module.inc at line 386
    * in /home/pathtomysite/modules/block/block.module at line 689
    * in /home/pathtomysite/includes/theme.inc at line 1018
    * in ??? at line 0
    * in /home/pathtomysite/includes/theme.inc at line 170
    * in /home/pathtomysite/themes/engines/phptemplate/phptemplate.engine at line 170
    * in ??? at line 0
    * in /home/pathtomysite/includes/theme.inc at line 170
    * in /home/pathtomysite/index.php at line 33

Severity	error 

and in another page

Referrer	/admin/build/block
Message	Unable to initialize embedded Gallery. You need to configure your embedded Gallery.
Error (ERROR_STORAGE_FAILURE)

    * in modules/core/classes/GalleryStorage/GalleryStorageExtras.class at line 1001 (gallerycoreapi::error)
    * in modules/core/classes/GalleryStorage.class at line 505 (gallerystorageextras::addmapentry)
    * in modules/core/classes/GalleryCoreApi.class at line 2833 (mysqlstorage::addmapentry)
    * in modules/core/classes/GalleryEmbed.class at line 846 (gallerycoreapi::addmapentry)
    * in /home/pathtomysite/sites/all/modules/gallery/gallery_base.inc at line 89 (galleryembed::addexternalidmapentry)
    * in /home/pathtomysite/sites/all/modules/gallery/gallery.module at line 205
    * in ??? at line 0
    * in /home/pathtomysite/includes/menu.inc at line 418
    * in /home/pathtomysite/index.php at line 15

Severity	error

A temporary fix to show the block would be great! Unfortunately, I'm a bit of an ignoramous when it comes to working in the DB. I found the table you mention, but I don't know how to delete the record for /portfolio! Sorry! I'm using phpMyAdmin.

salaam-
paul

Profix-

Thanks so much for trying to help with the problem.

Also thanks for the very clear steps in phpmyadmin. Unfortunately it wouldn't take! I don't know why, but I delete the contents of the pages field:
portfolio
portfolio/*
and below it says "Save" and then "Go back to previous page". When I save it keeps the old data. Nothing changes!

I ran into all sorts of weird problems as well as soon as I set the embedded path to "gallery" - the gallery itself would work fine but as soon as I wanted to administer anything related to Gallery in Drupal, I would get errors similar to yours. I eventually tracked it down to the .htaccess file.

Commenting out this rewrite rule

    RewriteCond %{THE_REQUEST} /gallery/([^?]+)(\?.|\ .)
    RewriteCond %{REQUEST_URI} !/index\.php$
    RewriteRule .   /index.php?q=gallery&g2_path=%1   [QSA,L]

(just insert a '#' without the quotes before each line) would get rid of the error and allow me to do my admin tasks, but also make internal Gallery links stop working. Uncommenting them again would get Gallery back to work but lead to the same errors for admin tasks. In any case it allowed me to do my admin stuff at all, but it seems awkward. Eventually it dawned on me that the reason is that the paths in all those cases contain the string "/gallery/" somewhere, which trips the rule. So I read up a bit on htaccess syntax and found that changing the first line above to

    RewriteCond %{THE_REQUEST} \ /gallery/([^?]+)(\?.|\ .)

does the trick - for me that makes it all work without a problem.

I know that the .htaccess file says it should not be manually modified but as Gallery totally messes that up anyway every time I make any minor change in the "URL Rewrite" settings - such that I only get "500 Internal Server Error" and the like when trying to connect - I have taken to keeping a backup copy of it around, copying that back into place after any changes and modifying it manually. A bit more tedious than I'd hoped but it works.

I hope this helps. If anyone has any clue as to why my .htaccess file is being rendered useless after any URL Rewrite changes in Gallery I'd also be very interested to learn about it.

Cheers,

Ronald

Thanks for the URL, I had not seen that before and indeed it seems to be about the same problem.

I did use /gallery/v/%path% at first but found that just plain ugly. I then tried other words like "album" but that did not work, either.
As for the suggestion in the codex to use %{THE_REQUEST} ^/gallery/([^?]+)(\?.|\ .) I had tried that and it did not work, the reason being that the actual request "THE_REQUEST" refers to looks something like "GET /gallery/path/to/item", i.e. the requested path is preceded by a blank space - thus the "\ " in my suggested solution - and not the start of the line as "^" would suggest. (The proper regex I've seen somewhere looked like "^[A-Z]{3,9}\ /gallery/([^?]+)(\?.|\ .)" but I was being lazy and thought the leading blank should be safe enough for a clear match.)

It now works for me and it's good to see that the reason and a work-around for the problem are actually presented in the documentation even if I did not find that when fighting with the problem.
I am still not sure whether I am doing something wrong to cause the .htaccess to get all mangled with any change to the URL rewrite settings, but I'll try and set up a test site straight from scratch and see how I go.

There is one thing I am not clear about at all and that's whether .htaccess files are needed in both the drupal root and the gallery2 base, and if those are meant to be identical. I seem to remember needing both, and running into problems when they went out of synch, so I ended up using just one file (in the gallery2 base, because gallery2 is really persistent about following all symbolic links it encounters) and a symbolic link in the drupal root, but have no idea if that's a good solution or rather part of the problem. It seemed to work best back then and there but I don't remember all the facts anymore.

Thanks again & best regards,

Ronald

@profix898: Wow, I'm now a member of sourceforge as well - never dreamt of that!
Thanks for your quick response.
I actually did try the "edit" link on the 'Troubleshooting' page but was told to register yet somewhere else first and was not 100% sure about my entitlement to do that, either.

As for the two .htaccess files, my occasional use of the standalone Gallery might have been what caused me problems with them but it has also been a life-saver at times. However I noticed that even in embedded use when I comment out lines in the gallery2/.htaccess files I get to a point where the embedded gallery stops working - my guess is that at some point everything does need to be directed to gallery2/main.php one way or another and the .htaccess may somehow interfere with its operation. Oh well, just speculating as I really don't quite understand how this whole URL rewriting business works in practice.

Well in my case when I hit submit in the "URL Rewrite" form under "Site Admin" it pretty much overwrites everything in the URL Rewrite section, and some (many) of the entries make even less sense to me than they do anyway. For starters it changes the "RewriteBase" - if I'm lucky just from "/" to "/gallery2/", but usually it writes "/http://www.mysite.com/". Which just looks wrong, or maybe it's not and I am. And then it introduces heaps of direct references to "/gallery2", and removes pretty much all references to "/gallery", e.g. changing "/gallery/v/%path%" with "/v/%path%". Bottom line is that Gallery reliably and reproducably stops working and I have not managed to get it back to work by manually editing the file so I just replaced it with a known working backup and then manually implemented any changes there.

Ah, we're getting to my pet peeve! ;)
Yes, moving the code to about anywhere and linking it in works just fine. As long as it's all in the one place. What I've been doing with about everything else, though, is to have the code in one place and symlink to it from multiple places. If I want to make changes to a particular instance I replace the symlink with a local copy of the file or directory and modify that. This works just fine with Drupal, all its modules, themes, and quite a few other products as well. Not with Gallery.

For example, assume you have two directories a and b, with each containing a symlink to the modules directory in the code base directory (c). Now if I want to add a particular module just in location a, I delete the symlink to c/modules, create a directory a/modules and fill it with symlinks to the items in c/modules. If I want to modify one of those modules (say "m"), I delete the symlink for it, create a directory a/modules/m and fill that with symlinks to everything in c/modules/m, then I replace the symlink to the file I want to modify with a local copy and modify that. Or I could, in case of Gallery, create a subdirectory "local" and put the copy in there, only that it will not find it because it will not even look for a/modules/m/local but only for c/modules/m/local because it fully dereferences all the symlinks. Why?
In case we talk about Drupal modules, Drupal will quite happily go to a/modules and work with whatever it finds there - it does not care whether what it handles are real files and directories or just symlinks to those (a bit like cd and pwd work in sh/bash) - it does not care where the stuff it handles really lives as long as it can read it, and will happily assume that all the files and directories live in a/modules/m even if they are just symlinks pointing to somewhere completely different.

Gallery, on the other hand, fully dereferences all symlinks wherever it encounters them, so if the symlinks in a/modules point to c/modules it will work there and only accept what it finds there, ignoring all the good stuff living locally in a/modules. A bit as if you were using cd and pwd -P in sh/bash all the time, rather than cd and pwd.

So Drupal (and most other projects) will just be fine believing that it's handling file "x" in a/modules/m while Gallery will see that x is just a symlink, insist on following that and then try to do everything at the location where the actual file lives that it points to.

This really drives me nuts because using the symlinks as described above is really a super-simple way not only to run multiple installations off one code base, but also up- and downgrade them extremely easily and independently from each other. Swap in and out modules, themes, modifications, etc, just by creating or changing single symlinks. Only that Gallery does not play ball with me and I don't have a clue why it does what it does when most other projects seem to be working just fine with the somewhat more naive/ignorant approach which would make my life so much easier. I managed to trick it into believing to run in the local installation by fiddling with the *.inc files in the /gallery2 directory, but as soon as modules or themes become involved I am stuffed again.

(And yes, I know that there is a multi-site install option as well but that does not support one crucial feature I was after - forgot what it was but found it important at the time - and also to me it looks a bit like a work-around/kludge for a problem that might better be avoided to start with. And I don't see how that allows me to switch back and forth between different code-bases as easily. I may well be missing something important but in that case would really like to know what that is. Or otherwise how to get around it.)

Sorry, I did not mean that as a rant at all, just sometimes get the feeling I'm shaving yaks. 8)

Ok, I might have been digressing a tad, though I'd really honestly be interested to know if there is a deeper reason for this different approach, and something that can be done about the problems I'm having with it.

Anyway, enough of that - didn't mean to distract from the actual topic at hand!

Thanks again & best regards,

Ronald

Hi profix898,

Sure, I'm happy to discuss this whenever it suits and hopefully I'll have made some more progress until then.
If you just post here again I will get a notification and be back, too.

Thanks again & talk to you later,

Ronald