Proposed Developments and Enhancements

This page records possible future developments, improvements, and design ideas for the music archive website. These are not all urgent tasks. Some are small practical improvements, while others are longer-term ideas that may or may not be needed as the site grows.

Last Updated: 13 July 2026

Progress Review

This review records progress made since the original list was written. The original proposals have been retained. Where work has been completed, changed, partly completed, or deliberately deferred, a progress note has been added rather than removing the original text.

Immediate / Small Improvements

  1. Make music-list.php page title dynamic. The visible page heading is already dynamic, but the browser title can also be made dynamic.

    Progress: Done. The browser title now uses the same dynamic heading value as the visible page heading.

  2. Hide the “groups of twelve” text on filtered pages. Pages such as instrument, genre, and status currently show all matching tracks on one page, so the wording about groups of twelve may not always apply.

    Progress: Still to do. The explanatory text is still shown generally and should later be conditional.

  3. Add “no tracks found” messages. For example, a valid URL such as music-list.php?view=instrument&value=Octopus should say that no tracks were found, rather than showing an empty page.

    Progress: Still to do for valid filtered music-list.php requests.

  4. Make value handling safer. Use $_GET['value'] ?? '' rather than plain $_GET['value'], so the page does not produce warnings if a value is missing.

    Progress: Done. The filtered views use the null-coalescing form $_GET['value'] ?? ''.

  5. Add a top anchor. Since the page includes “Back to top” links, add either <body id="top"> or <a id="top"></a> near the top of the page.

    Progress: Partly addressed through the shared menu and Back to top links, but the final site-wide placement should be checked when navigation is reviewed.

  6. Add redirects for old or mistaken pages. For example, consider redirecting contact.php to feedback.php, and possibly contests.php to contents.php.

    Progress: Still to do.

music-list.php Improvements

  1. Keep the current valid / invalid view system. Known views include title, ref, recent, lyrics, instrument, genre, and status. Anything else should show the friendly “Sorry” page.

    Progress: Done and retained. Invalid views show a friendly visible error rather than silently becoming another valid view.

  2. Possibly refactor filtered views later. Instrument, genre, and status currently each have their own query. This is clear and readable. Later, repeated code could be reduced if it becomes worth doing.

    Progress: Current approach retained. The separate queries remain easy to read. Phil's function-based suggestions may be borrowed selectively later, especially for repeated pagination or track output.

  3. Possibly paginate filtered views later. At present, filtered views show all matching tracks on one page. That is fine while the numbers are small.

    Progress: Deferred. Current filtered result numbers do not yet require pagination.

  4. Preserve value in pagination links if filtered views are paginated later. For example, the page should preserve view=genre&value=Adult Contemporary&page=2.

    Progress: Still applicable if filtered pagination is introduced.

  5. Possibly make headings more specific. For example, Tracks for Adult Contemporary could eventually become Genre: Adult Contemporary, and Tracks for Sketch could become Status: Sketch.

    Progress: Still optional. The present wording remains acceptable.

contents.php Improvements

  1. Add links under Composition Status. Statuses should link to pages such as music-list.php?view=status&value=Sketch.

    Progress: Done. Status totals now link to the corresponding filtered music list.

  2. Keep Genres and Instruments linked. These now link through to filtered music-list.php pages.

    Progress: Done and retained.

  3. Possibly make Overall totals linkable. For example, Tracks with Lyrics could link to music-list.php?view=lyrics, and Total Tracks could link to music-list.php?view=title.

    Progress: Still to do.

  4. Possibly add a Tracks with Artwork view. A future view could be music-list.php?view=artwork.

    Progress: Still a future possibility.

  5. Possibly add a Tracks with YouTube view. A future view could be music-list.php?view=youtube.

    Progress: Still a future possibility.

Track Page Improvements

  1. Show artwork only when artwork exists. The track page should not show an empty artwork section.

    Progress: Done.

  2. Use the images folder for artwork. Artwork files are stored in images/, not in a separate artwork/ folder.

    Progress: Done. The correct folder is images/.

  3. Make empty sections disappear. If a track has no YouTube video, lyrics, comments, artwork, or feedback, avoid showing an empty heading.

    Progress: Largely done for the current track-page sections; continue applying the same rule to future sections.

  4. Possibly improve YouTube display. Only show the YouTube section when there is actually a YouTube link.

    Progress: Done for the current design: the section is conditional on YouTube data being present.

  5. Display genres, status, and instruments more neatly. Later, these could become clickable links back to filtered music-list.php pages.

    Progress: Partly done. The data is displayed; making every item a management or browse link remains future work.

  6. Add previous / next track navigation. For example: Previous track, Back to list, Next track.

    Progress: Still to do.

  7. Improve track title and browser title. The browser title should ideally reflect the current track.

    Progress: Still to review.

