Config file for text, database for structured profile data

Architecture Decision Record

Status

accepted

Context

The portfolio has two kinds of updateable content. Some of it is simple scalar text — the homepage hero paragraphs, current focus label, intro copy. Other content is structured and needs CRUD — career timeline entries, skill groups, certifications, learning cards. The question was where each type should live.

Rationale

Not everything belongs in a database. A database makes sense when you need to add, edit, delete, and reorder rows through a UI. For text that changes maybe once a year and has no relational structure, a PHP config file is simpler, faster, and easier to reason about. Putting hero copy in MySQL means a table with one row and a form to edit it — unnecessary complexity. Putting career timeline entries in a PHP file means editing raw arrays to add a new role — unnecessary friction for something that changes every few years. Each type of content lives where it costs the least to maintain.

Trade-offs

The split means two places to look when updating content. Someone unfamiliar with the codebase might not immediately know that some content is in content.php and some are in the database tables. This is documented in the admin panel and in the file itself. The alternative — putting everything in the database — would mean admin forms for content that genuinely doesn't need them.

When I added a profile management system to the admin panel, I had to decide what goes in the database and what stays in a file.

The answer I landed on: if you need a UI to manage it, put it in the database. If you just need to edit a line of text occasionally, a PHP config file is enough.

Career timeline entries need CRUD — add a new role, edit the description, reorder. That belongs in MySQL with an admin interface.

The homepage hero copy — two paragraphs and a "current focus" label — doesn't need a table, a form, and a save button. It needs a file you open and edit directly. content.php is that file.

The risk is that content lives in two places. I accepted that tradeoff because the alternative — admin forms for every piece of text on the site — adds complexity without adding real value.

The rule I use: if updating it without a developer feels painful, put it in the database. If a text editor is fine, keep it in a file.