Manage Images screen in 3.x

an additional image cache preset for admin would be neat,, you could set it to 50x50(or any#) and compact the page some, neat. and then you could impose imagecache actions on those too depending on your theme.

EDIT: sorry, I meant image cache_effects

We discussed via that a grid would be optimal, but unfortunately we have one jQuery wizard in the group, and he's been swamped. I'll ping him and see if he's got any bandwidth available.

@scroogie, can you send me your email address via my d.o contact form? I'd like to fill you in on some back-emails we've had discussing some of this.

Also relevant, the author of VBO didn't really see his module being used in this way, so it's likely going to involve getting our hands dirty in the views objects to make this work: http://drupal.org/node/708510.

I'm really sold on the jQuery Sortable Grid as a means to sort. That would be a killer feature that would really set us apart from other gallery modules. I'm sure if you and I hacked on it hard enough we could get it working. Let's set sorting aside for now.

Some back emails we discussed pulling this screen out of views entirely and custom coding the page. Might be the best approach, especially with Sortable Grid integration.

We'll want to use node_gallery_change_image_weight_action_submit() and friends with batch API I would think. You can see in hook_form_alter() how I hacked up the tabledrag on the VBO view - maybe you can do something similar to interface into VBO? If nothing else, you can mimic VBO by setting the $context variable properly when calling those actions.

@scroogie, I've installed this to two different ng3 installs. I get the same result in both cases. The patch applies cleanly, and I get no errors, but I'm certainly not getting any jQuery hotness. I just get a series of images and links with no draggable features. Can you try applying the patch to a clean ng3-dev install and see if you can get it to work?

I have installed the jquery ui, and have it installed correctly with jquery.ui from google code. NOthing in the watchdog log, nor apache error logs.

I get just a ul list of image titles and thumbnails. No errors in the console. A quick scan of the source html looks to me like there's no jquery/sort js being called anywhere. Is it possible for you to setup a fresh install of ng3.x-dev and test your patch? I'm pretty sure you'll be able to reproduce my issue.

Also, I just committed in code in .install to create a imagecache scale and crop of 50 pixels named node-gallery-admin-thumbnail.

I can verify that the drag sorting works with NG3 cvs from today and the patch supplied.
It's neat!
Fresh install of node gallery on D6 wamp.
I had an extra admin thumbnail preset in image cache,, don't know, may have been left over..

oh, btw, it did take a few moments for the images to appear,, they were all file names until image cache kicked in

Off Topic.. the default relationship did not get created at install time.

maybe a bug.. It drag sorts fine, but it will only show me 10 images on the sort page.
I checked the view and it is set to unlimited.

@scroogie, Your on it!
The fix in #21 does the trick.
edit: it does take imagecache a few moments to execute (testers give a second or two.)

Justintime and 'crowd' will be the most popular people in the photography community...
This module is quickly approaching Awesome, NG3.. woot woot
The upload is so cool, and this drag sort is just plain FUN..

Just about time for a listed dev and beta

I speak too soon, the images all load up now, and drag-n-drop sorting works, all as exspected,
but it won't keep the changes. Drupal/node_gallery message(The order of the images was left unchanged.)

scratch that,, it seems that it won't save image moves with or without the added $view->set_items_per_page(0);
I guess I may have something set wrong or a bug..

I got mine working. JQuery UI wasn't getting enabled properly from drush. I just had to disable/re-enable via the GUI. My sort operation works properly, but I get the 10 image limit issue too.

Just a quick update before I call it a night - the views live preview doesn't limit the count to 10, so it's got to be something happening in the module.

I might not be doing this right..
apply the new patch to a fresh download of the 6.x-3.x-dev
if yes, the sorting not workin 4 me
but all the images show up on sort page.

@scroogie - the bigger the patch, the less code I have to write :)

I'm working on 2.x as of late, and haven't had time to even apply the patch yet. I'll try to get some time to go over it before Monday.

They are in a grid, it is a views page, all looks normal, just won't allow drag

EDIT,, that's why I think I may have done something wrong, maybe a file that should be there..
I started with a fresh NG3dev and applied only the patch from #28

If I disable jQuery UI, it goes to table drag, which does work and will save changes.

I thought something wasn't right.. maybe views code.. not sure

I cleaned out everything in my NG3 install(module,imagecaches,all content,content types,aliases,all views).
did a reinstall with patch from #28 and the drag sorting is working now.
It saves the move(drag)(admin-thumbs trade places), but when I use the 'save' button, it won't save the change.

The patch was applied before installation on all testing. because of the install changes.
I had an old view in there that does not get deleted when the node_gallery module is uninstalled.
I cleared firefox.. I use that function 50 times a day..it's great!
The page code has the elements you noted. Looks all normal, acts normal, but not saving. Maybe I should try it on a live server.

It would be nice if you patched relative to the /node_gallery/ directory.

contributions/modules/node_gallery/node_gallery.css Locally Modified (Based On 1.4.2.2)

Basically I have to move my modules folder under some folder "contributions." Kind of annoying.

Anyways, after moving nodegallery, the patch failed to apply.

patching file contributions/modules/node_gallery/js/ng_sort_jqueryui.js
(Stripping trailing CRs from patch.)
patching file contributions/modules/node_gallery/node_gallery.css
Hunk #1 FAILED at 16.
1 out of 1 hunk FAILED -- saving rejects to file contributions/modules/node_gallery/node_gallery.css.rej
(Stripping trailing CRs from patch.)
patching file contributions/modules/node_gallery/node_gallery.module
patch: **** malformed patch at line 67: \ No newline at end of file

