Admin theme is used on error pages below /admin

Did you test this?

  $custom_theme = variable_get('customerror_' . $error_code . '_theme', ($error_code == 403 ? variable_get('admin_theme', 0) : 0));
  if (!empty($theme)) {
    $custom_theme = $theme;

How is the above code supposed to work? Who will set the variable $theme?

Also, please do not use tabs and revise the code style to conform with Drupal's code style guidelines.

Why should the 403 have the admin theme by default? This is not backwards compatible with the existing behavior and can be confusing and even ugly for sites that have a nice custom theme but use garland or plain zen for admin.

Also, the code is obscure, which means it is not easy to maintain.

I refactored the D5 version in the attached. Please review and test.

I'd love this feature, and the patch here doesn't apply against the current version.

I too would like to see this feature applied, as I use two different themes for admin/non-admin sections.

Here is a patch against 6.x-dev version with code in #1 and #4 combined.

Sorry, a revised version of #8. Please review.

The patch at #4 no longer works. Is this working in the 5.x dev release?

Just tested 5.x dev and it doesn't have the patch. I've tried manually applying code from #4 but too much has changed. Does anyone have an old version of custom error from around July, 2008 ? It isn't listed in the previous releases.

I'm just chiming in here to say the patch in #8 works great for me and resolves the 'admin theme on 403/404 pages' issue. Thanks! It'd be great if the patch was incorporated into the module.

Committed the patch in #9 to 6.x-1.x-dev. Should be in the tarball in a few hours.

Thanks to all.

This isn't fixed for 5.x branch

I am not maintaining the 5.x branch actively anymore.

However, if someone wants, they could test the patch of 5.x and verify that it is working, or reroll it if it is not, and I will commit it once it is verified working on that branch.

I hope you are still working on this, as I cannot get any of these patches to work for me.
I might be a little green behind my Drupal-ears, but here goes (any understanding and help is deeply appreciated):

After I installed the module I copied the patch to the customerror module folder and opened a console and went to the customerror module path.
Then (for the #8 patch) I ran 'patch customerror.module customerror-drupal6-278575-8.patch' and it responded with:
Hunk #3 succeeded at 165 with fuzz 2 (offset 1 line)
Hunk #4 succeeded at 275 (offset -7 lines)
I get the 'Theme' selection option in '/admin/settings/customerror', but the 403 theme remains the admin theme and NOT the selected theme.
I tried to disable/enable the module as well but it didn't help.
I wonder if there is missing a part somewhere and what it should look like :S

Seems nobody (including anil614sagar) is working on this any more. It appears to fixed for D6, so I am changing version. D5 version is no longer maintained. I am not going to spend time on backporting this to D5.

However, if someone wants, they could test the patch of 5.x and verify that it is working, or reroll it if it is not, and I will commit it once it is verified working on that branch.

I'm closing now, but feel free to reopen if you're willing to test the D5 patch.

This was closed prematurely. This isn't fixed in 6.x after all. Reopening, and changing category to bug report.

Just made it clearer what the problem is about.

I am not going to work on issues affecting D6.

This is actually still happening on 7.x-1.1, debugging into the customerror_page() function, global $custom_theme is correctly being set above the switch ($code) statement but it is still rendering in the admin theme.

Reproducable by being logged in as an authenticated user, which has permission to view the administration theme and attempting to hit /admin. Works correctly when doing the same thing as an anonymous user without that permission.

The global $custom_theme that is used to implement this for the D5 and D6 branches is not used in D7.

D7 provides two different mechanisms for overriding the theme: hook_custom_theme() and theme callback.

However, both are called quite early in the bootstrap process, and the core mechanism that determines what theme to use for pages on the admin path overrides them.

I can't see how to fix this without hacking core or doing something equally nasty. Feel free to reopen if you have a patch that fixes this for D7.

It looks like this is changed for D8: #1954892: Replace 'theme callback' and hook_custom_theme() with a clean theme negotiation system. It is too early to tell, but maybe this can be reopend and fixed for the D8 version?

Damn that's a shame :( Hopefully someone can come up with a smart solution who has more experience with the core themeing processes. Thanks for the response :)