When I click the edit media button and the modal is loaded, styles from the administrative theme (seven in my case) get loaded and mess up the styling of the node edit page behind the modal frame (original comment: #1213252-94: Allow media file's fields to be edited in a modal or after upload in the media widget).

bsuttis figured out that this is because the media module defined media/*/edit/* as an administrative path. The problem can be fixed by implementing hook_admin_paths_alter() in a custom module:

* Implements hook_admin_paths_alter().
function mymodule_admin_paths_alter(&$paths) {
// Don't treat as admin path otherwise admin theme loads when modal appears.
$paths['media/*/edit/*'] = FALSE;

This solves the problem, but the question remains, whether this should actually be changed in media_admin_paths().

bsuttis' response: That's a good question, I realized later that when on node/*/edit a similar issue occurred (but reversed this time, site default CSS loaded on top of admin CSS).

I'd say the above fix works if you use one theme for admin/site default however it'll cause issues otherwise.

My solution to get around the node/*/edit issue and still use an admin theme for other /admin pages was to add $paths['node/*/edit'] = FALSE; to the hook as well so that editing a node will use the site's default theme.


Status:Active» Postponed (maintainer needs more info)

We actually had to add it to the admin paths as we've encountered way more problems with WYSIWYG and the site's default theme on media/*/edit/*. I think for now we should just recommend implementing the alter hook.

Not sure if this still a problem; there has been a lot of changes to media+file_entity over the past months... I will re-evaluate this soon.

Note that...

Status:Postponed (maintainer needs more info)» Active

I just realized that this is only a problem for me, because I have disabled "Use the administration theme when editing or creating content" on the Appearance settings page (see "Administration Theme" section at bottom of page).

So I think it should be this:

if (variable_get('node_admin_theme')) {
  $paths['media/*/edit/*'] = TRUE;

And probably be the same thing for the file/add path in file_entity...

Status:Active» Closed (works as designed)

+1 to Dave Reid's suggestion in #1; there have been a number of problems with Media and default site themes.

Although the suggestion in #3 could solve the issue, it could also cause confusion for site builders who may wonder why files sometimes use an administration path and sometimes don't. It might just be better for knowledgeable developers to use the alter hook or give users the "Use administration theme" permission.

Status:Closed (works as designed)» Active

@Devin Carlson: sorry for re-opening, but I don't agree.

I think it's fair to assume that a site-builder knows what he is doing when he decides to disable the "use admin theme" option (it's enabled by default). If he does disable the option, he always needs to make sure that the default theme can actually display the edit form properly... in my opinion this includes things like the media popup.

Duplicate issues:

There's another issue, where the administration's themes CSS is injected into the frontend theme after the popup is closed (it's loaded via ajax). For me, this is why I had to disable using the admin theme for said popup. It wasn't because I didn't like how it was styled, but because it would completely mess up the frontend website when you close the popup.

See my issue here:
#1783268: media_file_edit_modal (CTools Modal) is injecting CSS which is removed via hook_css_alter()

So if you could clear up that CSS injection problem as well.

There's all sorts of problems with how this is currently working.

Why don't we do what node module does?

I was having this exact same problem. I put the hook in per above. Thank you!

I'm not sure what the problems mentioned in #1 are but I tend to agree with #6.

Having any site that uses the default theme for node editing break when closing the dialog is not great and expecting users to write custom code to work around it seems a bit odd becuase it isn't exactly a far out edge case.

Is there any movement in this field? The modal breaks the front-end theme. Which seems like a fairly large bug to me, also I there's a large inconsistency in the pop-ups. When selecting a file the end user gets a totally different window. This is from a ux point-of-view bad practice. I would rather see the same modal style is used for selecting content and editing content.