| only for RuBoard - do not distribute or recompile | |
The administration interface we have implemented is very simple. All we have done is build a Web interface to the database with some front end authentication. This is much of the same code as used in Chapter 24. We have included it here for completeness, but with little discussion.
The administration interface requires a user to log in via the login.php file, which then takes her to the administration menu, admin.php. Th login page is shown in Figure 25.11. (We have omitted the login.php file here for brevity—it's almost exactly the same as the one in Chapter 24. If you want to look at it, it's on the CD-ROM.) The administration menu is shown in Figure 25.12.
The code for the admin menu is shown in Listing 25.17.
<?
// include function files for this application
require_once("book_sc_fns.php");
session_start();
if ($username && $passwd)
// they have just tried logging in
{
if (login($username, $passwd))
{
// if they are in the database register the user id
$admin_user = $username;
session_register("admin_user");
}
else
{
// unsuccessful login
do_html_header("Problem:");
echo "You could not be logged in.
You must be logged in to view this page.<br>";
do_html_url("login.php", "Login");
do_html_footer();
exit;
}
}
do_html_header("Administration");
if (check_admin_user())
display_admin_menu();
else
echo "You are not authorized to enter the administration area.";
do_html_footer();
?>
This code probably looks familiar; it is similar to a script from Chapter 24. After the administrator reaches this point, she can change her password or log out—this code is identical to the code in Chapter 24, so we will not cover it here.
We identify the administration user after login by means of the $admin_user session variable and the check_admin_user() function. This function and the others used by the administrative scripts can be found in the function library admin_fns.php.
If the administrator chooses to add a new category or book, she will go to either insert_category_form.php or insert_book_form.php, as appropriate. Each of these scripts presents the administrator with a form to fill in. Each is processed by a corresponding script (insert_category.php and insert_book.php), which verifies that the form is filled out and inserts the new data into the database. We will look at the book versions of the scripts only, as they are very similar to one another.
The output of insert_book_form.php is shown in Figure 25.13.
You will notice that the Category field for books is an HTML SELECT element. The options for this SELECT come from a call to the get_categories() function we have looked at previously.
When the Add Book button is clicked, the insert_book.php script will be activated. The code for this script is shown in Listing 25.18.
<?
// include function files for this application
require_once("book_sc_fns.php");
session_start();
do_html_header("Adding a book");
if (check_admin_user())
{
if (filled_out($HTTP_POST_VARS))
{
if(insert_book($isbn, $title, $author, $catid, $price, $description))
echo "Book '$title'was added to the database.<br>";
else
echo "Book '$title'could not be added to the database.<br>";
}
else
echo "You have not filled out the form. Please try again.";
do_html_url("admin.php", "Back to administration menu");
}
else
echo "You are not authorised to view this page.";
do_html_footer();
?>
You can see that this script calls the function insert_book(). This function and the others used by the administrative scripts can be found in the function library admin_fns.php.
In addition to adding new categories and books, the administrative user can edit and delete these items. We have implemented this by reusing as much code as possible. When the administrator clicks the Go to main site link in the administration menu, she will go to the category index at index.php and can navigate the site in the same way as a regular user, using the same scripts.
There is a difference in the administrative navigation, however: Administrators will see different options based on the fact that they have the registered session variable $admin_user. For example, if we look at the show_book.php page that we were looking at previously in the chapter, we will see some different menu options. Look at Figure 25.14.
The administrator has access to two new options on this page: Edit Item and Admin Menu. You will also notice that we don't see the shopping cart in the upper-right corner—instead, we have a Log Out button.
The code for this is all there, back in Listing 25.8, as follows:
if( check_admin_user() )
{
display_button("edit_book_form.php?isbn=$isbn", "edit-item", "Edit Item");
display_button("admin.php", "admin-menu", "Admin Menu");
display_button($target, "continue", "Continue");
}
If you look back at the show_cat.php script, you will see that it also has these options built in to it.
If the administrator clicks the Edit Item button, she will go to the edit_book_form.php script. The output of this script is shown in Figure 25.15.
This is, in fact, the same form we used to get the book's details in the first place. We built an option into that form to pass in and display existing book data. We did the same thing with the category form. To see what we mean, look at Listing 25.19.
function display_book_form($book = "")
// This displays the book form.
// It is very similar to the category form.
// This form can be used for inserting or editing books.
// To insert, don't pass any parameters. This will set $edit
// to false, and the form will go to insert_book.php.
// To update, pass an array containing a book. The
// form will be displayed with the old data and point to update_book.php.
// It will also add a "Delete book" button.
{
// if passed an existing book, proceed in "edit mode"
$edit = is_array($book);
// most of the form is in plain HTML with some
// optional PHP bits throughout
?>
<form method=post
action="<?=$edit?"edit_book.php":"insert_book.php";?>">
<table border=0>
<tr>
<td>ISBN:</td>
<td><input type=text name=isbn
value="<?=$edit?$book["isbn"]:""; ?>"></td>
</tr>
<tr>
<td>Book Title:</td>
<td><input type=text name=title
value="<?=$edit?$book["title"]:""; ?>"></td>
</tr>
<tr>
<td>Book Author:</td>
<td><input type=text name=author
value="<?=$edit?$book["author"]:""; ?>"></td>
</tr>
<tr>
<td>Category:</td>
<td><select name=catid>
<?
// list of possible categories comes from database
$cat_array=get_categories();
foreach ($cat_array as $thiscat)
{
echo "<option value=\"";
echo $thiscat["catid"];
echo "\"";
// if existing book, put in current catgory
if ($edit && $thiscat["catid"] == $book["catid"])
echo " selected";
echo">";
echo $thiscat["catname"];
echo "\n";
}
?>
</select>
</td>
</tr>
<tr>
<td>Price:</td>
<td><input type=text name=price
value="<?=$edit?$book["price"]:""; ?>"></td>
</tr>
<tr>
<td>Description:</td>
<td><textarea rows=3 cols=50
name=description>
<?=$edit?$book["description"]:""; ?>
</textarea></td>
</tr>
<tr>
<td <? if (!$edit) echo "colspan=2"; ?> align=center>
<?
if ($edit)
// we need the old isbn to find book in database
// if the isbn is being updated
echo "<input type=hidden name=oldisbn
value=\"".$book["isbn"]."\">";
?>
<input type=submit
value="<?=$edit?"Update":"Add"; ?> Book">
</form></td>
<?
if ($edit)
{
echo "<td>";
echo "<form method=post action=\"delete_book.php\">";
echo "<input type=hidden name=isbn
value=\"".$book["isbn"]."\">";
echo "<input type=submit
value=\"Delete book\">";
echo "</form></td>";
}
?>
</td>
</tr>
</table>
</form>
<?
}
If we pass in an array containing the book data, the form will be rendered in edit mode and will fill in the fields with the existing data:
<input type=text name=price
value="<?=$edit?$book["price"]:""; ?>">
We even get a different submit button. In fact, for the edit form we get two—one to update the book, and one to delete it. These call the scripts edit_book.php and delete_book.php, which update the database accordingly.
The category versions of these scripts work in much the same way except for one thing. When an administrator tries to delete a category, it will not be deleted if any books are still in it. (This is checked with a database query.) This avoids any problems we might get with deletion anomalies. We discussed these in Chapter 7, "Designing Your Web Database." In this case, if a category was deleted that still had books in it, these books would become orphans. We wouldn't know what category they were in, and we would have no way of navigating to them!
That's the overview of the administration interface. For more details, refer to the code—it's all on the CD-ROM.
| only for RuBoard - do not distribute or recompile | |