Conflict with i18n: Sorting/Managing Galleries empty - uploads failing (Dev broken?) [#801012]

I have this issue on two different installs. I tried with Drupal cache enabled and disabled. Running latest .dev.

Both screens display empty and only a cache flush brings the images and options on screen. Reloading the page wipes the screen clear again.

If I make any changes on the Manage Images screen I get redirected to http://localhost:8082/acquia-drupal/de/node/ and nothing changed...

Uploading images "seems" to work but no image is displayed even after a cache flush. Sidenote: Upon uploading the images I now cannot set title and caption. Is this intended or is something broken?

I cannot track back when this began but I suspect it was after installing the latest dev. Can anybody confirm this mess or is something broken on both of my installs?

Comment	File	Size	Author
#22	i18n.patch	733 bytes	justintime
#7	missing image	19.11 KB	dddave
	newly uploaded pic.png	25.34 KB	dddave
	messed-up upload screen.png	26.78 KB	dddave

Comments

Comment #1

dddave commented 17 May 2010 at 12:01

Almost forgot: #710544: Gallery Images not displaying unless cache is clear sounds related although I never noticed such behavior.

Comment #2

dddave commented 17 May 2010 at 12:12

Sounds like a severe problem: http://drupal.org/node/790400#comment-2976700

Comment #3

justintime commented 17 May 2010 at 13:14

I need to get a 2.x install setup again to debug this, but a quick question. Looks like both you and mortality have a "Translate" tab - what module provides this? Can you disable it really quick and see if the problem is between the two modules? I would have thought I would have caught this in my testing, and I don't have that module that you two do. Just taking a stab in the dark...

Comment #4

dddave commented 17 May 2010 at 13:16

Error reporting was set to write only to the log (duuuh):

When I try to change the cover via "Manage images":
Invalid argument supplied for foreach() in /is/htdocs/wp1141249_Q7UT4FKE6D/www/drupal6/sites/all/modules/node_gallery/node_gallery.pages.inc in Zeile 568.
Invalid argument supplied for foreach() in /is/htdocs/wp1141249_Q7UT4FKE6D/www/drupal6/sites/all/modules/node_gallery/node_gallery.pages.inc in Zeile 562.

Sorting images brings up loads of those:

Invalid argument supplied for foreach() in C:\Users\David\Sites\acquia-drupal-site\acquia-drupal\sites\all\modules\cck\modules\fieldgroup\fieldgroup.module on line 611.
Invalid argument supplied for foreach() in C:\Users\David\Sites\acquia-drupal-site\acquia-drupal\sites\all\modules\cck\modules\fieldgroup\fieldgroup.module on line 626.

and those
Invalid argument supplied for foreach() in C:\Users\David\Sites\acquia-drupal-site\acquia-drupal\sites\all\modules\cck\content.module on line 1284.

and finally

Invalid argument supplied for foreach() in C:\Users\David\Sites\acquia-drupal-site\acquia-drupal\sites\all\modules\node_gallery\node_gallery.pages.inc  on line 562.
Invalid argument supplied for foreach() in C:\Users\David\Sites\acquia-drupal-site\acquia-drupal\sites\all\modules\node_gallery\node_gallery.pages.inc  on line 568.

Uploading creates this:
warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, '_node_form' was given in C:\Users\David\Sites\acquia-drupal-site\acquia-drupal\includes\form.inc on line 372. on /upload and when I ignore this and hit save I receive these warnings:


    * warning: Invalid argument supplied for foreach() in C:\Users\David\Sites\acquia-drupal-site\acquia-drupal\sites\all\modules\node_gallery\node_gallery.pages.inc on line 562.
    * warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, '_node_form' was given in C:\Users\David\Sites\acquia-drupal-site\acquia-drupal\includes\form.inc on line 372.
    * warning: Invalid argument supplied for foreach() in C:\Users\David\Sites\acquia-drupal-site\acquia-drupal\sites\all\modules\cck\content.module on line 1244.
    * warning: Invalid argument supplied for foreach() in C:\Users\David\Sites\acquia-drupal-site\acquia-drupal\sites\all\modules\cck\content.module on line 1284.
    * warning: Invalid argument supplied for foreach() in C:\Users\David\Sites\acquia-drupal-site\acquia-drupal\sites\all\modules\cck\content.module on line 1284.
    * warning: Invalid argument supplied for foreach() in C:\Users\David\Sites\acquia-drupal-site\acquia-drupal\sites\all\modules\cck\includes\content.token.inc on line 39.

Comment #5

dddave commented 17 May 2010 at 13:22

@justintime

This is provided by i18n when I allow translations for this content. I'll disable it and try again.

Comment #6

justintime commented 17 May 2010 at 13:33

Also, I wonder if this has to do with the CCK fix. Do you have NG configured to display any CCK fields on the manage images tab? Try setting those to default and see if the problem persists. Since this bug has something to do with the cache, make sure to clear it before testing anything.

Comment #7

dddave commented 17 May 2010 at 13:39

Status	File	Size
new	missing image	19.11 KB

Info:

Both install are multilingual and both are D6.16 patched (http://drupal.org/node/732064#comment-2788744). Don't know if this is related to this.

CCK is 2.6.

I tried with disabled multilingual options for galleries and images but failed. I tried creating new galleries but the uploading doesn't work (messages provided in #4) although the system "thinks" it uploaded an image. See attached pic. Note that the "missing" image is set as cover image. As such it is displayed so the upload was in fact successful.

Comment #8

dddave commented 17 May 2010 at 13:50

Nope, this did not do the trick...

Comment #9

justintime commented 17 May 2010 at 14:46

What permissions does your user have? I just setup a clean install of 2.x locally and didn't get the problem. I did it as the admin user.

Comment #10

dddave commented 17 May 2010 at 14:54

All errors created as UID1.

Comment #11

justintime commented 17 May 2010 at 14:59

That means the error is somewhere in between a clean install, and your two installations. Is it possible for you to start from scratch and try recreating one of the two problem sites and find out when it starts to break?

Comment #12

justintime commented 17 May 2010 at 15:05

Odd question - does your gallery have more than 50 images by chance?

Comment #13

dddave commented 17 May 2010 at 15:22

On one install I have only three images in one gallery. The other install contains dozens of galleries but none of them especially big. Most of them only have 3 to 6 images.

The galleries display without a problem only managing, sorting and uploading is affected. I'll try a vanilla set-up and see what I get. This may take a while though...

This is so odd. Both installs a pretty similar in their basic set up. One is for brutal testing and eats all the modules and changes I want to test out. Some oddities there would be explainable to me but the other is "near-production" and very well taken care of.

I'll keep you posted...

Comment #14

dddave commented 17 May 2010 at 17:10

Just noticed that my "failed" uploads are listed as published by Anonymous and show no content type on the content page...

Comment #15

justintime commented 17 May 2010 at 17:15

No content type would explain the majority of the errors from #4. So, the root problem isn't actually the manage/sort tabs, it's the broken upload. I'm guessing if you delete those nodes that your manage/sort tabs will start working again.

Comment #16

justintime commented 17 May 2010 at 17:22

I think this all might be due to #601186: Image total count not being flushed on failed uploads. There was code in there that failed all uploads and exited if you uploaded 5 images and had a limit of 3. I removed this hard fail, and tried to make it more intelligent, but perhaps there's a bug in there.

Is it possible that a user violated their upload limits on that gallery to trigger this condition?

Comment #17

dddave commented 17 May 2010 at 18:13

re #15

Don't know if a failed upload was the cause BUT deleting the rogue images did not solve the issue.

re #16

I am currently trying to break a vanilla install and I don't succeed. I'll try recreating my other environment to see what breaks NG. As long as there are no other reports this might be some kind of odd interference with some other module...we'll see.

Comment #18

dddave commented 18 May 2010 at 07:05

Hurray, I managed to break it again. Sadly I am not sure what exactly was the cause and I am going to give it a new try today. It seems to be either related to a multilingual setup AND/OR the flag module. More details to follow.

edit: forgot to mention that this time flushing the caches is not bringing anything back on Manage/Sort. Uploads fails also so the only error in the logs is:
call_user_func_array() [<a href='function.call-user-func-array'>function.call-user-func-array</a>]: First argument is expected to be a valid callback, '_node_form' was given in C:\Users\David\Sites\acquia-drupal2\includes\form.inc on line 372.

edit2: This fails with the newest dev and a new Gallery content type and/or a new image content type.

Comment #19

dddave commented 18 May 2010 at 10:02

Title:

Sorting/Managing Galleries empty - uploads failing (Dev broken?)

» Conflict with i18n: Sorting/Managing Galleries empty - uploads failing (Dev broken?)

GOTCHA!

I found the conflicting module. Enabling i18n's core module "Internationalization" kills Manage/Sort/Upload immediately. I don't know why on my other installs the cache flush brings the thumbnails back on screen until refresh but my latest tries on virgin installs didn't show this behavior.

So to recreate:

1) enable NG 2 dev and the necessary modules and create a gallery with some pics.

2) enable drupal core modules Locale and Content translation

