Student projects/Admin page cleanup

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
• Redo the user management interface
• 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

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)

• 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.