Make media_gallery work with media-7.x-2.x branch

Subscribe

.

Yeah, would really like to see this too. Have need for the Media Gallery, but have chosen to use Media 2.x since that is where the efforts are going.

Would be so great if Media Gallery could work with it so users that needs it can migrate.

subscribe.

subscribe

subscribing

subscribe

Does has anyone asked media devs already, what changes are relevant? Because if we know, we can try to provide patches ...

Currently Media Gallery is only available for Media 7.x-1.x-beta2, and Media has a security update 7.x-1.x-beta5. I think it is necessary to make Media Gallery compatible with a newer version of Media.

I have been creating content for the last day on a site I brought over from another server. I noticed there was an upgrade available to go from Media 7.x-1.x-beta2 to Media 7.x-1.x-beta5. I allowed Drupal to do this and then created a couple of Galleries. For some reason the images were not showing up in the gallery. Researching this issue led me to look into it here.

Well apparently I SHOULDN'T have done this upgrade. Now I am unable to revert back to Media 7.x-1.x-beta2. When I try I get errors: "Unresolved dependency file_styles (Missing)
Media requires this module."

So where do I stand? Am I hosed? Can I drop tables in phpMyAdmin to remove reference to this media? Do I start all over again?

If you have tried to turn back to older version and get errors now, than: First try to reinstall Media 7.x-1.x-beta5 again.It should override its own leftovers or will spit errors about existing fields. Ignore that. We only needs its own db relations and uninall functions to work properly. Than uninstall it regulary and completly (1.disable, 2.empty cache , 3. db update, 4. uninstall (not remove!), 5. empty cache, 6. db update again, 7. empty cache again, 8. now you can remove the folder in sites/all/modules)

After that check for leftovers in db again. Should be easy to find (but DO NOT remove any of it from system table), only remove media_*** fields and variables.

then you shouldn't have a problem to install 7.x-1.x-beta2 from scratch again, if you want so.

A further development of Media module has been made. See http://drupal.org/node/992978 for more details. Many permissions are now added. But when I test the module, users can upload images to gallery which is not create by them. Any ideas?

Currently Media Gallery is only available for Media 7.x-1.x-beta2, and Media has a security update 7.x-1.x-beta5. I think it is necessary to make Media Gallery compatible with a newer version of Media.

This already happened several months ago. The latest (July 11th) release of Media Gallery (7.x-1.0-beta6) is compatible with and requires Media 7.x-1.0-beta5.

If you are having issues with that upgrade, please don't file them here, since this issue is about making Media Gallery compatible with the 7.x-2.x branch.

By the way, it's tempting to postpone this issue, since we really have to do #1291054: Release Media Gallery beta7 that is compatible with Media 7.x-1.x RCs and stables first, and Media 7.x-2.x isn't close to stable yet....

However, it could make sense to open up a 7.x-2.x branch of Media Gallery if someone wants to write code to make it work with Media 7.x-2.x. I am guessing a separate branch is the way to go here, but I haven't really looked into what the required changes would be. (If it turns out they're small and don't interfere with the ability of Media Gallery to be compatible with Media 7.x-1.x, then I guess we don't actually need a separate branch.)

subscribe

Subscribing. I am really eager to see Media and Media Gallery 7.x-2.x branch available.

subscribe

#1291054: Release Media Gallery beta7 that is compatible with Media 7.x-1.x RCs and stables should actually be closed. Media Gallery works fine with Media 7.x-1.0-rc1 without needing to edit any code. So I guess the focus should be on developing Media Gallery 7.x-2.x compatible with Media 7.x-2.x. So is a 7.x-2.x version of Media Gallery under development?

Subscribe

Digidog I have been meaning to thank you for the information. As it ended up, there where enough changes that I ended up just re-building the site from scratch with the right modules.

However, I want to say I really appreciate you taking the time to reply and guide me.

Thank you,

Jerry

subscribe

@onny Stop subscribing, start following.

Fyi - so far, I have been using media-7.x-2.x with media_gallery-7.x-1.x without any issues. All I did was relax the restriction "(<1.99)" in media_gallery.info. Not a live site, so tried it out...

I just tried media_gallery-7.x-1.x with media-7.x-2.x with while removing the <1.99 restriction as #23 mentions.

However things have changed:
FieldException: Attempt to create a field of unknown type <em class="placeholder">media</em>. in field_create_field() (line 106 of /tmp/drupal-7.10/modules/field/field.crud.inc).

Could this be related to #1391332: Support file field as well as deprecated media asset field

I just tried to change the type to 'file' for media_gallery_media in _media_gallery_controlled_fields(), which made the error go away.
But more changed are probably required .... as I was unable to add media files.

To followup on myself...

Enabling the 'mediafield' module which is included in the media-7.x-2.x branch also solves the error above.

My comments was based on these versions:
- media-7.x-2.x-dev of 2011-10-26
- media_gallery-7.x-1.x-dev of 2011-10-13

I have stuck to that version for now. So maybe things have indeed changed...

subscribe

subscribe

@rggoode @tomgf in the future, please use the Follow button at the top right of issues. It allows you to subscribe to issues without triggering unnecessary emails going out to everyone else.

tried this myself. most works but here are some errors i found while digging deeper

1. when trying to edit a gallery:

