Problem/Motivation
The current admin interface divides admin pages mainly by Configuration, Structure and Content, but there is no clear definition of what is what.
For several modules, admin pages were placed in an earlier Drupal version, but since then their functionality has been increased (for example contact forms). Others contain user generated content (for example taxonomy terms). As a result, some pages are in places where they are not expected, and a number of issues try to fix the placing of few pages at a time in the current structure. (See list of related issues).
The lack of consistency also has a secondary effect of failing to properly guide appropriate placement of menu items by contrib modules.
During DevDaysMilan, we did an exercise to see whether we could define what's Configuration, Structure and Content. What we came up with instead is a different way of classifying admin pages as Content, Site administration and Site building; as well as Users, Modules, and Translations.
The idea is to organize the admin area into sections by tasks and whether those tasks represent the building of the new site (typically exported to code) or the ongoing maintenance of content and administration (ephemeral database entities). It also allows us to use the structure of the admin interface to show new users how Drupal works.
Further thoughts:
- This classification is based on sites (or other projects) that are build by sitebuilders and themers - for other users who will then administrate the existing site (site administrators). They might need to change the recipient of an existing contact form, but not change the fields on the form. Or change the wording of the welcome email for new users, but not manage the fields and display of the user accounts in general.
- Of course there will always be projects, where site administrators also need to access more structural tasks, but if their role has permission to do so these admin pages are still available.
- All (lists of) content should go in the content section, including for example list of taxonomy terms, but we can use the operation links to guide users across site building, administration and and content.
- The issue that some menu items and taxonomy terms are structural – provided as part of the site building – instead of user generated content remains unsolved by this, but there is also no regression since they are currently technically content.
- Most reports can be placed under Administration as they help maintaining the site.
Proposed resolution
Decide whether this is a good direction to proceed.
Then formulate a set of rules to check where each admin page should be placed (instead of individual pick the places). This would (a) show whether what we are doing works, and (b) provide a standard that contrib modules can follow.
During discussion at DevDays Milan, it was proposed to do this as a community initiative.
Remaining tasks
User interface changes
Yes.
API changes
Might be if paths are changing.
Data model changes