Subject says it.
These are NOT clean installs, but they are standard installs with minimal content running from a recent git pull (11 Aug 2013).
On two different installs logged in as user 1, I am unable to visit any user pages, including the one for user/1 (i.e. my own user page). In addition, in admin/people, the Operations column is blank.
It works fine on a clean install on the same servers. So somewhere in the process of pointing and clicking, I was able to break this, but since I don't visit that page often, not sure when/where/how. I know that's not much help, but it's bound to come up again since I don't think I did anything particularly strange.
This only affects access to user pages - all other admin pages work fine and the Administrator role has all available permissions.
All of these paths give Access Denied errors
/user
/user/1
/user/8
/user/1/edit
/user/8/edit
etc
This is true on two systems:
- CentOS 5, Apache 2.2.22, PHP 5.3.13
- Win8, Apache 2.4.2, PHP 5.4.3
This is not related to #1112824: Access Denied for /user/login when user is already logged in which is a UI/feature issue.
Comments
Comment #0.0
ergophobe commentedClarify that these are not clean installs.
Comment #1
ergophobe commentedSo I did a directory diff between the working clean install and the non-working install on the config_[hash] directory.
Turned out that on the non-clean, I had enabled the Layout module. When I disabled the layout, the "Operations" column once again had Edit buttons and whatnot.
Though I get no warnings, notices or errors output, it looks like this is perhaps a variation of #1986140: User 1 profile Access Denied (view and edit) -> Warning Illegal offset type in isset or empty
That in turn has been marked a duplicate of #1978910: Convert layout_page_view to a Controller which is meant to fix Access Denied for all user pages (see #60, https://drupal.org/node/1978910#comment-7584719 ).
Comment #1.0
ergophobe commentedmention behavior on clean system