Fatal Error during Media Browser upload

I can confirm this error.
It only happens when inserting media inline with wysiwyg button. I have no error when browsing a multimedia asset field.

Additional confirmation. I get the message after uploading (though the file uploads ok - it'll appear in my Library) and when trying to insert media inline using the WYSIYG button. The screen darkens and becomes unusable, and I need to hit the back button to get out.

Sorry I can't help troubleshoot code, can only report.

Using...

Drupal core 7.0-beta3 (just uploaded it tonight)
Media 7.x-1.0-beta1
Styles 7.x-1.0-alpha4
Entity 7.x-1.0-beta1

See the top of the project page on media releases (see "READ THIS").

Thanks for the report though, please confirm w/ BETA2

I know you need someone to test against D7-beta2, but since I've just done some testing and written it up I thought it'd be useful to post it:

1) D7 beta 3 with:
- Styles 1-dev
- media beta2
- media gallery beta1
- wysiwyg 2-dev
- multiform 1-dev
- entity beta 2
- TinyMCE

Steps:

1) Enable Styles and file styles - no issues
2) Enable Entity Metadata, Entity CRUD API and Multiple forms - no issues
3) Enable wysiwyg - no issues
4) Enable Media - no issues
5) Configuration wysiwyg profiles
6) Enable TinyMCE for full html
7) Edit -> Buttons -> Media browser
8) Add content -> Basic page
9) click media browser
10) Upload a file - results in screen going gray and freezing

Refreshing the browser returns these messages:
* Notice: Undefined index: media_link in media_format_form() (line 262 of /var/aegir/media8/sites/all/modules/media/media.filter.inc).
* Notice: Undefined index: media_link in media_get_file_without_label() (line 355 of /var/aegir/media8/sites/all/modules/media/media.filter.inc).
* Notice: Undefined index: settings in media_get_file_without_label() (line 357 of /var/aegir/media8/sites/all/modules/media/media.filter.inc).
* Warning: array_merge(): Argument #1 is not an array in media_get_file_without_label() (line 357 of /var/aegir/media8/sites/all/modules/media/media.filter.inc).

@bjalford:

This is awesome. Thank you so much for the thorough steps to reproduce.

Since BETA2 has been cut, anyone who wants to start on stabilizing HEAD for BETA3 is my hero.

Best,
Jacob

I have similar fresh installation (I use CKEditor).
To Basic page I have added "Multimedia asset" -> "Media file selector" filed.
If I try to use Media browser through wysiwyg and CKEditor I get exactly same error.
If I try to use Media browser through added field everything is OK, but then images are added as attachments not as part of a text.

It seems to me that problem arises when Media browser is trying to insert image into the body.

No need to +1 this. BETA-3 is not supported yet. If you want to start trying to fix it or you have additional info to share, go for it.

I'm still geting a feel for D7, but it looks to have to do with the field. media_link doesn't exist in the display array of the returned field from:

$instance = field_info_instance('media', 'file', $media->type); 

I too am looking at the D7 api changes for the first time trying to fix this for site I'm upgrading.

Line 82 of media.fields.inc defines the 'view modes'

/**
 * Used to Implement hook_field_view_modes().
 */
function media_field_view_modes($obj_type) {
  $modes = array();
  if ($obj_type == 'media') {
    $modes = array(
      'media_link' => array('label' => t('Link')),
      'media_preview' => array('label' => t('Preview')),
      'media_small' => array('label' => t('Small')),
      'media_large' => array('label' => t('Large')),
      'media_original' => array('label' => t('Original')),
    );
  }
  return $modes;
}

So the $view_mode that is passed to

media_get_file_without_label($media, $view_mode, $settings = array()) 

(line 353 media.filter.inc) does not match with those returned by

$instance = field_info_instance('media', 'file', $media->type); 

So, do the 'view modes' that the media module defines in media_field_view_modes need to match those returned by the field_info_instance function? If so, how best to approach this?

Any pointers or suggestions?

