There are no images in this gallery.

Hi,

similar problems here with all versions of the "image" module from 5.x-1.6 until 5.x-2.0-alpha3, currently running under Drupal 5.10:

Accessing www.example.com/image results in:

%1

There are no images in this gallery.

When removing the argument handling code (http://drupal.org/node/207198)

$args[0] = $args[1];
return $args;

from the view, I get:

Image Galleries

There are no images in this gallery.

Sometimes, adding the argument handling code to the image_gallery view fixes sub-galleries; directly accessing a sub-gallery works on some sites, on others with seemingly identical configuration of the view it does not work. On those sites where sub-galleries seem to work, clicking in the root gallery in the breadcrumb results in "There are no images in this gallery" while on some other sites the sub-galleries are displayed with thumbnail and name. Very strange and very erratic as it seems.

Has anyone managed to fix image galleries with current Drupal and image module versions?

Thanks & greetings, -asb

Hi!
Similar problem after Drupal update (6.3 to 6.4) and Image module update (6.x-1.0-alpha2 to 6.x-1.0-alpha3). I can see the gallery tree, images count and date of last change but no image is displayed.
Michalic

Edit: That was probably a cache issue. It works now.

Check the views API trouble issue ... http://drupal.org/node/220295 - do you see any change if you downgrade to an earlier version of views?

@Hetta: You're muddying the water: The issue that you're pointing to is about Views2 for D6. This thread is about D5.

This is still completely broken in the 2008-12-21 -dev snapshot. I upgraded from 1.9 to that version and I'm seeing exactly what asb described in #1.

This issue is blocking the upgrade path to D6 — the front page says "If you're upgrading to 6.x you need to upgrade to the 5.x-2.x branch of the module in Drupal 5 before before [sic] moving to Drupal 6."

It looks like that is coming from the view's "Empty Text" value. If that true then I'm seeing this a well. But assuming that it doesn't check for images recursively through child-galleries, the statement is correct. In your example there weren't any images directly in "Gallery1" or "Gallery2" (even if there were images in your "Sub-galleries") so the view displayed the Empty Text value. As a temporary fix, you can edit/clear the "Empty Text" textarea from the view in order to change/remove that line.

another cause for similar symptoms:

I just upgraded from 5.x-1.9 to 5.x-2.0-alpha3. The images were displaying in the galleries correctly (after clearing the views cache) but at the top of every gallery was the line "There are 0 images in this gallery" which I tracked back to the theme_image_gallery function. Then I remembered that I'd overridden this function in my theme a while back. I commented out the theme override from my template.php file and the errant line went away.

Marked #299356: There are no images in this gallery. as duplicate of this issue. Is this still an issue? Did you update to the latest version?

I've upgraded past 5.x-2.x to D6 and everything is fine there.

This made me VERY nervous when upgrading from 5.x-1.9 — having to pass through a broken version for making "the big jump" is more than a nuisance, but after getting to D6 (and solving some permission issues) it's stable again.

Personally, I have no more interest in investigating this any further.

Well, could someone please at least explain and summarize *why* the upgrade to 5.x-2.x is required first?

The module update functions are identical in 5.x-2.x and 6.x-1.x, so I do not see a reason for why the updates in 6.x-1.x would not be sufficient.

I have no idea, but http://drupal.org/project/image leaves no doubts...

An update from 5.x-1.x over 5.x-2.x to 6.x is required because the 2.x upgrade introduces a new table, which is required in 6.x.

There were LOTS of broken 5.x-1.x to 6.x upgrades in the issue queue (and I expect there still are), with various work-arounds, most of which boiled down to: get your database backup, upgrade image to 5.x-2.x and then do the 6.x thingies.

Yeah, but the natural procedure is to check that everything is ok before making the jump to D6, and having a dysfunctional 5.x-2.x is a major obstacle.

In my experience with a few smaller sites, most of the problems went away once I got to 6.x-1.x, but it's a very bumpy ride...

I've opened an issue for the same problem at http://drupal.org/node/367523.

Anyone having solution please post.

upgraded from 5.x-1.9 to 5.x-2.0-alpha3 today to be ready for 6.x when necessary... and now I don't see my images in the galleries. the title of the gallery and then the footer of the site and that's all.

Running into the same problem on 5.xx. Subscribing and crossing fingers for a fix, I'd love to use this.

@sun: check with drewish about why the passage via 5.x-2.x is required? I'm guessing he put that note there. I also wonder why it's needed -- surely when you upgrade to 6 the system would know the last update function for this module and run the 5200 function first? I admit I don't know this for certain.

To other commenters: I am trying to understand the exact problem.

Do you:
a) get "no image" text in galleries where there SHOULD be images?
or
b) get "no image" text for parent galleries which happen to have only child galleries and no images?

