Student projects/Admin page cleanup: Difference between revisions
From MoodleDocs
mNo edit summary |
|||
Line 10: | Line 10: | ||
* '''(not yet started)''' [[Student projects/Admin page cleanup/Admin subpages|Code script for displaying and accepting input from new admin interface (based on XML)]] | * '''(not yet started)''' [[Student projects/Admin page cleanup/Admin subpages|Code script for displaying and accepting input from new admin interface (based on XML)]] | ||
* '''(not yet started)''' [[Student projects/Admin page cleanup/Bookmarks|Build a per-user bookmarking system for admin settings]] | * '''(not yet started)''' [[Student projects/Admin page cleanup/Bookmarks|Build a per-user bookmarking system for admin settings]] | ||
* Redo the user management interface | * '''(not yet started)''' [[Student projects/Admin page cleanup/User management interface|Redo the user management interface]] | ||
* Code the necessary PHP to highlight changed settings after an upgrade | * '''(not yet started)''' [[Student projects/Admin page cleanup/Upgrade|Code the necessary PHP to highlight changed settings after an upgrade]] | ||
== Random Ideas == | == Random Ideas == |
Revision as of 21:29, 24 June 2006
Apologies for the mess on this page. I'll sort it out soon.
Right now, I'm trying to work on a more "logical" reorganization of the settings accessible via the admin page and simultaneously coding the PHP for the hierarchy (as a block) and for processing the XML file. Slowly getting there... Please use the talk page to leave me any comments, I'll be checking it regularly.
Key Project Tasks
- (almost done -- 1 issue remaining) Design XML DTD
- (almost done -- 3 issues remaining) Design new admin block
- (in progress) Reorganize and port Moodle admin settings to XML
- (not yet started) Code script for displaying and accepting input from new admin interface (based on XML)
- (not yet started) Build a per-user bookmarking system for admin settings
- (not yet started) Redo the user management interface
- (not yet started) Code the necessary PHP to highlight changed settings after an upgrade
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
- whether a setting should appear on the initial (installation) config page (granted, this'll require a rewrite or modification of the initial config page)
- 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)
- Site settings and editor settings could be grouped together (but I won't jumble up settings between the two of them; they'll just have the same parent in the hierarchy).
- Logs and Site Files sections look good as-is... probably won't make very many changes there
- Will try to improve on course administration interface (ideas to come soon)
- (Sort of) redo the user management interface so that we can get rid of the "Assign Teachers", "Assign Admins", etc. options on the main admin page (i.e. have a single link to a "User Management Interface" and do everything else from there.
- Group Modules, Filters, and Blocks (and other 16 types of plugins) under a top-level category called Plug-Ins (similar to the way it's done on moodle.org)
- Will probably use the PHP SimpleXML extension for reading XML files; variable data will be stored in current locations, not in XML, thus no XML changes will be made by PHP
Random Questions
- There are no settings for specific filters? They're only active or inactive? A: There can be, just none have any yet.
- When it comes to the hierarchical menu, I mentioned JavaScript-based... custom-written or is there already some sort of open source framework for collapsible JavaScript hierarchies? A: Settled -- I've already custom-written a JS hierarchy
- Anyone mind if I rewrite the user management pages? I'm thinking a single interface to do everything with regards to users. (details soon to be posted at Student projects/Admin page cleanup/User management interface)
- XML Schema or DTD?
- Are there changes to the admin section between the MOODLE_15_STABLE and MOODLE_16 interface? Which should I be working with primarily? A: Yup, use MOODLE_16.
Links
- Get back to the Student Projects listing.
- You can get my official SoC app here.
- My sample moodle setups are here for 1.5 and here for 1.6.
- A beta hierarchy script (actually, a PHP hierarchy object) that I created for this is available here.
- Useful link for me to learn about module programming.