Rebuilding the Portfolio
Reconstructing a legacy WordPress portfolio locally while preserving content identity, media and project/article relationships, then updating its presentation.
- Version
- Local reconstruction and redesign
- Status
- In development
- Built with
- PHP, WordPress, Python, Docker
- My work
- WordPress development, migration tooling and presentation

Project overview
A portfolio has its own history. Mine includes project pages, technical posts, images and links between them, along with a theme that has been changed over time. Rebuilding the site meant keeping that history usable while making room to change how it is presented.
The first job was to reconstruct the WordPress environment locally. A redesign is much easier to assess when the old projects and articles are present, but a page that looks similar is only part of the problem. Its identity, metadata, media and relationships also need to survive.
Keeping the content attached to itself
The local import starts with the WordPress export rather than a collection of public page responses. It preserves explicit record IDs, repeated metadata and the connector records that associate technical writing with projects. Attachment paths are handled alongside the content so the local site can use its downloaded media.
Those details affect ordinary navigation. A project can have several source links and several related articles. Repeated metadata must remain repeated, and an article connection must still point to the intended record after import. Treating either as a single convenient field would quietly change the site.
The import and verification code therefore check the reconstructed data as well as the rendered pages. Repeating an import is part of the workflow too; rebuilding the environment should not create a second set of projects or connector records.
A local site that can be rebuilt
The development wrapper brings together WordPress, WP-CLI, cached dependencies, media preparation and verification. After the required downloads are available, a fresh environment can be bootstrapped offline. Local support code supplies the registrations and settings needed by the exported content and limits background network, mail and scheduling side effects.
A clean offline bootstrap and repeated-import check passed with 65 content records, 266 metadata rows, 279 media files and all six exported project relationships. HTTP checks also covered 35 responses and 137 local assets. These checks establish a useful reconstruction baseline; visual behavior and interaction need separate browser review.
Changing the presentation without losing the baseline
The original theme archive is retained alongside the current work. The theme’s WordPress, Underscores and bundled frontend-library origins remain part of its source credits. This gives the redesign a reference point instead of allowing the latest implementation to erase what came before.
The updated project presentation handles source links, related writing and related projects through shared code. Archives and other pages use common presentation facilities as well. That keeps repeated site behavior together while allowing each project body to explain its own work.
The linked posts from 2016 describe the earlier theme and project-page work. The reconstruction is a later development: preserving the content model, making local rebuilding repeatable and giving the portfolio a presentation that can continue to change.


