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: 14 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.

Done: The dynamic music-list.php title, valid and invalid view handling, linked status, genre, and instrument lists, public feedback visibility, feedback administration, administrator login, session protection, account creation, the administration dashboard, adding main audio file records, and adding instrument, composition-status, and genre data to existing tracks are now working. The shared searchable Track ID control is also working across the three linked-data administration pages.
Partly done: A practical administration area now exists. The add-only workflow for tracks, instruments, composition statuses, and genres is working, but editing existing records, removing linked data, file uploads, reports, and a combined track-management page remain future work.
Alternative approach now preferred: The site currently keeps most database-processing PHP near the top of a page and leaves the main HTML structure readable below it. Repeated sections may later move into functions or include files, but the whole page will not be rewritten into long PHP echo blocks merely to avoid moving between PHP and HTML.
Still following the original development principle: Make one understandable change, test it, and then move on.

Latest Development Update — 14 July 2026

Administration workflow: The administration area now provides a much easier alternative to entering routine archive data directly through SQL. A main track record can be created first, followed by separate add-only operations for instruments, composition statuses, and genres.
Searchable Track ID selection: The linked-data administration pages use a Track ID text box backed by an HTML datalist. The administrator can begin entering the ID and select a matching track. JavaScript then displays the reference and title as confirmation before the form is submitted.
Shared JavaScript: The duplicated Track ID confirmation code has been moved into js/admin-track-selector.js and is loaded by the instrument, composition-status, and genre pages. The existing js/script.js continues to contain the audio-player behaviour for now.
Instrument entry decision: After testing, the free-text instrument field is considered fit for purpose. The proposed dropdown of existing instrument names and the proposed controlled instrument-definition table are both deferred unless a real consistency problem appears later.
CSS work: Large-scale CSS rationalisation has been parked. A separate test page under dwukmusic/ is being used to compare experimental stylesheets safely.
Next portability objective: Create a reusable head include and standardise paths so that the PHP files and supporting subdirectories can be copied into dwukmusic/ while still using the central root-level audio/ and images/ folders.

Immediate / Small Improvements

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.
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.
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.
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'] ?? ''.
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: Done using an alternative modern approach. The empty <a id="top"></a> element was removed and id="top" is now attached to the visible site-banner element in includes/menu.php. Existing Back to top links continue to work.
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

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.
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.
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.
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.
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

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.
Keep Genres and Instruments linked. These now link through to filtered music-list.php pages.
Progress: Done and retained.
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.
Possibly add a Tracks with Artwork view. A future view could be music-list.php?view=artwork.
Progress: Still a future possibility.
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

Show artwork only when artwork exists. The track page should not show an empty artwork section.
Progress: Done.
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/.
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.
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.
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.
Add previous / next track navigation. For example: Previous track, Back to list, Next track.
Progress: Still to do.
Improve track title and browser title. The browser title should ideally reflect the current track.
Progress: Still to review.

Feedback System Improvements

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.
Admin hide / unhide feedback. Feedback should be hideable without deleting it.
Progress: Done.
Admin delete feedback. This is a possible future admin action, but should be handled carefully.
Progress: Still deliberately deferred.
Confirmation before deleting feedback. Use a browser confirmation before permanently deleting a feedback record.
Progress: Still required if permanent deletion is added.
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.
Admin feedback list page. A page for listing feedback records in date order.
Progress: Done.
Admin feedback view page. A page for viewing one feedback record in detail.
Progress: Done.
Make Track ID clickable in feedback admin. Where feedback relates to a track, the Track ID should link to that track page.
Progress: Done.
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.
Possibly add admin notes later. This would allow private notes about how feedback has been handled.
Progress: Still a future possibility.
Possibly add feedback categories later. For example: General comment, Bug report, Track feedback, or Suggestion.
Progress: Still a future possibility.

Admin and Security Improvements

Protect admin pages. Admin feedback pages should eventually be hidden from the public.
Progress: Done for the current admin pages using requireAdmin();.
Create a simple admin login. One administrator account is enough for the current stage of the project.
Progress: Done and tested.
Use sessions. A session can record whether the admin user is logged in.
Progress: Done.
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.
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.
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.
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 main track records, adding instruments, adding composition statuses, and adding genres.

Database and Content Management Improvements

Composition status definitions page. A page explaining what different statuses mean.
Progress: Done.
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.
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.
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.
Add artwork management. Allow artwork to be uploaded, selected, or changed through an admin page.
Progress: Still to do.
Add YouTube management. Allow YouTube links to be added or edited through an admin page.
Progress: Still to do.
Add genre and instrument management. Allow genres and instruments to be added or removed from tracks through the site.
Progress: Partly done, with the add-only stage now substantially complete. admin-add-instrument.php, admin-add-composition-status.php, and admin-add-genre.php can add linked data to existing tracks. Editing and removing linked records, controlled definition tables, and a combined management page remain future work.
Add validation for missing audio files. Check whether every database filename exists in the audio folder.
Progress: Still to do.
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.

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, using a revised track-selection method. The page now uses a searchable Track ID text box backed by a datalist. Entering or selecting an ID displays the track reference and title as confirmation. The instrument itself remains a free-text field.
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: Reconsidered and deferred. After testing the working page, the current free-text instrument field was judged fit for purpose. A dropdown of existing instrument names can still be added later if inconsistent spelling or naming becomes a practical problem.
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: The free-text option is already the current working method. The earlier plan to combine an existing-instrument dropdown with free text is no longer an immediate priority.
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.
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.
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.

