In-Place Editor (IPE) should use admin theme

Agreed. I've noticed this breaks on custom themes quite severely.

Not sure if it would work, but I wonder if adding a hook_admin_paths can help?https://api.drupal.org/api/drupal/modules%21system%21system.api.php/func...

The revision_scheduler module does this:

/**
 * Implements hook_admin_paths().
 */
function revision_scheduler_admin_paths() {
  $paths = array();
  if (variable_get('node_admin_theme')) {
    $paths['node/*/revisions/schedule'] = TRUE;
    $paths['node/*/revisions/schedule/add'] = TRUE;

    // Support the workbench moderation paths.
    if (module_exists('workbench_moderation')) {
      $paths['node/*/moderation/schedule'] = TRUE;
      $paths['node/*/moderation/schedule/add'] = TRUE;
    }
  }
  $paths['revision-scheduler/*'] = TRUE;
  return $paths;
}

I actually disagree and think that panels IPE should use the active (not admin) theme. That's the point of the IPE... to edit in-place. I think it's an issue with the theme that it's not working correctly as several projects where we've created custom themes we have not run into any issues with the IPE.

This is also a dupe of https://drupal.org/node/2084063.

Hi Craig,

While you may not agree with the statement that IPE 'should' use the admin_theme, perhaps we can turn this into a feature request so we can make it configurable? When multiple users of the module run into this problem i would think it is worth the effort.

You mention not running into these problems yourself with custom themes but did these include custom styling for form elements? In our current project we do have this and it breaks the usabillity of the forms in the IPE. Indeed we could adjust form styling specifically for the IPE but in the end we would have to do this for every client.

If you can roughly send me in the right direction i will be more that willing to invest a little and commit a patch.

Kind regards,
Eric

The way the IPE works is that it adds extra markup to the rendered node view page. This allows ajax to work as an in-place-editor. You can't really have it use a different theme because it embeds itself into the active theme.

If you want to allow a user to edit the panelizer settings, layout, content, etc. in the admin theme all they need to do is click the Panelizer tab that is next to the node view/edit tabs. Note that doing this is not using the IPE.

The custom themes I've worked on for sites using panels/panelizer/IPE have had the form elements styled. I guess I'm somewhat confused where you're seeing the issue.

Do you have any screenshots of what you're experiencing?

I agree that it would be very nice if we could just define per site whether IPE should use the admin or front-end theme in the pop-up. I've tried all three steps listed on http://www.duckzland.com/content/drupal-7-force-ajax-use-admin-theme, but none seem to work.

caschbre; in our current project, the form labels are displayed in front of the form elements with a fixed width. We don't want/need this in IPE as it breaks the layout. In such case, it would be nice if IPE would just use Bartik.

IPE should use the admin or front-end theme in the pop-up

So are you referring to just the modal window that opens up where the user can select a pane or layout? Or are you referring to when the the main window that shows the panels where you can drag panes around?

Do you have any screenshots of the areas affected?

See attached image. We are indeed refering to the modal window that opens up with the pane edit form. We would like this edit form to be styled with the chosen admin theme.

The main window that let's you drag panes around is displayed in the default theme just like it is supposed to. Nothing to change there.

Same here. The form fields within the modal dialog look funny when used with the site theme.

Is the solution to stop IPE from breaking to use CSS with !important to enforce its styles AND to better namespace its UI CSS classes to avoid clashing with the Bootstrap modals?

Reducing this to Major as it does not cause dataloss.

+1

Yes,
would be great if IPE could be able to use the admin theme!

This would be a solution for some of our problems w/ IPE. I was about to add a bug about how the IPE "Finish" and "Cancel" buttons are too close. We could just add some CSS to our theme, and would rather make it part of IPE. However, this would be resolved if we didn't have to include our front-end theming work with IPE. Makes more sense to make IPE use the admin theme.

Even though I agree with the sentiment, this appears to be an issue with ctools modals more than IPE; as Panels utilizes ctools modals for these popovers. Any theme control for modals would need to be taken up with ctools.

In #1646654: Using admin theme in modal Earl seems to suggest that it's the responsibility of the module that defines the menu callbacks (FPP, Panels, etc.), however there must be something more going on here because all of the paths in question start with /admin/* and so are already considered urls that should use the admin theme.

We tried several back-end hooks and other tricks to get it to use the admin theme, but were unsuccessful.

Instead we decided to use some CSS to do a browser reset of the forms. Now they are at least usable. Attached is the SASS that we used. It's written with hopes of it being usable across projects, so hopefully someone else will be able to make use of this.