Closed (duplicate)
Project:
D7 Media
Version:
7.x-2.x-dev
Component:
Media WYSIWYG
Priority:
Major
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
8 Nov 2013 at 10:42 UTC
Updated:
30 Sep 2016 at 14:13 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
cato commentedMore info on this, it would seem that it's passing bad arguments to taxonomy_field_formatter_prepare_view() when an embedded file has taxonomy fields that are filled in. If they are left blank, it works. If they are filled in, it crashes. Now, I don't know if this is related to file entity or if it's a media / mediabutton / media wysiwyg thing.
I added a watchdog log on the parameters passed in to taxonomy_field_formatter_prepare_view() just to see what's passed and it looks like this:
watchdog('testing hello','
');
This one does not crash:
This one crashes:
Also, there are a number of errors in the same taxonomy_field_formatter_prepare_view leading up to the final Recoverable Fatal Error and they are "illegal string offset 'tid'" and "illegal string offset 'taxonomy_term'"
The last error that occurs and that crashes the content view / listing is
Appreciate any and all input on this issue as it is holding us back in development
Comment #2
cato commentedUpdate: It seems that multi-language was turned on somewhere in the development process and that some nodes were left as "language neutral" and some were in English.
Nodes that are Language Neutral crash when the Media Button is used. Nodes that are English do not crash.
Go figure...
Comment #3
gmclelland commentedPossibly related:
#2062721: Add a white list of file fields that can be overwritten when the file is added in the wysiwyg
#2062365: Several types of fields are not being handled correctly when file is embedded in the WYSIWYG
Comment #4
mcjim commentedIf you turn off the display of the taxonomy term (assuming it's on), do the errors go away?
You'll find this at Structure > File Types > (your file type) > Manage Display.
Comment #5
johnennew commentedI've rewritten the title and description of this problem and supply a patch for review.
This places a dependency on entity because of the use of entity_metadata_wrapper which may not be necessary, but I think the pattern is neat.
Comment #6
johnennew commentedComment #8
johnennew commented5: media-allow_other_field_types_to_be_overridden-2130847-5.patch queued for re-testing.
Comment #10
johnennew commentedHmm.. cant seem to get the tests to fail locally.
Please find a better patch which allows multi value fields as well.
Comment #11
johnennew commentedand heres the patch in 10 again with some content.
Comment #13
johnennew commentedWeird, these tests don't fail on me locally - any ideas?
Comment #14
Anonymous (not verified) commented"If you turn off the display of the taxonomy term (assuming it's on), do the errors go away?"
Yes.
Comment #15
dkingofpa commentedMarked #2288595: Select list fields on file entity can't be edited in media WYSIWYG ui as duplicate of this issue.
Comment #16
heddnClosing as duplicate of #2062721: Add a white list of file fields that can be overwritten when the file is added in the wysiwyg. BTW, I tested this on my local with taxonomy terms and the approach here simply doesn't work, even with the addition of entity api. Example: taxonomy term tags that auto-create fail.
Comment #17
vegantriathleteComment #18
brockfanning commentedSince there are several version of this issue that have been closed, just posting an FYI that I made a patch here: #2062365-9: Several types of fields are not being handled correctly when file is embedded in the WYSIWYG.
Comment #19
mibfire commentedThere is error when $field_value is empty. I fixed this in the attached patch.