New to webdesign

@mmx68 — the problem described here is exactly the kind that grows as member counts rise. @buddylee17 pointed toward server-side handling, which is the right direction. The practical solution is to stop creating one static file per person and switch to a single dynamic profile page that reads and writes a member record based on a unique identifier (session or ID in the URL).

A short practical roadmap:

• Add authentication so each member has a login and a stable user id. Store passwords with a strong hash (bcrypt).
• Create a users table (id, username, email, bio, avatar, timestamps) and load the record into a single edit-profile form on GET; apply server-side validation and update the same record on POST.
• Always use parameterized queries / prepared statements to prevent SQL injection and validate/sanitize all inputs server-side. For avatars, validate MIME type, limit size, and keep files outside the webroot or use randomized filenames.
• Keep authorization checks so members can only edit their own records (compare session id to requested id).

Quick example of the SQL pattern used by the edit/update flow:

SELECT id, username, email, bio FROM users WHERE id = ?
UPDATE users SET email = ?, bio = ? WHERE id = ?

If building from scratch feels heavy, consider a CMS or user-management library to save time. Dreamweaver can help with markup, but generated server-side helpers often need manual review for security and robustness.