Until here the NG functionality is fine.

3) download i18n and enable "Internationalization"
-> mayhem

i18n wasn't updated recently and NG was working until a couple of days ago. So I am pretty sure that some of the changes made in one of the latest devs conflicts with i18n.

Comment #20

justintime commented 18 May 2010 at 13:46

I can reproduce. It's a nasty one, trying to track it with a debugger, and I'm still having problems catching it. It has something to do with hook_nodeapi, and therefore most likely is caused by the patch at #550994: Admin editing gallery changes user ID. More to come once I find the problem.

Comment #21

justintime commented 18 May 2010 at 14:11

Scratch that - it's not the above referenced patch. None of the code in that patch ever gets called.

Comment #22

justintime commented 18 May 2010 at 15:37

Status	File	Size
new	i18n.patch	733 bytes

Wow. That was not fun. In the end, the fix was to move two lines of code one line down :(

For those who might wonder, the call to node_gallery_get_config() from node_gallery_get_types() makes a call to node_get_types(), which invokes hook_db_rewrite_sql(). i18n implements this hook, and it in turn calls menu_get_object on the gallery object in the URL, which makes another call to node_gallery_get_types(), which, yes, you guessed it, calls node_gallery_get_config() again. Since the initialization of the $ng_types array has completed, but the population of it hasn't executed yet, the second node_gallery_get_types() call returns an empty array, which acts like there are no NG relationships setup yet. Whew! Thank god for Xdebug, or I never would have found it.

By moving the initialization of the array one line down, we only init the array after the node_gallery_get_config() rabbit hole has been completed, eliminating the bug. The bug was caused by the patch submitted at #713430: Array-related warnings when there are no gallery or image types.

The attached patch should fix up the current dev, but I'm going to commit it right away to dev because it's such a simple patch and has a big fix in it.

Comment #23

dddave commented 19 May 2010 at 11:40

Status:

Active

» Fixed

Dev from may 19th solves this issue.

THX!

Comment #24

2 June 2010 at 11:50