I managed to get it working locally by replacing the 5 modes defined in media_field_view_modes($obj_type) with

  'media_preview' => array('label' => t('Preview')),
  'media_original' => array('label' => t('Original')),
  'default' => array('label' => t('Default')),

I'm sure this is not the best way to fix it, but I am at the edge of my ignorance with the Field API.

So, is it just that the display modes are not defined properly? Should these be defined in another hook?

Also, I can't find any documentation about hook_field_view_modes...

Still confused.

Just a question out of pure curiosity in terms of development process... I read:

See the top of the project page on media releases (see "READ THIS").
Thanks for the report though, please confirm w/ BETA2

but I do not understand what's the logic. It would seem natural to me that - since the final D7 will be cloaser to Beta3 than to Beta2 one should focus on making the module working on Beta3, not Beta2. After all we are not talking about two different releases (D6 and D7) but between a buggy, unsupported version and the first "candidate to become release candidate".... anybody cares to explain what I am missing here?

Thanks! :)

Not sure what you're asking but the media releases are lockstep with core to avoid people know what version will work with what core version.

My question is: what's the point in testing a bug against B2?

If a bug is there against B3, that's what matters the most, as RC will be ~B3, and certainly more similar to B3 than to B2... Using a metaphor: from my point of view the bug report looks like: "The boat is too heavy and with the media module sinks" and the reply I quoted beforehand "yeah... that's because they have now installed the engines. Tests if without engines it is light enough to get the media module going".

As a matter of facts - though - the boat will have engines onboard... so I am just curious to understand what's the point in testing stuff without the engines (i.e. Beta2) as requested in the reply to the bug filing. Honest question... just trying to understand how the development cycle works! :)

I thought Mac's explanation/metaphor was a bit odd but I get his point and agree completely. I had thought the exact same thing as he said in #12.

It doesn't make sense to maintain backwards compatibility on BETA releases. I can understand if, however unlikely, that there is a breaking change in core from 7.1 to 7.2 to maintain a separate branch. However I don't think this should be maintained in Beta. Current release and testing should always be developed with the latest beta release of core, then worry about branching only once version 1 is released. You might end up wasting time having to workaround something in beta 2 that is fixed in beta 3 or ignore something in beta 2 because it works but is really broken in beta 3 (like this thread).

Mac/mcaden, I think that reply about trying with beta2 was to me - I had listed that I was testing with beta1 (of the Module). If that's the case, then it's natural that he would say, "try beta2" - I took that as beta2 of the module, not core. I'm thinking we might just have been talking past each other a bit.

I have no doubts that every effort's being made at getting things working with beta3 of core. And I'm looking forward to it - I'm not a code monkey, so I can't help very much, sadly. But I think it's a great module, and will look forward to using it.

Ah, I think I see. JacobSingh's comment (#8) made it sound to me like the maintainers weren't bothering with the beta 3 version of drupal 7 yet and were instead just trying to get it to work with drupal 7 beta 2. Instead, I guess what he was meaning was that MEDIA beta 3 hasn't been released yet and that's the one we hope should be fully functional with the latest version of core.

@Michael - Ok, that's all clear than... it was just a misunderstanding on what the Beta refers to. I also understand now why Jacob had an hard time understanding what I was asking for (sorry mcaden for the odd metaphor, it was my last resort!).

It should however be pointed out that the bug was filed against the *development version* of the Media Module, not Beta 2, and since the problem is with Drupal Beta 3, precisely because of what is written on the media page:

Media releases correspond w/ core releases so Media BETA-2 is known to work with DRUPAL BETA2

it is truly counter-intuitive to suggest to try Media-B2 in conjunction with Drupal-B3. :)

BTW: Does anybody knows what's the string ID of the HEAD version of the module to be used with drush? I tried:

drush dl media-7.x-1.x-HEAD