Feedback System Improvements

  1. Filter public feedback by visibility. Public track pages should only show feedback where is_visible = 1.

    Progress: Done. Public track pages use is_visible = 1.

  2. Admin hide / unhide feedback. Feedback should be hideable without deleting it.

    Progress: Done.

  3. Admin delete feedback. This is a possible future admin action, but should be handled carefully.

    Progress: Still deliberately deferred.

  4. Confirmation before deleting feedback. Use a browser confirmation before permanently deleting a feedback record.

    Progress: Still required if permanent deletion is added.

  5. Include Feedback ID in notification emails. The ID should be added after the database insert, using the last inserted ID.

    Progress: Done after the insert by using the last inserted ID.

  6. Admin feedback list page. A page for listing feedback records in date order.

    Progress: Done.

  7. Admin feedback view page. A page for viewing one feedback record in detail.

    Progress: Done.

  8. Make Track ID clickable in feedback admin. Where feedback relates to a track, the Track ID should link to that track page.

    Progress: Done.

  9. Show dashes for general feedback. General feedback may not have a track ID or track title, so display a dash instead of a blank value.

    Progress: Done.

  10. Possibly add admin notes later. This would allow private notes about how feedback has been handled.

    Progress: Still a future possibility.

  11. Possibly add feedback categories later. For example: General comment, Bug report, Track feedback, or Suggestion.

    Progress: Still a future possibility.

Admin and Security Improvements

  1. Protect admin pages. Admin feedback pages should eventually be hidden from the public.

    Progress: Done for the current admin pages using requireAdmin();.

  2. Create a simple admin login. One administrator account is enough for the current stage of the project.

    Progress: Done and tested.

  3. Use sessions. A session can record whether the admin user is logged in.

    Progress: Done.

  4. Create includes/admin-auth.php. Admin pages could include this file at the top to protect them.

    Progress: Done using the preferred shorter filename includes/auth.php instead.

  5. Possibly create an admin folder. Admin pages could later move into an admin/ folder.

    Progress: Reviewed and deliberately deferred. It remains a sensible later migration once the admin pages have settled.

  6. Avoid multiple users and roles for now. Do not overbuild the admin system until there is a real need.

    Progress: Reconsidered in part. A protected page can now create additional full administrator accounts, but roles and permission levels are still deliberately deferred.

  7. Create an admin dashboard. A simple page linking to feedback admin, track admin, developer pages, and other tools.

    Progress: Done. It currently links to feedback administration, administrator creation, adding tracks, and adding instruments.

Database and Content Management Improvements

  1. Composition status definitions page. A page explaining what different statuses mean.

    Progress: Done.

  2. Review actual status names. Current statuses include items such as Developing, Experimental, Fragment, Draft, Released, Sketch, and Finished. These may need rationalising later.

    Progress: Still to do later; no urgent rationalisation is required.

  3. Possibly improve the status model later. At present, one track has one status. A more flexible model is possible later, but only if needed.

    Progress: Completed using an alternative approach. The composition status table now permits more than one status for a track, using the track ID and status together as the key.

  4. Add track editing / admin pages. Eventually, tracks could be edited through web forms rather than directly in the database.

    Progress: Partly done. admin-add-track.php inserts a new main audio_files record, but editing existing main records is still future work.

  5. Add artwork management. Allow artwork to be uploaded, selected, or changed through an admin page.

    Progress: Still to do.

  6. Add YouTube management. Allow YouTube links to be added or edited through an admin page.

    Progress: Still to do.

  7. Add genre and instrument management. Allow genres and instruments to be added or removed from tracks through the site.

    Progress: Partly done. admin-add-instrument.php can add instrument data to an existing track. Editing, removing, genre management, and combined management remain future work.

  8. Add validation for missing audio files. Check whether every database filename exists in the audio folder.

    Progress: Still to do.

  9. Add validation for missing artwork files. Check whether every artwork filename exists in the images folder.

    Progress: Still to do.

Instrument Administration Development Plan

