Using Codex to Rebuild My Blog and Import 15+ Years of Blogger Posts Source

March 28, 2026 Markdown source

1---
2title: "Using Codex to Rebuild My Blog and Import 15+ Years of Blogger Posts"
3date: "2026-03-28"
4published: true
5tags: ["codex", "ai", "blog", "php", "markdown", "docker", "automation"]
6author: "Gavin Jackson"
7excerpt: "How I used Codex to rebuild gavinj.net as a lightweight PHP and Markdown blog, import years of old Blogger posts, and help with both development and deployment."
8---
9
10# Using Codex to Rebuild My Blog and Import 15+ Years of Blogger Posts
11
12Over the last few weeks I used Codex to help me rebuild **gavinj.net** from scratch.
13
14The goal was not to create a giant CMS or a complicated devops pipeline. I wanted something much simpler: a fast, lightweight blog that I could understand end to end, host cheaply, edit easily, and keep under my own control.
15
16I also wanted to bring across a large archive of old Blogger posts without turning the migration into a months-long cleanup project.
17
18Codex ([https://openai.com/codex/](https://openai.com/codex/)) turned out to be very good at exactly this kind of work.
19
20## What I Wanted
21
22My requirements were pretty straightforward:
23
24- no database
25- no heavy framework
26- content stored as plain files
27- local development that was easy to run and easy to throw away
28- a design that felt clean and personal rather than looking like a default theme
29- a practical migration path from Blogger into the new structure
30
31That led to a simple architecture:
32
33- PHP for rendering
34- Markdown files with YAML frontmatter for content
35- a `posts/` directory as the source of truth
36- Docker Compose for local testing
37- a minimal production deployment on Apache with PHP
38
39None of those choices are exotic, and that was the point. I wanted boring, understandable technology.
40
41## Why Codex Worked Well
42
43What impressed me most was not that Codex could generate code. Plenty of tools can do that now.
44
45What mattered was that it worked well as a collaborator across the whole lifecycle:
46
47- helping scaffold the initial PHP blog engine
48- refining the layout and visual style over multiple iterations
49- adding features like RSS, tags, source viewing, and draft support
50- writing migration scripts for the old Blogger archive
51- helping reason through local dev and deployment setup
52- handling small but annoying infrastructure details that usually slow projects down
53
54That combination is where tools like this become genuinely useful.
55
56## Building the New Blog
57
58The first step was creating a minimal blog engine instead of dropping in WordPress or another full CMS.
59
60Codex helped build a simple PHP application that:
61
62- scans the `posts/` directory for Markdown files
63- parses YAML frontmatter
64- renders posts into HTML
65- builds the homepage, post pages, RSS feed, and tag views
66- keeps everything file-based and easy to inspect
67
68Using Markdown for articles was one of the best choices in the whole rebuild. It means the content is portable, easy to diff in Git, and pleasant to edit without needing a browser-based admin interface.
69
70Each post is just a file with metadata at the top:
71
72```markdown
73---
74title: "Example title"
75date: "2026-03-28"
76tags: ["php", "markdown"]
77author: "Gavin Jackson"
78excerpt: "Short summary for listings."
79---
80```
81
82That gives me a format that is simple enough to maintain manually, but structured enough to support tagging, excerpts, draft handling, and publication dates.
83
84## Iterating on the Design Together
85
86The design did not appear fully formed in one shot.
87
88This was much more of a back-and-forth process, which is exactly how real development usually works. We started with a clean dark layout, then kept refining it:
89
90- spacing
91- typography
92- post cards
93- navigation
94- accent colors
95- mobile behaviour
96- the tag cloud
97- source view rendering
98- the resume page
99
100This was one of the more useful patterns with Codex. I could say things like "this feels too generic", "move that into the sidebar", or "make the hover accent match the site branding", and then iterate quickly from there.
101
102It felt less like using a code generator and more like pairing with someone who can make changes quickly once the direction is clear.
103
104## Importing the Old Blogger Archive
105
106The second major problem was content migration.
107
108I have a lot of old posts going back many years, and I did not want to manually copy and paste them into the new system. Codex helped create an import script that pulled entries from the Blogger Atom feed and turned them into local post files.
109
110The first pass imported legacy posts with frontmatter and preserved the original HTML body. That was a smart intermediate step because it got the archive into the new framework quickly without blocking on perfect conversion.
111
112From there, I could progressively improve the content instead of trying to solve everything up front.
113
114The import process included things like:
115
116- extracting titles and publication dates
117- generating slugs
118- capturing categories as tags
119- storing original publication timestamps
120- preserving legacy URLs
121- generating excerpts automatically
122
123That meant the old archive became part of the new site structure almost immediately.
124
125## Converting Old HTML to Markdown
126
127Once the import was done, the next step was improving the archive quality.
128
129A lot of older Blogger posts were HTML-heavy, which is normal for content that has lived through multiple platforms and editors. Codex helped write a second migration script to convert those imported HTML posts into cleaner Markdown.
130
131That script handled:
132
133- headings
134- paragraphs
135- lists
136- links
137- blockquotes
138- inline code and code blocks
139- embedded images
140- special handling for old monospace code spans
141
142It also materialised image assets into the local repository so the new site was no longer dependent on external hosted content for every imported image.
143
144That was a good example of where AI assistance saved real time. Writing and refining HTML-to-Markdown conversion logic is fiddly work. It is not impossible, but it is exactly the kind of task where having a fast coding partner is valuable.
145
146## Local Development with Docker Compose
147
148I wanted local testing to be easy and disposable, so we added a local `docker-compose.yml` setup with `nginx` and `php-fpm`.
149
150That gave me a repeatable dev environment that I could start with:
151
152```bash
153docker compose up --build
154```
155
156The setup also included:
157
158- a custom PHP image
159- Composer installed in the container
160- automatic dependency installation on first start
161- bind mounts for live editing
162- a named volume for `vendor/` so dependencies persisted across restarts
163
164That is exactly the kind of practical quality-of-life improvement I appreciate. It meant I could work on the site without having to remember local PHP versions, install steps, or one-off machine setup.
165
166## Deployment Help Matters Too
167
168One thing I want to emphasize is that Codex was not only useful for writing the application.
169
170It was also helpful in the deployment phase.
171
172Once the site itself was in good shape, I still needed to get it running properly in production. That included things like:
173
174- Apache virtual host configuration
175- rewrite rules
176- PHP module setup
177- checking the right pieces were enabled
178- getting Let's Encrypt SSL certificates in place
179- generally closing the loop from "works on my machine" to "actually live"
180
181That part is often underappreciated when people talk about AI coding tools. Real projects do not stop at code generation. There is always a layer of server configuration, packaging, permissions, services, and certificates that has to be sorted out before a site is genuinely done.
182
183Having help there was just as valuable as having help with the PHP and CSS.
184
185## What I Still Liked About Being in Control
186
187Using Codex did not mean handing the project over and hoping for the best.
188
189I still made the architectural choices. I still reviewed the code, decided what to keep, adjusted the content, and steered the design. The value came from compressing the implementation and iteration time, not from removing human judgment.
190
191That is probably the best way to think about tools like this.
192
193They are strongest when:
194
195- you know roughly what you want
196- you can review the output
197- you are willing to iterate
198- you want to move faster through the boring or fiddly parts
199
200For me, that was exactly the situation here.
201
202## The Result
203
204The end result is a blog that feels much closer to what I wanted all along:
205
206- lightweight
207- easy to host
208- Git-friendly
209- based on plain files
210- easy to extend
211- easier to maintain than my old setup
212- capable of carrying both new writing and old archive content
213
214Just as importantly, the process was enjoyable.
215
216Instead of getting bogged down in boilerplate, migration drudgery, or deployment trivia, I could keep making decisions and moving forward. Codex handled a lot of the implementation load, but still left me in control of the final shape of the site.
217
218That is the part I think people sometimes miss. The best use of tools like this is not pressing a button and walking away.
219
220It is collaborating with them to get better results faster.
221
222And for this rebuild, that worked remarkably well.
223

---
title: "Using Codex to Rebuild My Blog and Import 15+ Years of Blogger Posts"
date: "2026-03-28"
published: true
tags: ["codex", "ai", "blog", "php", "markdown", "docker", "automation"]
author: "Gavin Jackson"
excerpt: "How I used Codex to rebuild gavinj.net as a lightweight PHP and Markdown blog, import years of old Blogger posts, and help with both development and deployment."
---

# Using Codex to Rebuild My Blog and Import 15+ Years of Blogger Posts

Over the last few weeks I used Codex to help me rebuild **gavinj.net** from scratch.

The goal was not to create a giant CMS or a complicated devops pipeline. I wanted something much simpler: a fast, lightweight blog that I could understand end to end, host cheaply, edit easily, and keep under my own control.

I also wanted to bring across a large archive of old Blogger posts without turning the migration into a months-long cleanup project.

Codex ([https://openai.com/codex/](https://openai.com/codex/)) turned out to be very good at exactly this kind of work.

## What I Wanted

My requirements were pretty straightforward:

- no database
- no heavy framework
- content stored as plain files
- local development that was easy to run and easy to throw away
- a design that felt clean and personal rather than looking like a default theme
- a practical migration path from Blogger into the new structure

That led to a simple architecture:

- PHP for rendering
- Markdown files with YAML frontmatter for content
- a `posts/` directory as the source of truth
- Docker Compose for local testing
- a minimal production deployment on Apache with PHP

None of those choices are exotic, and that was the point. I wanted boring, understandable technology.

## Why Codex Worked Well

What impressed me most was not that Codex could generate code. Plenty of tools can do that now.

What mattered was that it worked well as a collaborator across the whole lifecycle:

- helping scaffold the initial PHP blog engine
- refining the layout and visual style over multiple iterations
- adding features like RSS, tags, source viewing, and draft support
- writing migration scripts for the old Blogger archive
- helping reason through local dev and deployment setup
- handling small but annoying infrastructure details that usually slow projects down

That combination is where tools like this become genuinely useful.

## Building the New Blog

The first step was creating a minimal blog engine instead of dropping in WordPress or another full CMS.

Codex helped build a simple PHP application that:

- scans the `posts/` directory for Markdown files
- parses YAML frontmatter
- renders posts into HTML
- builds the homepage, post pages, RSS feed, and tag views
- keeps everything file-based and easy to inspect

Using Markdown for articles was one of the best choices in the whole rebuild. It means the content is portable, easy to diff in Git, and pleasant to edit without needing a browser-based admin interface.

Each post is just a file with metadata at the top:

```markdown
---
title: "Example title"
date: "2026-03-28"
tags: ["php", "markdown"]
author: "Gavin Jackson"
excerpt: "Short summary for listings."
---
```

That gives me a format that is simple enough to maintain manually, but structured enough to support tagging, excerpts, draft handling, and publication dates.

## Iterating on the Design Together

The design did not appear fully formed in one shot.

This was much more of a back-and-forth process, which is exactly how real development usually works. We started with a clean dark layout, then kept refining it:

- spacing
- typography
- post cards
- navigation
- accent colors
- mobile behaviour
- the tag cloud
- source view rendering
- the resume page

This was one of the more useful patterns with Codex. I could say things like "this feels too generic", "move that into the sidebar", or "make the hover accent match the site branding", and then iterate quickly from there.

It felt less like using a code generator and more like pairing with someone who can make changes quickly once the direction is clear.

## Importing the Old Blogger Archive

The second major problem was content migration.

I have a lot of old posts going back many years, and I did not want to manually copy and paste them into the new system. Codex helped create an import script that pulled entries from the Blogger Atom feed and turned them into local post files.

The first pass imported legacy posts with frontmatter and preserved the original HTML body. That was a smart intermediate step because it got the archive into the new framework quickly without blocking on perfect conversion.

From there, I could progressively improve the content instead of trying to solve everything up front.

The import process included things like:

- extracting titles and publication dates
- generating slugs
- capturing categories as tags
- storing original publication timestamps
- preserving legacy URLs
- generating excerpts automatically

That meant the old archive became part of the new site structure almost immediately.

## Converting Old HTML to Markdown

Once the import was done, the next step was improving the archive quality.

A lot of older Blogger posts were HTML-heavy, which is normal for content that has lived through multiple platforms and editors. Codex helped write a second migration script to convert those imported HTML posts into cleaner Markdown.

That script handled:

- headings
- paragraphs
- lists
- links
- blockquotes
- inline code and code blocks
- embedded images
- special handling for old monospace code spans

It also materialised image assets into the local repository so the new site was no longer dependent on external hosted content for every imported image.

That was a good example of where AI assistance saved real time. Writing and refining HTML-to-Markdown conversion logic is fiddly work. It is not impossible, but it is exactly the kind of task where having a fast coding partner is valuable.

## Local Development with Docker Compose

I wanted local testing to be easy and disposable, so we added a local `docker-compose.yml` setup with `nginx` and `php-fpm`.

That gave me a repeatable dev environment that I could start with:

```bash
docker compose up --build
```

The setup also included:

- a custom PHP image
- Composer installed in the container
- automatic dependency installation on first start
- bind mounts for live editing
- a named volume for `vendor/` so dependencies persisted across restarts

That is exactly the kind of practical quality-of-life improvement I appreciate. It meant I could work on the site without having to remember local PHP versions, install steps, or one-off machine setup.

## Deployment Help Matters Too

One thing I want to emphasize is that Codex was not only useful for writing the application.

It was also helpful in the deployment phase.

Once the site itself was in good shape, I still needed to get it running properly in production. That included things like:

- Apache virtual host configuration
- rewrite rules
- PHP module setup
- checking the right pieces were enabled
- getting Let's Encrypt SSL certificates in place
- generally closing the loop from "works on my machine" to "actually live"

That part is often underappreciated when people talk about AI coding tools. Real projects do not stop at code generation. There is always a layer of server configuration, packaging, permissions, services, and certificates that has to be sorted out before a site is genuinely done.

Having help there was just as valuable as having help with the PHP and CSS.

## What I Still Liked About Being in Control

Using Codex did not mean handing the project over and hoping for the best.

I still made the architectural choices. I still reviewed the code, decided what to keep, adjusted the content, and steered the design. The value came from compressing the implementation and iteration time, not from removing human judgment.

That is probably the best way to think about tools like this.

They are strongest when:

- you know roughly what you want
- you can review the output
- you are willing to iterate
- you want to move faster through the boring or fiddly parts

For me, that was exactly the situation here.

## The Result

The end result is a blog that feels much closer to what I wanted all along:

- lightweight
- easy to host
- Git-friendly
- based on plain files
- easy to extend
- easier to maintain than my old setup
- capable of carrying both new writing and old archive content

Just as importantly, the process was enjoyable.

Instead of getting bogged down in boilerplate, migration drudgery, or deployment trivia, I could keep making decisions and moving forward. Codex handled a lot of the implementation load, but still left me in control of the final shape of the site.

That is the part I think people sometimes miss. The best use of tools like this is not pressing a button and walking away.

It is collaborating with them to get better results faster.

And for this rebuild, that worked remarkably well.