Developer Manual
Administration
As the music archive grows, it becomes increasingly useful to provide an administration section for managing the site. The administration area can be developed gradually, following the same incremental philosophy used throughout the project.
Phase 1 — Protect the Admin Pages
Initially, the administration pages should be kept separate from the public-facing pages.
/
index.php
track.php
search.php
...
/admin/
index.php
feedback-admin.php
tracks-admin.php
artwork-admin.php
login.php
logout.php
/includes/
admin-auth.php
Every page within the /admin/ folder should begin with:
require_once __DIR__ . '/../includes/admin-auth.php';
If the administrator is not logged in, the page should redirect to login.php.
Phase 2 — One Administrator
Initially there is no need for a complete user-management system. A single administrator account is sufficient.
Rather than creating a users table immediately, the site can simply authenticate one username and one securely hashed password.
Since there is currently only one administrator, introducing additional complexity provides little benefit.
Phase 3 — Sessions
After a successful login, PHP sessions can be used to remember the user's authenticated state.
$_SESSION['logged_in'] = true;
Every administration page checks this session variable before displaying its contents. Logging out simply destroys the session.
This is standard PHP practice and provides a simple, reliable solution.
Phase 4 — Build Administration Tools
Once the administration framework exists, new tools can be added incrementally.
For example, the Administration menu may eventually become:
- Dashboard
- Tracks
- Add
- Edit
- Delete
- Artwork
- Feedback
- Moderate
- Reply
- Hide
- Resolve
- Genres
- Instruments
- Composition Status
- Database Statistics
- Developer Tools
Notice that these correspond closely with the existing database tables, making the administration area a natural extension of the archive.
Avoid Unnecessary Complexity
There is no immediate need for:
- Multiple users
- User roles
- Permissions
- Editors or moderators
These features add significant complexity and should only be introduced when there is a genuine requirement.
Future Expansion
If additional contributors eventually need access to the administration area, a users table can be introduced.
A possible structure might include:
users id username password_hash display_name role active created_at
Typical roles might include:
- Administrator
- Editor
- Viewer
The Administration Dashboard
One feature worth introducing early is an Administration Dashboard. Initially it need do little more than act as the front door to the administration area.
Administration Tracks Feedback Artwork Genres Instruments Developer Manual Log Out
Once this dashboard exists, every new administration feature simply becomes another link on the page.
Design Philosophy
The administration system should follow the same philosophy used throughout this project:
- Build incrementally.
- Keep the code understandable.
- Avoid unnecessary complexity.
- Only introduce new features when there is a genuine need.
The recommended approach is therefore to begin with a single password-protected administrator account and only introduce a full users table when there is a second person who genuinely requires access.