This issue follows moving from PHP 5.6 -> PHP 7+
When clicking to open a Media Browser instance, the iFrame returns an Internal Server Error that does not log any errors in PHP with max error logging settings enabled.
When debugging using XDebug, setting a break point on line 82 of media-dialog-page.tpl and following through seems to actually load the iFrame correctly. So when debugging and stepping through, the iFrame loads, when not debugging, we get an Internal Server Error without any errors logging.
After experimenting by looking at the iFrame URL, removing the options query parameter from the iFrame URL actually loads the iFrame correctly; so for instance with an iFrame query string like this: src=“/media/browser?render=media-popup&types=&enabledPlugins=&options=l8ZC20anLgOynI23Te4fxFUnxOZ1XlhWHft5o2hHcq8&plugins=undefined” this will return an Internal Server Error, however with the options parameter omitted: src=“/media/browser?render=media-popup&types=&enabledPlugins=&plugins=undefined” this will load correctly.
As I have already burned up quite a bit of time on this one, I haven't delved too deeply into this options parameter, so it's usage may be buried further down, however I had tried updating to different versions of the Media module: 2.x, 3.x, 4.x and relative dev versions, but this still remained an issue. PHP 5.6 does not seem to be affected by this.
My quick and dirty solution to this, was to do the following in the media.module, in the media_set_browser_params() function, on line 1233 where the $safe_options array is declared, to modify the safe_options to remove the options param, and remove it from the $params array:
// Filter out everything except a whitelist of known safe options.
$safe_options = array(
'enabledPlugins',
'fid',
'id',
'multiselect',
'field',
//'options',
'plugins',
'render',
'types',
'render_multi_edit_form',
);
unset($params['options']);
Now I'm currently unsure the usage of options, although I'm sure it is some sort of checksum that is being checked down the line, but it doesn't appear to be an issue with PHP5.6, only 7+ upwards, reverting PHP 5.6 back seems to work. I don't have the time to really dig, so I'm submitting this patch regardless, in case someone may be able to shed some light on this, or wants a quick fix.
Comments
Comment #2
leslie.cordell CreditAttribution: leslie.cordell commentedComment #3
leslie.cordell CreditAttribution: leslie.cordell commentedComment #5
joseph.olstadHi Mr.les thanks for this. Not being nit picky, just giving pointer, to make a patch you need to clone the media project, not your docroot
docroot/sites/all/modules/contrib/
here are the instructions how to create a patch.
The standard method:
https://www.drupal.org/node/707484
The alternative method:
https://wunder.io/blog/how-create-patch-drupal-module
alternatively you can edit the patch you just made and remove docroot/sites/all/modules/contrib/
Comment #6
joseph.olstadaside from this, the code in question "options" is related to a security release for media
I wonder why you're having issues with php 7+, I've tested this myself on php 7.0 and it works fine.
I suspect your php.ini for your php 7+ might need adjusting and also perhaps your web server settings. Check your browser developer console for XHR and network section as well as the Javascript console , refresh while looking at those tabs .
media/browser URL prevent tampering of (allowed file extensions, access, etc.)
Comment #7
joseph.olstadKeep in mind, there's about 100000+ installs on medias version 7.x-2.19 and 7.x-2.20
I highly doubt that php 7+ is causing issues for all of these installs, in fact I myself have php 7.0 installed running media.
we also have test coverage for the "options" in question and all simple tests are passing for php 7.1 and php 7.2
see the latest test results for all branches of media
Are you using drupal core the latest 7.x-dev release ? or 7.59 ?
Comment #8
leslie.cordell CreditAttribution: leslie.cordell commentedThanks very much Joseph for the feedback, I'll get working on another patch shortly. Yeah it makes sense, I've a feeling it could be due to some sort of conflict, I'll add an update once I've got it figured!
Comment #9
ChaseOnTheWebI too am having problems since upgrading from PHP 5.6 to PHP 7.1. I get the Apache Internal Server Error message with no PHP errors in the log; the only thing I get is a vague "End of script output before headers" in Apache error.log. I'm using media in a multisite. I've stepped through two sites in Xdebug. PHP always eventually crashes, but each site crashes in a slightly different spot.
I'm starting to believe this may be a bug with PHP itself. I haven't been able to get a core dump for PHP to investigate further.
I was able to get file upload working again where I needed it by disabling the Library tab in the field widget options.
Observations:
I need to see if I can spin up a demo site that repeats the issue, when I have time.
Comment #10
joseph.olstadIncrease your memory limit for php thread max
I ran php 7.0.x yesterday a-ok but fails if only 128m limit
Check php.ini
Comment #11
joseph.olstadI have php 7.1.x and 7.2.x environments handy and will run a test or two soon
Comment #12
joseph.olstadI just tested on my server using the media_dev distribution (most recent version media_dev-7.x-4.0-beta8)
successfully using
php 7.1.20-1+ubuntu18.04.1+deb.sury.org+1
and also success with
PHP 7.2.9-1+ubuntu18.04.1+deb.sury.org+1
and also success with
PHP 7.0.31-1+ubuntu18.04.1+deb.sury.org+1
Drupal core 7.59+25-dev (2018-Sep-11) (This will become Drupal core 7.60, it is pre-release that is compatible with php 7.2.x) I am also using the latest contrib modules, sometimes dev , sometimes with patches. The make file is in the media_dev repo for all to see.
I had no problems, no server errors.
My memory limit on the server php.ini is set to 512 M for all versions of php I tested, a bit overkill but this is because I do dev on this server, probably 192 M as a limit would be ok, 256M would be a pretty safe memory limit too.
128M is not enough, this I know, if your memory limit is set to 128 M you should increase it otherwise things won't work properly.
Comment #13
joseph.olstadComment #14
ChaseOnTheWebI'm familiar with the PHP Out of Memory error. I do not get an out of memory message in any logs when I get the Internal Server Error. I am currently at 256M memory limit with a selective increase to 384M for certain paths. I tried raising it to 1024M on dev just to see if that made any difference and it did not.
Comment #15
joseph.olstadChaseOnTheWeb
can you test whatever you need tested on the media_dev distribution, if you want, try the latest one 7.x-4.0-beta9
these are the modules the media_dev distribution uses by default:
Comment #16
joseph.olstadFor those interested, simplytest.me is now repaired, it is working correctly again for distributions.
If you want to easily test media on php 7.0.x use simplytest.me and the media_dev distribution.
Here is a link
simplytest.me uses php 7.0.x ,
anyone have steps to reproduce this issue? I have php 7.0.x , php 7.1.x, and php 7.2.x environments ready, and the media_dev distribution is a good start for a media environment.
Comment #17
joseph.olstadfor possible solution, there may be some helpful information here:
For a similar compatibility issue, vistree had to uninstall some related modules and re install them in php 7.1.x, would be nice to pinpoint this down.
see #2998796-17: Media YouTube ignore in media field after changing PHP from 5.6 to 7.1
Wouldn't rule out an issue with a minor release of php 7.1.x , make sure you're using the latest version of php 7.1.x and if you have an issue, please let us know what minor version. My tests were using php 7.1.20-1+ubuntu18.04.1+deb.sury.org+1 and I was unable to find an issue but maybe I didn't fully test your use cases step by step. For me I tested basic functionality of the module, wysiwyg embedding and the media browser, this works for me for all versions of php that I tested including php 7.2.x.
Comment #18
ChaseOnTheWebI have not had a chance to debug this any further.
Here are the versions I've tried:
7.1.12 (Acquia Dev Desktop, OSX) and 7.1.22 (Acquia Cloud, Linux)
7.2.9 (Acquia Dev Desktop, OSX)
I thought I would try building PHP with debug symbols enabled, but that has turned out to be a headache on OSX. When I have time I'll have to spin up a Linux VM and see what more progress I can make.
Comment #19
joseph.olstadjust to let you all know, I've extensively tested media with the media_dev distribution
no patch needed.
My servers run Ubuntu however I've ran Media on other operating systems before.
keep in mind there's almost 50,000 installs of the recent version of media.
If you're running php 7.2.x , make sure you're using the latest DEV release of Drupal core, NOT 7.59 , for php 7.2.x you need 7.x-dev of drupal core 7.x
otherwise you'd have to patch 7.59
rather than patch, it's easier to just use the dev release of core.
7.60 should be released soon so once it is released that should resolve it.
Comment #20
baronmunchowsen CreditAttribution: baronmunchowsen commentedHi there,
I am experiencing this same issue on Pantheon with PHP 7.1 running Media-7.x-2.20. I can also recreate the same issue locally using php 7.1 on Nginx (Valet+ https://github.com/weprovide/valet-plus). I get a 502 Nginx Error when using the media browser from a field with the media browser set as the field widget (field type = image, field widget = media browser). I do not get the same error when using the media browser from a wysiwyg.
To debug I can remove the 'options' parameter from the media/browser URL and do not get the server error. The 'options' parameter is not present when the dialog is triggered from the WYSIWYG context and as such works without error.
Thanks
Edit 1:
Commenting out
array_walk_recursive($params, 'media_recursive_check_plain');
on line 1263 of media.module (https://cgit.drupalcode.org/media/tree/media.module?id=7.x-2.20#n1263) removes the issue. Not sure why it would.Edit 2:
The issue seems to be with array_walk_recursive itself. Replacing the call with a custom implementation such as below, fixes the issue:
However I am not getting any errors with other implementations of array_walk_recursive in the Drupal code (e.g. Webform), nor when I create a test script to parse an array of values. Therefore I'm somewhat stumped as to why this is happening at the precise point.
Comment #21
joseph.olstadthanks for your persistence with this issue.
I'll try review these latest findings soon.
unfortunately I do not have any nginx environments handy at the moment.
Comment #22
ChaseOnTheWebThe suggestion in #20 worked for me on both my local and production environments on all sites where I was seeing the issue.
I have made a patch for the workaround in #20.
@mr.les, could you try the proposed patch and see if it helps you as well?
Thanks for your assistance, baronmunchowsen!
Comment #23
baronmunchowsen CreditAttribution: baronmunchowsen commentedA further note - changing PHP version to 5.6 removes the issue also.
Thanks!
Comment #24
joseph.olstadEnveryone having this issue are you running NGINX or Apache2?
Comment #25
joseph.olstadTriggered more tests.
Comment #26
joseph.olstadOk this passes all tests, if no objections will commit it and publish new releases for all branches.
Comment #27
joseph.olstadTo be pushed in very soon
Comment #31
joseph.olstad