The current practical requirement is to add instrument information to an existing track. In coder-friendly terms, the admin page inserts a row into the instruments table and links it to an existing audio_files row through audio_file_id.

  1. Keep the current add-only instrument page. The first version of admin-add-instrument.php should add a new instrument association without editing or removing existing rows.

    Progress: Done. The page uses a dropdown to select an existing track and a free-text field to enter the instrument.

  2. Add a dropdown of instruments already used in the archive. Populate it from the existing data using a query such as SELECT DISTINCT instrument FROM instruments ORDER BY instrument. This will make commonly used names quick to select and help keep spelling and capitalisation consistent.

    Progress: Next proposed improvement.

  3. Retain a free-text option for a genuinely new instrument. The form should allow either an existing instrument to be selected or a new instrument name to be entered. Validation should make the choice clear and avoid adding the same instrument twice to the same track.

    Progress: Planned. The exact form behaviour will be decided when the dropdown is added.

  4. Do not create an instrument definitions table yet. For the current stage, the distinct values already stored in instruments can act as the available list. This avoids changing working database relationships before there is a clear need.

    Progress: Alternative approach preferred after reconsideration.

  5. Consider a controlled instrument list later. If consistency, descriptions, aliases, ordering, or richer instrument data becomes important, introduce a table such as instrument_definitions and a linking table such as track_instruments. Existing data would need to be migrated and the current queries updated.

    Progress: Deferred long-term option, not rejected.

  6. Build a combined track-management page later. A future page such as admin-manage-track.php?id=123 could edit the main track record and add or remove instruments, genres, and composition statuses from one place.

    Progress: Preferred eventual direction. The present small add-only pages can supply working logic that may later be reused.

Search Improvements

  1. Search by reference. This has already been discussed and added.

    Progress: Done.

  2. Search by title. This is already part of the search system.

    Progress: Done.

  3. Search by instrument. This is already part of the search system.

    Progress: Done.

  4. Search by genre. This is already part of the search system.

    Progress: Done.

  5. Search by composition status. This is already part of the search system or has been discussed.

    Progress: Done.

  6. Improve search help text. The search page should clearly explain what users can search for.

    Progress: Done.

  7. Possibly search lyrics later. This could be useful, but is not urgent.

    Progress: Still optional.

  8. Possibly search comments later. This may be useful for archive work.

    Progress: Still optional.

  9. Possibly highlight search terms in results. This would be a nice future improvement, but is not essential.

    Progress: Still optional.

Navigation and Menu Improvements

  1. Browse dropdown menu. The Browse menu includes options such as By Title, With Lyrics, Recent, and By Ref.

    Progress: Done.

  2. Keep By Ref lower in the menu. By Ref is especially useful for internal work, but probably less important for general visitors.

    Progress: Done in the current Browse menu.

  3. Possibly add Browse by Genre. This may not be necessary because the Contents page already provides genre links.

    Progress: Alternative approach currently preferred: use linked genre entries on Contents rather than enlarging the main menu.

  4. Possibly add Browse by Instrument. This may not be necessary because the Contents page already provides instrument links.

    Progress: Alternative approach currently preferred: use linked instrument entries on Contents rather than enlarging the main menu.

  5. Possibly add Browse by Status. This may not be necessary because the Contents page can provide status links.

    Progress: Alternative approach currently preferred: use linked status entries on Contents rather than enlarging the main menu.

  6. Separate public menu and developer menu. This is already being done using includes/menu.php and includes/menu-dev.php.

    Progress: Reconsidered in part. A Dev dropdown has also been added to the main menu for current development convenience, while menu-dev.php remains available. Access and visibility can be tightened later.

Developer Documentation

  1. Developer Manual. A central place to document the structure and thinking behind the website.

    Progress: Done and continuing to evolve.

  2. Project philosophy page. The site is a living archive and workshop, not just a polished catalogue.

    Progress: Largely documented through the home page and development documents; a separate page remains optional.

  3. Development philosophy. The guiding principle is to change one thing, test it, and then move on.

    Progress: Done and actively followed.

  4. Database development history. Document why tables and fields were added.

    Progress: Partly documented; continue recording significant schema decisions.

  5. Composition status definitions. Document what each status means.

    Progress: Done.

  6. Administration design page. Document how the admin system should grow slowly and practically.

    Progress: Partly covered by this roadmap and the working dashboard; a dedicated page remains optional.

  7. Project progress summary. Record what has already been built.

    Progress: Done and continuing to be updated.

  8. Handling invalid music-list.php requests. Document why invalid views show a visible error instead of silently defaulting.

    Progress: Done.

  9. Possibly create a site roadmap page. This could list planned features and their status.

    Progress: This page now serves that purpose.