with no joy... :(

Getting back to the real problem, another observation about this for me:

Install Core D7 beta 2, Media D7 beta 1...upgrade core to D7 beta 3 and media to beta 2...seems to work

Install Core D7 beta 3, Media D7 beta 2...this issue appears

After looking at what was being returned from field_info_instance the changes from ecofinn looked valid. I've made the changes he suggested above in #11 and did a little testing. This worked. I've rolled it into a patch and shortly I will be looking into what caused this to be a problem. (Where the original "link, preview, small, original, large" ones came from to begin with and where that might've changed)

Okay, so here's the deal:

Acquia uses Media related modules in production http://drupalgardens.com

Every 3 weeks we update Drupal to the latest BETA and I try to push out a media release to go along w/ that beta. So I'm absolutely thrilled to see all bugs reported, but I just want people testing on a platform where the bugs are expected, or at least reporting as such. So if you're using core BETA-2, use media BETA-2, if you're using core BETA-3, don't expect any media version to work right now, but certainly don't use the BETA-2 release and report against that. Use HEAD.

To get the HEAD of a module, see:
http://drupal.org/node/19304/cvs-instructions/HEAD

BAH,

TortoiseCVS FTL.

Re-rolled patch using straight cvs commands.

EDIT: This and the previous patch are the same, merely generated differently, and both are against HEAD

BAH, I think this'll do it.

For the record, the patch in #26 works for me, despite it failing SimpleTest.

ignore above patch - wrong file

AHA! I've been looking for WHY this is happening. I view the patch above as a workaround not a fix. I much prefer a fix.

So the following only applies WITHOUT applying the workaround patch....

To reproduce on HEAD:

1. Install d7 beta 3
2. Upload and install Wysiwyg and CKEditor
3. Upload and install HEAD
4. Turn on media button on CKEditor
5. Go to node and click 'edit'
6. Click the media button
7. select an image and click 'submit'
8. error appears: "Fatal error: Unsupported operand types in ...\modules\field\field.info.inc on line 355" (It's in black text somewhere on the dark gray background)

Manual fix on HEAD: (not sure where to fix in code yet, here's how to fix in UI)

1. Go to: Configuration -> Media Types -> (Image)manage display (admin/config/media/types/manage/image/display)
2. Click to expand the "Custom Display Settings"
3. Select the boxes that are unchecked
4. Save Changes
5. Now it should work

It appears that the module is trying to use display modes without them ever having been turned on. If you turn it on, suddenly it works.

What I've done instead of removing some extra formats is instead, when we check to see if file formats are hidden - we check if they even exist in the data. This patch should do the trick. I'm screwing something up as I format my patches so it'll probably fail but it should be perfectly valid. If anybody knows how I'm screwing up my patches please enlighten me. This patch is made against a fully updated checkout of HEAD

hmm...test system isn't picking up patch at all..I'm failing all over the place...I'm just going to stop worrying about it until somebody can tell me where I'm going wrong. Sorry for cluttering up the issues.

I have been able to successfully patch dev version of this module, but I did get something that might seem like an error in a format of a patch file.

patching file media/media.filter.inc
patch unexpectedly ends in middle of line
Hunk #1 succeeded at 259 with fuzz 2.

It seems that this is a fix for this bug.

This should fix the error in the patch file.

It still seems like we're treating the symptom rather than the cause but I prefer this solution over the first one.

ah, found where I've been screwing up the patches

Yeah, there is something else going on here... The Large and small styles should be showing up, but something changed and since they aren't custom it doesn't work, we need to find the root of this.

At some point along the way, D7 core changed such that field_info_instance() no longer returns data for every view mode, but only for ones that have settings. This patch fixes Media accordingly. There may be other places in Media that also need fixing, but this seems to address this particular issue.

This one perhaps?

Subject: Trying #886152 again: Fixed All fields are hidden after the administrator newly configures a view mode to not use 'default' display.
Parent: 40347e65e9715cca4bbd0cc55f1816df71d2fa9e

#886152: All fields are hidden after the administrator newly configures a view mode to not use 'default' display

Above patch doesn't quite work. IT stops throwing the error and shows all items in the drop-down, but it inserts the file_default for everything.

but it inserts the file_default for everything

Not if you install fresh. Or if you disable and re-enable the media module after applying the patch (since media_enable() re-configures the view modes / formatters). We could add an update function to the patch to also do this re-configuring, but I'm not too keen on overriding administrator choices (as a separate issue, we should move most of what media_enable() does into media_install()). If the administrator wants to un-customize the Large view mode, so that it uses the Default one, we should respect that.

.

Glancing over the patch it appears sound. I'll test it on my sandbox shortly.

Looks successful, I patched on an export directly from head and did a fresh install. Link, Large, Preview, and Original show up and all seem to act appropriately. The only problem I have is that the "preview" style actually enlarges a small portion of my image and makes it quite pixellated and ugly (image I tested on was banner-shaped: 332x90 but I think that's a problem with styles rather than media.

The patch itself seems to work at far as installation and media upload are concerned.

However it is impossible to format images (haven't tried with other types of media) via the CKeditor "image" dialogue. Formattings like alignment and border are removed on submission of the node.

I am unaware to say if this problem has been introduced by the patch modifications or it is in the text filter that replaces the media tags with HTML markup.

We would need some type of update function...

I committed #40, but would still like to followup w/ an update function to not break existing sites.

Also adding the "Needs tests" tag. We need to be increasing our test coverage of Media module, and adding tests as part of the issue which identified a bug has worked well for D7 core development, so let's try it here too.

.

Same issue occurs in drupal 7.0 full release. As mentioned in #1 It only happens when inserting media inline with wysiwyg button.

Yep, me too. Drupal full release in wysiwyg.

Okay, so I don't know if I'm going to have time to write an update function. Is there anyone using this in production who wants one?

I am not able to replicate the problem. Here are my module version, please let me know what you've got if you're still getting it:

Core: 7.0
Styles: DRUPAL-7--1 (latest)
Media: HEAD
WYSIWYG: HEAD

Best,
Jacob

Is this an issue when not using the media_dev profile? Is everyone using the profile?

I just installed without the media_dev profile. After configuring my text formats and WYSIWYG profile I had no issue inserting media through CKEditor.

Core: 7.0
Styles: DRUPAL-7--1 (latest)
Media: HEAD
WYSIWYG: HEAD

@gvc and others, *please* test again, and let us know what versions are broken when you re-post.

I'm renaming this to reflect the remaining work.

Thanks for the fix, the critical error goes away with the below versions and a DB upgrade for Styles. Mine is not the media_dev profile.
Core: 7.0
Styles: DRUPAL-7--1 (latest)
Media: HEAD
Entity API : DRUPAL-7--1-0-BETA6
WYSIWYG: HEAD
Editor : CKEditor 3.5.0.6260

After uploading 2 images, there's a new issue. The uploaded media is not visible post submission, instead the below details are displayed:

"[[{"type":"media","view_mode":"media_large","fid":"15","attributes":{"alt":"","class":"media-image","typeof":"foaf:Image"}}]][[{"type":"media","view_mode":"media_preview","fid":"14","attributes":{"alt":"","class":"media-image","height":"120","typeof":"foaf:Image","width":"120"}}]]"

You need to enabled the media filter for your text format in order to convert those codes to the media items.

I tried uninstalling (I previously had the dev version installed) and reinstalling the Media module with the following:

Drupal core: 7.0
Media: 7.x-1.0-beta2
Styles: 7.x-2.0-alpha1
WYSIWYG: 7.x-2.x-dev (latest update)
Entity API: 7.x-1.0-beta6
CKEditor: 3.5.0.6260

When I went to enable the media module after reinstalling, I get this error:

FieldException: Attempt to create an instance of field file on bundle default that already has an instance of that field. in field_create_instance() (line 488 of /home/spauldin/public_html/d7/modules/field/field.crud.inc).

After that, I tried the media inline insert anyway, and now when I click the media button in the ckeditor, I get "The requested page could not be found. " instead of the media upload/browser window.

Same error here with:

Drupal core: 7.0
Media: 7.x-1.0-beta2
Styles: 7.x-2.x-dev
WYSIWYG: 7.x-2.x-dev
Entity API: 7.x-1.0-beta6
CKEditor: 3.3.0.5542

* Notice: Undefined index: media_link in media_format_form() (line 262 of /Applications/MAMP/htdocs/drupal7/sites/all/modules/media/media.filter.inc).
* Notice: Undefined index: media_link in media_get_file_without_label() (line 355 of /Applications/MAMP/htdocs/drupal7/sites/all/modules/media/media.filter.inc).
* Notice: Undefined index: settings in media_get_file_without_label() (line 357 of /Applications/MAMP/htdocs/drupal7/sites/all/modules/media/media.filter.inc).
* Warning: array_merge() [function.array-merge]: Argument #1 is not an array in media_get_file_without_label() (line 357 of /Applications/MAMP/htdocs/drupal7/sites/all/modules/media/media.filter.inc).

I have the same problem as mentioned in #61 and other posts here.

My setup is this:
Drupal core: 7.0
Media: 7.x-1.0-beta2
Styles: 7.x-2.x-alpha2
WYSIWYG: 7.x-2.0
Entity API: 7.x-1.0-beta6
TinyMCE: 3.3.9.3

Re #61 and #62: I updated the project page to clarify that media beta 2 works with drupal 7 beta 2 only, and I made the 7.x-1.x-dev snapshot release visible, since that's the only version that works with 7.0 until we release a 1.0.

Thanks. I have updated Media, Styles and Entity to the latest dev versions and it's working now!

Thank you effulgentsia! After installing dev-version and clearing cache it started working. :)

#46: "The only problem I have is that the "preview" style actually enlarges a small portion of my image and makes it quite pixellated and ugly (image I tested on was banner-shaped: 332x90 but I think that's a problem with styles rather than media."

this should be resolved in the latest release of styles.

Resetting issue attributes to reflect original issue. New issue for expanding test coverage: #1026532: Write functional tests for adding Media to WYSIWYG.

I get the following error when using the add media in wysiwyg :

[[{"type":"media","view_mode":"media_original","fid":"34","attributes":{"class":"media-image","typeof":"foaf:Image"}}]]

My setup is:
Drupal core: 7.0
Media: 7.x-1.x-dev
Styles: 7.x-2.x-dev
WYSIWYG: 7.x-2.0
Entity API: 7.x-1.x-dev
CKEditor 3.5.1.6398
(All ofthe above up to date Feb.08.2011)

Re #59
"You need to enabled the media filter for your text format in order to convert those codes to the media items."
How do I do this ?

Re #65
"clearing cache"
Is that the views cache ? (tried that without luck)

Any help is appretiated !
Tor

@TMH - That's not an error - that is the output of the Media module. Go into /admin/config/content/formats and click "configure" for each of your formats that will use media and check the box that says "Converts Media tags to Markup"

Thanks for your help on that , I have now checked that box , and the message dissapear.

But the image doesnt display unfortunately , neighter in teaser or when I click "read more" but if I click edit then I can see the image in the body in the edit mode.

(The field display of the content type Article is at default values)

Nice if you have a tip for this too

Thanks in advance
Tor

Figured it out , had to adjust the filtered html so it alows media

anyways thaks for your help :)

Anyone have problems aligning image ? ( or set other properties)

when I right click and set properties to an image to align to left, it looks ok, but when I save it remes that property and is unaligned again.

I think this is a problem with the filter : "Converts Media tags to Markup"
because it works if I remove that filter. (but then I cant use media to browse for images)

You shouldn't be using a closed issue as your place to ask questions about totally unrelated issues.

To answer your question, you could've easily done a quick look on other issues to find issues like #1043570: Floating images left and right or make sure if you're using divs to align the images that you're using full html and not filtered html because "div" isn't allowed in filtered html.