I get the following notices when viewing an image page (gallery-item node). As far as I can tell, this message only appears for images whose thumbnail is NOT present on the first page of the gallery.

    Notice: Undefined offset: 1569 in node_gallery_api_get_item_position() (line 825 of ...\sites\all\modules\node_gallery\node_gallery_api.inc).
    Notice: Undefined offset: 1569 in node_gallery_api_get_item_position() (line 825 of ...\sites\all\modules\node_gallery\node_gallery_api.inc).
    Notice: Undefined offset: 1569 in node_gallery_api_get_item_position() (line 825 of ...\sites\all\modules\node_gallery\node_gallery_api.inc).

The offset varies for each image, obviously, but the rest of the message is always the same, and it is always repeated three times.

As a result, the pager (navigator) is broken in several ways:

  • the "first" and "previous" links are not shown
  • the "next" link actually leads to the first image of the gallery
  • the "last" link actually leads to the last image of the first page of the gallery
  • the "return to gallery" link leads to the first page of the gallery. I don't know if it's the intended result.

Another thing I noticed: on images that are on the first page of the gallery (no errors, navigation not broken), the "last" link also leads to the last image of the first page, not the last image of the whole gallery. The other links work as you would expect.

And on the last image of the first page of the galley, the "next" and "last" links aren't shown. (As if it was the last image of the whole gallery and the other pages didn't existed.)

I tried switching to the dev version of node_gallery, but apparently it hasn't solved the problem.

Comments

s427’s picture

Interesting: when I posted my message above, I had made modifications to the view responsible for displaying the thumbnails grid, in order to show more images on a single page (50 instead of 20). After posting my message here, I tried canceling those changes to the views, to see if it would solve the problem.

At first I thought it had worked: the error messages were no longer visible on the images of the second page of the gallery, and the navigator seemed to work again correctly.

But then I realized the problem was still here: only it had been pushed to the third page of the gallery!

So basically, before cancelling my changes I had 50 thumbnails per page, and only the images on the first page worked correctly.
After cancelling my changes to the view, those 50 first images were still working correctly, even though they were now displayed on three separate pages. But the following images (51 etc) still had the problem.

I tried deleting all the images in the gallery and re-uploading them, and now only the first 20 images work correctly, and the following (21 etc) still have this problem.

So it seems the problem is related to the number of thumbnails per page, as defined in the view at the moment when the upload is done. (I use the plupload integration, btw.)

s427’s picture

Priority: Normal » Major

Since I'm working on localhost with a lot of modules enabled, I was wondering if this bug was caused by some other module interfering.

So I started a brand new Drupal 7.34 installation on a different (empty) folder, using a different (empty) database, and I installed only node_gallery and its required modules (including plupload). I didn't change any configuration and I created a new gallery. Then I uploaded about 200 small images in this new gallery, using the plupload integration.

The problem is still here: when viewing an image on the first page of the gallery, the navigator only acknowledges 24 images in the gallery ("1 of 24"); the "last" link only goes to the last image of the page; and when viewing an image in any of the following pages, the navigator is broken and the same notice (undefined offset) is displayed 3 times.

Here's the list of all non-core modules I'm using on this installation:

Chaos tools                          7.x-1.5
Entity Reference                     7.x-1.1
File entity                          7.x-2.0-beta1
Plupload integration module          7.x-1.7
Node Gallery                         7.x-1.0+5-dev
Node Gallery API                     7.x-1.0+5-dev
Entity API                           7.x-1.5
Views                                7.x-3.8

As I mentioned earlier, it also occurs with the non-dev version of node_gallery.

I also tried disabling and uninstalling plupload. Then I created a new gallery and I uploaded 27 images manually. Sure enough, the same notice began to appear starting from the 25th image I uploaded (i.e. first image on the second page of the gallery). So it's not related to the plupload integration.

Since I'm not a developer, I think this is as far as I can go in order to debug this problem... I'll gladly provide more information if needed.

The following steps allowed me to "kinda" fix the problem:

  • edit the view node_gallery_gallery_item_views and set the pager option to show a bigger number of items per page than the total number of images in the gallery (e.g. 1000 items per page)
  • clear the views cache
  • visit the gallery page (every image is now on the same page and the navigator works correctly for all images)
  • revert the change made to the view (e.g. 24 items per page)
  • going back to the gallery page: the navigator still works for all images, even for images that are not on the first page of the gallery

But of course this only lasts until the views cache is cleared again...

hepabolu’s picture

I can confirm this behaviour. I noticed it too, although I haven't gone as far as s427 to find a workaround other than increasing the number of items on a page. I use the same versions of these modules.

DSHolmstrom’s picture

I tried the hack of increasing the number of items and then reducing it in the view. It works if you increase it before you upload the image. for example I set the view to display 100 items then uploaded 30. Then I set my view back to 24 and the gallery worked.

I tried in another gallery that was already broken to set the number up to 100 and then reduce it and this did not work for images that were already uploaded. They displayed with error messages and the pager did not work to go from page 1 to page two.

So it seems for this hack to work you have to first set the number very high, upload your gallery then reduce it to the number per page you want.If you want to add to the gallery first increase the number to display and upload and then reduce it again.

Not the worst thing and I hope the information helps temporarily and possibly to find the bug.

DSHolmstrom’s picture

I just installed the latest release 7.x.1.1 and it still happens.

s427’s picture

@DSHolmstrom: I don't think you need to change the number of items per page before uploading the images. It works, yes, but in my experience, what really matters is the state of the view when its cache is built. So even after uploading the images, you can change the number of items per page, clear Views' cache (in Views > Settings > Advanced), then rebuild it by visiting the gallery, and then change the number of items back to what it was (lower).

This means that this "solution" will only hold for as long as the cache is not rebuilt. I don't really know when that happens, so I'm afraid it's not a very reliable solution...

For now I have also increased the number of items per page to a large number, in order to avoid the problem altogether. But some of my galleries have several hundreds of images, which make them very slow to load... So I hope this gets fixed soon.

Samfall’s picture

I think this may be related to the issue here: Only 24 photos on "Manage items" page

A friend of mine came up with a solution that he'll be posting to that thread soon. It appears that when the program goes to find the node ids that belong to a certain gallery, it has difficulty identifying all of the nodes because of the pager value in the view. If you reset the pager value of the view in the function that grabs the nodes, it will more correctly identify the nodes in the gallery.

In other words, our solution may help you. I will post a link when we upload it.

s427’s picture

@Samfall: I assume you're talking about the patch submitted by whoisinkus a couple of days ago: https://www.drupal.org/node/2280221#comment-9778647

I just tested it and it does seem to fix the problem! Thanks a lot for notifying us here!