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

arthurf’s picture

Version: 7.x-1.x-dev » 7.x-2.x-dev
Status: Active » Postponed

If 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.

mfer’s picture

Is the intent that the media browser on be displayed in a modal?

arthurf’s picture

It 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.

mfer’s picture

Status: Postponed » Active

We 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.

dave reid’s picture

Devel 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?

dave reid’s picture

Status: Active » Postponed (maintainer needs more info)
dave reid’s picture

chris matthews’s picture

Issue summary: View changes
Status: Postponed (maintainer needs more info) » Closed (outdated)

Closing 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