Fatal error: Call to undefined function media_page_multiedit() in /media_gallery/media_gallery.pages.inc on line 384

2. trying to edit media:

    Notice: Undefined index: media_edit in drupal_retrieve_form() (line 752 of /includes/form.inc).
    Warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'media_edit' was given in drupal_retrieve_form() (line 787 of includes/form.inc).
    Notice: Undefined index: field_license in media_gallery_form_alter() (line 830 of modules/media_gallery/media_gallery.module).

discipolo, could you clarify what you have tried? Could you provide the modules' versions you are using? I am assuming you simply changed the .info requirements for Media Gallery but just want to check with you.

Cheers!

Would be great to open up the 2.x-dev branch. I have created a patch that will make it possible to get media gallery installed (resolving the media --> file field conversion).

@ aniebel you are correct.

@ discipolo I can vouch for this too. I am in this same boat. I got most of it working just by deleting the dependencies in the .info file. However the editing of the galleries and the edit media tabs give me these same errors.

gotta try if #33 takes care of these. shame theres no automatic test ...

Hi Isolesen,
I've tried to apply your patch but without success:

enrico@raechel:~/public_html/drupal7/sites/all/modules/media_gallery> git apply -v install-on-media-2x-branch.patch
Checking patch media_gallery.info...
error: while searching for:

dependencies[] = list
dependencies[] = number
dependencies[] = media (<1.99)
dependencies[] = taxonomy
dependencies[] = multiform


error: patch failed: media_gallery.info:5
error: media_gallery.info: patch does not apply
Checking patch media_gallery.install...

I can't install the module cause I have the Media 7.x-2.0-unstable3. Any idea?
Thanks

Found the problem: in the media_gallery.info file there is this:

dependencies[] = list
dependencies[] = number
dependencies[] = media (>1.99)
dependencies[] = taxonomy
dependencies[] = multiform (1.0-beta2)

and the patch looking for this:

dependencies[] = list
dependencies[] = number
dependencies[] = media (>1.99)
dependencies[] = taxonomy
dependencies[] = multiform

For the difference between the multiform line doesn't work

@kikko it applies cleanly on the git version. The patch from #32 only makes it possible to install media gallery on the media 2.x-branch. Still need to figure out how to make it the media gallery actually work.

Added patch that makes the add image button open up the popup correctly. The popup browser api has changed between the versions.

Disregard the last one. This is a better patch.

Added patch to change the view formatter to the correct type (file instead of deprecated media).

@David_Rothstein A new branch should be opened, I think. I will also make most sense to have branch names that are similar for media and media_gallery.

Yes please! I completely blacked my site out updating Media and other modules since media gallery is not compatible.

I too would love to see this branched to Media 2.x.

I would too!

I have applied lsolesen three patches and couldn't add new media to galleries. I did a little bit of debugging and I got it working. I also fixed the broken multiedit callback.
@lsolesen: I included your changes in my patch to make testing it easier, I hope you don't mind ;) .

I also would appreciate if a new 2.x branch was created.

This patch appears to be working for me with one exception. The multiform module now has a 1.0 release so I believe that the dependency in media_gallery.info can be updated to depend on the 1.0 release version of multiform.

So the dependency section of my media_gallery.info file now looks as follows.

dependencies[] = list
dependencies[] = number
dependencies[] = media (>1.99)
dependencies[] = taxonomy
dependencies[] = multiform

@leschekfm I do not mind. I will test your patch shortly.

@leschekfm I do not mind. I will test your patch shortly.

the patch from 46 and changes from 47 seemed to have worked for me.

I am experimenting with the media browser plus module and am using just 1.x version. has anyone tried using the 2.x version?

I have also had luck with #46.

@mlconnor --> when I apply the patch in 47 the multiform restriction has already been removed.

@leschekfm --> I tested the patch and it applies cleanly to git. And now the last remaining task with my patch has also been resolved, so pictures could actually be added to the gallery. Thanks for your extra work. Moving to RBTC.

What is the correct approach to move this forward? Create a Drupal sandbox project or? Any ideas?

Wrong patch added. This patch resolves issue #1564338: Notice: Undefined variable: offset i media_gallery_reorder_gallery(), but can also be applied here.

The only incompatibility I find that is left with required modules that is preventing me from enabling the Media Gallery modules after applying patches in #46 & #54:

Multiple forms (1.0-beta2) (incompatible with version 7.x-1.0)

FYI, Multiple Forms is at a stable 1.0 release.

I haven't been active in the Media Gallery queue recently (I'm no longer an active committer on this project), but just took a quick at the patches here now... thanks for everyone's work on this!

