I am using the Image module, and Image Gallery module, and have several images.
In fairness, I am also fairly new to Drupal.

I recently upgraded a test website from Drupal 6.11 to 6.12 following the Upgrade.txt file instructions.
When the upgrade was complete, the Image Import feature no longer presented an option to select the gallery when uploading.
I also noted that the Images Edit page no longer presented an option to change galleries. In both cases the field was not present.
I thought nothing of it as I was new to this and as it was a test site, I could afford to rebuild it.

I am now practising backing up, copying and moving Drupal installations. Before backup, I set the site into Maintenance mode, disable all non-core modules, and disable caching. After copying or moving the installation and updating settings.php, I re-enable all modules, reset permissions, enable caching and remove Maintenence Mode. I reenabled both the source site and the new target site.

All seems OK except that once again the field to select the Gallery is missing in both the Import Files page and the Image Edit page. I can display and scroll through galleries, and view and edit images, but the field to select/change gallery is not presented. The problem exists on both the source and the target websites.

Is this me doing something wrong, or is this a bug?

Thanks in advance.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

joachim’s picture

Status: Active » Postponed (maintainer needs more info)

> disable all non-core modules

I suspect this could be the problem, and that disabling image module makes the vocab get deleted or altered in some way. Or that on re-enabling image module, it doesn't pick up on the existing vocab.

Things to check:
- the vocab exists still
- the vocab image module thinks it is using -- install devel module and check the value of the variable 'image_gallery_nav_vocabulary' in the variable editor. It should be the vocab ID of your gallery vocab.

maxweld’s picture

Solved

The vocabulary is losing the link to the Image Types where it can be used.

Select Administer > Content Management > Taxonomy then edit the Image Galleries vocabulary, then set the allowed content types, i.e. Check the Image content type.

I checked for other vocabularies, and these have not lost the link, so this seems something particular to Image Galleries.

Thanks

maxweld’s picture

Category: support » bug

I think this needs to be fixed.

joachim’s picture

Title: Can no longer select/change Galleries after upgrade » Disabling then reenabling image module makes the gallery vocab forget about images
Status: Postponed (maintainer needs more info) » Active

It's not even an upgrading Drupal problem:

- disable image_gallery and image
- re-enable them
- the gallery taxo has lost images

This is quite possibly a core bug -- will check with forum module.

(I don't even know why Drupal upgrade handbook says to disable contrib modules -- it's nothing but hassle).

joachim’s picture

Priority: Normal » Critical
Status: Active » Needs review

Forum gets round this by implementing hook_enable to check for an existing vocab, and reassigns the node type to that vocab if so.

Here's a patch that copies that approach.
I've tested it on my system. If you could test it too (just disable all image modules then reenable them, check that the galleries work again) that would be great :)

I've left the creation of the vocab that's also in _image_gallery_get_vid as there may be legacy issues. Also, _image_gallery_get_vid re-creates the vocab if it gets deleted. Before removing that we should look at preventing the deletion of the gallery vocab.

joachim’s picture

Version: 6.x-1.0-alpha4 » 6.x-1.x-dev
FileSize
1.54 KB

Helps if I attach the file :)

joachim’s picture

Looks like I already created this patch here: #452268: Create gallery vocab on install and forgot about it ... :D Let's stick with this one -- they're almost identical anyway but on this one I indented the array nicely.

asb’s picture

Hi,

after upgrading from image module 5.x-2.0-alpha3 to 6.x-1.0-alpha4 I lost access to the image galleries.

Symptom: access to a gallery, e.g. image/tid/1917, results in "Zugriff verweigert" (Access denied) for user #1; this error is displayed for users as well as in the watchdog log.

I searched the issue queue for similar issues, and this was the closest. I can confirm that during the upgrade from Drupal 5.18 to 6.12 the connections between image module and the gallery vocabulary are lost (as well as the connections between other vocabularies and custom content types). And yes, I followed the Upgrade instructions from Drupal.org and disabled all modules before running update.php; Viktor Kane opposes to this in his book "Leveraging Drupal", maybe I should have listened to his advice ;)

However, restoring the settings seems to be simple; the access problem remained. The patch from #6 applies cleanly:

# sites/all/modules/image# patch -p0 < image_gallery_enable.patch
(Stripping trailing CRs from patch.)
patching file contrib/image_gallery/image_gallery.install
Hunk #1 succeeded at 30 with fuzz 1.

So I have a different issue, damn. Opening a new one, sigh...

Greetings, -asb

joachim’s picture