Can you reroll it?

It is definitely sort of working, but I am having similar problems as dbeall

1) Using Safari... When dragging the images, really odd spacing issues appear (see attached image)
2) Even though I can physically change the locations, it does not save the changes (as dbeall explained)
3) in the code there is a "$output .= '
';" In general, we should not use that sort of code. We should put a class="clearfix" on the wrapper div

I doubt this is the issue, but one of the things new in 3.x is some heavy caching of the images in a gallery, and their order within that gallery. Try clearing your cache and make sure that doesn't fix the problem. If it does, scroogie just needs to clear the cache after saving.

yes, but.... it never gets that far, just as soon as the save function is 'excited', the admin-thumbs revert instantly to previous sort order.

edit,, unless the cache cleared at save time would hold the new position in the sort page too..??
this stuff is over my level of knowledge.

edited:
Justintime probably has the right idea.. thinkin the sort page 'save' function should do two things,, clear the NG3 db cache first,, then save the sort change after. i have no clue..
The table drag holds a change.. hmmm
**crawling back in my cave now**

I get the error: "The order of the images was left unchanged."

Clearing the cache didn't do anything.

i tried your patch in post #48 and everything seams to work. I just changed the field_node_gallery_image to display node-gallery-thumbnail in the view, because there were no images displayed at first. the thumbnails are now shown in grid when i go to sort image and they are dregable. its much easier to sort images now.

thank you very much and keep up the good work. its a amazing module!

@scroogie - I'm committing this into 3.x HEAD, so that it can get some more exposure and testing.

I created a new issue for the jquery draggable grid issue, as this doesn't really fall under the scope of the manage images tab any longer. I posted some thoughts on the patch on the new issue: #824276: Implement a jQuery Draggable Grid for Image Sorting - please subscribe to that issue if you want to follow the jquery draggable grid issue.

Not sure if this thread is appropriate or whether it should be a new bug report but whenever I click 'manage images' i just get a white screen with not watchdog error and no apache error.

This is with the latest dev version, however the previous version had the same behaviour.

@oxford-dev, I am wondering what the max execution time is set at in your php.ini file..
Most are set at 30 seconds default, 120 to 200 might fix it..
max_execution_time=120;Maximum execution time of each script, in seconds

It instantly goes to white screen a split second after pressing the button. It isn't a time-out issue, thanks anyway.

@Oxford-dev - what is your memory limit? To raise memory limit could fixed the problem.

I'm getting ready to take a crack at this. I see two viable options:

• Port the existing 2.x manage images screen to 3.x. AFAIK, the last contributed patch seemed to eliminate most if not all outstanding issues with that approach.
• I just checked out Editview for a few minutes today. While it wasn't bug-free, it probably wouldn't take much to make it work seamlessly.

Personally, I'm leaning a bit towards Editview - it just feels like the more "Drupalish" way. It relies upon views, and uses AJAX. Instead of performing all edits in clicking a button that sends you into a batch like the 2.x manage images, it presents each node in a concise, editable form with a save and a delete button. Clicking either button performs an AJAX function that performs the necessary node_save() or node_delete() work.

Editview has been around awhile, has about 1,000 users of the 6.x branch, but seems to have idled a bit lately.

No matter what, I think we need to remove the requirement of VBO, but I'd still recommend it's usage for true batch editing (ie assign a vocabulary term to all images).

Thoughts?

Agree on everything except that it's just a simple call to a function. There's a lot of different things that can be attached to a node that are not taxo terms, most significantly the huge array of CCK fields. There's also the option to delete nodes, we need to deal with that. We also need to use batch API since there's a good chance this bulk edit form will be used on 10's if not 100's of images. None of it's Drupal rocket science, but it's code that has a lot of nooks and crannies.

I'll just port the current manage images screen over, and we can start tweaking from there.

I like Editview but I see some potentially critical issues that might force us to not use the module:
#477288: Huge amount of memory used
#640684: Saving edited node causes 100% CPU usage

Also, considering the module hasn't had a commit in over a year and the issue queue is largely ignored, I'd hesitate to suggest relying on this essentially abandoned module unless we're willing to sign on as being a co-maintainer.

@kmonty - there's a taxonomy bug with Editview too where tag-style vocabs don't work right. Maybe when I have free time I'll jump right on that :) I think Editview is off the list until it gets a maintainer.

@scroogie - VBO doesn't have the memory issue because there's no (or at least not much) ajax involved on the client side.

Stay tuned for a commit sometime this week (I hope)

I need someone to take a fresh look at this for me. I'm pretty weak with FAPI, and even worse with theming. If you apply the patch, and visit the Manage Images tab, you'll get two copies of the form, one themed, and one not. Please don't apply this patch if you're not a developer, because the submit functions haven't been tested yet and are likely broken.

If someone can help me over this hump, I can move on and get this thing finished.

Awesome, thanks. FWIW, I copied the code from them_gallery_sort_images_form just below that function, but I see now that $element is never used when calling drupal_render() within that function. The original $form array is used instead. Learn something(s) new every day!

Holy crap that was a lot more work than I thought it would be. There's some black voodoo magick going on in that code. I would commit this straight in, but coming in at over 1,000 lines of patch, I think I need a tester or two to review it for me first.

I have the day off today, and need to commit this so I can commit other changes too.

I'm going to mark this fixed because I hate long issues. If we find bugs/UI issues with this, please start a new issue. The next dev build today will have this code in it.