Note: You are currently viewing documentation for Moodle 1.9. Up-to-date documentation for the latest stable version is available here: Student projects/Admin page cleanup.

Student projects/Admin page cleanup: Difference between revisions

From MoodleDocs
(sorry for the many saves -- don't want to lose this if my browser crashes)
No edit summary
Line 52: Line 52:
*Site Files
*Site Files
*Environment
*Environment
== Proposed Structure ==
Coming soon...
== Official SoC Application ==
You can get my official SoC app [http://vkm.ca/?s=soc2006-moodle-app here].


== Random Ideas ==
== Random Ideas ==

Revision as of 15:46, 30 May 2006

Right now, I'm trying to work on a more "logical" reorganization of the settings accessible via the admin page. Slowly getting there... Please use the talk page to leave me any comments, I'll be checking it regularly.

Current Admin Layout (from 1.5)

Admin

  • Configuration
    • Variables
      • Interface
        • lang (select)
        • langmenu (select)
        • langlist (text)
        • langcache (select)
        • locale (text)
        • timezone (select)
        • country (select)
        • framename (text)
        • themelist (text)
        • allowuserthemes (select)
        • allowcoursethemes (select)
        • allowuserblockhiding (select)
        • showblocksonmodpages (select)
        • tabselectedtofront (select)
      • Security
      • Operating System
      • Maintenance
      • Mail
      • User
      • Permissions
      • Miscellaneous
    • Site Settings
    • Themes
    • Language
    • Modules
    • Blocks
    • Filters
    • Backup
    • Editor Settings
    • Calendar
    • Maintenance Mode
  • Users
    • Authentication
    • Edit User Accounts
    • Add a New User
    • Upload Users
    • Enrolments
    • Enrol Students
    • Assign Teachers
    • Assign Creators
    • Assign Admins
  • Courses
  • Logs
  • Site Files
  • Environment

Proposed Structure

Coming soon...

Official SoC Application

You can get my official SoC app here.

Random Ideas

  • I mentioned (in my proposal) using XML to store the hierarchy. I still think this is ideal (after all, XML seems to lend itself to hierarchical data), but I think there are a few ways to expand this. Notably, along with the settings, we can store
  1. whether a setting should appear on the initial (installation) config page (granted, this'll require a rewrite or modification of the initial config page)
  2. if a new setting has been set to the default because of an upgrade, then we can have a config page that appears when upgrading which shows only the flagged, new variables (i.e. those that were set to defaults)