CSS and Design Improvements

  1. Use table classes rather than global table styling. For example, use separate classes such as doc-table, admin-table, and detail-table.

    Progress: Still to do when CSS rationalisation is resumed.

  2. Improve admin table styling. This would be useful for feedback lists and other admin pages.

    Progress: Still to do.

  3. Improve track artwork sizing. Artwork is already working, but could be tuned later for desktop and mobile.

    Progress: Still optional.

  4. Fix spelling of lable eventually. The correct HTML element is label. This can be corrected later if it appears in the code.

    Progress: Still to check and correct during a later CSS tidy-up.

  5. Continue mobile layout improvements. Keep pages readable and easy to use on smaller screens.

    Progress: Ongoing.

  6. Keep the light, readable design. The current white background, dark text, and simple structure suit the project.

    Progress: Current preference retained.

Technical Hygiene

  1. Use dynamic CSS and JavaScript cache busting. This is already being done with filemtime().

    Progress: Done using filemtime(). A separate CSS test page can also switch between experimental stylesheets.

  2. Canonicalise www and non-www addresses. Choose either davidwhiteuk.com or www.davidwhiteuk.com and redirect the other.

    Progress: Still to confirm.

  3. Add redirects for legacy pages. For example, redirect contact.php to feedback.php.

    Progress: Still to do.

  4. Possibly add a simple site_log table. This could record Information, Warning, Error, and Security events.

    Progress: Still optional.

  5. Avoid blank screens. The work on music-list.php has already helped with this principle.

    Progress: Done as a guiding principle and improved in current error handling.

  6. Display friendly errors. The “Sorry” page in music-list.php is a good example.

    Progress: Done in music-list.php and now also used in admin forms with red error messages and green success messages.

  7. Do not silently default invalid URLs. Invalid URLs should show a visible message rather than pretending to be another valid page.

    Progress: Done for music-list.php.

Bigger Future Possibilities

  1. Create a proper admin area. Manage tracks, feedback, genres, instruments, statuses, artwork, and YouTube links.

    Progress: In progress. Login, logout, authentication, account creation, dashboard, feedback management, add-track, and add-instrument operations now exist.

  2. Create a track inventory page. An administrative list of all tracks, possibly showing missing information.

    Progress: Still to do.

  3. Create missing information reports. For example, tracks without lyrics, artwork, status, genres, instruments, or comments.

    Progress: Still to do.

  4. Create a public / private distinction. Some tracks may eventually be hidden from public view while remaining in the archive.

    Progress: Still to do.

  5. Add is_visible or is_public to audio files. This would be similar to the visibility field used for feedback.

    Progress: Still to do.

  6. Add date fields. For example: created_at, updated_at, and published_at.

    Progress: Partly present in feedback and admin-user tables, but not yet added as a full lifecycle model for audio files.

  7. Add project notes or history per track. Each piece could have its own development log.

    Progress: Still a future possibility.

  8. Add collaboration notes. Useful where Mary or others give feedback.

    Progress: Still a future possibility.

  9. Add richer categorisation. For example: mood, tempo, style, purpose, completeness, vocal / instrumental, and similar information.

    Progress: Still a future possibility.

  10. Add downloadable inventory or export. For example, export the track list as a CSV file.

    Progress: Still a future possibility.

  11. Add sitemap and SEO improvements. This is not urgent, but may be useful as the public site grows.

    Progress: Still a future possibility.

  12. Add a better 404 page. A friendly site-wide not-found page would improve the visitor experience.

    Progress: Still to do.

  13. Keep documenting decisions as the site grows. Documenting why decisions were made is one of the strongest features of the project.

    Progress: Ongoing and strongly retained.

Suggested Next Practical Priorities

The most useful next practical improvements are probably:

  1. Make the music-list.php browser title dynamic.

    Progress: Done.

  2. Hide the “groups of twelve” text on filtered pages.

    Progress: Still to do.

  3. Add no-results messages for valid filtered pages with no matching tracks.

    Progress: Still to do.

  4. Add a contact.php redirect to feedback.php.

    Progress: Still to do.

  5. Begin thinking about admin protection.

    Progress: Done and substantially implemented.

These are suggestions rather than requirements. The project should continue to grow slowly, with one change made and tested at a time.

Current Suggested Practical Priorities

  1. Add the existing-instrument dropdown to admin-add-instrument.php while retaining a free-text option for a new instrument.
  2. Add a no-results message for valid filtered music-list.php pages.
  3. Hide or rewrite the groups-of-twelve explanation on non-paginated filtered views.
  4. Add genre and composition-status operations as separate, understandable admin tasks before considering a combined track-management page.
  5. Keep the current administrator system stable and postpone the move into an admin/ folder until the page names and responsibilities have settled.