Composition Status Administration Development Plan

In coder-friendly terms, admin-add-composition-status.php inserts a new row into composition_status and links it to an existing audio_files record through audio_file_id.

Keep the page add-only for now. The page should add a composition status without editing or removing existing status rows.
Progress: Done and tested.
Use the shared searchable Track ID control. The page should confirm the selected track by displaying its reference and title.
Progress: Done using js/admin-track-selector.js.
Permit more than one status per track. The page should work with the revised multiple-status database model and reject only an exact duplicate of the same status for the same track.
Progress: Done. Duplicate checking is included before insertion.
Consider controlled status selection later. A future revision may use the status definitions as a controlled dropdown, but free text is retained for the present add-only workflow.
Progress: Deferred until the actual status names are reviewed and rationalised.

Genre Administration Development Plan

In coder-friendly terms, admin-add-genre.php inserts a new row into genres and links it to an existing audio_files record through audio_file_id.

Keep the page add-only for now. The page should add a genre without editing or removing existing genre rows.
Progress: Done and tested.
Use the shared searchable Track ID control. The page should confirm the selected track by displaying its reference and title.
Progress: Done using js/admin-track-selector.js.
Allow more than one genre per track. The page should reject only an exact duplicate of the same genre for the same track.
Progress: Done. Duplicate checking is included before insertion.
Consider a controlled genre list later. A dropdown or separate genre-definition table may be useful if naming consistency becomes a practical problem.
Progress: Deferred. The current free-text field is fit for purpose at this stage.

Search Improvements

Search by reference. This has already been discussed and added.
Progress: Done.
Search by title. This is already part of the search system.
Progress: Done.
Search by instrument. This is already part of the search system.
Progress: Done.
Search by genre. This is already part of the search system.
Progress: Done.
Search by composition status. This is already part of the search system or has been discussed.
Progress: Done.
Improve search help text. The search page should clearly explain what users can search for.
Progress: Done.
Possibly search lyrics later. This could be useful, but is not urgent.
Progress: Still optional.
Possibly search comments later. This may be useful for archive work.
Progress: Still optional.
Possibly highlight search terms in results. This would be a nice future improvement, but is not essential.
Progress: Still optional.

Navigation and Menu Improvements

Browse dropdown menu. The Browse menu includes options such as By Title, With Lyrics, Recent, and By Ref.
Progress: Done.
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.
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.
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.
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.
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

Developer Manual. A central place to document the structure and thinking behind the website.
Progress: Done and continuing to evolve.
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.
Development philosophy. The guiding principle is to change one thing, test it, and then move on.
Progress: Done and actively followed.
Database development history. Document why tables and fields were added.
Progress: Partly documented; continue recording significant schema decisions.
Composition status definitions. Document what each status means.
Progress: Done.
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.
Project progress summary. Record what has already been built.
Progress: Done and continuing to be updated.
Handling invalid music-list.php requests. Document why invalid views show a visible error instead of silently defaulting.
Progress: Done.
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

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.
Improve admin table styling. This would be useful for feedback lists and other admin pages.
Progress: Still to do.
Improve track artwork sizing. Artwork is already working, but could be tuned later for desktop and mobile.
Progress: Still optional.
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.
Continue mobile layout improvements. Keep pages readable and easy to use on smaller screens.
Progress: Ongoing.
Keep the light, readable design. The current white background, dark text, and simple structure suit the project.
Progress: Current preference retained.

Technical Hygiene

Use dynamic CSS and JavaScript cache busting. This is already being done with filemtime().
Progress: Done using filemtime(). A separate CSS test page in dwukmusic/ can switch between experimental stylesheets passed in the URL. The stylesheet name is restricted to an allowed list before it is used.
Canonicalise www and non-www addresses. Choose either davidwhiteuk.com or www.davidwhiteuk.com and redirect the other.
Progress: Still to confirm.
Add redirects for legacy pages. For example, redirect contact.php to feedback.php.
Progress: Still to do.
Possibly add a simple site_log table. This could record Information, Warning, Error, and Security events.
Progress: Still optional.
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.
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.
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.

JavaScript Organisation

Keep JavaScript separate from PHP helper functions. PHP runs on the server, while JavaScript runs in the visitor's browser. Therefore, browser functions such as Track ID confirmation belong in a .js file rather than includes/functions.php.
Progress: Decision adopted.
Use a dedicated shared file for Track ID confirmation. The same behaviour is required by the instrument, composition-status, and genre administration pages.
Progress: Done using js/admin-track-selector.js.
Keep the existing audio script separate. The current js/script.js allows only one audio player to play at a time. It may later be renamed to audio-player.js to make its purpose more obvious.
Progress: Current file retained. Renaming is optional and deferred to a later tidy-up.
Do not force all JavaScript into one file. Shared site-wide behaviour may use a common file, while page-specific behaviour can use a separate descriptive file. This avoids loading unrelated code and makes each file easier to understand.
Progress: Current preferred approach.

