WordPress: Publish the Post, Reuse the Page

Adding an entry to a hand-maintained weblog can involve writing the same event into several places. The front page needs it. An archive needs it. A permanent link needs a destination. The list of recent entries needs another line. The author has finished a paragraph and acquired a small clerical position.

WordPress helped turn that repetition into a publishing system. Store the post as content, describe the page with a reusable template, and let the software assemble the current view. Writing and page construction remain related without requiring the author to perform every construction step manually.

Matt Mullenweg announced the first release on May 27, 2003. The launch post listed a revised administration interface, default templates, link management, manual excerpts and text-formatting improvements. It described a free GPL-licensed application.¹

The consequential beginning was modest enough to inspect. Today’s plugin marketplace, theme conventions and block editor should not be allowed to crowd into a 2003 window simply because the name above the window remained WordPress.

A continuation with identifiable contributors

WordPress began from b2/cafelog. The project’s history identifies Mullenweg and Mike Little as its founders, while the preserved early readme credits the b2 foundation. The earlier developer’s work belongs in the lineage rather than disappearing at the fork.²³

A fork takes existing code in a new development direction. It can preserve a useful application when its future has become uncertain, but it also takes on maintenance, releases, documentation and the expectations of users. Copying the source is the easy part of accepting that responsibility.

The early application used PHP and MySQL. Its preserved 0.71 readme specifies versions in the PHP 4 and MySQL 3 generations. That anchors the deployment model in a web server executing scripts and querying a database, rather than a modern hosted editing application appearing by magic.³

A person installing it needed a suitable environment and configuration. A person writing with it could then use a publishing interface instead of maintaining each public page by hand. The installation work and the writing work occurred at different layers.

This distinction matters to the word easy. A tool can make recurring publishing easier while leaving a substantial first setup. The useful question is which work it removes and which work it requires someone to do once.

The request chooses the view

A publishing system receives a request and decides which content it should show. A front page might request recent posts. An archive might request entries from one month. A permanent link might request a particular post.

The records can support all three. Instead of keeping three independently edited copies of a paragraph, the system can retrieve the same stored content under different selection rules.

The early source archive makes this concrete. In the preserved 0.71 files, blog.header.php constructs a database request, and index.php iterates through posts while calling functions for titles, content and other presentation elements.³

That archive is useful evidence with a qualification: it is a preserved 0.71 package, not a verified byte-for-byte copy of the May 27 first release. The official archive’s displayed date for the package is inconsistent with the early version history. I use its contents to explain the early implementation family, without assigning that display date as its original launch.

The architecture nevertheless has a clear division. Selection determines the records. The template determines how the records become output. Changing one decision doesn’t require rewriting every stored post.

Original CC0 teaching diagram, 2026, informed by the preserved early source. It is not an administration screenshot or an exact copy of a release’s data structures.

Three posts and two public results

Invent a weblog containing these records:

ID	Date	Status	Title
10	2003-05-25	publish	The new printer
11	2003-05-26	draft	Why it won’t print
12	2003-05-27	publish	A working cable

For a simplified public front page, request published posts ordered by date from newest to oldest. The result contains ID 12 followed by ID 10. The draft remains stored but doesn’t appear in that public selection.

Here is original teaching SQL using an invented schema:

SELECT id, title
FROM posts
WHERE status = 'publish'
ORDER BY posted DESC;

The query is intentionally short. The early implementation had additional conditions and contexts, including special treatment for logged-in authors. Our example explains selection for one public view rather than reproducing its full query builder.

Now apply a template to each returned record. Conceptually, each becomes a heading followed by its content and a link to its own page. The template is a repeated arrangement; the text comes from each record.

If the heading markup changes from one chosen style to another, both published posts can acquire the new presentation without changing their titles. We have moved a recurring decision to one place where the site author can maintain it.

The model was checked with SQLite through modern Python. WordPress used MySQL, so the execution is a check of our invented records and ordering, not evidence that this exact teaching query was run by WordPress in 2003.

Notice the draft’s importance. It isn’t a missing record. It has a stored status that affects a particular view. A database-backed publisher must distinguish whether content exists from whether a given visitor should receive it.

A title is data until it reaches HTML

The template also sits at a language boundary. A title stored as text must be placed into an HTML document. Some characters have special meanings there.

Suppose an invented title is Cables & <Adapters>. A general plain-text renderer needs to encode the ampersand and angle brackets when inserting the title as text. Otherwise the browser may treat part of the title as markup.

An escaped teaching output is:

<h2>Cables &amp; &lt;Adapters&gt;</h2>