My quick comment is that the patches look small enough (and almost all of the changes seem like they'd be compatible with Media 7.x-1.x as well?) that it may make more sense to have this stay on the Media Gallery 7.x-1.x branch, and try to make that branch compatible with both versions of Media. I believe we talked above about that being a possibility depending on what the patch actually looked like, and it seems like it might be realistic to me... The reason is that keeping everything on one branch would allow for more focused development effort, I think (the main focus being to get Media Gallery to a stable release) rather than branching to 7.x-2.x and finding people to spend the time to maintain both of them. Just my opinion.

Looking quickly at the patch, I would say the media_gallery_update_XXXX() functions probably should not be updated (since they are historical update functions and anyone running them may still need it to behave the original way).

On a related note, does there need to be a new update function to convert existing 'media' fields to 'file', or does it work with either?

i think the media to file change would make it necessary with a 2x branch.

FYI the Media field type is bundled with the 2.x branch too, however it is not enabled by default and also clearly marked as deprecated and will go away at some stage.

I haven't tested myself, but it might be possible to use Media Gallery with the file field type for the 1.x branch as well, which would be preferred if there is just one branch. If so, then having an media_gallery_update_XXXX() function that automates that switch would both be a good thing and assure that it will better work with the 2.x branch.

Right, I'm pretty sure the media widget works for file fields in Media 1.x, so hopefully that means Media Gallery could switch too.

On the one hand, I guess it is a big change to force existing sites to make within a Media Gallery 1.x branch. On the other hand, I've already seen contrib modules out there that integrate well with file fields but not with media fields, so there is some appeal to having Media Gallery switch completely over if it's going to do so for Media 2.x anyway.

@tsvenson and @David_Rothstein We should not rely on media anymore, so we need to switch to file, right? If you think that it is possible with the 1.x-branch without breaking backward compability, we should give that a try. But there is also an api change in the javascript to be able to add media. What is your take on that?

@lsolesen: Great if it only depends on File Entity for the 2.x branch. For the media 1.x branch its less important as the File Entity module comes bundled with the Media module there.

If they can be made to work the same for both, that should mean less complex code to maintain though.

Updated the summary with some of the work outstanding.

sub

@leelush Stop subscribing, start following.

@fenstrat, thanks for the info.
As an Open Outreach user, I'm looking forward for the 2.x branch.

Patch #46:

-  field_bundle_settings('media', $bundle, $bundle_settings);
-  $instance = field_info_instance('media', 'file', $bundle);
+  field_bundle_settings('field', $bundle, $bundle_settings);
+  $instance = field_info_instance('file', 'file', $bundle);

Is it correct that it is field and not file in field_bundle_settings()?

Ah, I didn't notice this, but you are right. 'field' makes no sense here.

Nonetheless I would agree with #58 and #60 that update functions shouldn't be changed afterwards, so the changes to the update functions would be obsolete and a new update function should be written.

Furthermore I noticed that what was called 'media' in media-7.x-1.x gets converted to 'mediafield' in media-7.x-2.x.
This means that if media_gallery would not get a 2.x branch it would have to support three different field types (media, mediafield, file).

@leschekfm Could you update the patch to work with the latest dev and the comment I pointed out in #68.

I think we should support the file entity and drop media and mediafield entirely staying on the 1.x-branch of media_gallery. Could you have a stab at making an update function which will make this happen. This is an important part of getting beta 9 out.

Roadmap for that release: http://drupal.org/project/issues/search/media_gallery?text=&assigned=&su...

Hi. To add to the discussion #70, there may be cases where other modules require media 2.x. Hence even if media_gallery only requires media 1.x, it should be able to work with media 2.x too. Please confirm. Thanks.

@lsolesen - I just installed the latest dev version of Media Gallery and am manually applying the changes from patch in #46, and further comments/patches below. Will post an encompassing patch in a bit.

Attaching patch from #46 done against the latest dev version. Decided to go another route (not using Media Gallery) for the current task I'm working on, so unfortunately I didn't write new update hooks for the media -> file changes (as I planned).

Remember to switch status to need review for new patches.

@yuriy.babenko You need to make sure that the patch also works for media 1.x also for a clean install. There are to tasks:

1) Make media gallery work for both 1.x and 2.x branches of media for clean installs using file instead of media and mediafield. #1391332: Support file field as well as deprecated media asset field
2) Write an update hook which makes the switch from media to file for existing installs. #1349058: Convert 'Media' fields to 'File' fields that use the 'Media file selector' widget
3) Also see #1677150: Media gallery tries to use deprecated media_edit form

Those two tasks should come in different patches, so it is easier to review. Therefore the media restriction on version number should be removed not changed.

Shouldn't the switch be from deprecated media fields to the new field provided by the mediafield submodule instead of file fields? I'm confused. May be misreading this thread.

I'll test this patch against a 2.x version of media today! Very excited to find this patch.

@rerooting No, we want to switch to the file field from core, like media also does in the 2.x-branch. The media field will be deprecated. It is only included right now for backwards compability.

http://drupal.org/node/1391332#comment-6256996 had a go at these two:
1) Make media gallery work for both 1.x and 2.x branches of media for clean installs using file instead of media and mediafield. #1391332: Use file field instead of deprecated media asset field
3) Also see #1677150: Media gallery tries to use deprecated media_edit form

Add issue summary.

Our best way forward here is first to add 'file' field support to the 1.x branch in #1391332: Support file field as well as deprecated media asset field. From there, the path to 2.x compatibility will be a lot clearer. I've updated the summary accordingly, plus updated #1391332.

@nedjo. I agree that it would be great with file support for the 1.x-branch first. Would you take the time to create a patch?

subscribe

please use the follow button instead of subscribe comments

so is there a way to make Media Gallery work with media 2.x?
I'm having a hard time determining this in this thread.
Thanks

it looks like the patch referenced in 79 was committed.
is media gallery support for media 2.x on its way?

Should this be set back to active now that #1391332: Support file field as well as deprecated media asset field has been committed? It seemed like it was postponed in #79 waiting on that issue.