Reusable Head Include and dwukmusic Portability Plan

The aim is to make a copy of the working PHP site under /dwukmusic/ for safe testing. The PHP files and supporting subdirectories can be copied, while the large shared media folders /audio/ and /images/ remain at the website root.

Create a reusable HTML head include. Consider creating includes/head.php to hold the common character set, viewport, browser title, and stylesheet link.
Proposed approach: Each page sets values such as $pageTitle and, where required, $cssFile before including head.php. The include should provide safe defaults if either variable has not been set.
Keep the stylesheet URL portable. For pages copied together into dwukmusic/, the browser-facing CSS URL should remain relative, for example css/styles.css or css/<selected stylesheet>. This lets the same page structure work from either the website root or the copied test folder.
Important implementation detail: Inside includes/head.php, use the include file's filesystem location for filemtime(), for example __DIR__ . '/../css/' . $cssFile, while keeping the HTML href relative to the requested page.
Use relative links between copied site pages. Links such as track.php, admin-dashboard.php, feedback.php, and css/styles.css should be relative to the page being viewed. If the same folder structure is copied intact, these links should continue to work inside dwukmusic/ without pointing back to the live root copy.
Progress: Planned path review still to be completed across the site.
Use root-absolute URLs only for shared media. Audio and artwork/banner files should use root-absolute browser URLs such as /audio/example.mp3 and /images/banner.png. This lets both the live pages and the dwukmusic/ copies use the same central media folders without duplicating them.
Progress: Still to audit. In particular, banner, artwork, and audio links should be checked and changed consistently.
Use reliable PHP include paths. Server-side includes and requirements should use __DIR__ where practical, for example require_once __DIR__ . '/includes/config.php'. This is separate from browser URLs and makes PHP file loading less dependent on the current working directory.
Progress: Already used in many database and authentication pages; continue applying it consistently.
Test the copied site in stages. Copy the PHP files and supporting folders into dwukmusic/, excluding audio/ and images/. Test the home page, menu, CSS, JavaScript, database access, public track pages, and administration pages one stage at a time.
Progress: The initial CSS test page already works in dwukmusic/. Full-site copy testing is the next stage.
Keep the future admin-folder migration separate. Moving admin pages into an admin/ subdirectory would introduce a different relative-path level and should remain a later, separately tested migration.
Progress: Deferred as previously decided.

Bigger Future Possibilities

Create a proper admin area. Manage tracks, feedback, genres, instruments, statuses, artwork, and YouTube links.
Progress: In progress and now practically useful. Login, logout, authentication, account creation, dashboard, feedback management, add-track, add-instrument, add-composition-status, and add-genre operations now exist.
Create a track inventory page. An administrative list of all tracks, possibly showing missing information.
Progress: Still to do.
Create missing information reports. For example, tracks without lyrics, artwork, status, genres, instruments, or comments.
Progress: Still to do.
Create a public / private distinction. Some tracks may eventually be hidden from public view while remaining in the archive.
Progress: Still to do.
Add is_visible or is_public to audio files. This would be similar to the visibility field used for feedback.
Progress: Still to do.
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.
Add project notes or history per track. Each piece could have its own development log.
Progress: Still a future possibility.
Add collaboration notes. Useful where Mary or others give feedback.
Progress: Still a future possibility.
Add richer categorisation. For example: mood, tempo, style, purpose, completeness, vocal / instrumental, and similar information.
Progress: Still a future possibility.
Add downloadable inventory or export. For example, export the track list as a CSV file.
Progress: Still a future possibility.
Add sitemap and SEO improvements. This is not urgent, but may be useful as the public site grows.
Progress: Still a future possibility.
Add a better 404 page. A friendly site-wide not-found page would improve the visitor experience.
Progress: Still to do.
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:

Make the music-list.php browser title dynamic.
Progress: Done.
Hide the “groups of twelve” text on filtered pages.
Progress: Still to do.
Add no-results messages for valid filtered pages with no matching tracks.
Progress: Still to do.
Add a contact.php redirect to feedback.php.
Progress: Still to do.
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

Create and test a reusable includes/head.php file, including safe handling of the browser title, selected stylesheet, and CSS cache-busting value.
Audit browser links so ordinary page, CSS, and JavaScript links remain relative and portable when the site is copied into dwukmusic/.
Change audio and image URLs to root-absolute paths such as /audio/... and /images/..., then test both the live site and the copied test site.
Copy the PHP files and supporting subdirectories into dwukmusic/ without copying the central audio/ and images/ folders, and test the copied site one page group at a time.
Add a no-results message for valid filtered music-list.php pages and hide or rewrite the groups-of-twelve explanation on non-paginated filtered views.
Keep the current add-only administration pages stable before combining them into a future track-management page.
Continue postponing the move into an admin/ folder until the current admin page names and responsibilities have settled.