Make WordPress Core

Opened 5 years ago

Last modified 5 years ago

#46716 new feature request

Site owner unable to control admin level users in Word Press dashboard

Reported by: anu24's profile anu24 Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Role/Capability Keywords:
Focuses: Cc:


Issue details:
I just created my website using WordPress. I am not a web developer and wordpress dashboard is pretty native and lacks default functionalities like giving sub headings in your page or blog ( editor should at least be as good as MS Word).

Also I can create new page under parent page but can't view their title under parent page in menu after publishing the page.( expected behavior)

So I need to take help of a web developer to get proper page templates, theme, plugin etc. I created a second administrator in my site to give access to a web dev to my site dashboard.

Now I ( site owner ) and the web developer have equal rights in the site. the Web developer can even change my password or delete me as an administrator, or log me out!!

How can wordpress allow that? There are plug ins which give different User roles but this is a core capability to add, edit or delete users including site owner. Plugins can be removed by an admin user so not useful to protect rights of site owner if he/she has to create other admins. If I do not give admin rights to web developer, he can not add templates/plugins/theme so I have to give admin rights..

Expected Behavior:
To make wordpress websites secure, the site owner should have Master admin rights.
Site owner should be able to add or remove other admins but other admins should not be able to view - site owner( master admin) among list of users. other admins should not be able to view, edit or delete any details of Master admin profile.

Also Publishing rights should be restricted to not allow every user to publish anything they write/change.

in fact there should be check box for different capabilities while creating users:

  1. User Management (All- master admin)
  2. User management ( all but not master admin)
  3. Developer capabilities ( templates, plug ins, coding )
  4. Read, write, edit posts (self only- Jr. blog writer)
  5. Read, write, edit, publish posts (self only- blog writer)
  6. Read, write, edit, publish posts ( all contributors- editor)
  7. Read write,edit, publish, delete posts, review publish comments ( all contributors- Sr.editor)

Additional improvements:
Today most blog sites have basic editing features which make them more user friendly for nontechnical bloggers. WordPress try to keep everything simple and is great for developers but please think from beginners' perspective and add basic capabilities to page editor. Also add menu editor or create core functionality to automatically add child page under parent page in main menu.

Change History (2)

#1 @knutsp
5 years ago

  • Severity changed from critical to normal
  • Type changed from defect (bug) to feature request

Hello @anu24 and very welcome to Trac!

Thank you for the report and suggestions.

I can't comment on all your suggestions, but mention that all capabilities can be customized to fit your needs. This is regarded plugin territory for now, and core only provides a basic set of roles and corresponding set of capabilities. Example: A contributor may be given edit_pages and then be able to create new pages for review, as for posts (not necessary publish them).

As it is, a user with the role Administrator, will have all capabilities. It is, however, possible to create a role with all capabilities, except edit_users, delete users and similar. A thing could be to include such a role among the built in roles.

Tickets here are best when they deal with one specific issue, and is not so good for listing a lot of enhancements and/or feature requests.

I take that the most important thing here is the concept of "site owner", as a role or special capability, one single user, preferably. That is very good suggestion. It should be connected to the site admin email setting, which is considered to be a kind owner (email only). A user with the same user_email as this setting could be defined as the site owner and this user be excluded from editing by general administrators. Some logic to handle this must be created.

This, and all the other suggestions, should probably be separate tickets, more tidy ones, separating concerns.

#2 @anu24
5 years ago

Thank You @Knutsp for responding timely. I was hopeless yesterday but feeling better now :).
I agree with your decision about role: "site owner" which should not be visible in users list to any other admin. Thus no one other than site owner himself/herself can edit profile/email/password etc crucial details of "site owner". Also agree that site owner Identity should be associated with his/her email provided while creating site.

I can create separate ticket for other suggestions. I understand that all the enhancements can be a lot of work- almost a full project.

Let's limit this ticket to only "site owner role creation in the core ( no one else can edit it)"?

The points below are for my understanding and should be separate from current ticket discussion

One question, like "posts list" which tell about published post, can we have an "activity log" that includes developer actions like adding/removing/editing/publishing themes/plug ins, taking site back up etc. tech actions. The activity log should be visible to site owner. This can help semi-technical site owners to have information about development activity going on in the site and they can get involved if necessary. I can create a separate ticket for this feature. The intent is to give site owners the ability to educate themselves and collaborate with development team and control undesired activity from third party especially when they are less technically qualified than the third party.

Will appreciate if you can let me know the name of plug in to create other roles without user management/ publishing rights. Just not sure if the plug in itself can be removed or edited by a admin level user.

Note: See TracTickets for help on using tickets.