Because if b), there's not much we can do about it. You can customize the view and remove the empty text -- that is what you are seeing. Or you could code some PHP in the empty text that checks the vocabulary tree for child terms... but that's a fair bit of work

This view is not clever enough to know that there are child galleries. What you're seeing is a combination of hard code for the child gallery list, and a view for the current term, so the view can't be selective about when it shows the empty text.

So:
if a), please provide further details.
if b), we can close as by design.

@joachim: Thanks for taking this on.

There is no special meaning in the update functions. "5200" can be treated cosmetically; all updates are run chronologically, so when updating from 5.x-1.x to 6.x-1.x the updates for 5.x-2.x are executed as if you would update to 5.x-2.x first.
The only other thing I'm aware of is a table name mismatch between 5.x and 6.x, which has been fixed in #257743: 6.x upgrade error: Unknown column 'f.nid' in 'field list' query.

@joachim (#15):

Usually, a) and b) applies. b) is expected to work since it worked before image galleries were moved to views; if this move was accompanied by a (major) functional degradation, please state this in the project page and/or documentation. Image galleries not indicating that there are sub-galleries are pretty pointless.

Regarding a): What further details do you require (besides those provided in #1)? I can "reproduce" this problem out of the box on every of my five D5 installations I'm running with the default view provided by the module; there is only one exception (for whatever reason on this installation the view isn't used but the old image gallery module, thus the image gallery do work there like they used to).

Thanks & greetings, -asb

Regarding b) -- there is a tradeoff here. Using views to build galleries gives you a lot of control over their display, their placement, their ordering, and so on. Downside is you get this message. IIRC you can choose to use hardcoded galleries instead of views galleries, or you could remove the empty text message.

It does indicate there are subgalleries though, doesn't it? Just gives you the 'no images here' message below the subgallery thumbnails. Or am I not understanding properly?

Regarding a)
Can you explain again the problem and give me clear instructions on how to reproduce this. Does it require an upgrade from 5-1 to 5-2 to reproduce?

Regarding b)

> IIRC you can choose to use hardcoded galleries instead of views galleries [...]

...that would be nice and give me back the image galleries on my sites I lost several months ago ;)

> or you could remove the empty text message.

...that would not help much (empty page without error message doesn't help at all).

> It does indicate there are subgalleries though, doesn't it?

No, it doesn't, exactly that's the annoying point.

* The old "image galleries" module displayed nested sub-galleries inside another gallery with one image, the title of the gallery, and a short description.
* The new "image galleries" view shows the gallery's title, the error message and nothing else. Sub-galleries are not identifiable through the view.

Regarding a)

> Can you explain again the problem and give me clear instructions on how to reproduce this.
> Does it require an upgrade from 5-1 to 5-2 to reproduce?

