(sorry if this is a bit nonsensical as I am working out my terminology still)
In order to access pages below the root we need to have the code collect a list of pages accessible
There is one main direct access rout via a “?do=directname” parameter, as well as script-defined routes via a “?go=#######” parameter.
The do parameters are stored in the /wanda/app/.. directories below the root in the info.php file, these also include the access group information as well as a user access menu list for building “go” lists… more or less the “drag and drop entry” for that application.
here is an example of a an info.php file,
INFO.PHP in (/wanda/app/calendar/)
// group settings for application group 'calendar': // note application group is the same name as the directory... $wandagroup['calendar'] = array( 'name' => 'Event Calendar' ,'description' => '' ,'level' => array( 1 => 'Guest - Can view Calendars' ,2 => 'User Access - Can see Email addresses' ,3 => 'Data Access - Can add to Calendars within department' ,4 => 'Manager Access - Can manage calendars' ,5 => 'Admin - can do all administrative functions.' ) ); // menu information for the application: // for group - Calendar $wandamenu['calendar'] = array( //main menu entry information, application name, menu description, and app icon (in public_html/wanda/icon/) 'name' => 'Event Calendar' ,'description' => 'Event Tracking Calendar' ,'icon' => 'calendar.png' // the user access scripts in the menu // name, icon, link (init means they begin the page chain) // minimum user level to access. ,'submenu' => array( 'calendar' => array( 'name' => 'Calendar' ,'icon' => 'calendar.png' ,'link' => 'init' ,'level' => 1 ) ,'search' => array( 'name' => 'Calendar Search' ,'icon' => 'calendar_edit.png' ,'link' => 'init' ,'level' => 1 ) ,'report' => array( 'name' => 'Calendar Reports & Tools' ,'icon' => 'page_white_text.png' ,'link' => 'init' ,'level' => 1 ) ) ); // direct-access entries via the go? parameter ( i.e. wanda.php?go=calendar) $wandadirect['calendar'] = 'calendar/pubcal.php';
So to build a list of all the direct links we include in all the info.phps in all the subdirectories of /wanda/app:
PAGELIB.PHP (continued)
//if "do" read in direct links, then, if it exists, go to it. if(isset($_GET['do']) || isset($_POST['do'])) { //read in app defaults... $wandagroup = array(); $wandamenu = array(); $wandadirdata = opendir( WANDA_APPS ); while (false !== ($wandafile = readdir($wandadirdata))) { if ($wandafile != "." && $wandafile != "..") { $wandainfo = WANDA_APPS.$wandafile.'/info.php'; if(is_file($wandainfo)) { include $wandainfo; } } } $wandadocode = cleanValue((isset($_GET['do']) ? $_GET['do'] : $_POST['do'] )); if(isset($wandadirect[$wandadocode])) { define('WANDA_APP' ,WANDA_APPS.substr($wandafile,0,strpos($wandafile,'/')+1)); include WANDA_APPS.$wandadirect[$wandadocode]; exit(); } }
In older version of WANDA I had the menus and such in a database table, which would be prone to problems if the DB was damaged or could be compromised by another rouge script. This feels more sturdy as well as secure.
Scripts that are direct access with forms can just use (as an example) wanda.php?do=calendar for their form action, it will submit back to the same page (or use another direct page entry if that is your thing)
If we fail this part we will leave direct access (except at the end to force login), so in next part we will go to user access, using links with sessions, and all that other goodness.
~~LINKBACK~~ ~~DISCUSSION~~