In Drupal 7.x (no v7 in dropdown for bugs): Changing theme in the apperance section causes: "Access denied You are not authorized to access this page." This happens when logged in as the admin user with default (i.e. all) privileges set. Visiting the appearance page does not cause the error, only chaning the theme via "Enable and set default" or "set default" causes it.

Additionally a 404 error is caused when visiting the dashboard and making a search. This was fixed in my case by my web host but not the access denied error.

A user in irc chat identified: system_theme_default() as a probable cause, in modules/system/system.admin.inc

Devel is not installed.
After removing all modules which can be removed I still get the error.
Cookies are enabled

Url for getting access denied is:

http://www.danielsportfolio.co.uk/drupal/admin/appearance/default?token=...

Comments

joemoraca’s picture

this is just a guess - but try turning off clean urls and see if it works

FredderickSmith’s picture

http://drupal.org/node/1114770#comment-4840588

I had some the same issues, including random 404 errors. I gave the details of my issues, and the solutions, in that link above. Maybe it can help you.

polli’s picture

Same problem, deleting the cookies from my Drupal site allowed me to change the theme again.

The only thing I have running is the experimental module for Etherpad lite http://drupal.org/sandbox/webflo/1255474. I think the Drupal cookie interferes with the cookie from the Etherpad lite system, because they have the same domain name.

If someone confirms a problem with cookies, I'll take a closer look at it.

EvaldsUrtans’s picture

I had the same issue, solution for me was to remove htaccess from website root folder (I had unnecessary directives there)

TrevorBradley’s picture

I had modified my .htaccess in the following way:

  ###RewriteRule ^ index.php [L]
  RewriteRule ^(.*)$ index.php?q=$1 [L]

because I have a multi-hosted site that already uses mod_rewrite to alias subdirectories into full sites... worked great in D6, kills D7 for some reason. I undid the change, changed settings.php to take away the base url, change the theme, changed .htaccess and settings.php back, and my theme is changed.

TrevorBradley’s picture

AHA! Got it. Apparently the problem is with bootstrap.inc Figured it out from an out of date patch listed here:

http://drupal.org/node/757506

The patch didn't work for 7.9, but I have (or am about to) post an update patch there!

ivorscott’s picture

I got the same access denied issue as I tired to get into the theme settings for Omega. I still have the problem but I found out that it if I make my theme the default and the administration theme simultaneously I got access. Really stupid right? Any how the method works fine for me. I'll fix my settings this way and then change my administration theme back to garland.

Jayson Wonder’s picture

This is what happened to me. Why is clean url giving access denied errors?

How can we fix this problem still using clean URL's?

markosaurus’s picture

Oh boo! Looks like the same issue for me.

Custom theme (bartik based) and I keep getting access denied errors for some reason. I would just hide them, but they seemt o kill IE8 completely!

Any ideas?

TrevorBradley’s picture

markosaurus: Do you happen to be on a shared host that uses mod_rewrite to have drupal installed in a subdirectory? If so, check out my patch here: http://drupal.org/node/757506

ljeci.ilir’s picture

Have run through the same issue.
After few hours looking all over the web for a solution with no results.
I tried to disable all modules working with themes (themkey, mobile tools ...) that I had installed. Then I was able to enable and disable theme in the appearance page.

Hope this will help someone.

Cheers

enorm’s picture

turn off "Skin" module!
had the same issue in d7 with no possibilities to activate or deactivate themes;
Skin module 7.x-1.3;

sláinte, Erich!

jnilles’s picture

I had the same (or a similar) problem. In addition to bringing up the access denied page when I tried to change the theme settings, it also would not show the theme on the blocks page. Tried turning off every unneeded module and adjusting the memory that is available to php. (I am also getting out of memory errors when I clear the cache.) I even started looking for a new host yesterday.

The theme in question was a custom theme. It turns out that I had accidentally added the closing php tag ?> to the bottom of my file. Wish I'd realized that yesterday morning when I first noticed it. Still getting out of memory errors when I clear the caches though :(

Anyway some more details on the problem:

  • Drupal 7.12
  • It was a custom theme.
  • The theme worked in production. That is nodes were properly themed and changes to CSS and node templates appeared. I only realized there was a problem when I needed to change the blocks. Environment - Linux, Apache 2.2, PHP 5.2.17, MySQL 5.0.91
  • It worked completely on my development box. Environment - Win32, Apache 2.2.11, PHP 5.3.0 MySQL 5.1.36

Hope this helps someone else.

p_rooster’s picture

Component: Code » User interface

I disabled the Overlay module and it started to work. I was able to install, enable, and set to default any theme I could get my hands on. It also seemed to work better with clean urls.

ascendant’s picture

I have this bug on a minimal Drupal installation using 7.x dev (May 16 2013 equivalent 7.22)
Using a fresh minimal installation, I tried to set the theme from Bartik to Seven and received this error.
EDIT: ignore this, Seven can't be used as the site theme, which I as a Drupal newbie did not know. The following does apply, though:

Also, seems worth mentioning, a PHP error is returned along with the access denied error
Warning: Cannot modify header information - headers already sent by (output started at (root)/includes/common.inc:2700) in header() (line 1216 of (root)/includes/bootstrap.inc).

This line is the same code commented out in this bug:
http://drupal.org/node/772274

tonebari’s picture

Issue summary: View changes

I had a module where I called a variable $conf. It was actually living outside Drupal originally, one thing led to another, it was scoped to global :-) Commented out my module and the problem disappeared! :-D

Abbass’s picture

If you have WAMP installed it comes down to ticking a box to solve this , here is the solution https://www.drupal.org/node/1114770#comment-11737454