- small fixes/updates

includes/function.inc

@@ -75,7 +75,7 @@ function format_interval($timestamp) {
     $timestamp = $timestamp % 60;
   }
   if ($timestamp > 0) {
-    $output .= floor($timestamp / 86400) ." sec";
+    $output .= "$timestamp sec";
   }
   return $output;
 }

modules/documentation.module

@@ -52,13 +52,13 @@ function documentation_page() {
   <H3>Modules</H3>
     
   <P>When developing drop.org it became clear that we wanted to have a system which is as modular as possible. A modular design will provide flexibility, adaptability, and continuity which in turn allows people to customize the site to their needs and likings.</P>
-  <P>A drop module is simply a file containing a set of routines written in PHP.  When used, the module code executes entirely within the context of the site.  Hence it can use all the functions and access all variables and structures of the main egine.  In fact, a module is not any different from any other PHP file: it is more of a notion that automatically leads to good design principles and a good development model. Modularity better suits the open-source development model, because otherwise you can't easily have people working in parallel without risk of interference.</P>
+  <P>A drop module is simply a file containing a set of routines written in PHP.  When used, the module code executes entirely within the context of the site.  Hence it can use all the functions and access all variables and structures of the main engine.  In fact, a module is not any different from any other PHP file: it is more of a notion that automatically leads to good design principles and a good development model. Modularity better suits the open-source development model, because otherwise you can't easily have people working in parallel without risk of interference.</P>
 
   <P>The idea is to be able to run random code at given places in the engine.  This random code should then be able to do whatever needed to enhance the functionality.  The places where code can be executed are called "hooks" and are defined by a fixed interface.</P>
   <P>Even though we aim towards modularity, a basic rule is to avoid defined interfaces.  We are exceptionally careful when it comes down to adding interfaces because once you give an interface to developers they will start coding to it and once somebody starts coding to it you are stuck with it.</P>
-  <P>In places where hooks are made available, the engine calls each module's exported functions.  This is done by iterating through the <CODE>./modules</CODE> directory where all modules must reside.  If your module is named <CODE>foo</CODE> (i.e. <CODE>./modules/foo.module</CODE>) and if there was a hook called <CODE>bar</CODE>, the engine will call <CODE>foo_bar()</CODE> if this was exported by your module.</P>
-  <P>Each module has to declare a associative array named <CODE>$module</CODE> that serves as the list of hooks that a module wants to export or carry out.  Each entry in the array contains the name of a hook and an export function.</P>
-  <P>In our above example, <CODE>$module</CODE> would look like:</P>
+  <P>In places where hooks are made available, the engine calls each module's exported functions.  This is done by iterating through the <CODE>./modules</CODE> directory where all modules must reside.  Say your module is named <CODE>foo</CODE> (i.e. <CODE>./modules/foo.module</CODE>) and if there was a hook called <CODE>bar</CODE>, the engine will call <CODE>foo_bar()</CODE> if this was exported by your module.</P>
+  <P>Each module has to declare an associative array named <CODE>$module</CODE> that serves as the list of hooks that a module wants to export or carry out.  Each entry in the array contains the name of a hook followed by the name of the exported function.</P>
+  <P>In our above example, our associative array <CODE>$module</CODE> would look like:</P>
   <PRE>
     $module = array("bar" => "foo_bar");
   </PRE>