Entwickler Journal is a specialist platform covering software development, architecture, DevOps, security and modern developer tooling. The earlier site ran on WordPress; today it runs on a bespoke, server-rendered PHP application built around Markdown.
The starting situation
The WordPress site served its original purpose well. As the platform grew, however, so did the demands on the content model: articles, series, projects, translations, categories, media with traceable provenance and SEO metadata all needed to be structured cleanly and connected to one another.
At the same time the platform was to stay lean — without a conventional CMS database and without extensive plugin dependencies.
The question was therefore not how WordPress might be adapted further, but which architecture would suit the platform better in the long run.
The goal
The new solution had to bring several requirements together:
- server-side rendering
- structured content that can be version-controlled
- publishing in both German and English
- a clear separation between application and content
- technical SEO as part of the architecture
- room for new content types
- traceable media provenance
- little technical overhead and good maintainability
The aim was not to rebuild a general-purpose CMS. The architecture was to contain exactly the functionality Entwickler Journal actually needs.
The architectural decision
The platform was built as a bespoke PHP application. Content lives not in a CMS database but as Markdown documents with structured YAML front matter. Editorial content and source code can therefore be version-controlled, validated and deployed together.
The application handles routing, content resolution, rendering, translation relationships, media, SEO metadata, sitemaps and feeds, structured data, navigation and internal relationships.
The frontend is delivered server-side. JavaScript adds functionality only where client-side interaction is genuinely required.
The publishing and content model
The architecture is organised around structured content types rather than pages in the conventional CMS sense. Articles, series and projects carry defined metadata, which makes them straightforward to evaluate and to connect with one another.
Markdown carries the editorial content. The front matter describes the title, publication date, language, categories, translation relationships and media. The content model therefore stays comprehensible both for editorial work and for the application.
Series are a content type in their own right rather than a filtered list of blog posts: related articles are held as a collection, with their own overview and their own ordering.
Two languages as part of the content model
German and English are not independent copies of one another. Related content is connected through shared translation keys.
The application can therefore recognise which translations exist, point the language switcher at the actual counterpart, generate hreflang relationships and language-specific sitemap entries — and handle missing translations deliberately rather than quietly.
The English version is part of the same publishing architecture, not a parallel site bolted on afterwards.
SEO and discovery
Technical SEO was built into the architecture rather than added once the site was finished: canonical URLs, hreflang, Open Graph, X Cards, structured data, breadcrumbs, a sitemap index and language-specific sitemaps, RSS feeds, semantic HTML and genuine 404 pages.
The metadata comes out of the same content model as the visible content, so editorial information is not maintained separately in several places.
Media with traceable provenance
For editorial media the system stores more than the file itself. It distinguishes between original material, AI-generated media and AI-modified media.
Depending on the content, that provenance can be shown to readers or evaluated technically. It becomes part of the publishing model rather than a footnote added later.
Quality assurance
The architecture is checked automatically. Tests and validators cover content structures, routing, translation relationships, internal links, SEO metadata, sitemaps, feeds, media references, templates and rendering.
Content and application are therefore verified together — a broken reference surfaces during the build rather than in production.
The outcome
A conventional WordPress site became a publishing platform of its own, with an architecture shaped around what Entwickler Journal actually requires. It brings publishing, two languages, SEO, media, projects, series and technical content together in a single system.
The project also illustrates a principle of web development at EicDevCon: an existing platform is not replaced simply because a custom build would be technically possible. A bespoke solution is worth it when it offers a demonstrable advantage for the requirements, the operation and the work that follows.
Technical overview
Backend – PHP, custom routing, content repository, translation repository Content – Markdown, YAML front matter, structured content types Frontend – server-side rendering, HTML, CSS, vanilla JavaScript Publishing – articles, series, projects, categories, translations Discovery – canonical, hreflang, JSON-LD, sitemap, RSS, Open Graph Quality – content validation, automated tests, responsive review