The browser can display the intended characters while keeping them inside text. Encoding preserves their meaning across a change of language context.

This is a general rendering example, not an audit finding about the preserved WordPress release. The exact handling of titles, rich post content and other fields can differ. Content intentionally containing permitted HTML needs a different policy from a title meant to remain plain text.

That is why a publisher can’t safely treat every stored string identically. A URL, a paragraph with permitted markup, and a plain title arrive at different destinations. The software needs an appropriate transformation for each context.

Separating content from presentation makes those transformations maintainable. It also concentrates responsibility in code that deserves careful review. One reused rendering mistake can be very consistent across an entire site.

The excerpt has a different job from the article

The first release advertised manually written excerpts. That matters because a summary is an editorial object in its own right. Cutting the first few words from a post doesn’t always produce a useful description.¹

Imagine our cable post begins with a long complaint about the printer. The complete piece eventually explains that the connector was wrong. A manually written summary can tell a feed reader what the post contains without preserving the opening’s entire performance.

The stored post and its excerpt can serve different views. One page displays full content. A listing or feed can display the summary. The system doesn’t have to assume that every destination should show the same amount of text.

Original CC0 teaching diagram, 2026. General publishing views with an invented post; no claim that every depicted layout was a first-release default.

A feed is another representation. It lets software receive entries in a structured format rather than interpreting the visual page as if it were a reader. The launch mention of excerpts in RSS, and the early template’s feed links, make that part of the period publishing arrangement.¹³

This brings maintenance consequences. Correcting a stored post can affect several representations, but caches and consuming applications may retain older copies. One authoritative record helps avoid manual divergence; it doesn’t force every external reader to refresh immediately.

Links were part of the publication

WordPress’s launch included a link manager for blogrolls. A weblog was often a publication that pointed outward as well as publishing inward. Maintaining those links through records and display choices made them part of the software’s routine work.¹

That is a useful period detail because it shifts attention away from today’s assumption that a publishing application is primarily an editor. The early package also maintained the surrounding network of references, feeds and responses.

The software reduced repeated arrangement. It didn’t decide which links were worth recommending or which comments deserved attention. Those remain editorial choices, even when the interface gives them fields and buttons.

A publishing tool therefore accumulates two kinds of burden. It has to render content correctly, and it has to provide enough control for people to keep the publication coherent. Better mechanics make the recurring work possible; they don’t make the editorial work disappear.

The familiar extension system came later

The May 2004 WordPress 1.2 announcement introduced a new plugin architecture. The February 2005 1.5 announcement described a more flexible theme system and a pages feature for content beyond ordinary blog entries.⁴⁵

Those are consequential developments, but they are later developments. The first release already had templates without having the same theme organization later users would recognize. A template and a mature theme system shouldn’t be treated as synonymous historical features.

Likewise, the open-source license made inspection and modification possible, but it didn’t automatically supply a maintained extension ecosystem. Interfaces, documentation and a community of contributors had to develop around the application.

The version boundaries give the beginning its own shape. WordPress 0.7 was a specific improvement to an existing publishing lineage, followed by further architectural changes. Its importance is clearer when the first release is permitted to have less in it.

Repetition becomes a software responsibility

The original query example shows how a database separates stored content from a chosen public view. The template example shows how one presentation decision can apply repeatedly. The excerpt shows why different outputs can need different editorial material.

Together, those mechanisms let a writer concentrate more of the recurring effort on the next entry. Archives, headings and feed representations become tasks the system can carry out according to rules.

That is a substantial change without requiring any claim that blogging began with WordPress. It inherited an existing practice and codebase, then offered an inspectable, extensible route for continuing them.

A publishing application cannot supply something worth saying. It can prevent an author from having to say it separately in five files. There is already enough repetition on the web without requiring it in the maintenance procedure.

Sources

Footnotes

1. Matt Mullenweg, WordPress Now Available, May 27, 2003. First release and period features. ↩ ↩² ↩³ ↩⁴

2. WordPress project, About WordPress, retrospective contributor and fork chronology. ↩

3. WordPress, official archive and 0.71-gold package, inspected readme.html, index.php and blog.header.php. Preserved early code; archive display date not adopted as original release date. Package remains outside the delivered vault. ↩ ↩² ↩³ ↩⁴

4. Mullenweg, WordPress 1.2, May 22, 2004, new plugin architecture. ↩

5. Mullenweg, WordPress 1.5 announcement, February 17, 2005, notes February 14 soft launch; themes and pages belong to this later milestone. ↩