That's the hard part. Yes, I think updates might be involved; and yes, I think something happened when moving to the 5.x-2.0-alpha branch. I can not remember more precise, it broke such a long time ago. If this definitely doesn't occur with fresh installations (what I haven't tried), reproducing will be really tough; at least my affected sites don't show a consistent behaviour, and this might be because auf their different age (and thus the inital version from which using the "image" module started), or because of manyfold edits of the view and the configuration.

From my five still running D5 sites, I'm getting the behaviour as follows with "image" module version 5.x-2.0-alpha3 (all updates through update.php went well, all other modules are kept at their recommanded releases); all sites contain image nodes, organized in galleries and sub-galleries:

* Site "K", started with Drupal 4.4 or 4.5; "Image gallery" is working more or less fine; "Views" module is installed, but Image gallery doesn't use a view; sub-galleries are listed with image, title, and description; neither root nor sub-galleries display "edit" local task, so most probably absolutely no image gallery view is used.
* Site "C", started with early version of Drupal 5, Image gallery uses view; doesn't work out of the box, but workaround (Argument Handling Code referenced in #1) makes it work partially: root gallery at /image is empty and says "There are no images in this gallery"; sub-galleries mostly do work; sample export provided as "image-gallery-workaround.txt";
* Sites "E" and "M", started with Drupal 5.x, Argument Handling Code; sample export provided as "image-gallery-broken.txt";
* Site "F", started as site "C", but shows behaviour like sites "E" and "M".

Now to the fun part: all root galleries become availabe if I change "Provide Page View - URL" from /image to /image/$arg; however

* /image seems not to be a view (no "edit" local task; are there other indicators?), but when clicking into a sub-gallery, I'm getting a view;
* sub-galleries (1st level) that contain further sub-galleries (2nd level) are not listed;
* I'm getting a very strange breadcrumb:

Startseite » Image galleries » Uncategorized » Bildergalerien » Opernaufführung

Pointing to: / » /image » /image/tid » /image/%24arg » /image/1862

That doesn't represent the vocabulary; "Opernaufführung" is a root term

Summary (including some assumptions):
* As long as no image gallery view is used, I'm getting no trouble; I have not the slightest idea why the view isn't used;
* as soon as the image gallery view is used, image galleries break completely (no sub-galleries are indicated, all galleries are empty);
* In case "C", the Argument Handling Code from #1 fixes the image gallery partially, in three other cases it has no effect;
* changing /image to /image$arg plus adding the Argument Handling Code fixes cases "E", "M", and "F" partially, but breaks the breadcrumb path.

So far my observations; the more I'm writing, the more confused I get, sorry.

Thank you very much for having a look into this issue!

Greetings, asb

Yikes. Thanks for being so comprehensive with your details!

I've just taken a look at my D5 installation.
First problem that springs out -- the default gallery view tries to be at the path /image, and yet the code is geared towards *always* handling this itself. That's a total bug. The default view should NOT get a path. If the default image is at /image, then when you go to that path you'll get JUST the view and nothing more. The view alone is not capable of showing child galleries. So yup, you'll get just the empty text.

Can you try overriding the default view to set its path to something -- anything to move it out of the way -- and then see what you get at /image? Keep it enabled though, as that is the test the module does to see whether to use the view to build the gallery.

Applying the patch from the image modules directory gives me:

/var/www/drupal/sites/all/modules/image# patch < image_gallery_remove_view_path.patch
(Stripping trailing CRs from patch.)
patching file views_defaults.inc
Hunk #1 FAILED at 25.
1 out of 1 hunk FAILED -- saving rejects to file views_defaults.inc.rej

Contents of views_defaults.inc.rej:

# cat views_defaults.inc.rej
***************
*** 25,31 ****
    $view->page_empty = t('There are no images in this gallery.');
    $view->page_empty_format = '1';
    $view->page_type = 'image_gallery';
-   $view->url = 'image';
    $view->use_pager = TRUE;
    $view->nodes_per_page = '6';
    $view->sort = array (
--- 25,30 ----
    $view->page_empty = t('There are no images in this gallery.');
    $view->page_empty_format = '1';
    $view->page_type = 'image_gallery';
    $view->use_pager = TRUE;
    $view->nodes_per_page = '6';
    $view->sort = array (

To get the view named "image_gallery" out of the way:

* Relabeling the view's path from /image to /image2, saving view
* Accessing /image, gives me the classical image gallery without "edit" local task (= no view)
* Sub-galleries are listed with image, title, and description;
* Clicking on a sub-gallery, saying "There are 7 images in this gallery" gives me: "There are no images in this gallery" (and an empty gallery).

* Removing any view's path from the view, making it inaccessible through an URL; still no images in sub-galleries;

Now to the fun part: removing the Argument Handling Code from the view:

$args[0] = $args[1];
return $args;

WOW! The image galleries are there!

* /image gives an overview over the available galleries - working;
* sub-galleries have images and are being displayed through the "image gallery" view - working;
* Breadcrumb trails are still broken - partially working;

Trying to reproduce solution on other sites

* Not applying patch;
* Removing URL path from view;
* Removing Argument Handling Code;
* Clearing views cache at /admin/build/views/tools;

Image Galleries still (again) working: YES!

Some minor to dos to finally close this:

* Broken Breadcrumb paths (maybe posting another issue); the site not using views in sub-galleries gives good paths (why the heck isn't this site using "image gallery" views? URL path is configured to bilder/galerie - arghh; removing path from view, now it becomes consistent and uses the "image gallery" view in sub-galleries)
* Rolling a new patch
* Getting "Image" module out of alpha stage ;)

Thank you very much for this great hint!!

Greetings, -asb

So we've a partial fix?

* Clicking on a sub-gallery, saying "There are 7 images in this gallery" gives me: "There are no images in this gallery" (and an empty gallery).

Can you confirm that you're seeing the view, not the hardcoded version? Set the view empty text to something like "this is the view and it's empty!".
Also, try disabling the view and see if you get images back.

EDIT: ah, I see we had a comment clash -- you edited yours while I was posting this!
About the patch -- GAH. Patches seem to hate me of late :/ It's actually another patch here that we need to rollback which I hadn't seen earlier: http://drupal.org/node/295293

Broken Breadcrumb -- yeah, another issue probably.

Getting "Image" module out of alpha stage -- yup, I'd like that very much :)

We were writing at the same time ;) Yes, from my point of view the issue is fully fixed, I reproduced it on all my five D5 sites; breadcrumb paths are a secondary problem (many modules involved, separate issue). Let's hear what the others say, by I think we can change the status to "fixed".

It feels great to get image galleries back after morethan one year being "offline" ;-)

Greetings, -asb

same issue here galleries all appear empty unaccessable now although image imports / individual image nodes still work

I disabled image_gallery view from views and the galleries seem to be working atm.

not sure how to apply a patch, or subscribe to this thread. no clue how to remove argument handling. I dont have an option for clearing views.

* Not applying patch;
* Removing URL path from view;
* Removing Argument Handling Code;
* Clearing views cache at /admin/build/views/tools;

Hi,

i've edit /sites/all/modules/image/contrib/image_gallery/views_defaults.inc

and comment the line
// $view->url = 'image';

like in the patch, just that, and it's work fine now.

++

I've followed all the steps in #22 and have got to the point of seeing the galleries with title and descriptions and numbers of images listed .Very happt to see them back. I still get however , when going to one of the sub galleries they sre still empty and showing the 'There are no images in this gallery.'.
My steps -
* Not applying patch;
* Removing URL path from view; ( I just removed image from the url field
* Removing Argument Handling Code; ( this one I'm not sure about how to do , so I added the code from #22 to the argument handling code ?? )
* Clearing views cache at /admin/build/views/tools;

From no subgalleries , at least now I can see them , but no images showing in them .
What have I done wrong ? thanks for any help

Solved . Turns out it was the taxonomy argument in views which was set to no text , changed to Display all values , and I have my galleries back woohoo.
hummm. Not really. Now i have latest images in every gallery .

I'm pretty sure the taxo arg is meant to be set to no text, otherwise you'll get everything when there is no argument.
You possibly need to remove the view URL from the code rather than just the override. Only thing I can think of.

Thanks Joachim.
Yes, I deleted the view , made a new one and set it to text after the upgrade to 5.x.1.9 , and its all working again properly now. I cant see how the upgrade did anything . However its all working beautfully again. Very grateful for this thread, and thanks for your assistance.

This was fixed by the rollback of #295293: image_gallery defines view without URL set.