With #1391332: Support file field as well as deprecated media asset field we are able to use file fields. To do that, we had to check which media version is active and use version dependent functions and hooks of media.

It would be easy for new installations, to just change the type of media_gallery_media from media to file. For existing installations, is is not that easy to convert a media field to file field. This may also be the reason, why #1349058: Convert 'Media' fields to 'File' fields that use the 'Media file selector' widget does not convert the fields. It copies the data to a new field. So we seem to do the same. Create a new file field and move the content (with the help of the media module) from media_gallery_media.

The media module is in active development. If we like to support media 2.x with media_gallery 7.x-1.x we need to fix some more issues like:
#1824870: media_type_get_types() is no longer part of media 2.x
#1824652: use new file_entity_access functions instead of media_access (the old permissions will no longer work in media 2.x)
#1802938: Remove "delete" link from Contextual Links in Gallery view
#1781260: Remove file from gallery may delete file
This means, that we again need to check for media versions and implement version specific codes. (I don't like this version checks in code.) It may be possible with wrappers (access, function calls, form-id-filtering,...).

So my suggestion is to behave it like media. Fix bugs in the current version and make it stable (so 1.x will still use the media field). Make a new 2.x version, which uses media 2.x and the file field. Users upgrading from 1.x to 2.x can use the patch from media to convert the field.

Any suggestions/comments about this?

Creating a 2.x version to correspond with media sounds like a logical way to go. Would this be difficult to setup and maintain?

@Moloc I think we should use the adapter pattern, if it is possible, so we only have to maintain one branch, but still can have clean code, so we only need to check for the media version once.

Hi! Tested the patch on an existing installation and received this error when running update.php
media_gallery_media already exists and is not of type file. Installation cannot continue. Please remove this field or change its type. See screenshot as well.

Woohoo! I uninstalled the module through the uniinstall process, thus deleting old data, and gave it another go. Hey! As far as I can, tell it works great with latest Media 7.x 2.0-unstable6. Amazing!

@leanderl - have you also tried stable Media 7.x? Was there are reason to use an unstable version?

Great work folks! I look forward to trying it out. (And in the future, helping out).

@therobyouknow — The reason for testing this with Media 7.x-2.0-unstablewhatever is because the whole point of this issue is to get Media Gallery working with the 7.x-2.x branch of Media, which does not yet have a stable release. Media Gallery already works with the Media 7.x-1.x branch which is where the stable releases are.

I have since my last post discovered that I can't get title to show below an image both for "galleries view" and "gallery view". I. e. both when looking at all galleries and a particular gallery. But I am sure that can be overcome rather easily -- I just need some time to sit down with it and perhaps do some overrides in template.php.

Everything else seems to work like a clockwork. I'm especially happy to have such a slick drag and drop sorting solution at hand, something I failed miserably at when trying to port this myself back in March. Great work!

Great work folks. Thanks @BrightBold for explaining. When I said about a stable release I had meant in 2.x - but of course, as you point out, there isn't yet a stable 2.x, so thanks for correcting me. And I'm thrilled at this work, because it means that it will be possible to use the media_gallery with Panopoly (which supports Media 2.x), so that the brilliant multi-upload/batch uploading of images in media_gallery are available alongside the brilliant page layout system from Panopoly. Thanks. I will try to help where I can as I become more capable. On rung 5 of the Drupal Ladder at the moment.

@leanderl great to know that you have had success (your comments #93 and #96) with this but can you give exact module versions and steps that gave you success so that others can repeat it, please specify the following:

• Your step 1: Preliminary setup - anything we should know? (No need to give full details, just specifics to media, if you think we should know stuff, like your mention of the uninstall and reinstall, do we need to do this as well or can we skip to my step 2 ("Your step 2", next step below) for your instructions below?)
• Your step 2 (can we start from here or is there anything that needs doing before hand): What versions of media and media gallery did you start with? (if dev version - and therefore no version number - then please specify on what date you downloaded the dev)
• Your step 3: Then which patch(es) did you apply, e.g. did you apply just the patch to media_gallery supplied by @bangpound in comment #90 ( support_media_2.x-1244204-90.patch ) or not? or something else too or instead?

You've probably guessed I have tried to repeat your success so that's why I am asking for guidance because I was unsuccessful, here are my steps:

1. Preliminaries you should be aware of about my setup, it's the panopoly distro (which comes with media 2.x (which I am overwriting below by downloading the dev version, MAMP PRO local install on MacOS X). I don't think the Panopoly Drupal 7 distro should be an issue hindering what I want to achieve though, but just so you know
2. download the specific version of media_gallery that I think is required - issue command: drush dl media_gallery-7.x-1.x-dev (this version @bangpound indicates their patch in comment #90 can be applied to the "latest dev" (2012-Oct-30 at time of my writing, and @bangpound's comment also posted on same day 2012-Oct-30) I assume )
3. download the specific version of media that I think is required - issue drush command drush dl media 7.x-2.0-unstable6 (as you stated in #93)
4. download the patch for applying to media_gallery supplied by @bangpound in comment #90 above ( support_media_2.x-1244204-90.patch )
5. place this patch directly in ../sites/all/modules/media_gallery - i.e. the directory for the media_gallery (because attempting to apply the patch from the site doc root doesn't work - error messages about file not found)
6. apply the patch - issue command: git apply support_media_2.x-1244204-90.patch - after I issued just a usual further terminal prompt seen, no confirmation, no error messages, assuming it worked (?)
7. enable media (do this first because media_gallery depends on it) - issue command: drush en media
8. enable media_gallery (then do this, once media is enabled) - issue command: drush en media_gallery
9. result: get error message: Module media_gallery cannot be enabled because it depends on media (<1.99) but 2.0-unstable6 is available [error]

So I'm surprised - would the patch in comment #90 not have turned off this dependency check in the media_gallery, or modified it to accept media 2.x, so that it does work?

By the way, drush pmlshows my media_gallery version as:
Media Media Gallery (media_gallery) Module Not installed 7.x-1.0-beta8+8-dev

I used Drupal 7.16, Media 7.x 2.0-unstable6 and media_gallery dev version as of today Nov 1, 2012. Media_gallery was patched with #90.
I also changed the dependency in media_gallery.info "by hand".
to dependencies[] = media (>1.99).

My experince of patching is that you have to download the module with git clone to a separate folder outside of your drupal install and then do the patching there. So that the module is its own independent git repo during the patching. After patching you can copy the patched version to your Drupal site and delete the .git folder inside the module (so as not to conflict with the overall .git-repo for your site).

I'll attach my working version of media_gallery for you, if it helps you...

It'll be interesting to see if it works for you. On the installation I've used it on I've previously had media 7.x-1 and media_gallery running.

Another thing that you may find silly that I point out, but I still will, is that you need File Entity module "paired" with Media in release version.

update: got a little further, not solved yet though. I don't think the patch was installing in my step 6 I described in my last comment #98. Probably because I haven't got git completely setup in the site docroot (I could do this), I thought I could use the git patch apply command without needing to set git up, perhaps this is not the case.

Any way, the following patch apply did work (used instructions for applying a patch in http://drupal.org/node/60818 ), but I get an error message when trying to enable the media_gallery module you can see, this error message is familiar from the earlier comments, so I will investigate further:

(the following done in media_gallery module directory)

$ patch < support_media_2.x-1244204-90.patch
patching file media_gallery.info
patching file media_gallery.install
patching file media_gallery.module

(Moved out of media_gallery directory back to docroot of site in case drush needs me out of it to enable the module.)

$ drush en media_gallery
The following extensions will be enabled: media_gallery
Do you really want to continue? (y/n): y
Drush command terminated abnormally due to an unrecoverable error.                                                               [error]
Error: Call to undefined function file_type_get_enabled_types() in
sites/all/modules/media_gallery/media_gallery.install, line 854
$ 

@leanderl - thank you just got your comment #99, I was posting some results I had at the same time as your posts so maybe some of my comments in #100 did not account for your comments in #99. I will read through what you said in #99 and try things out. Thank you also for providing the media_gallery version, that you used, as a download. On the subject of git, as I mentioned in #100, I don't think I had my git setup completely setup which might explain some problems I had with applying the patch. In other words I was taking some shortcuts that I shouldn't have. So if I can do it properly and then it should work out for me hopefully. Thanks again.

Success I have tested media_gallery and seen it working in the Drupal Panopoly distribution, using media 2.x! I would also expect media_gallery to work with media 2.x in a vanilla, plain Drupal 7 install (I think I would be correct in saying that there is no dependency on the Panopoly distribution in order to make media_gallery work with media 2.x). I am just using Panopoly for the fantastic page layout system - and now that I have multiple image/batch uploading, I'm on the way to building a great publishing website.

I achieved testing this successfully on my setup by replacing my step 6) in my comment #98 with the different instructions for applying a patch in #100.

@leanderl I haven't tried your suggestions yet, but I will read through them, as it's important for me to make sure that I am doing things properly (or doing them in a better way). So thank you for those.

So my revised instructions (update to those in comment #98) are:

1. Preliminaries you should be aware of about my setup, it's the panopoly distro (which comes with media 2.x (which I am overwriting below by downloading the dev version, MAMP PRO local install on MacOS X). I don't think the Panopoly Drupal 7 distro should be an issue hindering what I want to achieve though, but just so you know
2. download the specific version of media_gallery that I think is required - issue command: drush dl media_gallery-7.x-1.x-dev (this version @bangpound indicates their patch in comment #90 can be applied to the "latest dev" (2012-Oct-30 at time of my writing, and @bangpound's comment also posted on same day 2012-Oct-30) I assume )
3. download the specific version of media that I think is required - issue drush command drush dl media 7.x-2.0-unstable6 (as you stated in #93)
4. download the patch for applying to media_gallery supplied by @bangpound in comment #90 above ( support_media_2.x-1244204-90.patch )
5. place this patch directly in ../sites/all/modules/media_gallery - i.e. the directory for the media_gallery (because attempting to apply the patch from the site doc root doesn't work - error messages about file not found)
6. (adjusted step - new - this replaces the same step in comment #98 with the step I made in comment #100)
   (the following done in media_gallery module directory)

   $ patch < support_media_2.x-1244204-90.patch
   patching file media_gallery.info
   patching file media_gallery.install
   patching file media_gallery.module
   (Moved out of media_gallery directory back to docroot of site in case drush needs me out of it to enable the module.)
   
   $ drush en media_gallery
   The following extensions will be enabled: media_gallery
   Do you really want to continue? (y/n): y
   Drush command terminated abnormally due to an unrecoverable error.                                                               [error]
   Error: Call to undefined function file_type_get_enabled_types() in
   sites/all/modules/media_gallery/media_gallery.install, line 854
   $ 
   

7. enable media (do this first because media_gallery depends on it) - issue command: drush en media
8. enable media_gallery (then do this, once media is enabled) - issue command: drush en media_gallery

The error message seen during enabling media_gallery ( Error: Call to undefined function file_type_get_enabled_types() in sites/all/modules/media_gallery/media_gallery.install, line 854 ) appears to be of no consequence (well so far so good), as I have been able to upload multiple images and view them in media gallery. However I will still investigate.

@leanderl As for your comment in comment #99: "Another thing that you may find silly that I point out, but I still will, is that you need File Entity module "paired" with Media in release version." - not a silly comment, at all! Always appreciated. I'm not quite sure what you mean, I looked at the modules I had installed and looked for file_entity in the list of modules:

$ drush pml | grep file_entity
 Media                    File entity (file_entity)                                      Module  Enabled        7.x-2.0-unstable6     
$ 

- does the above make any sense to you about the pairing? Let me know if it does, and if there is anything else that I need to do.

Update revision to this comment: I removed step 9 as the patch applied to media_gallery also updates the version checking code so enabling media_gallery now works with the media 2.x as mentioned. It's not really a step anyway more an outcome.

Proof of media_gallery working in Panopoly

http://i50.tinypic.com/aetoqb.jpg

Note the error message though:

"Warning: array_flip(): Can only flip STRING and INTEGER values! in DrupalDefaultEntityController->load() (line 178 of Sites/arttravelmedia.com/includes/entity.inc)."

This occurred because I deleted 3 pictures. The error message is displayed for each picture deleted. It does not display if you don't delete any of your pictures after uploading them. The error is displayed for both the authenticated user that can upload the gallery and also visible to unauthenticated users.

I will raise a separate issue for this error, if it has not been raised already. UPDATE: issue raised: http://drupal.org/node/1830038

Another thing I noticed when using the drag-drop re-ordering is that the images increase in size after reordering, do it again and they get bigger again, do it again and they get bigger, etc. Again, I'll raise another issue if it hasn't been raised already. UPDATE: Issue raised: http://drupal.org/node/1830050

I too have experienced the "Warning: array_flip(): Can only flip STRING and INTEGER values! in DrupalDefaultEntityController->load()" when deleting an image. The warning doesn't go away it's stays on the galleries page "forever", so there is something in the rendition of the gallery page that causes it. It's not just a "report" from the delete action.

Great work by everyon on this! I really would love an easy and slick gallery solution like this and I wish I could help, but this problem which is referencing includes/entity.inc row 178 of core, gives me too little to work with. I tried to look at all code related to deleting in the media_gallery module, but found no opening to where this could be happening.

@bangpound - a 2.x branch for media_gallery (7.x-2.x-dev) for use with media 2.x makes a LOT of sense. Very good point. What do we have to do to get this setup on the media_gallery project page?

@leanderl - thank you for reproducing the same problem ( issue tracked here: http://drupal.org/node/1830038 - "Delete image works but warning: array_flip(): Can only flip STRING and INTEGER values! in DrupalDefaultEntityController->load()" ). My guess is that the delete operation is not completely purging the entries for the deleted images in the database.

So I'm getting my debugging environment setup to try to learn how to help with fixing this issue (and others) at some point - story below

For me to help with this, this week I have been trying to get a decent local development setup that can run PHP debugging I have been successful so far evaluating PhpED remotely stepping though Drupal PHP code on a LAMP stack. PHPED works out the box via a easy to use wizard (why make it harder?). Before that I was trying to compile xdebug for the Mac and got so far resolving some dependencies but what a pain! So I've paused on that (I resent the mindset of making a virtue out of complexity by having to compile one's own IDE debug setup!!! (xdebug) What a demotivater and not even got off the starting blocks to actually step through the code to fix it!) As I am already an owner of Komodo IDE 7 I am looking to get that working with remote PHP debugging before considering PhpED. ActiveState Komodo's support have been in touch to assist as I have not got it working so far with MAMP PRO and ActiveState's pre-compiled download of xdebug.so. Worst case is that I just go and buy PhpEd and run it from Parallels in Windows (Windows only app) and either connect to MAMP on the host MacOS or a LAMP stack in another Parallels VM or virtualbox. I've considered the drupal.org/project/quickstart for out of the box Drupal LAMP stack but an update of this is half-way it progress it seems and the project page documentation is confusing - raised an issue here: http://drupal.org/node/1832032

Great work everyone involved on getting media_gallery working with 2.x so far. Really appreciated!!!

Found root cause of "Warning: array_flip(): Can only flip STRING and INTEGER values! in DrupalDefaultEntityController->load()" when deleting an image

@leanderl - thank you for reproducing the same problem ( issue tracked here: http://drupal.org/node/1830038 - "Delete image works but warning: array_flip(): Can only flip STRING and INTEGER values! in DrupalDefaultEntityController->load()" ). My guess is that the delete operation is not completely purging the entries for the deleted images in the database.

My guess in comment #106 of this issue was correct so I have updated the issue ticket here with the detail here: http://drupal.org/node/1830038#comment-6712600"

Hey! nice work!

I've been thinking and maybe the problem is that the delete action is managed by File Entity module (not media). And our new media_gallery 7.x-2.x doesn't follow the "protocol" for asking file entity to delete a file in the right way. So probably one would have to dive deep into file entity and understand that module to get it right.

Update: unfortunately there is more to be done that my suggested remedy here:http://drupal.org/node/1830038#comment-6713358

However, steps shown here in further comment on the issue do remedy, though they are a workaround until the media_gallery code can be fixed to not leave references to the deleted files in the database in the first place. The work around is here: http://drupal.org/node/1830038#comment-6713454

We should not change the media_gallery_media field type from media to file. This change will have the effect, that existing sites will never be able to update to a newer version. (See comment #92)

Instead, i think we should create a new field media_gallery_files with type file.

Is someone who co-owns the media_gallery module going to create a 7.x-2.x-dev branch then, specifically for use with media 2.x?

This should be easy to do; if I had access to the media_gallery module on drupal.org I would go ahead now and create a media_gallery 2.x dev release/branch and apply the patch to get media_gallery working with media 2.x. This would be a lot clearer and straight forward for folks who come to media_gallery wanting to run it with media 2.x. By having a link for download media_gallery 2.x this would be easy for them. This would give more clarity about the state and directory of this module, rather than having to trawl through the issue list and then comments to find the patch that actually gets media_gallery working with 2.x.

Sure, there are still issues, but transfer those related to media 2.x and media_gallery development into the new release media_gallery 2.x. Let's not let other things get in the way/or try to "boil the ocean."

I'm not sure what the hesitation is for creating a media_gallery 2.x, @bangpound suggested it on November 8: http://drupal.org/node/1244204#comment-6708140 in comment #104 (GREAT IDEA)

There, I've done it, I've created a new separate issue: "Create media gallery 2.x branch": http://drupal.org/node/1844106

Hopefully this gives more visibility as this activity of creating a new branch should be in a separate issue. Hopefully this will help with making stable patch code/efforts on media_gallery the working media 2.x working with the media gallery. We know this works now, but we need a clean place, i.e. a new branch to develop further without needing to support legacy code.

Fix notices in media_gallery_multiedit_access(). Uploading for make files..

There's an emerging consensus in this issue that the fairly extensive changes needed for media 2.x support should be done in a separate branch.

However, despite efforts to limit the patch in #1391332: Support file field as well as deprecated media asset field to introducing file field support in mediafield 1.x (see the issue summary), that wasn't done and instead the commit in that issue introduced some fairly messy code aimed at supporting both media 1.x and 2.x in the same branch, see http://drupalcode.org/project/media_gallery.git/commitdiff/0e94214.

Before or after creating a media_gallery 2.x branch, #1391332 will need to be partially reverted, removing the workarounds that were introduced to support both media branches.

Reference #1391332.

Thanks @nedjo:

Before or after creating a media_gallery 2.x branch, #1391332 will need to be partially reverted, removing the workarounds that were introduced to support both media branches.

Yes - myself, I strongly recommend after: The activity of partially reverting #1391332 is not a blocker for creating a 2.x branch.

Let's push ahead with a new 2.x branch, starting with a dev release containing this "messy" code, subsequent dev releases on this branch can fix that. After all, this is what dev releases are for! Once we've cleaned up we can release a proper release alongside the dev.

@therobyouknow I agree with @nedjo that the 1.x-branch should be cleaned out before branching. It shouldn't take too long though.

@lsolesen fair enough! Thanks.

tested latest patch. seems to work fine. but clicking a thumb the overlay loads and then black screen.

@e-anima - which patch? The one in comment #90 by @bangpound: http://drupal.org/node/1244204#comment-6669972 ? I think this would be the right one. Please confirm.

If I recall, from my own steps: http://drupal.org/node/1244204#comment-6678836
I was able to view individual images as you require. I tested this on Chrome but not other browsers. It might be that the other code in Drupal that media/media gallery uses has progressed since I tested and the bug you are seeing was introduced.

@e-anima to help reproduce your problem - can you supply details of:

• Drupal core version 7.??
• Other modules installed (to see there are known imcompatibility issues)
• web environment: LAMP,MAMP,WAMP,DAMP, versions
• web browser? OS? to view the site where the problem occurred? (obviously it should work on ALL clients but this will help reproduce your problem)
• How many items in your gallery, images dimensions, file sizes (might be worth considering, to see if this gallery code scales well to different galleries)
• Performance optimisations turned on or off? (see under your admin or config pages of your drupal site) Sometimes Javascript aggregation/concatenation/compression options mess up things like what you've seen. Well, I've seen problems related to this area so I left some optimisations switched off for the time being

i tried #113 first, the latest available patch. now i am trying #90

• performance: all off, i am testing with user 1
• crome/ff opens black screen, meaning: http://www.root.artwaves.de/screensnapr/1354013595-Pwhrkp.jpg
• i use the latest drupal 7.17 amd media 2.x
• No wamp map damp stuff, i installed manually on my debian.
• Using two items

i use a lot of cotribs. on that special page no quicktabs or other fancy stuff is loaded, i also disabled the colorbox module.

i checked the css, seems that it must be the fault of mine because the image is there. i will check my css.

the error is that the #colorbox element.style is set to opacity:0, mo wonder nothing shows up.

Which one is the correct patch #90 or #113 ?!?

@sw3b, @e-anima Myself I used #90 for my instructions in my comment at #102: http://drupal.org/node/1244204#comment-6678836
I have used #90 to get media_gallery working with media 2.x (if that's what you mean by "correct" patch).

I have not used #113 and have not looked at it to understand what it is yet.

(Incidentally, just for your information: Just a tip if you aren't aware of for quickly seeing what a patch is about, is to get the dreditor extension for chrome (maybe other browsers too). I believe this is an extension of "grease monkey". It enables one to easily view the code-level diff changes of a patch.)

Just for your awareness at the moment, be advised there are moves to create a 2.x branch of media_gallery specifically for media 2.x. This means that the code will be cleaner in media_gallery on that 2.x branch in that it will not have to support the 1.x version of media (media_gallery 1.x remains to do that), the issue for this task to create media_gallery 2.x is here: http://drupal.org/node/1844106

Ok i try #90 and there is no error... but when i try to add an image to a gallery nothing happen .. do you have an idea about this ?!? The windows close an when i refresh the windows nothing are add in the gallery.

Also I notice if the module overlay is enable there is a double windows who appear when adding a media.

There is an error on the page after adding an image and...

Notice : Undefined index: files dans media_gallery_add_images() (ligne 271 dans /home/username/www/www/sites/sitepgca/modules/media_gallery/media_gallery.pages.inc).
Warning : Invalid argument supplied for foreach() dans media_gallery_add_images() (ligne 280 dans /home/username/www/www/sites/sitepgca/modules/media_gallery/media_gallery.pages.inc).

There is an error in the log...

PDOException : SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'media_gallery_media_display' cannot be null: INSERT INTO {field_data_media_gallery_media} (entity_type, entity_id, revision_id, bundle, delta, language, media_gallery_media_fid, media_gallery_media_display, media_gallery_media_description) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8); Array ( [:db_insert_placeholder_0] => node [:db_insert_placeholder_1] => 1 [:db_insert_placeholder_2] => 1 [:db_insert_placeholder_3] => media_gallery [:db_insert_placeholder_4] => 0 [:db_insert_placeholder_5] => und [:db_insert_placeholder_6] => 1 [:db_insert_placeholder_7] => [:db_insert_placeholder_8] => ) dans field_sql_storage_field_storage_write() (line 448 dans /home/username/www/www/modules/field/modules/field_sql_storage/field_sql_storage.module).

PS I solve my problem... how, i do not know but i use the media_gallery at #99 and it work great ! Thanks @leanderl to share it.

@bangpound awesome! I am looking forward to trying your new patch in #125!!! Thank you! I plan to download Drupal Panopoly distribution rc3 (which uses Media 2.x and apply your patch to see if I can get Media Gallery working in Panopoly. Other users should be aware that you don't have to use Panopoly, this is just my preferred distro.

@bangpound did you know that a media_gallery 2.x has been created - @Moloc did the hard work - you should be able to see it at on the usual media gallery project page here: http://drupal.org/project/media_gallery

See also @Moloc's comment here: http://drupal.org/node/1844106#comment-6798610

I will apply your #125 patch first to media_gallery 7.x-1.0-beta8 and then also try it with 7.x-2.x-dev

I will publish full steps as I did before (like this: http://drupal.org/node/1244204#comment-6678836 )

Thanks @bangpound for the detail on the release - it will save me effort on media 1.x and instead allow me to focus completely on media 2.x

Thank you all for your work.

When we started this thread, it seemed to be easy to make a patch.
Now we have a own branch. There are a lot of changes, which makes no sense to couple all in one patch.

So i suggest to close this one. Lets work on each 2.x issue in a own issue, so they can be fixed faster.

Lets do the work in the following issues:
#1848914: Use file field instead of media field (2.x) (this may be fixed first to have a clean install of media_gallery)
#1848912: Use file_entities edit functions (maybe we need to rename that)
#1824652: use new file_entity_access functions instead of media_access
#1802938: Remove "delete" link from Contextual Links in Gallery view
#1781260: Remove file from gallery may delete file
#1856402: Use new admin/content/file link

If you find more bugs, just create a new issue.

@Moloc - thank you for your work. Agreed with your proposals - let's not add to this issue anymore (well this will be my last post here, now)

How to update/upgrade from Media 1 to Media 2 and idem dito for Media Gallery. I am running media 1 and gallery 1 in production and upgrading is most desirable.
Did anybody do this?

I'm running media 2 dev and and gallery 1 dev (deleted the dependency from the info file).

it works, but had to enable 'administer files' under permissions for anonymous users, just to view the galleries. However, anonymous users do not actually have edit/delete functionalities for media files ... which is fine.

this is of course NOT the way to go. but it works for me now, and I really needed the media 2 branch since it can replace the media browser plus module I was using before, but was giving problems.

If I just install the gallery 2, what I should do of course. I get a white screen (of death).

does this module is working? if yes please let me know where to download? I am unable to enable the module.

...as per #130 / #132

Please file separate issues for any bugs fount - don't reopen long-closed issues

Update summary.