I'm not sure if this is better classified as a bug or feature request, but I think that the URL that gets loaded in the iframe when browsing media, media/browser, should be prefixed with "js/", so that it is js/media/browser.
I know that when the devel module attaches the query log to the bottom of a page, it is programmed to not do this for pages that begin w/ "js/" and "ajax/" among other things (since the convention seems to be to use "js/" and "ajax/" in the path for pages that are loaded via javascript).
I also know that it is common for people using the securepages module to add "js/*" to the list of paths to ignore (i.e., a path for which redirects to https or http version of the URL are disabled).
If the media browser follows this convention, it'll be one less path to have to remember adding to the list of URL paths to ignore in the securepages configuration.
Comments
Comment #1
arthurf commentedIf you want to post a patch for this that'd be great. I'm not sure that there really is a drupal-wide standard for this, though it might be an interesting conversation to start.
Comment #2
mfer commentedIs the intent that the media browser on be displayed in a modal?
Comment #3
arthurf commentedIt is an iframe popup. There was discussion about moving to use a modal framework like ctools but the consensus was that because plugins add arbitrary html and css it was better to do this inside an iframe.
Comment #4
mfer commentedWe should put the js/ in place. The media browser can be gotten to as a full page but it doesn't work right. I know of a few devs this unspoken expectation messed with. Putting the js/ prefix in place makes it more evident.
Comment #5
dave reidDevel is not automatically programmed to ignore any requests that start with 'js/'. In reality it ignores if a content type header that includes 'json' has been sent, which would never apply in this case. So I think the better solution here is to disable devel for the media browser 'popup' pages by using
$GLOBALS['devel_shutdown'] = FALSE;Actually even better would have Devel implement hook_suppress().
Maybe the argument for secure pages could be expanded a bit? Why would we want to make that change?
Comment #6
dave reidComment #7
dave reidSee also: #1666528: Add support for hook_suppress() to hide devel output
Comment #8
chris matthews commentedClosing this issue as outdated. However, if you think this issue is still important, please let us know and we will gladly re-open it for review.
sincerely,
- the Drupal Media Team