Applying the patch will only have an effect for subsequent disabling and re-enabling of the image modules -- so on future upgrades. It can't and won't fix the problem from old upgrades. (Well, you can disable and re-enable image module and that will restore the connection).

Try disbling & renabling image_gallery and image with the patch applied and see if the connection between the gallery vocab and image nodes is there once you re-enable.
If you can confirm it works then that would get us one step closed towards committing this patch.

As for access denied, I don't know -- perhaps another issue indeed.

sun’s picture

Ugh. Ugly (core?) bug.

On that note, image_gallery_requirements() looks like pretty nonsense to me.

Also, image_gallery_install() is (more than) superfluous.

However, image_gallery_requirements() uses _image_gallery_get_vid() to retrieve the vocabulary id. Does that make sense?

Also, I'd prefer the condition/test like it is done in image_gallery_uninstall(), i.e. check the variable first and don't try to load a vocabulary with the id NULL :)

Holy! Updates like image_gallery_update_1() we should remove. I wonder who coded that.

joachim’s picture

It looks like image_gallery_update_1 might date back from when image_gallery was splice out of image module? Just guessing, this is way before my time. But the module associated is getting changed. Might image_nav_vocabulary be the old var name? That should have got updated too, but soooo old probably not worth it.

I'm not sure I've ever seen the warning from image_gallery_requirements. It makes sense to tell the user to create some galleries, but not in requirements -- a simple dsm() would suffice I think! hook_enable was new for 5 and a lot of the way this module works dates back from 4.7 or older. I would say that's why it's image_gallery_requirements doing all this mucking about. I reckon we can probably delete image_gallery_requirements(). And I reckon we can do without image_gallery_install() too :)

asb’s picture

@joachim (#9):

> Try disabling & renabling image_gallery and image with the patch applied and see if the connection between the gallery vocab and image
> nodes is there once you re-enable.

I tried that with the patch applied, and the image content type <-> gallery vocabulary connection remained, so I'm giving this patch a 1+ ;)

However, I did not try another D5 -> D6 migration with this patch applied.

Greetings, -asb

libre fan’s picture

Hello there and many thanks for the useful patch but how do you apply it?

Just paste into sites/all/modules/image/contrib/image_gallery/image_gallery/ as image_gallery_enable.patch
???

or should the content of the file be pasted into sites/all/modules/image/contrib/image_gallery/image_gallery/ as image_gallery.install
???

Sorry to sound so dumb

As I couldn't wait - such a great module Image is - I simply uninstall totally and made a fresh install of the module from a new download. Gallery works fine, now (only have one image in the gallery so far).

joachim’s picture

Information about patches can be found at http://drupal.org/patch/apply

joachim’s picture

sun: should we clean up image_gallery_requirements and image_gallery_install in this patch or another?

maxweld’s picture

Just tested the patch and it works fine.

Its the first time I have used patch command so interesting.

Thanks.

sun’s picture

FileSize
5.07 KB

New patch; needs testing.

andrewmacpherson’s picture

Status: Needs review » Needs work

Joachim's image_gallery_enable.patch from comment #6 worked for me.

Sun's newer image.enable.patch from comment #17 didn't work.

I tried both using a fresh download from CVS each time.

joachim’s picture

Status: Needs work » Needs review
FileSize
4.17 KB

New patch based on sun's patch:
- kill hook_requirements
- add hook_enable, which calls:
- a modified _image_gallery_get_vid.

The code comments and clean-up I've already committed separately.

sun’s picture

Uhm, not quite - you committed a bit more for the .install file ;)

Thanks for reporting, reviewing, and testing! Committed attached patch.

A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.

sun’s picture

Status: Needs review » Fixed
joachim’s picture

OOPS!
That clean-up commit was meant to be those code style changes in update_1. No idea HOW that happened :(

Thanks for watching my back.
We can mark this as fixed now :D

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

joachim’s picture

Status: Closed (fixed) » Active

This is still broken in latest Alpha and HEAD.

The test is to disable *image* module, rather than image_gallery -- the module that supplies the node type.

$ drush disable image --yes
$ drush enable image_gallery --yes
joachim’s picture

Status: Active » Fixed
FileSize
1.76 KB

I am adding in the hook_enable from the patch at #6 -- it's from forum.module, we know it works, and I've just tested it.

_image_gallery_get_vid() is too complex and covers too many cases without explaining what these cases are or what it is testing.
I'm going to leave it as is rather than revert since it may be covering cases such as what hook_requirements used to?
Perhaps sun can shed light on this and clean it up later.

Committed attached patch.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.